From report at bugs.python.org  Fri Jun  1 01:36:07 2012
From: report at bugs.python.org (Michael Foord)
Date: Thu, 31 May 2012 23:36:07 +0000
Subject: [docs] [issue14971] (unittest) loadTestsFromName does not work on
	method	with a decorator
In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za>
Message-ID: <1338507367.89.0.969625389225.issue14971@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Whilst functools.wraps would fix the problem it still sounds like a bug (or at the very least a reasonable feature request).

----------

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

From report at bugs.python.org  Fri Jun  1 04:43:09 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Jun 2012 02:43:09 +0000
Subject: [docs] [issue14957] Improve docs for str.splitlines
In-Reply-To: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za>
Message-ID: <1338518589.63.0.462076342939.issue14957@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch

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

From report at bugs.python.org  Fri Jun  1 04:54:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Jun 2012 02:54:54 +0000
Subject: [docs] [issue14968] Section "Inplace Operators" of :mod:`operator`
	should be	a subsection
In-Reply-To: <1338467566.04.0.840263099985.issue14968@psf.upfronthosting.co.za>
Message-ID: <1338519294.76.0.168361446341.issue14968@psf.upfronthosting.co.za>


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

Good catch, +1 for the patch.

----------
nosy: +eric.araujo, sandro.tosi
stage:  -> commit review
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jun  1 10:23:47 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 01 Jun 2012 08:23:47 +0000
Subject: [docs] [issue9544] xdrlib.Packer().pack_fstring throws a TypeError
	when	called with a str()
In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za>
Message-ID: <1338539027.07.0.347159908246.issue9544@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Fri Jun  1 10:26:11 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 01 Jun 2012 08:26:11 +0000
Subject: [docs] [issue12354] packaging.pypi.simple docs use both client and
	crawler	variable, which might be confusing
In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za>
Message-ID: <1338539171.12.0.524370118219.issue12354@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Can this be closed?

----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Fri Jun  1 10:59:35 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 01 Jun 2012 08:59:35 +0000
Subject: [docs] [issue12354] packaging.pypi.simple docs use both client and
	crawler	variable, which might be confusing
In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za>
Message-ID: <1338541175.31.0.0351310265555.issue12354@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
status: open -> pending

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

From report at bugs.python.org  Fri Jun  1 15:03:26 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 01 Jun 2012 13:03:26 +0000
Subject: [docs] [issue14979] pdb: Link to source
Message-ID: <1338555806.37.0.54245715922.issue14979@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/pdb.html#pdb.Pdb

Documentation for pdb says: "The debugger is extensible ? it is actually defined as the class Pdb. This is currently undocumented but easily understood by reading the source."

There should a link to the source.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 162074
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: pdb: Link to source

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

From report at bugs.python.org  Fri Jun  1 17:41:57 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 01 Jun 2012 15:41:57 +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: <1338565317.25.0.015015476832.issue11796@psf.upfronthosting.co.za>


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


----------
nosy: +anikom15, flox, josmiley

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

From report at bugs.python.org  Fri Jun  1 20:03:51 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Jun 2012 18:03:51 +0000
Subject: [docs] [issue14979] pdb doc: Add link to source
In-Reply-To: <1338555806.37.0.54245715922.issue14979@psf.upfronthosting.co.za>
Message-ID: <1338573831.41.0.462117817423.issue14979@psf.upfronthosting.co.za>


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

Sounds good to me.  Raymond, do you concur?

----------
nosy: +eric.araujo, rhettinger
title: pdb: Link to source -> pdb doc: Add link to source
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jun  1 20:08:34 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Jun 2012 18:08:34 +0000
Subject: [docs] [issue12354] packaging.pypi.simple docs use both client and
	crawler	name, which might be confusing
In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za>
Message-ID: <1338574114.78.0.374893263632.issue12354@psf.upfronthosting.co.za>


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

Not yet; the commit was adding missing doc to the Crawler class, but I haven?t reviewed the use of client vs. crawler yet.

Alexis, you introduced the client/crawler naming after reading some book; what do you think now?

----------
status: pending -> open
title: packaging.pypi.simple docs use both client and crawler variable, which might be confusing -> packaging.pypi.simple docs use both client and crawler name, which might be confusing

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

From report at bugs.python.org  Fri Jun  1 20:26:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jun 2012 18:26:32 +0000
Subject: [docs] [issue14968] Section "Inplace Operators" of :mod:`operator`
	should be	a subsection
In-Reply-To: <1338467566.04.0.840263099985.issue14968@psf.upfronthosting.co.za>
Message-ID: <E1SaWYQ-0001ih-JF@dinsdale.python.org>


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

New changeset bf6305bce3af by Sandro Tosi in branch '3.2':
Issue #14968: set 'Inplace Operators' as subsection; patch by Lars Buitinck
http://hg.python.org/cpython/rev/bf6305bce3af

New changeset 7c9702b08bfb by Sandro Tosi in branch 'default':
Issue #14968: merge with 3.2
http://hg.python.org/cpython/rev/7c9702b08bfb

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

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

From report at bugs.python.org  Fri Jun  1 20:27:57 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 01 Jun 2012 18:27:57 +0000
Subject: [docs] [issue14968] Section "Inplace Operators" of :mod:`operator`
	should be	a subsection
In-Reply-To: <1338467566.04.0.840263099985.issue14968@psf.upfronthosting.co.za>
Message-ID: <1338575277.3.0.872995460639.issue14968@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks Lars for the patch! ?ric, why did you add 2.7 version? AFAISee 2.7 doesn't have the "Inplace Operators" section.

----------

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

From report at bugs.python.org  Fri Jun  1 21:56:26 2012
From: report at bugs.python.org (Michael Driscoll)
Date: Fri, 01 Jun 2012 19:56:26 +0000
Subject: [docs] [issue14957] Improve docs for str.splitlines
In-Reply-To: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za>
Message-ID: <1338580586.5.0.15321258184.issue14957@psf.upfronthosting.co.za>


Michael Driscoll <mike at pythonlibrary.org> added the comment:

I'm assuming Nick is talking about the stdtypes.rst (in Doc/library) file, correct? If so, I went ahead and created a simple patch that almost uses his verbiage verbatim.

----------
keywords: +patch
nosy: +michael.driscoll
Added file: http://bugs.python.org/file25791/stdtypes.patch

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

From report at bugs.python.org  Fri Jun  1 22:21:24 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Jun 2012 20:21:24 +0000
Subject: [docs] [issue14957] Improve docs for str.splitlines
In-Reply-To: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za>
Message-ID: <E1SaYLa-0004H6-P4@dinsdale.python.org>


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

New changeset 24572015e24f by R David Murray in branch '3.2':
#14957: clarify splitlines docs.
http://hg.python.org/cpython/rev/24572015e24f

New changeset 2a43088318ed by R David Murray in branch 'default':
#14957: clarify splitlines docs.
http://hg.python.org/cpython/rev/2a43088318ed

New changeset 0df7594e4ebd by R David Murray in branch '2.7':
#14957: clarify splitlines docs.
http://hg.python.org/cpython/rev/0df7594e4ebd

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

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

From report at bugs.python.org  Fri Jun  1 22:22:29 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Jun 2012 20:22:29 +0000
Subject: [docs] [issue14957] Improve docs for str.splitlines
In-Reply-To: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za>
Message-ID: <1338582149.34.0.120556170629.issue14957@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.  I added an example, too, since split has some.

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

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

From report at bugs.python.org  Sat Jun  2 17:21:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Jun 2012 15:21:49 +0000
Subject: [docs] [issue14957] Improve docs for str.splitlines
In-Reply-To: <1338330890.64.0.0644445250227.issue14957@psf.upfronthosting.co.za>
Message-ID: <E1Saq9D-00079I-RX@dinsdale.python.org>


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

New changeset 4d9b3a58e208 by R David Murray in branch '3.2':
#14957: fix doc typo.
http://hg.python.org/cpython/rev/4d9b3a58e208

New changeset 3bb35ad5d9da by R David Murray in branch 'default':
#14957: fix doc typo.
http://hg.python.org/cpython/rev/3bb35ad5d9da

New changeset 48564362b687 by R David Murray in branch '2.7':
#14957: fix doc typo.
http://hg.python.org/cpython/rev/48564362b687

----------

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

From report at bugs.python.org  Sat Jun  2 20:42:44 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Sat, 02 Jun 2012 18:42:44 +0000
Subject: [docs] [issue14901] Python Windows FAQ is Very Outdated
In-Reply-To: <1337873167.77.0.855144378298.issue14901@psf.upfronthosting.co.za>
Message-ID: <1338662564.02.0.558823318101.issue14901@psf.upfronthosting.co.za>


Daniel Swanson <popcorn.tomato.dude at gmail.com> added the comment:

>>> 1a) Update all Windows references to Windows 7 or Vista/7. We can include XP, but I think Microsoft is dropping support next year.

According to wikipedia Windows XP is the second most popular operating system, probably better not to drop it all together. http://en.wikipedia.org/wiki/Usage_share_of_operating_systems

Of course there are people who have 5 or 6 computers and use the same windows disk on all of them which might skew the data.

----------

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

From report at bugs.python.org  Sat Jun  2 23:06:02 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Jun 2012 21:06:02 +0000
Subject: [docs] [issue14971] (unittest) loadTestsFromName does not work on
	method	with a decorator
In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za>
Message-ID: <1338671162.04.0.423731053206.issue14971@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's a patch.

----------
components: +Library (Lib) -Documentation
keywords: +patch
Added file: http://bugs.python.org/file25803/unittest_method_name_difference.patch

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

From sandro.tosi at gmail.com  Sat Jun  2 23:43:46 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 2 Jun 2012 23:43:46 +0200
Subject: [docs] Glossary mistake
In-Reply-To: <CAAx7R0R+XBXbOoMBV8Rrb2uCX+OYgUBMg0bEBoLPGpQor=A8rw@mail.gmail.com>
References: <CAAx7R0R+XBXbOoMBV8Rrb2uCX+OYgUBMg0bEBoLPGpQor=A8rw@mail.gmail.com>
Message-ID: <CAB4XWXymaH_Nh8x7Dstb2np=pOuX273RALNk377VQqPWmULQig@mail.gmail.com>

Hello Gaston,
thanks for your email

On Thu, May 31, 2012 at 10:31 PM, Gaston Fiore <gaston.fiore at gmail.com> wrote:
> In the glossary, in the definition of "file object", there's an extra
> word "other" in the second sentence of the definition. It currently
> reads:

This was already fixed in the on-work 3.3 branch, and how i've
backported the fix to 2.7 and 3.2 too,

Regards,
-- 
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  Sun Jun  3 05:48:02 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Jun 2012 03:48:02 +0000
Subject: [docs] [issue14424] document PyType_GenericAlloc
In-Reply-To: <1332851611.13.0.643004221435.issue14424@psf.upfronthosting.co.za>
Message-ID: <E1Sb1nM-0007K9-Lj@dinsdale.python.org>


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

New changeset 3c43be281196 by Eli Bendersky in branch 'default':
Issue #14424: Document PyType_GenericAlloc, and fix the documentation of PyType_GenericNew
http://hg.python.org/cpython/rev/3c43be281196

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

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

From report at bugs.python.org  Sun Jun  3 05:48:32 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 03 Jun 2012 03:48:32 +0000
Subject: [docs] [issue14424] document PyType_GenericAlloc
In-Reply-To: <1332851611.13.0.643004221435.issue14424@psf.upfronthosting.co.za>
Message-ID: <1338695312.81.0.919420387224.issue14424@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jun  3 05:48:43 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 03 Jun 2012 03:48:43 +0000
Subject: [docs] [issue14424] document PyType_GenericAlloc
In-Reply-To: <1332851611.13.0.643004221435.issue14424@psf.upfronthosting.co.za>
Message-ID: <1338695323.14.0.672515962256.issue14424@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.2

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

From report at bugs.python.org  Sun Jun  3 07:12:08 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 03 Jun 2012 05:12:08 +0000
Subject: [docs] [issue14190] Minor C API documentation bugs
In-Reply-To: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za>
Message-ID: <1338700328.47.0.647121999611.issue14190@psf.upfronthosting.co.za>


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

Fixed what was relevant for default (3.3) in 90f0dd118aa4 (the commit message there has a typo in the issue number).

Since 3.3 is going to be out soon, I see no real reason to backport to 3.2

If anyone is willing to create a complete patch for 2.7 that fixes the relevant issues, I will review it. Ejaj, are your diffs for 2.7? Can you create a single patch?

----------

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

From sandro.tosi at gmail.com  Sun Jun  3 11:43:50 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 3 Jun 2012 11:43:50 +0200
Subject: [docs] Control flow - explanation
In-Reply-To: <E120546B09CD6E469353715657E04467B34F3BC5@CWYIGMBCRP01.Corp.Acxiom.net>
References: <E120546B09CD6E469353715657E04467B34F3BC5@CWYIGMBCRP01.Corp.Acxiom.net>
Message-ID: <CAB4XWXzk_5Yga8Pj4Ymzcs_K4i3kK+7bkhXbi+DRifUAmadHdQ@mail.gmail.com>

Hello Greg,

On Tue, May 29, 2012 at 8:42 PM, Kennedy Greg - grkenn
<Greg.Kennedy at acxiom.com> wrote:
> This seems as good a
> place as any to begin addressing the ?white space as a control structure?
> aspect of Python, perhaps with a demonstration that adding tabs to the Else:
> block will result in incorrect behavior.? I don?t recall seeing this being
> mentioned earlier in the tutorial, yet it?s an important defining aspect of
> the grammar.

This is introduced in the very first chapter of the tutorial,
http://docs.python.org/tutorial/appetite.html, in the dot list at
mid-page: "statement grouping is done by indentation instead of
beginning and ending brackets;".

Regards,
-- 
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 Jun  3 12:49:56 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 3 Jun 2012 12:49:56 +0200
Subject: [docs] proposal: sigle-file TXT format documentation
In-Reply-To: <E1SYJL1-0000xQ-G9.alexey-kosarev-mail-ru@f248.mail.ru>
References: <E1SYJL1-0000xQ-G9.alexey-kosarev-mail-ru@f248.mail.ru>
Message-ID: <CAB4XWXyc-NXFc1pKnpxuD5C9LBddnXbaXtaLeSimZkKU7zrj8A@mail.gmail.com>

Hello Alexey,

On Sat, May 26, 2012 at 5:55 PM, Alexey Kosarev <alexey.kosarev at mail.ru> wrote:
> Hi!
> I strongly propose to introduce single-file TXT documentation.

IMO I don't think a ~7MB file is that useful or readable.

> Current plain text documentation is totally navigable, but it's not conveniet to use it on any reading device or search through it using less + grep.

you already stated the solution: use grep :)

Regards,
-- 
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 Jun  4 02:32:53 2012
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 04 Jun 2012 00:32:53 +0000
Subject: [docs] [issue14995] PyLong_FromString documentation should state
	that the	string must be null-terminated
Message-ID: <1338769973.67.0.784454345332.issue14995@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

PyLong_FromString will raise a ValueError if the given string doesn't contain a null byte after the digits.  For example, this will result in a ValueError

   char *pend;
   PyLong_FromString("1234 extra", &pend, 10)

While this will successfully read the number and set the pointer to the extra data:

   char *pend;
   PyLong_FromString("1234\0extra", &pend, 10)

The requirement for a null-terminated string of digits is not clear from the docs.  Suggested re-wording attached.

----------
assignee: docs at python
components: Documentation
files: PyLong_FromString-doc.patch
keywords: patch
messages: 162242
nosy: docs at python, rfk
priority: normal
severity: normal
status: open
title: PyLong_FromString documentation should state that the string must be null-terminated
Added file: http://bugs.python.org/file25812/PyLong_FromString-doc.patch

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

From pybugs at rebertia.com  Tue Jun  5 01:59:59 2012
From: pybugs at rebertia.com (pybugs at rebertia.com)
Date: Mon, 04 Jun 2012 23:59:59 -0000
Subject: [docs] document return statement in finally blocks (issue 14167)
Message-ID: <20120604235959.13275.8937@psf.upfronthosting.co.za>


http://bugs.python.org/review/14167/diff/4310/Doc/reference/compound_stmts.rst
File Doc/reference/compound_stmts.rst (right):

http://bugs.python.org/review/14167/diff/4310/Doc/reference/compound_stmts.rst#newcode311
Doc/reference/compound_stmts.rst:311: it is re-raised at the end of the
:keyword:`finally` clause. If the
`break` statements aren't (re-)"raised" [per se] since they aren't
exceptions, so some rephrasing is needed here.

http://bugs.python.org/review/14167/diff/4310/Doc/reference/compound_stmts.rst#newcode312
Doc/reference/compound_stmts.rst:312: :keyword:`finally` clause raises
another exception the saved exception
Could use a comma: "another exception*,* the"

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

From report at bugs.python.org  Tue Jun  5 09:55:00 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 05 Jun 2012 07:55:00 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1338882900.53.0.670878951504.issue13515@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/issue13515>
_______________________________________

From report at bugs.python.org  Tue Jun  5 16:01:34 2012
From: report at bugs.python.org (Alexis Metaireau)
Date: Tue, 05 Jun 2012 14:01:34 +0000
Subject: [docs] [issue12354] packaging.pypi.simple docs use both client and
	crawler	name, which might be confusing
In-Reply-To: <1338574114.78.0.374893263632.issue12354@psf.upfronthosting.co.za>
Message-ID: <4FCE113C.1000304@notmyidea.org>


Alexis Metaireau <alexis at notmyidea.org> added the comment:

> Alexis, you introduced the client/crawler naming after reading some book; what do you think now?

Making the distinction between a crawler and a client is probably not a 
good idea since it introduces two concepts instead of one simple one.

We have indexes and different ways to access them: What about having an 
"XMLRPCClient" and a "SimpleClient"?

In addition, having a simpler API, something like 
packaging.indexes.get_client('simple' OR 'xmlrpc') can be useful, but 
that's a different issue.

----------

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

From report at bugs.python.org  Tue Jun  5 16:14:17 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 05 Jun 2012 14:14:17 +0000
Subject: [docs] [issue12354] packaging.pypi.simple docs use both client and
	crawler	name, which might be confusing
In-Reply-To: <1308334574.8.0.60329566716.issue12354@psf.upfronthosting.co.za>
Message-ID: <1338905657.63.0.492131578451.issue12354@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy:  -petri.lehtinen

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

From report at bugs.python.org  Tue Jun  5 18:32:41 2012
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 05 Jun 2012 16:32:41 +0000
Subject: [docs] [issue14966] Fully document subprocess.CalledProcessError
In-Reply-To: <1338446762.96.0.360332771622.issue14966@psf.upfronthosting.co.za>
Message-ID: <1338913961.2.0.243389703999.issue14966@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/issue14966>
_______________________________________

From report at bugs.python.org  Wed Jun  6 09:44:23 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 06 Jun 2012 07:44:23 +0000
Subject: [docs] [issue15013] smtplib: add low-level APIs to doc?
Message-ID: <1338968663.18.0.754320203153.issue15013@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

In the smtplib doc I read:

  Low-level methods corresponding to the standard SMTP/ESMTP commands HELP, RSET, NOOP, MAIL, RCPT, and DATA are also supported. Normally these do not need to be called directly, so they are not documented here. For details, consult the module code.

Well, I think the documentation should include also those low-level apis (maybe in a separate subsection).

>From my POV, smtplib should implement the protocol, and give the programmers the tools to use the protocol as they prefers, and as a plus some companion methods to easy the most common operations.

I'm in need to use the low-level apis, and not finding them in the doc is a disservice to me (with my user hat on ;)) and just say "go read the source" is kinda rude and unexpected.

What do you think?

----------
assignee: docs at python
components: Documentation
messages: 162395
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: smtplib: add low-level APIs to doc?
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun  6 14:54:49 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Jun 2012 12:54:49 +0000
Subject: [docs] [issue15013] smtplib: add low-level APIs to doc?
In-Reply-To: <1338968663.18.0.754320203153.issue15013@psf.upfronthosting.co.za>
Message-ID: <1338987289.8.0.975220451137.issue15013@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, personally I just read the code, and didn't think anything of it.  I guess Python code is documentation to me :)

I don't see why there would be any objection to documenting them if you want to, though.  It's not like we're going to want to change that API.

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

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

From report at bugs.python.org  Wed Jun  6 14:55:04 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Jun 2012 12:55:04 +0000
Subject: [docs] [issue15013] smtplib: add low-level APIs to doc?
In-Reply-To: <1338968663.18.0.754320203153.issue15013@psf.upfronthosting.co.za>
Message-ID: <1338987304.62.0.993568198088.issue15013@psf.upfronthosting.co.za>


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


----------
components: +email
nosy: +barry

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

From report at bugs.python.org  Wed Jun  6 20:00:57 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 06 Jun 2012 18:00:57 +0000
Subject: [docs] [issue14502] Document better what happens on releasing an
	unacquired	lock
In-Reply-To: <1333609616.9.0.633115743228.issue14502@psf.upfronthosting.co.za>
Message-ID: <1339005657.14.0.652294196637.issue14502@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

The docs of 2.7 and 3.2 still first say that RuntimeError is raised, and then that a ThreadError is raised:

    ...
    If an attempt is made to release an unlocked lock, a RuntimeError
    will be raised.

    ...

Lock.release()
    ...
    When invoked on an unlocked lock, a ThreadError is raised.


In 2.7 and 3.2, ThreadError is not a RuntimeError, so this is wrong.

----------
nosy: +petri.lehtinen
resolution: fixed -> 
status: closed -> open

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

From report at bugs.python.org  Wed Jun  6 20:28:45 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 06 Jun 2012 18:28:45 +0000
Subject: [docs] [issue9544] xdrlib.Packer().pack_fstring throws a TypeError
	when	called with a str()
In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za>
Message-ID: <1339007325.11.0.69318292966.issue9544@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attached a patch against 3.2. It reflects the facts that pack_fstring and pack_fopaque are the same methd, and pack_string, pack_opaque and pack_bytes are the same method.

----------
versions: +Python 3.2, Python 3.3 -Python 3.1

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

From report at bugs.python.org  Wed Jun  6 20:29:37 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 06 Jun 2012 18:29:37 +0000
Subject: [docs] [issue9544] xdrlib.Packer().pack_fstring throws a TypeError
	when	called with a str()
In-Reply-To: <1281333086.43.0.820305754452.issue9544@psf.upfronthosting.co.za>
Message-ID: <1339007377.66.0.412103826155.issue9544@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


Added file: http://bugs.python.org/file25849/issue9544.patch

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

From report at bugs.python.org  Thu Jun  7 19:25:09 2012
From: report at bugs.python.org (Mateusz Loskot)
Date: Thu, 07 Jun 2012 17:25:09 +0000
Subject: [docs] [issue15029] Update Defining New Types chapter according to
	PEP 253
Message-ID: <1339089909.82.0.778815916296.issue15029@psf.upfronthosting.co.za>


New submission from Mateusz Loskot <mateusz at loskot.net>:

The chapter '2. Defining New Types" in the Python 3.2 documentation [1] does not cover all important elements, especially in the subsection 2.1.4. Subclassing other types.

The accepted PEP 253 [2] provides much more detailed and thorough explanation for Python C API users willing to define and subclass new types, than the official manual.

I'd like to suggest update of the manual with information enclosed in the PEP 253. In fact, the PEP's sections like

* Preparing a type for subtyping
* Creating a subtype of a built-in type in C

could be copied with little editing, IMHO.

The PEP 253 really seems to be a must-read document for Python C API users.

[1] http://docs.python.org/release/3.2.2/extending/newtypes.html
[2] http://www.python.org/dev/peps/pep-0253/

----------
assignee: docs at python
components: Documentation
messages: 162480
nosy: docs at python, mloskot
priority: normal
severity: normal
status: open
title: Update Defining New Types chapter according to PEP 253
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun  7 19:27:12 2012
From: report at bugs.python.org (Mateusz Loskot)
Date: Thu, 07 Jun 2012 17:27:12 +0000
Subject: [docs] [issue15029] Update Defining New Types chapter according to
	PEP 253
In-Reply-To: <1339089909.82.0.778815916296.issue15029@psf.upfronthosting.co.za>
Message-ID: <1339090032.28.0.76700491246.issue15029@psf.upfronthosting.co.za>


Mateusz Loskot <mateusz at loskot.net> added the comment:

Similar request has been rejected in response to the Issue 621526 [1],
but I'm not proposing to include PEP into docs, but to update and improve docs with material discussed in accepted PEPs. 

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

----------

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

From report at bugs.python.org  Fri Jun  8 03:22:05 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Jun 2012 01:22:05 +0000
Subject: [docs] [issue15034] tutorial should use best practices in user
	defined	execeptions section
Message-ID: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

And I wish I knew what those were.

----------
assignee: docs at python
components: Documentation
messages: 162513
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: tutorial should use best practices in user defined execeptions section
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jun  8 03:47:10 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Jun 2012 01:47:10 +0000
Subject: [docs] [issue8652] Minor improvements to the "Handling Exceptions"
	part of	the tutorial
In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>
Message-ID: <E1ScoI8-0004uC-Ml@dinsdale.python.org>


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

New changeset b873afe640e2 by R David Murray in branch '2.7':
#8652: update errors tutorial.
http://hg.python.org/cpython/rev/b873afe640e2

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

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

From report at bugs.python.org  Fri Jun  8 03:51:55 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Jun 2012 01:51:55 +0000
Subject: [docs] [issue8652] Minor improvements to the "Handling Exceptions"
	part of	the tutorial
In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>
Message-ID: <1339120314.93.0.0163988748314.issue8652@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The Python3 tutorial was already fixed, and the explanation of the parens is not needed there since the "old syntax" is not supported.

I did not do any reordering since the use of 'as' immediately follows in the text and seems to make fine sense as is.  Actually, it now makes more sense than the equivalent exposition in the Python3 docs, where the paragraph is absent.

Thanks for the patch, Marien.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> behavior
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jun  8 10:50:03 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Fri, 08 Jun 2012 08:50:03 +0000
Subject: [docs] [issue15034] tutorial should use best practices in user
	defined	execeptions section
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1339145403.59.0.439232151968.issue15034@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
nosy: +hynek

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

From report at bugs.python.org  Fri Jun  8 14:32:06 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 08 Jun 2012 12:32:06 +0000
Subject: [docs] [issue14006] Improve the documentation of
	xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1339158726.96.0.609547653097.issue14006@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun  8 14:36:44 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 08 Jun 2012 12:36:44 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1339159004.17.0.117975196827.issue11379@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/issue11379>
_______________________________________

From report at bugs.python.org  Fri Jun  8 14:38:10 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 08 Jun 2012 12:38:10 +0000
Subject: [docs] [issue1040439] Missing documentation on how to link with
	libpython
Message-ID: <1339159090.27.0.0286585249261.issue1040439@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/issue1040439>
_______________________________________

From report at bugs.python.org  Fri Jun  8 14:38:16 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 08 Jun 2012 12:38:16 +0000
Subject: [docs] [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1339159096.65.0.718457342615.issue14097@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/issue14097>
_______________________________________

From report at bugs.python.org  Fri Jun  8 20:03:27 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Jun 2012 18:03:27 +0000
Subject: [docs] [issue15034] tutorial should use best practices in user
	defined	execeptions section
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1339178607.48.0.694482248093.issue15034@psf.upfronthosting.co.za>


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

I don?t understand the request.

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

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

From report at bugs.python.org  Fri Jun  8 20:08:52 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Jun 2012 18:08:52 +0000
Subject: [docs] [issue15034] tutorial should use best practices in user
	defined	execeptions section
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1339178932.45.0.993022595611.issue15034@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The obvious example is that the tutorial makes no mention of calling 'super' in __init__.  I'm also aware that there are issues of pickleability that arise if you do things one way, but do not arise if you do things another way.  But I don't know the details, and I'd like to see the tutorial show an example of the *best* way to write a user defined exception so that they behave like the built in Python exceptions.

----------

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

From report at bugs.python.org  Fri Jun  8 20:40:09 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Jun 2012 18:40:09 +0000
Subject: [docs] [issue15034] tutorial should use best practices in user
	defined	exceptions section
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1339180809.46.0.800943041808.issue15034@psf.upfronthosting.co.za>


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


----------
title: tutorial should use best practices in user defined execeptions section -> tutorial should use best practices in user defined exceptions section

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

From report at bugs.python.org  Fri Jun  8 20:40:40 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Jun 2012 18:40:40 +0000
Subject: [docs] [issue15034] tutorial should use best practices in user
	defined	exceptions section
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1339180840.63.0.77390519895.issue15034@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky

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

From report at bugs.python.org  Sat Jun  9 16:56:49 2012
From: report at bugs.python.org (Michael Foord)
Date: Sat, 09 Jun 2012 14:56:49 +0000
Subject: [docs] [issue14971] (unittest) loadTestsFromName does not work on
	method	with a decorator
In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za>
Message-ID: <1339253809.13.0.40939727142.issue14971@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Patch looks great - thanks David.

----------
assignee: docs at python -> michael.foord

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

From report at bugs.python.org  Sun Jun 10 02:49:34 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Sun, 10 Jun 2012 00:49:34 +0000
Subject: [docs] [issue15041] tkinter "see also" list is from Python2
Message-ID: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>


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

I was looking for information about menus in tkinter and checked the "see also" list. The second is copyrighted 1999, the third says Python 2.5 and the first is pretty much just links to the second and third. The forth is a book. It is my opinion that these resources should be updated.

----------
assignee: docs at python
components: Documentation
messages: 162568
nosy: docs at python, weirdink13
priority: normal
severity: normal
status: open
title: tkinter "see also" list is from Python2
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun 10 02:53:12 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Sun, 10 Jun 2012 00:53:12 +0000
Subject: [docs] [issue15041] tkinter documentation "see also" list in
	Python3 is from	Python2
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1339289592.86.0.373154693352.issue15041@psf.upfronthosting.co.za>


Changes by Daniel Swanson <popcorn.tomato.dude at gmail.com>:


----------
title: tkinter "see also" list is from Python2 -> tkinter documentation "see also" list in Python3 is from Python2
type:  -> enhancement

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

From report at bugs.python.org  Sun Jun 10 03:20:49 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 10 Jun 2012 01:20:49 +0000
Subject: [docs] [issue14680] pydoc with -w option does not work for a lot of
	help	topics
In-Reply-To: <1335478272.08.0.215124599111.issue14680@psf.upfronthosting.co.za>
Message-ID: <1339291249.19.0.393823798013.issue14680@psf.upfronthosting.co.za>


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

Thanks for the report.  Are you interested in making a patch?  Also, could you tell if the bug happens in 3.2?

----------
nosy: +eric.araujo
stage:  -> needs patch

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

From report at bugs.python.org  Sun Jun 10 03:23:02 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 10 Jun 2012 01:23:02 +0000
Subject: [docs] [issue14616] subprocess docs should mention
	pipes.quote/shlex.quote
In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za>
Message-ID: <1339291382.74.0.230043291639.issue14616@psf.upfronthosting.co.za>


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

Text LGTM; I haven?t looked at the position in the doc file though.  Sandro, once again I?m adding you to nosy in the hope that you?ll have time to make a review and maybe a commit, with my thanks!

----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Sun Jun 10 03:23:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 10 Jun 2012 01:23:46 +0000
Subject: [docs] [issue14616] subprocess docs should mention
	pipes.quote/shlex.quote
In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za>
Message-ID: <1339291426.65.0.392752807446.issue14616@psf.upfronthosting.co.za>


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

Please also take my note about pipes.quote in my OP into account.

----------

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

From report at bugs.python.org  Sun Jun 10 03:44:16 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 10 Jun 2012 01:44:16 +0000
Subject: [docs] [issue14968] Section "Inplace Operators" of :mod:`operator`
	should be	a subsection
In-Reply-To: <1338467566.04.0.840263099985.issue14968@psf.upfronthosting.co.za>
Message-ID: <1339292656.18.0.884008326445.issue14968@psf.upfronthosting.co.za>


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

Sandro: I added 2.7 to indicate it should be checked too.  As you said, the bug wasn?t there, because there is no In-place Operators section (which I think there should be, i.e. backporting #9717 (if you do that, please use a full commit message instead of ?backport of skldgjlkg?)).

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 2.7

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

From report at bugs.python.org  Sun Jun 10 16:05:58 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jun 2012 14:05:58 +0000
Subject: [docs] [issue7699] strptime, strftime documentation
In-Reply-To: <1263433562.71.0.126740414986.issue7699@psf.upfronthosting.co.za>
Message-ID: <1339337158.26.0.239791719009.issue7699@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This was applied by Georg in SVN revision r77561 on 2010-01-17.

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

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

From report at bugs.python.org  Sun Jun 10 19:18:34 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jun 2012 17:18:34 +0000
Subject: [docs] [issue15041] tkinter documentation "see also" list in
	Python3 is from	Python2
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1339348714.91.0.904458500945.issue15041@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you find any resources that we can link to, please post them here.

----------
assignee: docs at python -> 
nosy: +r.david.murray, terry.reedy

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

From report at bugs.python.org  Sun Jun 10 19:22:52 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Jun 2012 17:22:52 +0000
Subject: [docs] [issue15041] tkinter documentation "see also" list in
	Python3 is from	Python2
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1339348972.87.0.735524471389.issue15041@psf.upfronthosting.co.za>


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


----------
nosy: +asvetlov

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

From report at bugs.python.org  Sun Jun 10 20:04:47 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 10 Jun 2012 18:04:47 +0000
Subject: [docs] [issue15041] tkinter documentation: update "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1339351487.46.0.333908343015.issue15041@psf.upfronthosting.co.za>


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

The 2.7 doc can also be updated. Here is a couple to add or replace.

Tcl/Tk 8.5 Manual http://www.tcl.tk/man/tcl8.5/
The the current tcl/tk reference manual. The Tk Commands section is the most relevant for tkinter.

TKDocs http://www.tkdocs.com/
Extensive tutorial plus friendlier widget pages for some of the widgets.

----------
assignee:  -> docs at python
components: +Tkinter
nosy: +serwy
stage:  -> needs patch
title: tkinter documentation "see also" list in Python3 is from Python2 -> tkinter documentation: update  "see also" list
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Jun 11 03:26:10 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Jun 2012 01:26:10 +0000
Subject: [docs] [issue15041] tkinter documentation: update "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1339377970.52.0.877674219876.issue15041@psf.upfronthosting.co.za>


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

Kevin Walzer, who uses tk/inter regularly, sent me the following

effbot has a more recent work-in-progress update of his Tkinter docs here: http://effbot.org/tkinterbook/

I refer to this a lot.

"Programming Python" by Mark Lutz (Amazon link here: http://www.amazon.com/Programming-Python-Mark-Lutz/dp/0596158106/ref=dp_ob_title_bk) has excellent coverage of Tkinter.

+1 for the TkDocs site--very nice.

----------

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

From report at bugs.python.org  Mon Jun 11 22:13:05 2012
From: report at bugs.python.org (Michael Driscoll)
Date: Mon, 11 Jun 2012 20:13:05 +0000
Subject: [docs] [issue14966] Fully document subprocess.CalledProcessError
In-Reply-To: <1338446762.96.0.360332771622.issue14966@psf.upfronthosting.co.za>
Message-ID: <1339445585.68.0.277016758116.issue14966@psf.upfronthosting.co.za>


Michael Driscoll <mike at pythonlibrary.org> added the comment:

I don't see the error, TimeoutExpired, documented either. At least the doc page mentions CalledProcessError a couple times. Do we want to use the docstring for CalledProcessError for the documentation page? Where on the page would it go? I assume we'd want an example showing how to use it?

----------
nosy: +michael.driscoll

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

From report at bugs.python.org  Mon Jun 11 22:32:21 2012
From: report at bugs.python.org (Michael Driscoll)
Date: Mon, 11 Jun 2012 20:32:21 +0000
Subject: [docs] [issue15041] tkinter documentation: update "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1339446741.79.0.813454193044.issue15041@psf.upfronthosting.co.za>


Michael Driscoll <mike at pythonlibrary.org> added the comment:

I thought the ebook, "Modern Tkinter for Busy Python Developers" by Mark Roseman was pretty good too: http://www.amazon.com/Modern-Tkinter-Python-Developers-ebook/dp/B0071QDNLO/ref=sr_1_1?ie=UTF8&qid=1339446684&sr=8-1

----------
nosy: +michael.driscoll

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

From report at bugs.python.org  Tue Jun 12 13:57:37 2012
From: report at bugs.python.org (Michael Herrmann)
Date: Tue, 12 Jun 2012 11:57:37 +0000
Subject: [docs] [issue12982] .pyo file can't be imported unless -O is given
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339502257.26.0.373028531891.issue12982@psf.upfronthosting.co.za>


Michael Herrmann <mherrmann.at at gmail.com> added the comment:

Hi,

I need to use a third-party library that ships as a mixture of .pyc and .pyo files. I found it a little surprising and inconvenient that I have to set the -O flag just to read .pyo files. I don't mind whether .pyc or .pyo files are being created during compilation, I just want to be able to read from both .pyc and .pyo files without having to use the -O flag. Can somebody fix this? I unfortunately have absolutely no clue how.

Thanks!

----------
components: +Interpreter Core -Documentation
nosy: +mherrmann.at

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

From report at bugs.python.org  Tue Jun 12 14:02:59 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Jun 2012 12:02:59 +0000
Subject: [docs] [issue13783] Clean up PEP 380 C API additions
In-Reply-To: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za>
Message-ID: <1339502579.34.0.720166504962.issue13783@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee: docs at python -> ncoghlan
priority: normal -> release blocker

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

From report at bugs.python.org  Tue Jun 12 15:15:58 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jun 2012 13:15:58 +0000
Subject: [docs] [issue12982] .pyo file can't be imported unless -O is given
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339506957.81.0.336240976747.issue12982@psf.upfronthosting.co.za>


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

Michael, I don?t think your proposed change would be considered favorably: importing .pyc or .pyo is well defined for CPython and the -O switch is really required for .pyo.  However you may be able to import them anyway without any change to Python if you write a custom importer (more info in PEP 302 and the import docs) which reuses the low-level imp module to find and load .pyo files.

----------

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

From report at bugs.python.org  Tue Jun 12 15:16:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Jun 2012 13:16:46 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339507006.63.0.000941653071945.issue12982@psf.upfronthosting.co.za>


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


----------
title: .pyo file can't be imported unless -O is given -> Document that importing .pyo files needs python -O

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

From report at bugs.python.org  Tue Jun 12 15:25:50 2012
From: report at bugs.python.org (Michael Herrmann)
Date: Tue, 12 Jun 2012 13:25:50 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339507550.31.0.900829147792.issue12982@psf.upfronthosting.co.za>


Michael Herrmann <mherrmann.at at gmail.com> added the comment:

Hi Eric,

thank you for your quick reply. I'm not the first one who encounters this problem and in my opinion it is simply counter-intuitive that you cannot read a mixture of .pyo and .pyc files. That is why I think that my proposed change is valuable. In the meantime, I will follow your suggestion and try to use the imp-module to load the .pyo-files myself. Thank you!

Best regards,
Michael

----------

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

From report at bugs.python.org  Tue Jun 12 15:26:10 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Jun 2012 13:26:10 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339507570.11.0.0160915347923.issue12982@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Actually it's a lot easier than that, although it is very much a hack: just rename the .pyo files to .pyc, and python without -O will happily import them.  Since the optimization happens when the bytecode is written, this does what you want.

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

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

From report at bugs.python.org  Tue Jun 12 15:28:37 2012
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Tue, 12 Jun 2012 13:28:37 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1339507550.31.0.900829147792.issue12982@psf.upfronthosting.co.za>
Message-ID: <B45075F8-1B00-456F-A4CA-E72876CE167D@normalesup.org>


Eric O. LEBIGOT <eric.lebigot at normalesup.org> added the comment:

Hi Michael,

Thank you for your message.

You are mentioning the suggestion of "the other Eric" (Araujo). My suggestion was to rename your .pyo files as .pyc files; it is hackish (according to a previous post from Eric Araujo), but might save you some trouble, on the short term, as .pyc do not need -O.

Best wishes,

EOL

On Jun 12, 2012, at 21:25, Michael Herrmann wrote:

> 
> Michael Herrmann <mherrmann.at at gmail.com> added the comment:
> 
> Hi Eric,
> 
> thank you for your quick reply. I'm not the first one who encounters this problem and in my opinion it is simply counter-intuitive that you cannot read a mixture of .pyo and .pyc files. That is why I think that my proposed change is valuable. In the meantime, I will follow your suggestion and try to use the imp-module to load the .pyo-files myself. Thank you!
> 
> Best regards,
> Michael
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12982>
> _______________________________________

----------

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

From report at bugs.python.org  Tue Jun 12 15:39:33 2012
From: report at bugs.python.org (Michael Herrmann)
Date: Tue, 12 Jun 2012 13:39:33 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339508372.59.0.252523688505.issue12982@psf.upfronthosting.co.za>


Michael Herrmann <mherrmann.at at gmail.com> added the comment:

Dear Eric OL,

I see - I had read your e-mail but because of the similar names I thought the message here was yours too, and thus only replied once. I apologize!

I can of course find a workaround such as renaming .pyo to .pyc. However, I would like to avoid having to modify the distribution of the third party library I am using in any way. The reason is that if a new version of this third party library is released and I have to upgrade to this new version, I will again have to manually do all the changes I had to do for the old version for the new version, and of course some changes won't work any more and there will be problems...

I'm finding it tedious to use the imp-module to read in the .pyo-files by hand and might just fall back to your suggestion. Thank you for it. Nevertheless, I am still hoping that this may be resolved in a future release.

Best,
Michael

----------

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

From report at bugs.python.org  Tue Jun 12 20:21:15 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Jun 2012 18:21:15 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339525275.33.0.69913784865.issue12982@psf.upfronthosting.co.za>


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

Michael, you should ask the closed source library distributor to distribute all files as .pyc so you have access to docstrings while programming and to avoid the problem with reading them. He could also distribute an all-.pyo version. A mixture seems accidental.

Is the import restriction currently intended? If a change *is* made, should it be regarded as an enhancement rather than a bug fix? I asked both question on pydev for more input.

----------

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

From report at bugs.python.org  Tue Jun 12 21:05:10 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Tue, 12 Jun 2012 19:05:10 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339527910.87.0.138175095534.issue12982@psf.upfronthosting.co.za>


Changes by Ronan Lamy <ronan.lamy at gmail.com>:


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

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

From report at bugs.python.org  Tue Jun 12 22:20:46 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Jun 2012 20:20:46 +0000
Subject: [docs] [issue15053] imp.lock_held() "Changed in Python 3.3"
	mention	accidentally one function up
Message-ID: <1339532446.32.0.0402768881162.issue15053@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

If you look at http://docs.python.org/dev/py3k/library/imp.html#imp.get_tag you will notice it has the "Changed in Python 3.3" notice for imp.lock_held() in it, the function *below* imp.get_tag().

----------
assignee: docs at python
components: Documentation
messages: 162694
nosy: brett.cannon, docs at python, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: imp.lock_held() "Changed in Python 3.3" mention accidentally one function up
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun 13 02:26:47 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Jun 2012 00:26:47 +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: <1339547206.9.0.143228160052.issue15053@psf.upfronthosting.co.za>


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

Well, if the versionchanged were for get_tag(), it would be indented appropriately. But it is actually for the "The following functions help interact with the import system?s internal locking mechanism" paragraph.

Feel free to improve :)

----------

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

From report at bugs.python.org  Wed Jun 13 17:34:14 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 13 Jun 2012 15:34:14 +0000
Subject: [docs] [issue15055] dictnotes.txt is out of date
Message-ID: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

dictnotes.txt is out of date w.r.t. dictobject.c

Remove notes from dictnotes.txt that duplicate comments in dictobject.c
and ensure comments in dictobject.c cover all aspects of tunable parameters.

Patch attached.

----------
assignee: docs at python
components: Documentation
files: dictnotes.patch
keywords: patch
messages: 162709
nosy: Mark.Shannon, docs at python
priority: normal
severity: normal
status: open
title: dictnotes.txt is out of date
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file25947/dictnotes.patch

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

From report at bugs.python.org  Wed Jun 13 18:00:08 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Jun 2012 16:00:08 +0000
Subject: [docs] [issue15055] dictnotes.txt is out of date
In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za>
Message-ID: <1339603208.19.0.610611943166.issue15055@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jun 13 18:12:39 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Jun 2012 16:12:39 +0000
Subject: [docs] [issue15055] dictnotes.txt is out of date
In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za>
Message-ID: <1339603959.14.0.944500875479.issue15055@psf.upfronthosting.co.za>


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

Mark, where was it approved that you could change all the tunable parameters?  I remembered that the split dict was approved but not changing all of the tuneables (at one point, I had spent a month validating that the tuneables were correct across a wide variety of applications).

----------

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

From report at bugs.python.org  Wed Jun 13 18:32:42 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 13 Jun 2012 16:32:42 +0000
Subject: [docs] [issue15055] dictnotes.txt is out of date
In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za>
Message-ID: <1339605162.66.0.338638065931.issue15055@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Raymond,

I don't think this is the place to discuss the changes to the tunables in dictobject.c.

This patch merely ensures that dictnotes.txt and the comments in dictobject.c are in agreement. It doesn't change any code (apart from creating the GROWTH_RATE macro for clarity).

----------

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

From report at bugs.python.org  Wed Jun 13 19:33:27 2012
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 13 Jun 2012 17:33:27 +0000
Subject: [docs] [issue13783] Clean up PEP 380 C API additions
In-Reply-To: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za>
Message-ID: <1339608807.91.0.077927106188.issue13783@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

There is one call to PyGen_FetchStopIterationValue in ceval.c.

But I don't think it should be public. 

There is no real reason for the "Gen" in the name. The function is used by generator handling code, but the code itself relates to StopIteration.
Perhaps it should be moved to errors.c and renamed _PyErr_FetchStopIterationValue.

----------
nosy: +Mark.Shannon

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

From report at bugs.python.org  Wed Jun 13 20:28:01 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 13 Jun 2012 18:28:01 +0000
Subject: [docs] [issue15060] docs: socket typo
Message-ID: <1339612081.61.0.600965829536.issue15060@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

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

s/integral/integer/

----------
assignee: docs at python
components: Documentation
messages: 162720
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: docs: socket typo

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

From report at bugs.python.org  Wed Jun 13 21:58:40 2012
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 13 Jun 2012 19:58:40 +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: <1339617520.61.0.94375523671.issue14674@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Removed file: http://bugs.python.org/file25594/json.rst.patch

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

From report at bugs.python.org  Wed Jun 13 22:01:12 2012
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 13 Jun 2012 20:01:12 +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: <1339617671.97.0.554487885392.issue14674@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Any further comments now that the matter of encodings is covered more thoroughly?

----------
Added file: http://bugs.python.org/file25999/json.rst.patch

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

From report at bugs.python.org  Wed Jun 13 22:01:51 2012
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 13 Jun 2012 20:01:51 +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: <1339617711.94.0.374040690077.issue14674@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Removed file: http://bugs.python.org/file25606/json.rst.patch

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

From report at bugs.python.org  Wed Jun 13 23:59:37 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jun 2012 21:59:37 +0000
Subject: [docs] [issue15060] docs: socket typo
In-Reply-To: <1339612081.61.0.600965829536.issue15060@psf.upfronthosting.co.za>
Message-ID: <E1SevbD-0001da-Fo@dinsdale.python.org>


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

New changeset 744fb52ffdf0 by Sandro Tosi in branch '2.7':
Issue #15060: fix typo in socket doc; Patch by anatoly techtonik
http://hg.python.org/cpython/rev/744fb52ffdf0

New changeset 4d755a711823 by Sandro Tosi in branch '3.2':
Issue #15060: fix typo in socket doc; Patch by anatoly techtonik
http://hg.python.org/cpython/rev/4d755a711823

New changeset 29fb36928433 by Sandro Tosi in branch 'default':
Issue #15060: merge with 3.2
http://hg.python.org/cpython/rev/29fb36928433

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

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

From report at bugs.python.org  Thu Jun 14 00:00:40 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 13 Jun 2012 22:00:40 +0000
Subject: [docs] [issue15060] docs: socket typo
In-Reply-To: <1339612081.61.0.600965829536.issue15060@psf.upfronthosting.co.za>
Message-ID: <1339624839.86.0.35004996809.issue15060@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks!

----------
nosy: +sandro.tosi
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 14 00:37:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Jun 2012 22:37:38 +0000
Subject: [docs] [issue15060] docs: socket typo
In-Reply-To: <1339612081.61.0.600965829536.issue15060@psf.upfronthosting.co.za>
Message-ID: <E1SewC1-0004qI-Gm@dinsdale.python.org>


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

New changeset 412c7daed0db by Sandro Tosi in branch '2.7':
Issue #15060: better fix, thanks to review on #python-dev
http://hg.python.org/cpython/rev/412c7daed0db

New changeset e616985284cd by Sandro Tosi in branch '3.2':
Issue #15060: better fix, thanks to review on #python-dev
http://hg.python.org/cpython/rev/e616985284cd

New changeset d16065304bbd by Sandro Tosi in branch 'default':
Issue #15060: merge with 3.2
http://hg.python.org/cpython/rev/d16065304bbd

----------

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

From report at bugs.python.org  Thu Jun 14 05:19:32 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Jun 2012 03:19:32 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339643972.3.0.135280616246.issue12982@psf.upfronthosting.co.za>


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

The response from pydev is that running .pyc with -O or running .pyo without is not officially supported. Even if mixing usually works now, it does not always work properly for code with __debug__, assert, or __doc__. The scope of possible malfunctions may increase if ideas for more aggressive optimization are implemented. So mixing the two types of cache files is 'do at your own risk' and 'don't complain if it does not work now or ceases to work in the future'.

A principle reason for the above is that __debug__ == <not  -O> and that it affects complilation, not just execution.

The doc should say the above more clearly. Eric L., where is the doc quote from?

----------
components: +Documentation -Interpreter Core

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

From report at bugs.python.org  Thu Jun 14 06:30:55 2012
From: report at bugs.python.org (Bryce Verdier)
Date: Thu, 14 Jun 2012 04:30:55 +0000
Subject: [docs] [issue15063] Source code links for JSON documentation
Message-ID: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za>


New submission from Bryce Verdier <bryceverdier at gmail.com>:

In some parts of the documentation there are links to the source code. While looking in the JSON documentation that link isn't there.

Not sure if this is wanted or if it's complete. But I'm submitting it anyway in the hopes of feedback.

----------
assignee: docs at python
components: Documentation
files: json_source_link.patch
keywords: patch
messages: 162750
nosy: docs at python, louiscipher
priority: normal
severity: normal
status: open
title: Source code links for JSON documentation
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file26006/json_source_link.patch

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

From report at bugs.python.org  Thu Jun 14 15:08:03 2012
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Thu, 14 Jun 2012 13:08:03 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339679283.42.0.25601996839.issue12982@psf.upfronthosting.co.za>


Eric O. LEBIGOT <eric.lebigot at normalesup.org> added the comment:

Terry, it seems that the doc I was quoting is for version 1.5.1 (http://docs.python.org/release/1.5.1p1/tut/node43.html). I can't find it in more recent versions of the doc. I should not have quoted an obsolete version of the documentation?I'm not sure how this happened. :)

I am not fully sure why -O is essentially required for running .pyo files: why not have the Python interpreter handle everything automatically based on the extension?

----------

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

From report at bugs.python.org  Thu Jun 14 15:09:50 2012
From: report at bugs.python.org (Michael Herrmann)
Date: Thu, 14 Jun 2012 13:09:50 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339679390.35.0.625634548803.issue12982@psf.upfronthosting.co.za>


Michael Herrmann <mherrmann.at at gmail.com> added the comment:

That is *exactly* my point :)

----------

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

From report at bugs.python.org  Thu Jun 14 15:20:05 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jun 2012 13:20:05 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339680005.19.0.543112024515.issue12982@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Because:

  1) The __debug__ flag is defined to be process-global.  If you test it in one module, your code should be able to assume that it has the same value in all other modules

  2) python-dev does not support running .pyo code without -O turned on.  In the future it might be the case that -O would actually change the behavior of the running python interpreter such that .pyo code would fail of -O was not on.

So, you can do the rename or importer trick if you want, and it will work right now as long as your program does not depend on __debug__ being globally consistent (which would be the case for almost all programs), but we do not guarantee it will continue to work in future versions of Python.

----------

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

From report at bugs.python.org  Thu Jun 14 15:40:37 2012
From: report at bugs.python.org (Eric Snow)
Date: Thu, 14 Jun 2012 13:40:37 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339681237.0.0.173138588691.issue12982@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> I am not fully sure why -O is essentially required for running .pyo
> files: why not have the Python interpreter handle everything
> automatically based on the extension?

In part because it would take work to make it happen and apparently no one feels strongly enough about adding that functionality, or convinced enough that it's appropriate, to do the work.  If you're interested a good first step would be to write a PEP 302 metapath hook (finder that gets inserted to sys.metapath) that makes import of .pyo files work even when -O is not used.  Maybe you'd also want to have .pyc files work even when -O *is* used.

Keep in mind that there may be other reasons why such functionality would not go into the interpreter.  However, the beauty of import hooks is that it wouldn't matter once you have yours in hand.

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

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

From report at bugs.python.org  Thu Jun 14 17:19:08 2012
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Jun 2012 15:19:08 +0000
Subject: [docs] [issue15067] sqlite3 docs reference PEP 246,
	which was rejected
Message-ID: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

See: http://hg.python.org/cpython/file/d31e83497c5a/Doc/library/sqlite3.rst#l708

PEP 246 is headed by: 
"""
Rejection Notice

    I'm rejecting this PEP.  Something much better is about to happen;
    it's too early to say exactly what, but it's not going to resemble
    the proposal in this PEP too closely so it's better to start a new
    PEP.  GvR.
"""

I don't know what the "something much better" was/is, so I have no idea how that line in the docs should be replaced, but I don't think the PEP 246 reference is valid.

Thanks,

Zach

----------
assignee: docs at python
components: Documentation
messages: 162797
nosy: docs at python, ghaering, zach.ware
priority: normal
severity: normal
status: open
title: sqlite3 docs reference PEP 246, which was rejected
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 14 18:53:28 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Thu, 14 Jun 2012 16:53:28 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339692807.98.0.723832131002.issue12982@psf.upfronthosting.co.za>


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

Doing it at the interpreter level is trivial (cf. patch), except for an annoying bug I noticed (see below). Doing it from user code might require some care to avoid disrupting existing import hooks, but AFAICT something like sys.path_hooks.append(FileFinder.path_hook(['.pyo', SourcelessFileLoader, True])) is supposed to work. 

The bug is that -O has currently no effect on sourceless imports: it seems that frozen_importlib actually uses freeze-time __debug__ instead of the current interpreter's.

----------
keywords: +patch
Added file: http://bugs.python.org/file26008/issue12982.diff

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

From report at bugs.python.org  Thu Jun 14 20:28:29 2012
From: report at bugs.python.org (Eric Snow)
Date: Thu, 14 Jun 2012 18:28:29 +0000
Subject: [docs] [issue15067] sqlite3 docs reference PEP 246,
	which was rejected
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1339698509.23.0.473699956421.issue15067@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

At the time it referred to generic functions (a la PEP 3124: Overloading, Generic Functions, Interfaces, and Adaptation).  However, ultimately it was Abstract Base Classes (PEP 3119) that slid into this space.

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

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

From report at bugs.python.org  Thu Jun 14 20:59:08 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Jun 2012 18:59:08 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1339700348.78.0.986876797613.issue12982@psf.upfronthosting.co.za>


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

Eric, can you find a place in the current doc where -O and .pyo are mentioned, and where you think a sentence should go. What sentence(s) would you like to see.

Other comments:

__debug__ is intended to be a process-global compilation value (implemented as a keyword) set on startup

>>> __debug__
True
>>> __debug__ = False
SyntaxError: assignment to keyword

The devs are not willing to support having contradictory values in the same process. Indeed, since I posted last night, the pydev discussion has moved to the question of whether -O, __debug__, and .pyo as now defined are worth the nuisance they cause or whether some or all should be deprecated. (Docstring stripping for saving space could then be a separate tool.)

---
Python interpreters exist to run Python code. The existence, persistence, and other details of compilation caches are version-dependent implementation details. Being able to execute from such caches without source present is also an implementation detail, and for CPython, it gets secondary support at best. (This is a compromise between full support and no support.)

----------

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

From report at bugs.python.org  Thu Jun 14 21:35:37 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Jun 2012 19:35:37 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339702537.94.0.804791968316.issue15068@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That makes sense.  It is a consequence of (a) buffered input and (b) the fact that EOF on stdin doesn't really close it.  (And by interactive here I don't just mean Python's interactive prompt, but also the shell).

By default fileinput uses readlines with a buffer size, so it suffers from the same issue.  It is only the second time that you close stdin that it gets an empty buffer, and so terminates.

Anyone want to try to come up with a doc footnote to explain this?

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

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

From report at bugs.python.org  Thu Jun 14 22:02:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jun 2012 20:02:45 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339704165.37.0.0495078898296.issue15068@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Note that in the rare cases, when stdio ends immediately on the limit of the read buffer, just one EOF is sufficient. In particular for read(1) one EOF is sufficient always, and for read(2) it is sufficient in about half of the cases.

----------

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

From report at bugs.python.org  Thu Jun 14 22:18:18 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Jun 2012 20:18:18 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339705098.34.0.171649011196.issue15068@psf.upfronthosting.co.za>


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

It is unlikely to be solvable at the Python level. Witness the raw stream's behaviour (in Python 3):

>>> sys.stdin.buffer.raw.read(1000)

If you type a letter followed by ^D (Linux) or ^Z (Windows), this returns immediately:

>>> sys.stdin.buffer.raw.read(1000)
x^Db'x'

But since the result is non-empty, the buffering layer will not detect the EOF and will call read() on the raw stream again (as the 1000 bytes are not satisfied). To signal EOF to the buffered stream, you have to type ^D or ^Z *without preceding it with another character*. Try the following:

>>> sys.stdin.buffer.read(1000)

You'll see that as long as you type a letter before ^D or ^Z, the read() will not return (until you type more than 1000 characters, that is):
- ^D alone: returns!
- a letter followed by ^D: doesn't return
- a letter followed by ^D followed by ^D: returns!
- a letter followed by ^D followed by a letter followed by ^D: doesn't return

This is all caused by the fact that a C read() on stdin doesn't return until either the end of line or EOF (or the requested bytes number is satisfied). Just experiment with:

>>> os.read(0, 1000)

That's why I say this is not solvable at the Python level (except perhaps with bizarre ioctl hackery).

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

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

From report at bugs.python.org  Thu Jun 14 22:58:57 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 14 Jun 2012 20:58:57 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339707537.31.0.426469460568.issue15068@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/issue15068>
_______________________________________

From report at bugs.python.org  Thu Jun 14 23:26:35 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Jun 2012 21:26:35 +0000
Subject: [docs] [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <1339709195.09.0.241391915567.issue10376@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Martin, now the patch is good?

----------

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

From report at bugs.python.org  Fri Jun 15 10:09:59 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Jun 2012 08:09:59 +0000
Subject: [docs] [issue15034] tutorial should use best practices in user
	defined	exceptions section
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1339747799.4.0.971066655086.issue15034@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun 15 16:20:35 2012
From: report at bugs.python.org (Joey Geralnik)
Date: Fri, 15 Jun 2012 14:20:35 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339770034.92.0.432946035346.issue15068@psf.upfronthosting.co.za>


Joey Geralnik <jgeralnik at gmail.com> added the comment:

First off, I'm a complete noob looking at the python source code for the first time so forgive me if I've done something wrong.

What if the length of the chunk is checked as well? The following code works fine:

import sys
while True:
    chunk = sys.stdin.read(1000)
    if not chunk:
        break
    # process
    if len(chunk) < 1000:
        break

Something similar could be done in the fileinput class. The patch I've attached checks if the number of bytes read from the file is less than the size of the buffer (which means that the file has ended). If so, the next time the file is to be read it skips to the next file instead.

joey at j-Laptop:~/cpython$ ./python 
Python 3.3.0a3+ (default:befd56673c80+, Jun 15 2012, 17:14:12) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import fileinput
[73732 refs]
>>> lines = list(fileinput.input())
foo
bar
^D
[73774 refs]
>>> lines
['foo\n', 'bar\n']
[73780 refs]

----------
keywords: +patch
nosy: +jgeralnik
Added file: http://bugs.python.org/file26018/fileinput.patch

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

From report at bugs.python.org  Fri Jun 15 16:41:19 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jun 2012 14:41:19 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339770034.92.0.432946035346.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339771282.6648.143.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

>  The patch I've attached checks if the number of bytes read from the file is less than the size of the buffer (which means that the file has ended).

>From io.RawIOBase.read docs:

"""
Read up to n bytes from the object and return them. As a convenience, if
n is unspecified or -1, readall() is called. Otherwise, only one system
call is ever made. Fewer than n bytes may be returned if the operating
system call returns fewer than n bytes.

If 0 bytes are returned, and n was not 0, this indicates end of file.
"""

This is not an arbitrary assumption. In particular, when reading from a
terminal with line buffering (you can edit the line until you press
Enter) on C level you read only a whole line (if line length is not
greater than buffer length) and 0 bytes you will receive only by
pressing ^D or ^Z at the beginning of the line. Same for pipes and
sockets. On Python level there are many third-party implementations of
file-like objects which rely on this behavior, you cannot rewrite all of
them.

----------

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

From report at bugs.python.org  Fri Jun 15 16:59:07 2012
From: report at bugs.python.org (Joey Geralnik)
Date: Fri, 15 Jun 2012 14:59:07 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339772346.98.0.851965854994.issue15068@psf.upfronthosting.co.za>


Joey Geralnik <jgeralnik at gmail.com> added the comment:

But this is calling the readlines function, which continually reads from the file until more bytes have been read than the specified argument.

>From bz2.readlines:
"size can be specified to control the number of lines read: no further lines will be read once the total size of the lines read so far equals or exceeds size."

Do other file-like objects interpret this parameter differently?

----------

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

From report at bugs.python.org  Fri Jun 15 17:04:20 2012
From: report at bugs.python.org (Joey Geralnik)
Date: Fri, 15 Jun 2012 15:04:20 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339772660.2.0.797575168594.issue15068@psf.upfronthosting.co.za>


Joey Geralnik <jgeralnik at gmail.com> added the comment:

Forget other filelike objects. The FileInput class only works with actual files, so the readlines function should always return at least as many bytes as its first parameter. Is this assumption wrong?

----------

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

From report at bugs.python.org  Fri Jun 15 17:23:23 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jun 2012 15:23:23 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339773803.75.0.437408229764.issue15068@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

fileinput should work (for some definition of work) for anything that can be opened by name using the open syscall on unix.  That includes many more things than files.  Named pipes are a particularly interesting example in this context.

----------

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

From report at bugs.python.org  Fri Jun 15 17:29:25 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jun 2012 15:29:25 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339774164.99.0.128917489536.issue15068@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So the real question is: does readlines block until the byte count is satisified?  It might, but the docs for io.IOBase.readlines leave open the possibility that fewer lines will be read, and do not limit that to the EOF case.  It's not clear, however, if that is because the non-EOF-short-read case is specifically being allowed for, or if the documenter just didn't consider that case.

----------

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

From report at bugs.python.org  Fri Jun 15 17:32:44 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Jun 2012 15:32:44 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339774364.27.0.293773722729.issue15068@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The _pyio.py version of readlines does read until the count is equaled or exceeded.  This could, however, be an implementation detail and not part of the spec.

----------

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

From report at bugs.python.org  Fri Jun 15 17:40:02 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jun 2012 15:40:02 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339771282.6648.143.camel@raxxla>
Message-ID: <1339774613.3360.0.camel@localhost.localdomain>


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

Le vendredi 15 juin 2012 ? 14:41 +0000, Serhiy Storchaka a ?crit :
> >From io.RawIOBase.read docs:
> 
> """
> Read up to n bytes from the object and return them. As a convenience, if
> n is unspecified or -1, readall() is called. Otherwise, only one system
> call is ever made. Fewer than n bytes may be returned if the operating
> system call returns fewer than n bytes.

But sys.stdin does not implement RawIOBase, it implements TextIOBase.

----------

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

From report at bugs.python.org  Fri Jun 15 17:44:56 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jun 2012 15:44:56 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339772660.2.0.797575168594.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339775096.6648.163.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Forget other filelike objects. The FileInput class only works with actual files,

No. sys.stdin can be reassigned before using FileInput. And FileInput
has openhook parameter (for read compressed files or get files from Web,
for example).

>  so the readlines function should always return at least as many bytes as its first parameter. Is this assumption wrong?

qwert
'qwert\n'

You type five characters "qwert" end press <Enter>. Python immediately
receives these six characters, and returns a result of
sys.stdin.readline(1000). Only six characters, and no one symbol more,
because more characters you have not entered yet.

I believe that for such questions will be more appropriate to use a
mailing list (python-list at python.org, or newsgroup
gmane.comp.python.general on news://news.gmane.org), and not bugtracker.

----------

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

From report at bugs.python.org  Fri Jun 15 17:46:52 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jun 2012 15:46:52 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339775096.6648.163.camel@raxxla>
Message-ID: <1339775026.3360.1.camel@localhost.localdomain>


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

> >  so the readlines function should always return at least as many bytes as its first parameter. Is this assumption wrong?
> 
> qwert
> 'qwert\n'
> 
> You type five characters "qwert" end press <Enter>. Python immediately
> receives these six characters, and returns a result of
> sys.stdin.readline(1000).

Well, did you try readline() or readlines()?

----------

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

From report at bugs.python.org  Fri Jun 15 18:29:44 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jun 2012 16:29:44 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339774613.3360.0.camel@localhost.localdomain>
Message-ID: <1339775403.6648.166.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> But sys.stdin does not implement RawIOBase, it implements TextIOBase.

sys.stdin.buffer.raw implements RawIOBase.

----------

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

From report at bugs.python.org  Fri Jun 15 18:36:14 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Jun 2012 16:36:14 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339775026.3360.1.camel@localhost.localdomain>
Message-ID: <1339778185.2467.2.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> > 
> > qwert
> > 'qwert\n'

Oh, it seems that the mail server again ate some lines of my examples.

> Well, did you try readline() or readlines()?

Yes, it's my mistake, I used readline().

----------

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

From report at bugs.python.org  Fri Jun 15 18:38:32 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jun 2012 16:38:32 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339778185.2467.2.camel@raxxla>
Message-ID: <1339778127.3360.19.camel@localhost.localdomain>


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

> Oh, it seems that the mail server again ate some lines of my examples.

This is a bug in the e-mail gateway. You can lobby for a fix at
http://psf.upfronthosting.co.za/roundup/meta/issue264

----------

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

From report at bugs.python.org  Fri Jun 15 19:15:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Jun 2012 17:15:59 +0000
Subject: [docs] [issue14933] Misleading documentation about weakrefs
In-Reply-To: <1338211059.84.0.366871304361.issue14933@psf.upfronthosting.co.za>
Message-ID: <E1Sfa7p-0005nR-7h@dinsdale.python.org>


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

New changeset 69177ff1a643 by Antoine Pitrou in branch '3.2':
Issue #14933: fix misleading doc about weakref support in extension types.
http://hg.python.org/cpython/rev/69177ff1a643

New changeset b17c8005e08a by Antoine Pitrou in branch 'default':
Issue #14933: fix misleading doc about weakref support in extension types.
http://hg.python.org/cpython/rev/b17c8005e08a

New changeset 0ac1f90954dc by Antoine Pitrou in branch '2.7':
Issue #14933: fix misleading doc about weakref support in extension types.
http://hg.python.org/cpython/rev/0ac1f90954dc

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

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

From report at bugs.python.org  Fri Jun 15 19:16:14 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Jun 2012 17:16:14 +0000
Subject: [docs] [issue14933] Misleading documentation about weakrefs
In-Reply-To: <1338211059.84.0.366871304361.issue14933@psf.upfronthosting.co.za>
Message-ID: <1339780574.13.0.940579264552.issue14933@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jun 16 11:08:48 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 16 Jun 2012 09:08:48 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1339837728.49.0.964347100777.issue15068@psf.upfronthosting.co.za>


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


----------
nosy: +flox

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

From report at bugs.python.org  Sat Jun 16 16:21:08 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Sat, 16 Jun 2012 14:21:08 +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: <1339856468.35.0.707429841155.issue13498@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
nosy: +hynek

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

From report at bugs.python.org  Sat Jun 16 18:41:45 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 16 Jun 2012 16:41:45 +0000
Subject: [docs] [issue15063] Source code links for JSON documentation
In-Reply-To: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za>
Message-ID: <1339864904.86.0.189737847195.issue15063@psf.upfronthosting.co.za>


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

The source links were added by Raymond for selected modules that he judged readable, well-written and useful companions to the documentation.  For the json.encoder and decoder modules, I don?t think this is the case: the rst doc should explain well the behavior of the default encoder/decoder and how to subclass to change this behavior.  Did you see something interesting in the code?  I only had a look through it quickly, and saw the mix of C and Python code (which can be non-trivial to follow) and a dubious idiom (binding globals as locals to optimize access on CPython?doesn?t work on PyPy).  My opinion is -1; what do other people think?

----------
nosy: +eric.araujo, rhettinger
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Jun 16 19:20:48 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Jun 2012 17:20:48 +0000
Subject: [docs] [issue15063] Source code links for JSON documentation
In-Reply-To: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za>
Message-ID: <1339867248.83.0.937183965635.issue15063@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
resolution:  -> rejected

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

From christopher.mahan at bankofamerica.com  Tue Jun 12 22:25:32 2012
From: christopher.mahan at bankofamerica.com (Mahan, Christopher)
Date: Tue, 12 Jun 2012 20:25:32 +0000
Subject: [docs] bug in doc (formatting)
Message-ID: <D3BB93365F230C43A541FF9B627AB65B10AADCC2@smtp_mail.bankofamerica.com>

in
http://docs.python.org/library/string.html

the header Deprecated String Functions seems to include string functions that are not deprecated.

Thanks!

Chris Mahan
Representations and Warranties Group
Business Operations Support - Reporting & Analytics
Countrywide Home Loans*
4500 Park Granada, Calabasas, CA 91302
(213) 345-9879
christopher.mahan at bankofamerica.com

*Countrywide Home Loans, Inc. serves as an agent for Bank of America, First Franklin, and Merrill Lynch in connection with certain residential mortgage loan services.

Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Home Loans or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession.

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120612/eae3b3f1/attachment.html>

From davestechshop at gmail.com  Wed Jun  6 22:32:45 2012
From: davestechshop at gmail.com (Dave)
Date: Wed, 6 Jun 2012 16:32:45 -0400
Subject: [docs] [Tutor] special attributes naming confusion
In-Reply-To: <CAH=dxU7Z3XfT25RjomNBqQoXjA088titeNbNNnaX31p39J4AfQ@mail.gmail.com>
References: <CAH=dxU54VsKR=E+Ya0rXqeX-tDgy6pPMTCnBKT+rZ93qDgOn=g@mail.gmail.com>
	<jqobnu$tqu$1@dough.gmane.org>
	<CAH=dxU7Z3XfT25RjomNBqQoXjA088titeNbNNnaX31p39J4AfQ@mail.gmail.com>
Message-ID: <CAH=dxU4eRdhjphdL6aGZuKnajefB0YA66-6SJJ49HW1riaRroQ@mail.gmail.com>

I'm not sure where this comment belongs, but I want to share my perspective
on the documentation of these special method names. In the following
section there is an inconsistency which could be confusing to someone just
learning Python (e.g., me).

In the sentence on implementing custom mapping objects, the recommended
method names are listed as the short calling names: eys(), values(), items(),
etc.

But, in contrast, in the sentence on implementing sequence types, the
recommended method names are listed as the double underscore internal
implementation names: __add__(), __radd__(), __iadd__(), __mul__(), etc.

Here's the section of the documentation with this inconsistency. I think it
would help to use one or the other of these pairs (calling name vs.
internal implementation name) consistently in this section.

3.4.6. Emulating container
types?<http://docs.python.org/reference/datamodel.html#emulating-container-types>

The following methods can be defined to implement container objects.
Containers usually are sequences (such as lists or tuples) or mappings
(like dictionaries), but can represent other containers as well. The first
set of methods is used either to emulate a sequence or to emulate a
mapping; the difference is that for a sequence, the allowable keys should
be the integers *k* for which 0 <= k < N where *N* is the length of the
sequence, or slice objects, which define a range of items. (For backwards
compatibility, the method
__getslice__()<http://docs.python.org/reference/datamodel.html#object.__getslice__>(see
below) can also be defined to handle simple, but not extended slices.)
It is also recommended that mappings provide the methods keys(), values(),
items(), has_key(), get(), clear(), setdefault(), iterkeys(), itervalues(),
iteritems(), pop(), popitem(),
copy()<http://docs.python.org/library/copy.html#module-copy>,
and update() behaving similar to those for Python?s standard dictionary
objects. The UserDict<http://docs.python.org/library/userdict.html#module-UserDict>module
provides a
DictMixin class to help create those methods from a base set of
__getitem__()<http://docs.python.org/reference/datamodel.html#object.__getitem__>,
__setitem__()<http://docs.python.org/reference/datamodel.html#object.__setitem__>,
__delitem__()<http://docs.python.org/reference/datamodel.html#object.__delitem__>,
and keys(). Mutable sequences should provide methods append(), count(),
index(), extend(), insert(), pop(), remove(), reverse() and sort(), like
Python standard list objects. Finally, sequence types should implement
addition (meaning concatenation) and multiplication (meaning repetition) by
defining the methods
__add__()<http://docs.python.org/reference/datamodel.html#object.__add__>,
__radd__() <http://docs.python.org/reference/datamodel.html#object.__radd__>,
__iadd__() <http://docs.python.org/reference/datamodel.html#object.__iadd__>,
__mul__() <http://docs.python.org/reference/datamodel.html#object.__mul__>,
__rmul__() <http://docs.python.org/reference/datamodel.html#object.__rmul__>and
__imul__() <http://docs.python.org/reference/datamodel.html#object.__imul__>described
below; they should not define
__coerce__()<http://docs.python.org/reference/datamodel.html#object.__coerce__>or
other numerical operators. It is recommended that both mappings and
sequences implement the
__contains__()<http://docs.python.org/reference/datamodel.html#object.__contains__>method
to allow efficient use of the
in operator; for mappings, in should be equivalent of has_key(); for
sequences, it should search through the values. It is further recommended
that both mappings and sequences implement the
__iter__()<http://docs.python.org/reference/datamodel.html#object.__iter__>method
to allow efficient iteration through the container; for mappings,
__iter__() <http://docs.python.org/reference/datamodel.html#object.__iter__>should
be the same as
iterkeys(); for sequences, it should iterate through the values.
This is in addition to some missing documentation regarding mention how
some of the special method names should be conveniently called in code.
(See below.)


On Wed, Jun 6, 2012 at 3:59 PM, Dave <davestechshop at gmail.com> wrote:

>
>
> On Wed, Jun 6, 2012 at 3:40 PM, Mark Lawrence <breamoreboy at yahoo.co.uk>wrote:
>
>> On 06/06/2012 20:19, Dave wrote:
>>
>>> I was reading some tutorial material on creating iterators. It shows the
>>> following example implementation of an iterator:
>>>
>>> class Reverse:
>>>     """Iterator for looping over a sequence backwards."""
>>>     def __init__(self, data):
>>>         self.data = data
>>>         self.index = len(data)
>>>     def __iter__(self):
>>>         return self
>>>     def next(self):
>>>         if self.index == 0:
>>>             raise StopIteration
>>>         self.index = self.index - 1
>>>         return self.data[self.index]
>>>
>>>
>>> My question is how was I supposed to kinow that the function I call using
>>> the name iter() is implemented using the name __iter__()?
>>>
>>> Is there a rule that describes when I would implement an attribute name
>>> with leading and trailing double underscores, and then call it without
>>> those underscores? How many names like this exist in Python? Are these
>>> special cases or is there a general rule that leading and trailing double
>>> underscores get dropped when calling functions that were implemented with
>>> these names? I'm trying to understand the big picture as far as how
>>> Python
>>> works when it comes to this situation. Thanks.
>>>
>>>
>> Try this to start with http://docs.python.org/**reference/datamodel.html#
>> **special-method-names<http://docs.python.org/reference/datamodel.html#special-method-names>.
>> Note this is for Python 2.7.3, there may be differences in Python 3.x.
>>
>> --
>>
>
> Actually, I think I'm getting it now... as I read more of this page I see
> that there is no single generalization. These are indeed all special cases.
>
> But the documentation does appear to be incomplete. It leaves out the
> mapping to the name or symbol that should be used to call the special
> function in some cases. In particular, in the case of __iter(self), which
> is one of the first ones I looked at, it doesn't mention that this is
> usually called via iter(). It does mention how it would be called for
> mapping containers, however (i.e., iterkeys()).
>  object.__iter__(*self*)
>
> This method is called when an iterator is required for a container. This
> method should return a new iterator object that can iterate over all the
> objects in the container. For mappings, it should iterate over the keys of
> the container, and should also be made available as the method iterkeys().
>
> But as I read more, I see that much of the documentation does mention how
> these special method names are called. For example:
>
> object.__lt__(*self*, *other*) object.__le__(*self*, *other*)?<http://docs.python.org/reference/datamodel.html#object.__le__>
> object.__eq__(*self*, *other*) object.__ne__(*self*, *other*) object.
> __gt__(*self*, *other*) object.__ge__(*self*, *other*)
>
> New in version 2.1.
>
> These are the so-called ?rich comparison? methods, and are called for
> comparison operators in preference to __cmp__()<http://docs.python.org/reference/datamodel.html#object.__cmp__>below. The correspondence between operator symbols and method names is as
> follows: x<y calls x.__lt__(y), x<=y calls x.__le__(y), x==y calls
> x.__eq__(y), x!=y and x<>y call x.__ne__(y), x>y calls x.__gt__(y), and
> x>=y calls x.__ge__(y).
> I think there is enough info at this page to answer my question as well as
> I need it answered right now. Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120606/1ff25c92/attachment-0001.html>

From intel.dork at gmail.com  Mon Jun 11 18:51:43 2012
From: intel.dork at gmail.com (Intel Dork)
Date: Mon, 11 Jun 2012 09:51:43 -0700
Subject: [docs] Documentation issue with web site for 2.6.7
Message-ID: <CACMd8DM7PA9EnXL787FcsdgDbScRE0nefKLKd=zibHUa+v2Wcw@mail.gmail.com>

It seems that the "Quick Search" for the 2.6.7 version of the documentation
has gone missing. I see it for all other versions. Any way to restore that
functionality?

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

From James.A.Paget at aero.org  Thu Jun  7 01:13:39 2012
From: James.A.Paget at aero.org (James A Paget)
Date: Wed, 6 Jun 2012 16:13:39 -0700
Subject: [docs] Broken Link to Expat Project home page
Message-ID: <OF616F152D.FF277B1F-ON88257A15.007E7670-88257A15.007F97AA@notes.aero.org>

Dear Python Documentation Team,

Thanks for your excellent documentation of the Python language at 
http://docs.python.org.  I have found it very useful!

In section 19.13 (xml.parsers.expat, 
http://docs.python.org/library/pyexpat.html)  I have discovered a broken 
link to the Expat project home page.  The link is to http://www.expat.org, 
but the current web address is http://expat.sourceforge.net.  Please fix 
this link, or if docs.python.org operates like a Wiki, point me to 
instructions on how I can fix this for you.

-- Jim Paget
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120606/c0f51686/attachment.html>

From jmillarusiskin at seccuris.com  Mon Jun 11 20:00:01 2012
From: jmillarusiskin at seccuris.com (Josh Millar-Usiskin)
Date: Mon, 11 Jun 2012 13:00:01 -0500
Subject: [docs] cookielib documentation
Message-ID: <CBFB9C51.41D%jmillarusiskin@seccuris.com>

A non-text attachment was scrubbed...
Name: smime.p7m
Type: application/pkcs7-mime
Size: 5176 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20120611/28bd018a/attachment.p7c>

From malaclypse2 at gmail.com  Wed Jun  6 22:45:05 2012
From: malaclypse2 at gmail.com (Jerry Hill)
Date: Wed, 6 Jun 2012 16:45:05 -0400
Subject: [docs] [Tutor] special attributes naming confusion
In-Reply-To: <CAH=dxU4eRdhjphdL6aGZuKnajefB0YA66-6SJJ49HW1riaRroQ@mail.gmail.com>
References: <CAH=dxU54VsKR=E+Ya0rXqeX-tDgy6pPMTCnBKT+rZ93qDgOn=g@mail.gmail.com>
	<jqobnu$tqu$1@dough.gmane.org>
	<CAH=dxU7Z3XfT25RjomNBqQoXjA088titeNbNNnaX31p39J4AfQ@mail.gmail.com>
	<CAH=dxU4eRdhjphdL6aGZuKnajefB0YA66-6SJJ49HW1riaRroQ@mail.gmail.com>
Message-ID: <CADwdpyZUZdzrjxW+m_SpuNc71-cmFTQMEDceiTj1KiYZ_kWRww@mail.gmail.com>

On Wed, Jun 6, 2012 at 4:32 PM, Dave <davestechshop at gmail.com> wrote:
> I'm not sure where this comment belongs, but I want to share my perspective
> on the documentation of these special method names. In the following section
> there is an inconsistency which could be confusing to someone just learning
> Python (e.g., me).
>
> In the sentence on implementing custom mapping objects, the recommended
> method names are listed as the short calling names: eys(), values(),
> items(), etc.
>
> But, in contrast, in the sentence on implementing sequence types, the
> recommended method names are listed as the double underscore internal
> implementation names: __add__(), __radd__(), __iadd__(), __mul__(), etc.
>
> Here's the section of the documentation with this inconsistency. I think it
> would help to use one or the other of these pairs (calling name vs. internal
> implementation name) consistently in this section.

Those aren't pairs, where you can implement either one.  You have to
implement ALL of those methods to correctly emulate one of the built
in container classes.  The difference is that the "normal" method
names (the ones without double underscores) are meant to be called
directly on an instance of your class.  The double underscored names
are called by the internals of python, often in a variety of different
places.

For instance, the __iter__() method is called by the iter() built-in.
It can also called by any other piece of code that needs to acquire an
iterator from a generic container object.  There is no list of all
such pieces of code that could ever call the __iter__() method of your
object.

Jerry

From naijaexboy at gmail.com  Mon Jun  4 20:15:40 2012
From: naijaexboy at gmail.com (ayodele akingbulu)
Date: Mon, 4 Jun 2012 19:15:40 +0100
Subject: [docs] issues with installing and importing rdflib and rdfextras in
 python and eclipse pydev
Message-ID: <CAPN4LiUruXgR-SNJ9ZXRGP8mm7-Jsb_Ey4SzJ9Sy=7Pe3aAW+Q@mail.gmail.com>

Hi,

I have issues with the installation of rdflib and rdfextras packages on
windows for python 3.2.3. I cannot find anywhere in the document detailing
how to install this packages and succesfully import them in a python
program. not to talk less of accessing it on eclipse indigo.

Kindly help to look into this issue as it might be a bug.

Regards,
Ayo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120604/2409d3d8/attachment.html>

From nicholas.e.merrill at gmail.com  Tue Jun 12 01:18:59 2012
From: nicholas.e.merrill at gmail.com (Nick Merrill)
Date: Mon, 11 Jun 2012 19:18:59 -0400
Subject: [docs] strftime %S
Message-ID: <CAMcXY-JAkgkqNXm6LLB3=q_xG1C0trEcm=D2aDa1U4XxHbWO3w@mail.gmail.com>

[image: Inline image 1]
strftime("%S") should be [0,59] , right? Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120611/4779ff29/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2012-06-11 at 7.17.10 PM.png
Type: image/png
Size: 21394 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20120611/4779ff29/attachment-0001.png>

From shaddih at gmail.com  Mon Jun  4 19:45:53 2012
From: shaddih at gmail.com (Shaddi Hasan)
Date: Mon, 4 Jun 2012 10:45:53 -0700
Subject: [docs] minor documentation bug in random
Message-ID: <CAHrMpFi7C5GXCPynkAzr+vJusP2payVPVR2B9dv_C-cHwtNKEA@mail.gmail.com>

Hi there,

I think I may have found a minor documentation bug (really, typo) in
the documentation for Random. See:

http://docs.python.org/library/random.html#random.setstate

I believe it should read: "state should have been obtained from a
previous call to getstate(), and setstate() restores the internal
state of the generator to what it was at the time **getstate()** was
called."

Apologies if the mistake is in my understanding rather than the
documentation. :)

Shaddi

From teejahkirton at live.com  Sat Jun  9 22:04:12 2012
From: teejahkirton at live.com (e.kirton)
Date: Sat, 9 Jun 2012 16:04:12 -0400
Subject: [docs] python bug i thinkso
Message-ID: <BLU0-SMTP2823E888EE7356D0AE2C282B1F10@phx.gbl>

This is my code: print('#1')

one = input ()

one = int (one)

print('#2')

two = input ()

two = int (two)

ans = (one)+(two)

print ('answer') + repr (ans)

then i get this message when working the sum: Traceback (most recent call
last):

  File "C:\Python32\my.py", line 8, in <module>

    print ('answer') + repr (ans)

TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

Is it a bug or is it justme

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

From sandro.tosi at gmail.com  Sat Jun 16 23:47:13 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 16 Jun 2012 23:47:13 +0200
Subject: [docs] python bug i thinkso
In-Reply-To: <BLU0-SMTP2823E888EE7356D0AE2C282B1F10@phx.gbl>
References: <BLU0-SMTP2823E888EE7356D0AE2C282B1F10@phx.gbl>
Message-ID: <CAB4XWXyE8DOak-jZ1OsWJMw20AMS3sqfPan1-Q23q_L25UnCwA@mail.gmail.com>

Hello,
this mailing list is about bugs/enhancements to CPython documentation,
and your email doesn't fit this description. I'd suggest to contact a
user support forum, such as
http://mail.python.org/mailman/listinfo/python-list

Anyway...

On Sat, Jun 9, 2012 at 10:04 PM, e.kirton <teejahkirton at live.com> wrote:
> ? File "C:\Python32\my.py", line 8, in <module>
>
> ??? print ('answer') + repr (ans)
>
> TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

because you're summing "print ('answer')" with "repr(ans)"; if you
want to print 'answer' and the sum, then you can't use '+' this way
but f.e. the string formatting syntax:
http://docs.python.org/py3k/library/string.html#format-examples

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

From eliben at gmail.com  Sun Jun 17 05:15:56 2012
From: eliben at gmail.com (Eli Bendersky)
Date: Sun, 17 Jun 2012 06:15:56 +0300
Subject: [docs] Broken Link to Expat Project home page
In-Reply-To: <OF616F152D.FF277B1F-ON88257A15.007E7670-88257A15.007F97AA@notes.aero.org>
References: <OF616F152D.FF277B1F-ON88257A15.007E7670-88257A15.007F97AA@notes.aero.org>
Message-ID: <CAF-Rda_jpaGN0-LkL9AYWt+mETre8hfWMztK3L8Wn=c1kmVF5w@mail.gmail.com>

On Thu, Jun 7, 2012 at 2:13 AM, James A Paget <James.A.Paget at aero.org>wrote:

> Dear Python Documentation Team,
>
> Thanks for your excellent documentation of the Python language at
> http://docs.python.org.  I have found it very useful!
>
> In section 19.13 (xml.parsers.expat,
> http://docs.python.org/library/pyexpat.html)  I have discovered a broken
> link to the Expat project home page.  The link is to http://www.expat.org,
> but the current web address is http://expat.sourceforge.net.  Please fix
> this link, or if docs.python.org operates like a Wiki, point me to
> instructions on how I can fix this for you.
>

The link goes to www.libexpat.org, which appears to be functional and
containing the expected information. Can you be more precise about the
exact location of the invalid link?

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

From report at bugs.python.org  Sun Jun 17 05:20:28 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 17 Jun 2012 03:20:28 +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: <1339903228.5.0.61125564261.issue13823@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/issue13823>
_______________________________________

From report at bugs.python.org  Sun Jun 17 06:21:15 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Jun 2012 04:21:15 +0000
Subject: [docs] [issue15088] PyGen_NeedsFinalizing is public,
	but undocumented
In-Reply-To: <1339906861.99.0.42415214654.issue15088@psf.upfronthosting.co.za>
Message-ID: <1339906875.28.0.676379912797.issue15088@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jun 17 07:16:04 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jun 2012 05:16:04 +0000
Subject: [docs] [issue13783] Clean up PEP 380 C API additions
In-Reply-To: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za>
Message-ID: <E1Sg7qF-0000iK-6d@dinsdale.python.org>


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

New changeset cfbf6aa5c9e3 by Nick Coghlan in branch 'default':
Issue #13783: the PEP 380 implementation no longer expands the public C API
http://hg.python.org/cpython/rev/cfbf6aa5c9e3

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

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

From report at bugs.python.org  Sun Jun 17 07:45:33 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jun 2012 05:45:33 +0000
Subject: [docs] [issue13783] Clean up PEP 380 C API additions
In-Reply-To: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za>
Message-ID: <E1Sg8Il-0002NI-NK@dinsdale.python.org>


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

New changeset 438b861e2edb by Nick Coghlan in branch 'default':
Issue #13783: PEP 380 cleanup part 2, using the new identifier APIs in the generator implementation
http://hg.python.org/cpython/rev/438b861e2edb

----------

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

From report at bugs.python.org  Sun Jun 17 07:48:44 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Jun 2012 05:48:44 +0000
Subject: [docs] [issue13783] Clean up PEP 380 C API additions
In-Reply-To: <1326521987.14.0.4759346281.issue13783@psf.upfronthosting.co.za>
Message-ID: <1339912124.93.0.156927753895.issue13783@psf.upfronthosting.co.za>


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

I left the name of the new private API as _PyGen_FetchStopIterationValue. If anyone wants to make it public, they can raise a new issue to give it a more appropriate name (and move the definition accordingly).

PyStopIteration_Create is simply gone, replaced by the underlying call.

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

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

From report at bugs.python.org  Sun Jun 17 11:30:40 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Jun 2012 09:30: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: <1339925440.31.0.601978515001.issue13823@psf.upfronthosting.co.za>


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


----------
nosy: +flox

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

From report at bugs.python.org  Sun Jun 17 13:33:13 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 17 Jun 2012 11:33:13 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1339932793.03.0.512547712739.issue13515@psf.upfronthosting.co.za>


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

The new theme of the docs should solve the issue about the scary red boxes, but the original report is still valid.

----------

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

From report at bugs.python.org  Sun Jun 17 13:42:25 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 17 Jun 2012 11:42:25 +0000
Subject: [docs] [issue14469] Python 3 documentation links
In-Reply-To: <1333298580.51.0.119482106967.issue14469@psf.upfronthosting.co.za>
Message-ID: <1339933345.42.0.283103461543.issue14469@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/issue14469>
_______________________________________

From report at bugs.python.org  Sun Jun 17 14:13:57 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Jun 2012 12:13:57 +0000
Subject: [docs] [issue14840] Tutorial: Add a bit on the difference between
	tuples and	lists
In-Reply-To: <1337273770.17.0.397614380243.issue14840@psf.upfronthosting.co.za>
Message-ID: <E1SgEMb-0001f2-7p@dinsdale.python.org>


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

New changeset bb63919cde6e by Ezio Melotti in branch '2.7':
#14840: Add a bit on the difference between tuples and lists.  Initial patch by Zachary Ware.
http://hg.python.org/cpython/rev/bb63919cde6e

New changeset 3550416d83b3 by Ezio Melotti in branch '3.2':
#14840: Add a bit on the difference between tuples and lists.  Initial patch by Zachary Ware.
http://hg.python.org/cpython/rev/3550416d83b3

New changeset 2fad115408e9 by Ezio Melotti in branch 'default':
#14840: merge with 3.2.
http://hg.python.org/cpython/rev/2fad115408e9

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

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

From report at bugs.python.org  Sun Jun 17 14:15:47 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 17 Jun 2012 12:15:47 +0000
Subject: [docs] [issue14840] Tutorial: Add a bit on the difference between
	tuples and	lists
In-Reply-To: <1337273770.17.0.397614380243.issue14840@psf.upfronthosting.co.za>
Message-ID: <1339935347.35.0.745026847554.issue14840@psf.upfronthosting.co.za>


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

Fixed, thanks for the patch!

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

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

From report at bugs.python.org  Sun Jun 17 16:23:56 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sun, 17 Jun 2012 14:23:56 +0000
Subject: [docs] [issue15097] Improving wording on the thread-safeness of
	import
Message-ID: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

http://docs.python.org/library/threading.html#importing-in-threaded-code

Currently, the documentation states
"Firstly, other than in the main module, an import should not have the side effect of spawning a new thread and then waiting for that thread in any way. Failing to abide by this restriction can lead to a deadlock if the spawned thread directly or indirectly attempts to import a module."

which, I think, fails to make the main point: a call to import acquires the import lock. A call to import from a second thread will thus block.

As such, I would suggest rephrasing it to something like:
"Firstly, an import acquires the import lock for that thread. Therefore, the import should not have the side effect of waiting for a different thread in any way, as this can lead to a deadlock if that thread directly or indirectly attempts to import a module."

There are two additional points that might be interesting to note:
(1) Any module can be imported. If the import causes a deadlock, that is a bad thing. Every module *will* be imported by tools such as nosetests.
(1b) so: never, ever, have code that causes locks in a different thread  in module level code witout 'if __name__=="__main__" ' blocks?

(2) The lock is also acquired if a module has already been imported. For instance, in

import sys # (1)
def f():
    import sys # (2)

the import lock is acquired in (1) /and/ (2).


Adding example code and/or a flow diagram might be a bit too much, but it does clarify how easy it is to make this mistake. See the attached for an example (both a simple example script, as well as a flow diagram explaining what happens).

----------
assignee: docs at python
components: Documentation
files: deadlock.py
messages: 163068
nosy: docs at python, valhallasw
priority: normal
severity: normal
status: open
title: Improving wording on the thread-safeness of import
type: enhancement
Added file: http://bugs.python.org/file26037/deadlock.py

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

From report at bugs.python.org  Sun Jun 17 16:25:16 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sun, 17 Jun 2012 14:25:16 +0000
Subject: [docs] [issue15097] Improving wording on the thread-safeness of
	import
In-Reply-To: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za>
Message-ID: <1339943116.88.0.537681072773.issue15097@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


Removed file: http://bugs.python.org/file26037/deadlock.py

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

From report at bugs.python.org  Sun Jun 17 16:26:08 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sun, 17 Jun 2012 14:26:08 +0000
Subject: [docs] [issue15097] Improving wording on the thread-safeness of
	import
In-Reply-To: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za>
Message-ID: <1339943168.1.0.311615962482.issue15097@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


Added file: http://bugs.python.org/file26038/deadlock.py

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

From report at bugs.python.org  Sun Jun 17 16:51:24 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Jun 2012 14:51:24 +0000
Subject: [docs] [issue15097] Improving wording on the thread-safeness of
	import
In-Reply-To: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za>
Message-ID: <4FDDEEE9.2050006@v.loewis.de>


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

> which, I think, fails to make the main point:

I disagree. It currently makes it main point, but stops doing so
under your rephrasing. The main point of that section is

"While the import machinery is thread-safe, there are two key
restrictions on threaded imports due to inherent limitations in the way
that thread-safety is provided:"

The existence of an import lock is deliberately omitted from the text,
and the reader is supposed to abide by the restriction as written
regardless of the motivation behind it.

> Adding example code and/or a flow diagram might be a bit too much,
> but it does clarify how easy it is to make this mistake. See the
> attached for an example (both a simple example script, as well as a
> flow diagram explaining what happens).

The entire notion of an import lock is obsolete. Python 3.3 does not
have that anymore.

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

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

From report at bugs.python.org  Sun Jun 17 17:23:00 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 17 Jun 2012 15:23:00 +0000
Subject: [docs] [issue14840] Tutorial: Add a bit on the difference between
	tuples and	lists
In-Reply-To: <1337273770.17.0.397614380243.issue14840@psf.upfronthosting.co.za>
Message-ID: <1339946580.94.0.24271124771.issue14840@psf.upfronthosting.co.za>


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

Great addition, thanks!

----------

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

From report at bugs.python.org  Sun Jun 17 17:38:47 2012
From: report at bugs.python.org (Merlijn van Deen)
Date: Sun, 17 Jun 2012 15:38:47 +0000
Subject: [docs] [issue15097] Improving wording on the thread-safeness of
	import
In-Reply-To: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za>
Message-ID: <1339947527.89.0.899071676959.issue15097@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

First off, thank you for your response.

> The existence of an import lock is deliberately omitted from the text,
> and the reader is supposed to abide by the restriction as written
> regardless of the motivation behind it.

> The entire notion of an import lock is obsolete. Python 3.3 does not
> have that anymore.

" This warning is still valid but for a different reason " or " this warning is no longer valid in 3.3 "?


Assuming the first (which is what I guess based on the fact the deadlock still occurs in 3.3), I think the text can still be improved; the current wording suggests to me

a) it's OK to wait for a thread as long as you did not create it

and

b) it's OK to import something that waits for a thread as long as you do it from the main module

 - while both cases can still lead to a deadlock. 

so, leaving the implementation details out, this is my suggestion:

"Firstly, an import should not have the side effect of waiting for a thread in any way. This can lead to a deadlock if that thread directly or indirectly attempts to import a module."

----------

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

From sandro.tosi at gmail.com  Sun Jun 17 18:48:10 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 17 Jun 2012 18:48:10 +0200
Subject: [docs] Documentation issue with web site for 2.6.7
In-Reply-To: <CACMd8DM7PA9EnXL787FcsdgDbScRE0nefKLKd=zibHUa+v2Wcw@mail.gmail.com>
References: <CACMd8DM7PA9EnXL787FcsdgDbScRE0nefKLKd=zibHUa+v2Wcw@mail.gmail.com>
Message-ID: <CAB4XWXwjcEyUC_pGK2B7UZieFh+2fMREFobrFhCw=teyKwdyeA@mail.gmail.com>

Hello Alex,

On Mon, Jun 11, 2012 at 6:51 PM, Intel Dork <intel.dork at gmail.com> wrote:
> It seems that the "Quick Search" for the 2.6.7 version of the documentation
> has gone missing. I see it for all other versions. Any way to restore that
> functionality?

I've just tried and it seems to work fine: can you please check again,
and in case let us know what you're exactly doing, so we can
replicate.

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

From matrixhasu at gmail.com  Sun Jun 17 19:01:54 2012
From: matrixhasu at gmail.com (Sandro Tosi)
Date: Sun, 17 Jun 2012 19:01:54 +0200
Subject: [docs] strftime %S
In-Reply-To: <CAMcXY-JAkgkqNXm6LLB3=q_xG1C0trEcm=D2aDa1U4XxHbWO3w@mail.gmail.com>
References: <CAMcXY-JAkgkqNXm6LLB3=q_xG1C0trEcm=D2aDa1U4XxHbWO3w@mail.gmail.com>
Message-ID: <CAB4XWXwNpQWkFCGGavpRdDbc8wSRH-9JEhJ6w9Ekx91iHL_ZGQ@mail.gmail.com>

Hello Nick,

On Tue, Jun 12, 2012 at 1:18 AM, Nick Merrill
<nicholas.e.merrill at gmail.com>wrote:

> [image: Inline image 1]
> strftime("%S") should be [0,59] , right? Thanks!
>

You don't say what version of the documentation you're reading but at the
most right column of that table for the '%S' directive there's a note:

    The range really is 0 to 61; according to the Posix standard this
accounts for leap seconds and the (very rare) double leap seconds. The time
module may produce and does accept leap seconds since it is based on the
Posix standard, but the datetime module does not accept leap seconds in
strptime() input nor will it produce them in strftime() output.

http://docs.python.org/library/datetime.html?highlight=strftime#strftime-and-strptime-behavior

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120617/27120a84/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2012-06-11 at 7.17.10 PM.png
Type: image/png
Size: 21394 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20120617/27120a84/attachment-0001.png>

From sandro.tosi at gmail.com  Sun Jun 17 19:37:17 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 17 Jun 2012 19:37:17 +0200
Subject: [docs] bug in doc (formatting)
In-Reply-To: <D3BB93365F230C43A541FF9B627AB65B10AADCC2@smtp_mail.bankofamerica.com>
References: <D3BB93365F230C43A541FF9B627AB65B10AADCC2@smtp_mail.bankofamerica.com>
Message-ID: <CAB4XWXz70rNywXP1GyWAWkPnv2VnbET0bt+Sw5yD-R2huZRcTA@mail.gmail.com>

Hello Christopher,
thanks for your email.

On Tue, Jun 12, 2012 at 10:25 PM, Mahan, Christopher
<christopher.mahan at bankofamerica.com> wrote:
> http://docs.python.org/library/string.html
>
> the header Deprecated String Functions seems to include string functions
> that are not deprecated.

Even thought not all those functions are deprecated explicitly, you
should consider them "deprecated" in the sense that you should not use
them, but the same methods provided by string/unicode object; f.e.

# deprecated
>>> string.capitalize('asdf asdf')
'Asdf asdf'

# correct
>>> 'asdf asdf'.capitalize()
'Asdf asdf'

Regards,
-- 
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 Jun 18 14:12:26 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Jun 2012 12:12:26 +0000
Subject: [docs] [issue15099] exec of function doesn't call __getitem__ or
	__missing__	on undefined global
In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za>
Message-ID: <1340021546.75.0.752321482362.issue15099@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This looks like a documentation issue:  it's well documented that in the exec statement, the globals dictionary must be a dict.  What's not so clear from the documentation (AFAICT) is that it must actually have *type* dict, rather than merely being an instance of dict.  (Or, from experimentation, it *can* be an instance of a dict subclass, but the underlying C-implemented dict methods are called directly, so overloads for __getitem__ and the like don't have any effect.)

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, mark.dickinson
stage:  -> needs patch
type: behavior -> 
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jun 18 14:34:28 2012
From: report at bugs.python.org (John Firestone)
Date: Mon, 18 Jun 2012 12:34:28 +0000
Subject: [docs] [issue15099] exec of function doesn't call __getitem__ or
	__missing__	on undefined global
In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za>
Message-ID: <1340022868.32.0.436923241001.issue15099@psf.upfronthosting.co.za>


John Firestone <johnf at freenet.de> added the comment:

I find the behavior inconsistent. As you can see from this example, the exec'uted code *does* call the instance's overloaded __getitem__ and __missing__ methods when outside a function, but doesn't when inside.

----------

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

From report at bugs.python.org  Mon Jun 18 14:50:14 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Jun 2012 12:50:14 +0000
Subject: [docs] [issue15099] exec of function doesn't call __getitem__ or
	__missing__	on undefined global
In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za>
Message-ID: <1340023814.34.0.385085789347.issue15099@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> As you can see from this example, the exec'uted code *does* call the 
> instance's overloaded __getitem__ and __missing__ methods when outside a 
> function, but doesn't when inside.

Yep;  that's because the 's' and 'f' lookups at top level are *local* lookups, and the 's' lookup from inside the body of 'f' is done as a *global* lookup (as explained in the docs here: [1]).  In the exec statement, the locals can be any mapping-like object.  The behaviour's a bit clearer if you pass separate globals and locals dictionaries:

>>> source = """\
... print s
... def f():
...     print s
... f()
... """
>>> locals = {'s': 1729}
>>> globals = {'s': 31415}
>>> exec source in globals, locals
1729
31415


[1] http://docs.python.org/reference/executionmodel.html#interaction-with-dynamic-features

----------

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

From report at bugs.python.org  Mon Jun 18 15:48:26 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Jun 2012 13:48:26 +0000
Subject: [docs] [issue15099] exec of function doesn't call __getitem__ or
	__missing__	on undefined global
In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za>
Message-ID: <1340027306.05.0.515910728715.issue15099@psf.upfronthosting.co.za>


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

With Python3 though, __getitem__ seems called though.
OTOH the 'print' symbol is not found, even though the Dict1 got a '__builtins__' entry added.

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

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

From report at bugs.python.org  Mon Jun 18 19:45:03 2012
From: report at bugs.python.org (John Firestone)
Date: Mon, 18 Jun 2012 17:45:03 +0000
Subject: [docs] [issue15099] exec of function doesn't call __getitem__ or
	__missing__	on undefined global
In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za>
Message-ID: <1340041502.91.0.343406168254.issue15099@psf.upfronthosting.co.za>


John Firestone <johnf at freenet.de> added the comment:

Thank you all for the quick and interesting responses!

Here is another example, this time showing a simple
    s
sometimes behaves like
    globals()['s']
and sometimes doesn't.

class Dict(dict):
    def __getitem__(self, key):
        if key == 's':
            return 'got s'
        return dict.__getitem__(self, key)

dct = Dict()
dct['the_dict'] = dct
print 0, id(dct)

source = """if 1:
    print '1', id(globals()), globals() is the_dict
    print ' ', globals()['s']
    print ' ', s
    def f():
        print '2', id(globals()), globals() is the_dict
        print ' ', globals()['s']
        print ' ', s
        print '3'
    f()"""

exec(source, dct)


Python 2.7.3 (v2.7.3:70274d53c1dd, Apr  9 2012, 20:32:06) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
>>> import curiosity2
0 2459928
1 2459928 True
  got s
  got s
2 2459928 True
  got s
 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "curiosity2.py", line 22, in <module>
    exec(source, dct)
  File "<string>", line 10, in <module>
  File "<string>", line 8, in f
NameError: global name 's' is not defined
>>>

----------
Added file: http://bugs.python.org/file26044/curiosity2.py

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

From report at bugs.python.org  Mon Jun 18 20:42:27 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Jun 2012 18:42:27 +0000
Subject: [docs] [issue15099] exec of function doesn't call __getitem__ or
	__missing__	on undefined global
In-Reply-To: <1340017199.64.0.733628658868.issue15099@psf.upfronthosting.co.za>
Message-ID: <1340044947.61.0.333897684994.issue15099@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, this is definitely a dark corner of Python, and one that it seems worth trying to illuminate a bit in the documentation.

----------

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

From report at bugs.python.org  Tue Jun 19 09:04:13 2012
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Tue, 19 Jun 2012 07:04:13 +0000
Subject: [docs] [issue12982] Document that importing .pyo files needs python
	-O
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1340089453.61.0.726967250427.issue12982@psf.upfronthosting.co.za>


Eric O. LEBIGOT <eric.lebigot at normalesup.org> added the comment:

Thank you for this lucid account of the situation, Terry.

As for where in the documentation something additional could be said about .pyo files and the -O option, I must say that it is already mentioned in some relevant places (http://docs.python.org/tutorial/modules.html#compiled-python-files),

However, I can see one other place where some additional information would be useful: in the documentation for the -O option itself (http://docs.python.org/using/cmdline.html#miscellaneous-options). The current documentation only mentions the .pyo-producing effect of -O. Mentioning there that -O is *required* for interpreting .pyo files would be useful.

Thanks!

----------

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

From report at bugs.python.org  Tue Jun 19 10:02:45 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 19 Jun 2012 08:02:45 +0000
Subject: [docs] [issue15104] abusive language in __name__ description
Message-ID: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

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

"It is this environment in which the idiomatic ?conditional script? stanza causes a script to run"

?!?

----------
assignee: docs at python
components: Documentation
messages: 163140
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: abusive language in __name__ description

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

From report at bugs.python.org  Tue Jun 19 10:07:39 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 19 Jun 2012 08:07:39 +0000
Subject: [docs] [issue15104] abusive language in __name__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340093259.29.0.264314558479.issue15104@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

I?m no native speaker but I fail to see anything abusive here.

----------
nosy: +hynek

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

From report at bugs.python.org  Tue Jun 19 10:10:01 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 19 Jun 2012 08:10:01 +0000
Subject: [docs] [issue15104] abusive language in __name__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340093401.89.0.272253714167.issue15104@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It is abusive for those who don't get the meaning. Can you translate it to simple english?

----------

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

From report at bugs.python.org  Tue Jun 19 10:13:35 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 19 Jun 2012 08:13:35 +0000
Subject: [docs] [issue15104] abusive language in __name__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340093615.31.0.575677339107.issue15104@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Maybe "abusive language" is not the right translation from Russian. It could be "coarse language" or "foul language".

----------

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

From report at bugs.python.org  Tue Jun 19 10:23:39 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 19 Jun 2012 08:23:39 +0000
Subject: [docs] [issue15104] abusive language in __name__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340094219.1.0.753298521696.issue15104@psf.upfronthosting.co.za>


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

Which specific word do you consider "??????" or "?????????????"? This is all polite, courteous wording, in my understanding of English. But maybe a native speaker should really comment here.

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

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

From report at bugs.python.org  Tue Jun 19 10:50:26 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 19 Jun 2012 08:50:26 +0000
Subject: [docs] [issue15104] abusive language in __name__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340095826.9.0.46370318491.issue15104@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Ok, the "language is not clear enough" is the queasily polite, serious and corteous substitution for "abusive language" in the title of this issue.

Can you translate it to simple english?

----------

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

From report at bugs.python.org  Tue Jun 19 10:55:02 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 19 Jun 2012 08:55:02 +0000
Subject: [docs] [issue15104] abusive language in __name__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340096102.07.0.630310895095.issue15104@psf.upfronthosting.co.za>


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

"The following fragment can be used to make a Python file both a library and a script".

----------

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

From report at bugs.python.org  Tue Jun 19 10:57:38 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 19 Jun 2012 08:57:38 +0000
Subject: [docs] [issue15104] abusive language in __name__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340096258.12.0.169462663251.issue15104@psf.upfronthosting.co.za>


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

Or, actually 

"When the script executes as this (i.e. "__main__") module, the following conditional statement, which is in wide use and well-known, will cause the script to run".

----------

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

From report at bugs.python.org  Tue Jun 19 11:10:37 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 19 Jun 2012 09:10:37 +0000
Subject: [docs] [issue15104] abusive language in __name__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340097037.02.0.578938698853.issue15104@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Now I get it. That's much better. Thanks. =)

After rereading the description with this new info I spot that __main__ is called a module, which is not true, because it is only a module name. It makes sense to enclose it in quotes in title as well.

I'd reword this:
{{{
This module represents the (otherwise anonymous) scope in which the interpreter?s main program executes ? commands read either from standard input, from a script file, or from an interactive prompt. It is this environment in which the idiomatic ?conditional script? stanza causes a script to run:
}}}

to this:
{{{
This __name__ value represents (otherwise anonymous) scope of the program?s main module in the interpreter. __name__ becomes equal to '__main__' when commands read either from standard input, from a script file, or from an interactive prompt. For example, a common way to add code to module that will only be executable when run as a script is to place it into the following if block:
}}}

Not academic, but practical.

----------

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

From report at bugs.python.org  Tue Jun 19 11:13:33 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 19 Jun 2012 09:13:33 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1340097213.04.0.802924647836.issue15068@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Thanks Antoine.  I tested this in my virtualbox so something new must have happened...  Anyway, the GIL code should not have changed from before, only moved about slightly.  I?ll figure out what happened.

----------
nosy: +kristjan.jonsson

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

From report at bugs.python.org  Tue Jun 19 11:14:15 2012
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 19 Jun 2012 09:14:15 +0000
Subject: [docs] [issue15068] fileinput requires two EOF when reading stdin
In-Reply-To: <1339687174.96.0.0386214807139.issue15068@psf.upfronthosting.co.za>
Message-ID: <1340097255.42.0.180234036317.issue15068@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


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

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

From report at bugs.python.org  Tue Jun 19 14:48:16 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Jun 2012 12:48:16 +0000
Subject: [docs] [issue15104] Unclear language in __main__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340110096.11.0.0030469386472.issue15104@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  I think that chapter could use a more extensive rewrite with some additional information provided.  For example, you actually can have a __main__ module in a package, and anything inside it will execute when the package is run via -m.

The "otherwise anonymous" is a bit misleading, I think.  The real distinction is that when a module is run as a script, __name__ is set to __main__, whereas when it is imported, __name__ is the module name.  This distinction allows a module to easily detect when it is being run as a script rather than imported, and the "idiomatic 'conditional script' stanza" is how to implement the behavior of a module conditionally acting as a script depending on how it is accessed.

----------
nosy: +r.david.murray
stage:  -> needs patch
title: abusive language in __name__ description -> Unclear language in __main__ description
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jun 19 18:17:23 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Jun 2012 16:17:23 +0000
Subject: [docs] [issue15104] Unclear language in __main__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340122643.37.0.604631350947.issue15104@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jun 19 18:38:16 2012
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 19 Jun 2012 16:38:16 +0000
Subject: [docs] [issue14187] add "function annotation" entry to Glossary
In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>
Message-ID: <1340123896.74.0.0178893937343.issue14187@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jun 19 22:15:14 2012
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 19 Jun 2012 20:15:14 +0000
Subject: [docs] [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1340136914.68.0.395275847832.issue12779@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ping.  Does this block 3.3?

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

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

From report at bugs.python.org  Wed Jun 20 15:51:20 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jun 2012 13:51:20 +0000
Subject: [docs] [issue15115] Duplicated Content-Transfer-Encoding header
	when	applying email.encoders
In-Reply-To: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za>
Message-ID: <1340200280.75.0.169898607846.issue15115@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

First of all, I presume you are running this in python2.7, since it doesn't work in python3.  In Python3 MIMEText takes a string as input, not a bytes object, unless you pass it a _charset parameter.  If you do that, the encoding is done when the object is created, and the explicit call to encodings that you do fails.  If, on the other hand, you pass in a string, the explicit call to encodings fails.

In 2.7, the encoder call does not fail, but as you report this results in an extra header.  This is because MIMEText sets a content type and CTE header using the default values when it is first created.

The explicit call to encoders is not needed  What you want to do in stead is to pass the charset and type when you make the MIMEText call:

  MIMEText('<xml>aaa</xml>', 'xml', 'utf-8')

This is the correct way to do it, and the portable way.  So, you get the right output by using the API the way it was designed.  

That leaves the question of whether or not we should add some documentation (such as: *never* call the functions from the encoders module directly :).

Note that I don't *like* that the current API is that calling set_charset does the body encode if and only if there are no existing headers, but that is the way it has always worked, and there are programs out there that depend on it.  

In theory we could fix the encoders functions to check for existing headers and do the right thing in that case, but it is not something that would rate very high on my priority list.  I'll happily look at a patch if someone wants to propose one, but since the right way to do this exists, I'm going to treat this issue as documentation-only.  

If someone wants to propose a patch for this, please open a new issue.

----------
assignee:  -> docs at python
components: +Documentation -email
nosy: +docs at python
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.3 -Python 3.1

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

From report at bugs.python.org  Wed Jun 20 15:58:25 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jun 2012 13:58:25 +0000
Subject: [docs] [issue15115] Duplicated Content-Transfer-Encoding header
	when	applying email.encoders
In-Reply-To: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za>
Message-ID: <1340200705.26.0.725933976842.issue15115@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Barry: I think we should documentationally deprecate the encoders module.  I can't see any utility in a new program calling those functions explicitly, especially if the program ever wants to port to Python3.  Or maybe the Python2 docs would say deprecated in Python3.  

What do you think?

----------

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

From report at bugs.python.org  Wed Jun 20 16:12:09 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Jun 2012 14:12:09 +0000
Subject: [docs] [issue15115] Duplicated Content-Transfer-Encoding header
	when	applying email.encoders
In-Reply-To: <1340200705.26.0.725933976842.issue15115@psf.upfronthosting.co.za>
Message-ID: <20120620101209.73714a85@limelight.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jun 20, 2012, at 01:58 PM, R. David Murray wrote:

>Barry: I think we should documentationally deprecate the encoders module.  I
>can't see any utility in a new program calling those functions explicitly,
>especially if the program ever wants to port to Python3.  Or maybe the
>Python2 docs would say deprecated in Python3.

I agree that we should document them as deprecated, as long as we include text
explaining why, or providing alternatives (e.g. "you think you need this but
you don't because...")

I think it does make sense to include text in the Py2 docs about this.

----------

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

From report at bugs.python.org  Wed Jun 20 16:13:43 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Jun 2012 14:13:43 +0000
Subject: [docs] [issue15115] Duplicated Content-Transfer-Encoding header
	when	applying email.encoders
In-Reply-To: <1340200280.75.0.169898607846.issue15115@psf.upfronthosting.co.za>
Message-ID: <20120620101342.4f319a44@limelight.wooz.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jun 20, 2012, at 01:51 PM, R. David Murray wrote:

>Note that I don't *like* that the current API is that calling set_charset
>does the body encode if and only if there are no existing headers, but that
>is the way it has always worked, and there are programs out there that depend
>on it.

Can we nuke that for email6?

----------

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

From report at bugs.python.org  Wed Jun 20 16:54:13 2012
From: report at bugs.python.org (hhas)
Date: Wed, 20 Jun 2012 14:54:13 +0000
Subject: [docs] [issue15116] remove out-of-date Mac application
	scripting	documentation
Message-ID: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za>


New submission from hhas <hhas at users.sourceforge.net>:

1. The entire '4.6. Application Scripting' section should be deleted from the following Python 2 & 3 pages as appscript (and PyOSA) is no longer developed or supported and its use is not recommended for new projects (http://appscript.sourceforge.net/status.html):

http://docs.python.org/using/mac.html#application-scripting
http://docs.python.org/release/3.2/using/mac.html#application-scripting
http://docs.python.org/dev/using/mac.html#application-scripting


2. The sentence 'For more up-to-date implementation of AppleScript support for Python, see the third-party py-appscript project: <http://pypi.python.org/pypi/appscript/>' should be deleted from the following Python 2 page:

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

----------
assignee: docs at python
components: Documentation
messages: 163282
nosy: docs at python, hhas
priority: normal
severity: normal
status: open
title: remove out-of-date Mac application scripting documentation
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/issue15116>
_______________________________________

From report at bugs.python.org  Wed Jun 20 16:58:25 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Jun 2012 14:58:25 +0000
Subject: [docs] [issue15115] Duplicated Content-Transfer-Encoding header
	when	applying email.encoders
In-Reply-To: <1340188711.86.0.286169814605.issue15115@psf.upfronthosting.co.za>
Message-ID: <1340204305.29.0.549659375229.issue15115@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think so, yes.  When we have the mimeregistry equivalent of the headerregistry, the new mime Message classes can have a set_charset with a different implementation.  I'll want to talk about the API details on email-sig before I do anything, though.

----------

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

From report at bugs.python.org  Wed Jun 20 17:21:25 2012
From: report at bugs.python.org (wchlm)
Date: Wed, 20 Jun 2012 15:21:25 +0000
Subject: [docs] [issue15117] Please document top-level sqlite3 module
	variables
Message-ID: <1340205684.94.0.46461654189.issue15117@psf.upfronthosting.co.za>


New submission from wchlm <shenkin at gmail.com>:

sqlite3 top-level variables, such as version, sqlite_version, version_info, and sqlite_version_info are all useful for Python users of the module -- even essential at times. Yet there is no mention of them in the Py 2.7.3 documentation. 

dir(sqlite3) reveals a longer list. It would be good if someone with a deeper knowledge of the module could assemble a list of useful items and add them to the sqlite3 documentation.

----------
assignee: docs at python
components: Documentation
messages: 163285
nosy: docs at python, shenkin
priority: normal
severity: normal
status: open
title: Please document top-level sqlite3 module variables
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 20 17:36:32 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Jun 2012 15:36:32 +0000
Subject: [docs] [issue14393] Incorporate Guide to Magic Methods?
In-Reply-To: <1332493295.71.0.816804721304.issue14393@psf.upfronthosting.co.za>
Message-ID: <1340206591.75.0.600460239691.issue14393@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/issue14393>
_______________________________________

From report at bugs.python.org  Wed Jun 20 21:42:43 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Jun 2012 19:42:43 +0000
Subject: [docs] [issue15116] remove out-of-date Mac application
	scripting	documentation
In-Reply-To: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za>
Message-ID: <1340221363.34.0.841061039991.issue15116@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The entire "Using Macintosh" section of the documentation set is in need of an update.  I plan to have that done for 3.3 release and the next releases of 3.2.x and 2.7.x.  The 2.6 and 3.1 releases are in security fix mode only, prior to their retirement, and no longer receive doc or bug fix updates.

----------
assignee: docs at python -> ned.deily
nosy: +ned.deily
versions:  -Python 2.6, Python 3.1, Python 3.4

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

From report at bugs.python.org  Thu Jun 21 05:10:19 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Jun 2012 03:10:19 +0000
Subject: [docs] [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1340248219.21.0.458513203984.issue12779@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jun 21 12:00:39 2012
From: report at bugs.python.org (hansokumake)
Date: Thu, 21 Jun 2012 10:00:39 +0000
Subject: [docs] [issue15120] Different behavior of html.parser.HTMLParser
Message-ID: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za>


New submission from hansokumake <hansokumake at seznam.cz>:

I tried this example from the documentation:

from html.parser import HTMLParser

class MyHTMLParser(HTMLParser):
    def handle_starttag(self, tag, attrs):
        print("Encountered a start tag:", tag)
    def handle_endtag(self, tag):
        print("Encountered an end tag :", tag)
    def handle_data(self, data):
        print("Encountered some data  :", data)

parser = MyHTMLParser(strict=False)
parser.feed('<html><head><title>Test</title></head>'
            '<body><h1>Parse me!</h1></body></html>')



According to documentation the output should be like this:
Encountered a start tag: html
Encountered a start tag: head
Encountered a start tag: title
Encountered some data  : Test
Encountered an end tag : title
Encountered an end tag : head
Encountered a start tag: body
Encountered a start tag: h1
Encountered some data  : Parse me!
Encountered an end tag : h1
Encountered an end tag : body
Encountered an end tag : html

but Python produced this:
Encountered some data  : <html>
Encountered some data  : <head>
Encountered some data  : <title>
Encountered some data  : Test
Encountered an end tag : title
Encountered an end tag : head
Encountered some data  : <body>
Encountered some data  : <h1>
Encountered some data  : Parse me!
Encountered an end tag : h1
Encountered an end tag : body
Encountered an end tag : html


If strict is set to True, it works correctly.

----------
assignee: docs at python
components: Documentation
messages: 163318
nosy: docs at python, hansokumake
priority: normal
severity: normal
status: open
title: Different behavior of html.parser.HTMLParser
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Jun 21 12:24:00 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Jun 2012 10:24:00 +0000
Subject: [docs] [issue15120] Different behavior of html.parser.HTMLParser
In-Reply-To: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za>
Message-ID: <1340274240.69.0.491570383618.issue15120@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jun 21 12:33:20 2012
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 21 Jun 2012 10:33:20 +0000
Subject: [docs] [issue15120] Different behavior of html.parser.HTMLParser
In-Reply-To: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za>
Message-ID: <1340274800.32.0.355807534976.issue15120@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fred at fdrake.net>:


----------
nosy: +fdrake

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

From report at bugs.python.org  Thu Jun 21 15:41:22 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jun 2012 13:41:22 +0000
Subject: [docs] [issue15120] Different behavior of html.parser.HTMLParser
In-Reply-To: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za>
Message-ID: <1340286081.77.0.663307189062.issue15120@psf.upfronthosting.co.za>


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

What exact version of python have you used?
The example works here with 3.2.3+.

----------
assignee: docs at python -> ezio.melotti

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

From report at bugs.python.org  Thu Jun 21 18:27:52 2012
From: report at bugs.python.org (Damian)
Date: Thu, 21 Jun 2012 16:27:52 +0000
Subject: [docs] [issue15126] Theading isAlive() missing version note
Message-ID: <1340296072.22.0.188221984901.issue15126@psf.upfronthosting.co.za>


New submission from Damian <atagar1 at gmail.com>:

The threading module's isAlive() method had an is_alive() alias first created in python 2.6. The documentation page doesn't mention this...
http://docs.python.org/library/threading.html#threading.Thread.is_alive

However, this is noted for other methods like the Event's is_set()...
http://docs.python.org/library/threading.html#threading.Event.is_set

Very minor issue, just meant that I needed to do a bit of experimentation to figure it out.

----------
assignee: docs at python
components: Documentation
messages: 163344
nosy: atagar1, docs at python
priority: normal
severity: normal
status: open
title: Theading isAlive() missing version note
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 21 18:27:53 2012
From: report at bugs.python.org (hansokumake)
Date: Thu, 21 Jun 2012 16:27:53 +0000
Subject: [docs] [issue15120] Different behavior of html.parser.HTMLParser
In-Reply-To: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za>
Message-ID: <1340296073.85.0.156787549819.issue15120@psf.upfronthosting.co.za>


hansokumake <hansokumake at seznam.cz> added the comment:

I'm sorry. It's my fault. I still use Python 3.2.2.

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

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

From report at bugs.python.org  Thu Jun 21 18:33:36 2012
From: report at bugs.python.org (Damian)
Date: Thu, 21 Jun 2012 16:33:36 +0000
Subject: [docs] [issue15126] Theading isAlive() missing version note
In-Reply-To: <1340296072.22.0.188221984901.issue15126@psf.upfronthosting.co.za>
Message-ID: <1340296416.86.0.519235017086.issue15126@psf.upfronthosting.co.za>


Damian <atagar1 at gmail.com> added the comment:

I'm gonna hazard the guess that other methods like currentThread() and current_thread() are the same...
http://docs.python.org/library/threading.html#threading.current_thread

----------

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

From report at bugs.python.org  Thu Jun 21 18:35:13 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Jun 2012 16:35:13 +0000
Subject: [docs] [issue15120] Different behavior of html.parser.HTMLParser
In-Reply-To: <1340272839.74.0.0138242037615.issue15120@psf.upfronthosting.co.za>
Message-ID: <1340296513.73.0.281541338964.issue15120@psf.upfronthosting.co.za>


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


----------
resolution:  -> invalid
stage:  -> committed/rejected

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

From report at bugs.python.org  Thu Jun 21 22:49:12 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 21 Jun 2012 20:49:12 +0000
Subject: [docs] [issue15130] remove redundant paragraph in socket howto
Message-ID: <1340311752.3.0.940656841103.issue15130@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

same text used on Abstract is used in the beginning of the main text

----------
assignee: docs at python
components: Documentation
files: redundancy.diff
keywords: patch
messages: 163364
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: remove redundant paragraph in socket howto
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26076/redundancy.diff

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

From report at bugs.python.org  Thu Jun 21 23:59:01 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Jun 2012 21:59:01 +0000
Subject: [docs] [issue15126] Theading isAlive() missing version note
In-Reply-To: <1340296072.22.0.188221984901.issue15126@psf.upfronthosting.co.za>
Message-ID: <1340315941.55.0.158847496845.issue15126@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Since the news aliases are all over the module, the version change notice is at the top of the page:

"""
Note

Starting with Python 2.6, this module provides PEP 8 compliant aliases and properties to replace the camelCase names that were inspired by Java?s threading API. This updated API is compatible with that of the multiprocessing module. However, no schedule has been set for the deprecation of the camelCase names and they remain fully supported in both Python 2.x and 3.x.
"""

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Fri Jun 22 00:16:22 2012
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Jun 2012 22:16:22 +0000
Subject: [docs] [issue15131] Document py/pyw launchers
Message-ID: <1340316982.35.0.0939341708.issue15131@psf.upfronthosting.co.za>


New submission from Brian Curtin <brian at python.org>:

As of http://hg.python.org/cpython/rev/a7ecbb2ad967, the PEP 397 launchers are included. Their functionality should be documented.

----------
assignee: docs at python
components: Documentation, Windows
messages: 163374
nosy: brian.curtin, docs at python
priority: critical
severity: normal
stage: needs patch
status: open
title: Document py/pyw launchers
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun 22 00:16:46 2012
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Jun 2012 22:16:46 +0000
Subject: [docs] [issue15131] Document py/pyw launchers
In-Reply-To: <1340316982.35.0.0939341708.issue15131@psf.upfronthosting.co.za>
Message-ID: <1340317006.07.0.124692707294.issue15131@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> brian.curtin

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

From report at bugs.python.org  Fri Jun 22 13:13:12 2012
From: report at bugs.python.org (Pan Yongzhi)
Date: Fri, 22 Jun 2012 11:13:12 +0000
Subject: [docs] [issue15135] HOWTOs doesn't link to "Idioms and Anti-Idioms"
	article
Message-ID: <1340363592.11.0.988829373345.issue15135@psf.upfronthosting.co.za>


New submission from Pan Yongzhi <fossilet at users.sourceforge.net>:

In the py3k docs howtos table of contents, http://docs.python.org/py3k/howto/index.html, the link to the article "Idioms and Anti-Idioms in Python" is gone, but the article is still in the doc. It is at http://docs.python.org/py3k/howto/doanddont.html. Should it have a link at the howtos section?

----------
assignee: docs at python
components: Documentation
messages: 163396
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: HOWTOs doesn't link to "Idioms and Anti-Idioms" article
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Fri Jun 22 13:18:09 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Jun 2012 11:18:09 +0000
Subject: [docs] [issue15135] HOWTOs doesn't link to "Idioms and Anti-Idioms"
	article
In-Reply-To: <1340363592.11.0.988829373345.issue15135@psf.upfronthosting.co.za>
Message-ID: <1340363889.13.0.137170695431.issue15135@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun 22 19:03:57 2012
From: report at bugs.python.org (hhas)
Date: Fri, 22 Jun 2012 17:03:57 +0000
Subject: [docs] [issue15116] remove out-of-date Mac application
	scripting	documentation
In-Reply-To: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za>
Message-ID: <1340384637.34.0.379457759527.issue15116@psf.upfronthosting.co.za>


hhas <hhas at users.sourceforge.net> added the comment:

@Ned: The whole page has been needing updated for years, but no-one's ever quite managed to complete it. In that light, might I suggest a two-step approach? 

1. Edit the existing text now to remove all the obsolete info (e.g. section 4.1.2. is also defunct) and check in those changes before end of this month.

2. Develop whatever shiny new content you think is needed at your leisure. 

That way, if step 2 takes longer than expected (and creating new material always does), at least the current errors won't appear in the next release.


The update to the OSA page can also be done immediately, as that's just a straight text deletion.

----------

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

From report at bugs.python.org  Fri Jun 22 20:11:27 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Jun 2012 18:11:27 +0000
Subject: [docs] [issue15140] PEP 384 inconsistent with implementation
Message-ID: <1340388687.85.0.64744522039.issue15140@psf.upfronthosting.co.za>


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

In PEP 384, the PyType_Spec struct has a "const char *doc" that is not present in the implementation (Include/object.h).

----------
assignee: docs at python
components: Documentation
messages: 163449
nosy: docs at python, loewis, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 384 inconsistent with implementation
type: behavior

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

From report at bugs.python.org  Fri Jun 22 20:58:03 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 22 Jun 2012 18:58:03 +0000
Subject: [docs] [issue15140] PEP 384 inconsistent with implementation
In-Reply-To: <1340388687.85.0.64744522039.issue15140@psf.upfronthosting.co.za>
Message-ID: <1340391483.86.0.232411626457.issue15140@psf.upfronthosting.co.za>


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

It's a bug in the PEP: users need to provide the module documentation through Py_tp_doc (which actually is mentioned in the PEP).

I'll fix it.

----------

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

From report at bugs.python.org  Sat Jun 23 03:16:29 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 23 Jun 2012 01:16:29 +0000
Subject: [docs] [issue15148] shutul.which() docstring could be clearer
Message-ID: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I find this a little hard to parse (ignoring the obvious typo and the grammar error):

"""
Given a file, mode, and a path string, return the path whichs conform to the given mode on the path.
"""

One other suggestion: wouldn't 'file' read better as 'command'?

----------
assignee: docs at python
components: Documentation
messages: 163515
nosy: docs at python, hynek, tarek, tshepang
priority: normal
severity: normal
status: open
title: shutul.which() docstring could be clearer

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

From report at bugs.python.org  Sat Jun 23 03:16:39 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 23 Jun 2012 01:16:39 +0000
Subject: [docs] [issue15148] shutul.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1340414199.01.0.730719112934.issue15148@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jun 23 03:17:18 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 23 Jun 2012 01:17:18 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1340414238.42.0.276393018832.issue15148@psf.upfronthosting.co.za>


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


----------
title: shutul.which() docstring could be clearer -> shutil.which() docstring could be clearer

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

From report at bugs.python.org  Sat Jun 23 03:56:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jun 2012 01:56:48 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <E1SiFah-0008Hb-20@dinsdale.python.org>


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

New changeset 5975292ddf82 by Alexander Belopolsky in branch 'default':
Issue #15148: Fixed typos in shutil.which() docstring
http://hg.python.org/cpython/rev/5975292ddf82

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

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

From report at bugs.python.org  Sat Jun 23 04:09:47 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Jun 2012 02:09:47 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1340417387.28.0.761814311688.issue15148@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

*file* is correct because shutil.which() is more general than shell which command.  (It can be used to find source files on PYTHONPATH, for example.)

I think the confusing part is "return the path ... on the path."  This can be fixed in reST by marking the second "path" as the argument, but the docstring should be rephrased.  Note that reST documentation for shutil.which() is missing in Doc/library/shutil.rst.

----------
nosy: +belopolsky, brian.curtin

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

From report at bugs.python.org  Sat Jun 23 04:17:02 2012
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 23 Jun 2012 02:17:02 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1340417822.69.0.512504992354.issue15148@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

I updated file to command in 973b4806f760. It needs to be command so it matches the implementation's argument name, and because it doesn't exactly take a file.

Alexander, can you explain the part about finding a file on PYTHONPATH? I don't think this has anything to do with shutil.which, or at least I have no idea how it would.

----------

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

From report at bugs.python.org  Sat Jun 23 04:25:42 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Jun 2012 02:25:42 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1340418342.24.0.622326963272.issue15148@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

> Alexander, can you explain the part about finding a file on PYTHONPATH?

I thought about something like this:

>>> shutil.which('shutil.py', os.F_OK, ':'.join(sys.path))
'/Users/sasha/Work/python-hg/py3k/Lib/shutil.py'

but win32 code seems to assume a search for a command.

----------

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

From report at bugs.python.org  Sat Jun 23 04:30:13 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 23 Jun 2012 02:30:13 +0000
Subject: [docs] [issue15149] Release Schedule needs updating
Message-ID: <1340418613.19.0.188267492101.issue15149@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I see some stuff marked 'planned' has been rejected for 3.3, while some has already been implemented.

----------
assignee: docs at python
components: Documentation
messages: 163521
nosy: anthonybaxter, barry, benjamin.peterson, docs at python, eric.araujo, georg.brandl, gvanrossum, lemburg, loewis, ned.deily, tarek, tshepang
priority: normal
severity: normal
status: open
title: Release Schedule needs updating
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun 23 04:34:45 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Jun 2012 02:34:45 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1340418885.41.0.228502966136.issue15148@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Brian,

Did you intend to commit Tools/msi/msi.py in changeset 973b4806f760?

----------

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

From report at bugs.python.org  Sat Jun 23 04:36:43 2012
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 23 Jun 2012 02:36:43 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1340419003.02.0.692336452913.issue15148@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

No, reverting.

----------

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

From report at bugs.python.org  Sat Jun 23 05:27:47 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Jun 2012 03:27:47 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1340422066.96.0.162093899527.issue15148@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, Brian had it as 'file' before, and I asked him to change it because it is confusing.  'file' sounds like a Python file object, which this is not.  'filename' would be OK, but 'cmd', as you note, is what it is really about.

One possibility for the path confusion is to capitalize the references to the system path, since both posix and windows capitalize it.:

"Given a name, mode, and PATH, return the path to the first file which conforms to the given mode found on the PATH, or None if there is no such file.  mode defaults to os.F_OK|os.X_OK.  PATH can be specified via the path argument, if not specified it defaults to the PATH set in the environment."

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

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

From report at bugs.python.org  Sat Jun 23 05:49:28 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jun 2012 03:49:28 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <E1SiHLg-0006p5-R0@dinsdale.python.org>


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

New changeset 5f18d9d34f73 by Brian Curtin in branch 'default':
Fix #15148. Make the shutil.which docstring more thorough
http://hg.python.org/cpython/rev/5f18d9d34f73

New changeset aa153b827d17 by Brian Curtin in branch 'default':
Fix #15148. Capitalize PATH, hopefully leading to less confusion
http://hg.python.org/cpython/rev/aa153b827d17

----------

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

From report at bugs.python.org  Sat Jun 23 08:13:51 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Jun 2012 06:13:51 +0000
Subject: [docs] [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
Message-ID: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The PEP 362 implementation has been committed, but the inspect module documentation still needs to be updated.

----------
assignee: docs at python
components: Documentation
messages: 163534
nosy: docs at python, ncoghlan
priority: deferred blocker
severity: normal
status: open
title: Documentation for Signature, Parameter and signature in inspect module
versions: Python 3.3

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

From report at bugs.python.org  Sat Jun 23 08:48:10 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Jun 2012 06:48:10 +0000
Subject: [docs] [issue15104] Unclear language in __main__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1340434088.79.0.936099493953.issue15104@psf.upfronthosting.co.za>


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

As a native speaker, I agree that the sentence, in isolation, is hardly comprehensible. The previous one is also a bit flakey.

The situation is that top-level code executes in a module named __main__, which has one joint global/local namespace that is the global namespace for all subsidiary contexts. '__main__':<__main__ module> is added to sys.modules before user code is executed. The name __main__ is not normally in the __main__ (global) namespace, hence the comment about 'anonymous' in the first sentence. (It is not anonymous in sys.modules.) However (1) __main__ or any other module/namespace can 'import __main__' and get the reference to __main__ from sys.modules and (2) __main__ does have name __name__ bound to the *string* '__main__'. Hence a module can discover whether or not it *is* the __main__ module.

Part of the quoting confusion is that unquoted names in code become strings in namespace dicts, and hence quoted literals when referring to them as keys. What I did not realize until just now is that the __name__ attribute of a module *is* its name (key) in the module namespace (sys.modules dict). For instance, after 'import x.y' or 'from x import y', x.y.__name__ or y.__name is 'x.y' and that is its name (key) in sys.modules. So it appears that the __name__ of a package (sub)module is never just the filename (which I expected), and "__name__ is the module name" only if one considers the package name as part of the module name (which I did not).

The only non-capi reference to module.__name__ in the index is

3.2. The standard type hierarchy
Modules
"__name__ is the module?s name"

But what is the modules name? Its name in sys.modules, which is either __main__ or the full dotted name for modules in packages (as I just learned). Perhaps this could be explained better here.

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

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

From report at bugs.python.org  Sat Jun 23 08:53:04 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Jun 2012 06:53:04 +0000
Subject: [docs] [issue15149] Release Schedule needs updating
In-Reply-To: <1340418613.19.0.188267492101.issue15149@psf.upfronthosting.co.za>
Message-ID: <1340434384.41.0.0946464274354.issue15149@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Updated.

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

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

From report at bugs.python.org  Sat Jun 23 09:00:11 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Jun 2012 07:00:11 +0000
Subject: [docs] [issue15117] Please document top-level sqlite3 module
	variables
In-Reply-To: <1340205684.94.0.46461654189.issue15117@psf.upfronthosting.co.za>
Message-ID: <1340434811.91.0.810277256934.issue15117@psf.upfronthosting.co.za>


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


----------
nosy: +ghaering

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

From report at bugs.python.org  Sat Jun 23 09:40:47 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Jun 2012 07:40:47 +0000
Subject: [docs] [issue15135] HOWTOs doesn't link to "Idioms and Anti-Idioms"
	article
In-Reply-To: <1340363592.11.0.988829373345.issue15135@psf.upfronthosting.co.za>
Message-ID: <1340437247.1.0.711342551334.issue15135@psf.upfronthosting.co.za>


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

The file is 'controversial'. The link was intentionally removed (and the file deleted and restored but not relinked, pending update) in #7391 (which was closed and re-opened).

Your links do not work because the comma/period that follow are considered part of the urls. To be safe, always follow with whitespace.

----------
nosy: +terry.reedy
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jun 23 11:50:10 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jun 2012 09:50:10 +0000
Subject: [docs] [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <E1SiMyi-0004FW-BH@dinsdale.python.org>


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

New changeset 5ca9a51f3d85 by Mark Dickinson in branch '3.2':
Issue #12965: Clean up C-API docs for PyLong_AsLong(AndOverflow); clarify that __int__ will be called for non-PyLongs
http://hg.python.org/cpython/rev/5ca9a51f3d85

New changeset 63fc1552cd36 by Mark Dickinson in branch 'default':
Issue #12965: Merge from 3.2
http://hg.python.org/cpython/rev/63fc1552cd36

----------

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

From report at bugs.python.org  Sat Jun 23 12:15:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jun 2012 10:15:14 +0000
Subject: [docs] [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <E1SiNN0-0005ke-Fh@dinsdale.python.org>


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

New changeset 3ace8e17074a by Mark Dickinson in branch '3.2':
Issue #12965: Clean up C-API docs for PyLong_AsLongLong(AndOverflow); clarify that __int__ will be called for non-PyLongs
http://hg.python.org/cpython/rev/3ace8e17074a

New changeset 85683f005fc8 by Mark Dickinson in branch 'default':
Issue #12965: Merge from 3.2.
http://hg.python.org/cpython/rev/85683f005fc8

----------

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

From report at bugs.python.org  Sat Jun 23 13:13:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jun 2012 11:13:49 +0000
Subject: [docs] [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <E1SiOHP-0000mp-S2@dinsdale.python.org>


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

New changeset e1416a4d728a by Mark Dickinson in branch '3.2':
Issue #12965:  More PyLong_As* clarifications.  Thanks Stefan Krah.
http://hg.python.org/cpython/rev/e1416a4d728a

New changeset 349bc58e8c66 by Mark Dickinson in branch 'default':
Issue #12965: Merge from 3.2.
http://hg.python.org/cpython/rev/349bc58e8c66

----------

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

From report at bugs.python.org  Sat Jun 23 13:18:56 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 23 Jun 2012 11:18:56 +0000
Subject: [docs] [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <1340450336.16.0.0159623839342.issue12965@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Docs mostly fixed now for Python 3.2 and Python 3.3.  That leaves 2.7, where there are some additional complications (e.g., __long__ in addition to __int__, when / whether short ints are accepted, etc.).

While it would be good to fix the 2.7 docs as well, I don't see myself having time for this in the near future, so I'm unassigning for now;  Stefan, I think should feel free to take this issue and check in clarifications for 2.7, if you want to.

----------
assignee: mark.dickinson -> 
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Jun 23 13:28:38 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Jun 2012 11:28:38 +0000
Subject: [docs] [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <1340450917.68.0.849937470111.issue10376@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Any chance to commit the patch before final feature freeze?

----------

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

From report at bugs.python.org  Sat Jun 23 13:34:20 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jun 2012 11:34:20 +0000
Subject: [docs] [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <1340451260.59.0.141221687332.issue10376@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> 
nosy: +nadeem.vawda
stage:  -> patch review

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

From report at bugs.python.org  Sat Jun 23 14:46:16 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Jun 2012 12:46:16 +0000
Subject: [docs] [issue15135] HOWTOs doesn't link to "Idioms and Anti-Idioms"
	article
In-Reply-To: <1340363592.11.0.988829373345.issue15135@psf.upfronthosting.co.za>
Message-ID: <1340455576.64.0.629780912806.issue15135@psf.upfronthosting.co.za>


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

> Your links do not work because the comma/period that follow are 
> considered part of the urls. To be safe, always follow with whitespace.

FWIW this will be fixed soon and the fix will work on older messages too:
http://psf.upfronthosting.co.za/roundup/meta/issue437
http://issues.roundup-tracker.org/issue2550759

----------

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

From report at bugs.python.org  Sat Jun 23 15:15:59 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 23 Jun 2012 13:15:59 +0000
Subject: [docs] [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <1340457359.58.0.116333840039.issue10376@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Patch looks fine to me.

Antoine, can you commit this? I'm currently away from the computer that
has my SSH key on it.

----------

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

From report at bugs.python.org  Sat Jun 23 16:48:25 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Jun 2012 14:48:25 +0000
Subject: [docs] [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <E1SiRdP-0006bd-B9@dinsdale.python.org>


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

New changeset 0e8285321659 by Antoine Pitrou in branch 'default':
On behalf of Nadeem Vawda: issue #10376: micro-optimize reading from a Zipfile.
http://hg.python.org/cpython/rev/0e8285321659

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

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

From report at bugs.python.org  Sat Jun 23 16:51:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Jun 2012 14:51:22 +0000
Subject: [docs] [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <1340463082.3.0.991594163202.issue10376@psf.upfronthosting.co.za>


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

> Antoine, can you commit this?

Ok, done.

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

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

From report at bugs.python.org  Sat Jun 23 18:40:15 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 23 Jun 2012 16:40:15 +0000
Subject: [docs] [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <1340469615.21.0.383807635523.issue12965@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

OK, I'll see if I find some time for the 2.7 docs.

----------
assignee:  -> skrah

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

From report at bugs.python.org  Sun Jun 24 21:02:46 2012
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 24 Jun 2012 19:02:46 +0000
Subject: [docs] [issue15055] dictnotes.txt is out of date
In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za>
Message-ID: <1340564566.48.0.400139106023.issue15055@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Is there any reason not to commit this patch?
The docs are out of sync with the code and need to be updated.

----------

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

From report at bugs.python.org  Sun Jun 24 21:07:30 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Jun 2012 19:07:30 +0000
Subject: [docs] [issue15055] dictnotes.txt is out of date
In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za>
Message-ID: <E1Sis9h-0006aF-B2@dinsdale.python.org>


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

New changeset 1120041f2df4 by Antoine Pitrou in branch 'default':
Issue #15055: update dictnotes.txt.  Patch by Mark Shannon.
http://hg.python.org/cpython/rev/1120041f2df4

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

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

From report at bugs.python.org  Sun Jun 24 21:08:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Jun 2012 19:08:34 +0000
Subject: [docs] [issue15055] dictnotes.txt is out of date
In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za>
Message-ID: <1340564914.11.0.153674982436.issue15055@psf.upfronthosting.co.za>


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

Sorry, Mark. This is committed now.

----------
assignee: rhettinger -> 
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Jun 24 21:13:47 2012
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 24 Jun 2012 19:13:47 +0000
Subject: [docs] [issue15055] dictnotes.txt is out of date
In-Reply-To: <1339601654.21.0.693621364895.issue15055@psf.upfronthosting.co.za>
Message-ID: <1340565227.82.0.492147658804.issue15055@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

No apology needed :)
Thanks.

----------

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

From report at bugs.python.org  Mon Jun 25 05:02:01 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Jun 2012 03:02:01 +0000
Subject: [docs] [issue15063] Source code links for JSON documentation
In-Reply-To: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za>
Message-ID: <1340593321.35.0.490395550094.issue15063@psf.upfronthosting.co.za>


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


----------
resolution: rejected -> 

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

From report at bugs.python.org  Mon Jun 25 06:45:41 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Jun 2012 04:45:41 +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: <1340599541.14.0.764073814398.issue14674@psf.upfronthosting.co.za>


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

This looks good to me, apart from very minor style things that I can change before committing.  Ezio, any last comments?

One thing I haven?t done is comparing the length of the new section to the rest of the file to see if it?s a small or big addition; if it?s too big, that would be distracting.

----------

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

From report at bugs.python.org  Mon Jun 25 06:49:01 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Jun 2012 04:49:01 +0000
Subject: [docs] [issue14893] Tutorial: Add function annotation example to
	function	tutorial
In-Reply-To: <1337802155.15.0.316800230533.issue14893@psf.upfronthosting.co.za>
Message-ID: <1340599741.48.0.203517644065.issue14893@psf.upfronthosting.co.za>


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

LGTM, will commit.

----------
assignee: docs at python -> eric.araujo

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

From report at bugs.python.org  Mon Jun 25 07:11:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Jun 2012 05:11:33 +0000
Subject: [docs] [issue12415] Missing: How to checkout the Doc sources
In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za>
Message-ID: <1340601093.45.0.81251746244.issue12415@psf.upfronthosting.co.za>


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

Any comment on my last message?

----------

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

From report at bugs.python.org  Mon Jun 25 07:14:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Jun 2012 05:14:38 +0000
Subject: [docs] [issue13799] Base 16 should be hexadecimal in Unicode HOWTO
In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za>
Message-ID: <1340601278.72.0.832577649632.issue13799@psf.upfronthosting.co.za>


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

I think that when I started programming I was exposed to ?hexadecimal? (e.g. HTML character references can use decimal or hexadecimal numbers) before understanding the generic principle of bases for numbers, so I?m sympathetic to the request.  Terry, Sandro, do you have feedback on that?

----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Mon Jun 25 08:09:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Jun 2012 06:09:33 +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: <1340604573.33.0.310009882721.issue14202@psf.upfronthosting.co.za>


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

Unassigning; I have to use my Python time for distutils bugs, or doc bugs for modules I actually like (I?m no fan of XML nor DOM :).  I would politely insist that doc fixes have to get backported to 2.7 unless it would be really bothersome (like a big change to IO docs done by Antoine and not backported).

----------
assignee: eric.araujo -> docs at python

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

From report at bugs.python.org  Mon Jun 25 10:14:31 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Jun 2012 08:14:31 +0000
Subject: [docs] [issue13799] Base 16 should be hexadecimal in Unicode HOWTO
In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za>
Message-ID: <1340612071.28.0.937179852863.issue13799@psf.upfronthosting.co.za>


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

I learned about different number bases in 8th grade math class (a long time ago) and how to use base 2 to win nim. I learned 'octal' and 'hexadecimal' much later. In the absence of an official, documented vocabulary for such non-Python concepts, I think this should be closed as overly picky and based on an erroneous premise. In any case, programmers should know both terms. Anyone with a deficient math education can look up 'base 16' on Wikipedia and be redirected to hexadecimal as a synonym and read an article that is much longer than one might expect, with more detail than most would want to know.

A more obscure term that one might more reasonably object to is 'radix', as in 'radix 16', as a synonym for 'base'.

----------

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

From report at bugs.python.org  Mon Jun 25 10:17:40 2012
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 25 Jun 2012 08:17:40 +0000
Subject: [docs] [issue13799] Base 16 should be hexadecimal in Unicode HOWTO
In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za>
Message-ID: <1340612260.28.0.660772825574.issue13799@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

?0 from me.

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

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

From report at bugs.python.org  Mon Jun 25 10:51:51 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 25 Jun 2012 08:51:51 +0000
Subject: [docs] [issue13799] Base 16 should be hexadecimal in Unicode HOWTO
In-Reply-To: <1326718246.49.0.980962494093.issue13799@psf.upfronthosting.co.za>
Message-ID: <1340614311.27.0.409166651315.issue13799@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I was tempted to suggest that 'hexadecimal' would be more searchable than 'base 16', but the first Google hit for 'base 16' is:

  en.wikipedia.org/wiki/Hexadecimal

:-)

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

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

From report at bugs.python.org  Mon Jun 25 18:26:47 2012
From: report at bugs.python.org (Philip Olson)
Date: Mon, 25 Jun 2012 16:26:47 +0000
Subject: [docs] [issue12415] Missing: How to checkout the Doc sources
In-Reply-To: <1309069778.19.0.06342861361.issue12415@psf.upfronthosting.co.za>
Message-ID: <1340641607.67.0.902478313873.issue12415@psf.upfronthosting.co.za>


Philip Olson <philip at roshambo.org> added the comment:

I think you should make the commit. 

Also, the aforementioned [old] Subversion reference for Sphinx is a real issue here. And I think the "Without make" section should link to http://sphinx.pocoo.org/

----------

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

From report at bugs.python.org  Mon Jun 25 20:02:00 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 25 Jun 2012 18:02:00 +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
Message-ID: <1340647320.14.0.672684715585.issue15183@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

I looked at 'python -m time -h' and the timeit doc, and it was not clear to me (after a quick read) that the statement(s) inside --setup option and setup keyword argument weren't included in the speed test. I had to check for myself by writing code.

----------
assignee: docs at python
components: Documentation
messages: 163999
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: it should be made clear that the statement in the --setup option and the setup kw arg aren't included in the count
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jun 25 20:02:47 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 25 Jun 2012 18:02:47 +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: <1340647367.89.0.690327792806.issue15183@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

sorry, I meant 'python -m timeit -h'

----------

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

From report at bugs.python.org  Tue Jun 26 06:33:26 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Jun 2012 04:33:26 +0000
Subject: [docs] [issue15034] tutorial should use best practices in user
	defined	exceptions section
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1340685206.19.0.148201502268.issue15034@psf.upfronthosting.co.za>


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

This seems more like a Stack Overflow question or fodder for a blog post.  

When such best practices become well known and agreed upon, they can be added toa HOWTO document.  The tutorial is problematic because beginners start there and sprinkling the nuances of super() throughout the tutorial will only get in the way of the main learning points for a given section.

----------
nosy: +rhettinger
resolution:  -> later
status: open -> closed

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

From report at bugs.python.org  Tue Jun 26 08:05:21 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 26 Jun 2012 06:05:21 +0000
Subject: [docs] [issue15172] Document nasm-2.10.01 as required version for
	openssl
In-Reply-To: <1340569947.64.0.165180800824.issue15172@psf.upfronthosting.co.za>
Message-ID: <1340690721.27.0.707480389165.issue15172@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Good that it works now. I've tagged this as a documentation issue.

----------
assignee:  -> docs at python
components: +Documentation -Tests
keywords:  -buildbot
nosy: +docs at python
title: SHA1 failures on the 64-bit Windows buildbot -> Document nasm-2.10.01 as required version for openssl
type: behavior -> enhancement

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

From report at bugs.python.org  Tue Jun 26 08:16:39 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Jun 2012 06:16:39 +0000
Subject: [docs] [issue13685] argparse update help msg  for % signs
In-Reply-To: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za>
Message-ID: <1340691399.67.0.603567759394.issue13685@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
title: argparse does not sanitize help strings for % signs -> argparse update help msg  for % signs

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

From report at bugs.python.org  Tue Jun 26 08:18:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Jun 2012 06:18:31 +0000
Subject: [docs] [issue13685] argparse update help msg  for % signs
In-Reply-To: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za>
Message-ID: <E1SjP6a-0007gl-06@dinsdale.python.org>


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

New changeset c696416eb4e9 by Senthil Kumaran in branch '3.2':
Issue #13685 - Update argparse help message for % sign usage.
http://hg.python.org/cpython/rev/c696416eb4e9

New changeset 493d58c3c57f by Senthil Kumaran in branch 'default':
merge from 3.2 - Issue13685
http://hg.python.org/cpython/rev/493d58c3c57f

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

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

From report at bugs.python.org  Tue Jun 26 08:19:10 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Jun 2012 06:19:10 +0000
Subject: [docs] [issue13685] argparse update help msg  for % signs
In-Reply-To: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za>
Message-ID: <1340691550.05.0.153939046437.issue13685@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


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

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

From report at bugs.python.org  Tue Jun 26 12:31:14 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Jun 2012 10:31:14 +0000
Subject: [docs] [issue14979] pdb doc: Add link to source
In-Reply-To: <1338555806.37.0.54245715922.issue14979@psf.upfronthosting.co.za>
Message-ID: <1340706674.17.0.590622528567.issue14979@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Adding link to pdb source may be not be suitable. Readers may require to understand the states which pdb goes through. Docs here are better, IMO. -1 vote from me.

----------
nosy: +orsenthil

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

From report at bugs.python.org  Tue Jun 26 13:45:20 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 26 Jun 2012 11:45:20 +0000
Subject: [docs] [issue14979] pdb doc: Explain how to extend debugger instead
	of	sending readers to the source
In-Reply-To: <1338555806.37.0.54245715922.issue14979@psf.upfronthosting.co.za>
Message-ID: <1340711120.27.0.721786750555.issue14979@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I agree that reading the source doesn't make it clear how to extend or use PDB, so I've changed the title. High level overview is required.

I think an example would really help there. For instance a simple execution scroller - analogue of `python -m trace --trace <filename.py>`, but with PDB and play/pause buttons controlled from external script.

----------
title: pdb doc: Add link to source -> pdb doc: Explain how to extend debugger instead of sending readers to the source

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

From report at bugs.python.org  Tue Jun 26 14:05:34 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Jun 2012 12:05:34 +0000
Subject: [docs] [issue13666] datetime documentation typos
In-Reply-To: <1324936913.94.0.649454454071.issue13666@psf.upfronthosting.co.za>
Message-ID: <E1SjUWR-0001wa-FY@dinsdale.python.org>


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

New changeset ec970793f390 by Senthil Kumaran in branch '3.2':
issue13666 - Fixing datetime documentation example when using tzinfo
http://hg.python.org/cpython/rev/ec970793f390

New changeset 98d40bd23381 by Senthil Kumaran in branch 'default':
issue13666 - merge from 3.2
http://hg.python.org/cpython/rev/98d40bd23381

New changeset 01d180987d90 by Senthil Kumaran in branch '2.7':
issue13666 - Fixing datetime documentation example when using tzinfo
http://hg.python.org/cpython/rev/01d180987d90

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

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

From report at bugs.python.org  Tue Jun 26 14:07:48 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Jun 2012 12:07:48 +0000
Subject: [docs] [issue13666] datetime documentation typos
In-Reply-To: <1324936913.94.0.649454454071.issue13666@psf.upfronthosting.co.za>
Message-ID: <1340712468.45.0.0828857344591.issue13666@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The docs are fixed now.

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

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

From report at bugs.python.org  Tue Jun 26 15:43:24 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Jun 2012 13:43:24 +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: <1340718204.68.0.805313396117.issue15034@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, let's move this, then.  I asked the question because I'd like to know what the best practice is for exceptions in the stdlib.  This is an area in which we have made quite a bit of progress recently (ie: the work done on exceptions for Python3, and PEP 3151), but I think there is still a lack of documentation (and possibly consensus?) on best practices for the stdlib.

----------
components: +Devguide -Documentation
resolution: later -> 
status: closed -> open
title: tutorial should use best practices in user defined exceptions section -> Devguide should document best practices for stdlib exceptions

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

From report at bugs.python.org  Tue Jun 26 20:26:23 2012
From: report at bugs.python.org (moijes12)
Date: Tue, 26 Jun 2012 18:26:23 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1340735182.61.0.174129672244.issue11681@psf.upfronthosting.co.za>


moijes12 <moijes12 at gmail.com> added the comment:

Hi Marc

I tried reproducing this for bytearray using Python 2.7.2 but I can't see a warning.

devel at moses:~$ python --version
Python 2.7.2+
devel at moses:~$ cat test_py.py 
k = range(10)
kb = bytearray(k)
print kb
kb = bytearray("hi")
print kb
devel at moses:~$ python -b test_py.py 
 
hi
devel at moses:~$ python -bb test_py.py 
 
hi

Please correct me if I'm wrong anywhere here. I'd like to work on this.

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

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

From report at bugs.python.org  Tue Jun 26 22:50:38 2012
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Jun 2012 20:50:38 +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: <1340743838.13.0.0441407555757.issue15151@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Moving back to blocker for beta2.

----------
nosy: +georg.brandl
priority: deferred blocker -> release blocker

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

From report at bugs.python.org  Wed Jun 27 03:00:02 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Jun 2012 01:00:02 +0000
Subject: [docs] [issue13685] argparse update help msg  for % signs
In-Reply-To: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za>
Message-ID: <1340758801.83.0.878400807491.issue13685@psf.upfronthosting.co.za>


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

Senthil, would you mind porting the fix to 2.7?  Thanks.

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

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

From report at bugs.python.org  Wed Jun 27 10:29:56 2012
From: report at bugs.python.org (=?utf-8?q?Beno=C3=AEt_Bryon?=)
Date: Wed, 27 Jun 2012 08:29:56 +0000
Subject: [docs] [issue14899] Naming conventions and guidelines for packages
	and	namespace packages
In-Reply-To: <1337863326.85.0.0790625001968.issue14899@psf.upfronthosting.co.za>
Message-ID: <1340785796.19.0.66569040019.issue14899@psf.upfronthosting.co.za>


Beno?t Bryon <benoit at marmelune.net> added the comment:

The proposal has been added to PEPs repository as PEP 423 :
http://hg.python.org/peps/rev/52767ab7e140

Review is about to be started at python-dev at python.org.

To adapt the scope of this issue, in cpython documentation, I am to:

* remove the Doc/packaging/packagenames.rst document
* replace it by references to PEP 423

Obviously, this work requires that PEP 423 is accepted.

----------

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

From report at bugs.python.org  Wed Jun 27 12:29:51 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jun 2012 10:29:51 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
Message-ID: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Since Python 2.3 many open functions supports "Universal line mode" (PEP 278). Since 3.0 (and 2.6) PEP 3116 suggests better alternative -- io.TextWrapper.

Now support for the 'U' mode in the different open functions is heterogeneous. Some functions simply ignore the 'U' mode (but accept it), others perceive it as a synonym for text-mode, others just pass it on lower lever, other attempt to implement it, but the implementation is obtained imperfect and contradictory (as in ZipExtFile). The documentation for built-in open does not advise the use of the 'U' mode. The 'U' mode support cumbersome. I propose to deprecate the 'U' mode. If someone wanted to work with the universal line support, he'll surely need to work with encodings too, and io.TextWrapper provides is better choise.

The deprecation plan for the 'U' mode of open functions might be as follow:

3.3.  Deprecating the 'U' mode in docs for all opens (building open, io.open, codecs.open, gzip.open, ZipFile.open, etc). Add suggestion about io.TextWrapper.
3.4.  Raise a warning on use of the 'U' mode.
3.5.  Raise an exception on use of the 'U' mode.
3.6 (or 4.0?).  Remove the 'U' mode processing code.

As the first stage involves only the changes to the documentation, I hope deprecation can starts in 3.3.

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 164142
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: Deprecate the 'U' open mode
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jun 27 12:32:30 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jun 2012 10:32:30 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1340793150.68.0.528550397881.issue15204@psf.upfronthosting.co.za>


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


----------
nosy: +gvanrossum, jackjansen, pitrou, stutzbach

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

From report at bugs.python.org  Wed Jun 27 12:50:58 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Jun 2012 10:50:58 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1340794258.0.0.381368337223.issue15204@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Related issues: #2091, #5148, #6759, #12900.

----------

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

From report at bugs.python.org  Wed Jun 27 12:53:21 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Jun 2012 10:53:21 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1340794401.58.0.268876514955.issue15204@psf.upfronthosting.co.za>


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

Starting to deprecate "U" in the 3.3 docs sounds reasonable to me.

----------
nosy: +georg.brandl, nadeem.vawda

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

From report at bugs.python.org  Wed Jun 27 15:31:01 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Jun 2012 13:31:01 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1340803861.6.0.985390625011.issue15204@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unless there are places where it is actually broken, I don't think there is a good reason to have step 3.5, though.  Just add the deprecation warning and remove it in 4.0.

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

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

From report at bugs.python.org  Wed Jun 27 17:52:50 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 27 Jun 2012 15:52:50 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1340812370.25.0.177749660647.issue15204@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/issue15204>
_______________________________________

From report at bugs.python.org  Thu Jun 28 02:57:04 2012
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Jun 2012 00:57:04 +0000
Subject: [docs] [issue15213] _PyOS_URandom documentation
Message-ID: <1340845023.83.0.143337072725.issue15213@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

The comment for Python/random.c:_PyOS_URandom() states

> Fill buffer with size pseudo-random bytes, not suitable for cryptographic use, from the operating random number generator (RNG).

which is not correct as all paths use a RNG that is suitable for most cryptographic purposes except long living private keys for asymmetric encryption.

Also the function isn't documented although it's an official API function and plays a vital role on the new hash randomization.

----------
assignee: docs at python
components: Documentation
messages: 164218
nosy: christian.heimes, docs at python, haypo, pitrou
priority: low
severity: normal
status: open
title: _PyOS_URandom documentation
versions: Python 3.3

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

From report at bugs.python.org  Thu Jun 28 08:27:42 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 28 Jun 2012 06:27:42 +0000
Subject: [docs] [issue15213] _PyOS_URandom documentation
In-Reply-To: <1340845023.83.0.143337072725.issue15213@psf.upfronthosting.co.za>
Message-ID: <1340864862.4.0.456609795796.issue15213@psf.upfronthosting.co.za>


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

It's not an official API, as the leading underscore specifies. Changing the comment sounds fine to me.

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

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

From report at bugs.python.org  Thu Jun 28 11:30:28 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jun 2012 09:30:28 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340803861.6.0.985390625011.issue15204@psf.upfronthosting.co.za>
Message-ID: <1340875849.2462.92.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Unless there are places where it is actually broken, I don't think there is a good reason to have step 3.5, though.  Just add the deprecation warning and remove it in 4.0.

Well. In any case, the 'U' mode in most cases has no effect, and the
code, where it has an effect (in zipfile), is very rarely used (and it
is actually complicated and broken).

Here are the patches for the first (documentation) and the second stage
(warnings).

----------

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

From report at bugs.python.org  Thu Jun 28 11:32:08 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jun 2012 09:32:08 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1340875928.64.0.114891194565.issue15204@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file26197/deprecate-U-mode-stage1.patch

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

From report at bugs.python.org  Thu Jun 28 11:32:48 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Jun 2012 09:32:48 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1340875968.14.0.556512244438.issue15204@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file26198/deprecate-U-mode-stage2.patch

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

From report at bugs.python.org  Thu Jun 28 12:45:16 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 28 Jun 2012 10:45:16 +0000
Subject: [docs] [issue14469] Python 3 documentation links
In-Reply-To: <1333298580.51.0.119482106967.issue14469@psf.upfronthosting.co.za>
Message-ID: <1340880316.05.0.827804775332.issue14469@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Right now, I do not see the problem mentioned in this report.

http://www.python.org/doc/ point to a page which has reference docs to both 2.7 and 3.0. 
The left hand side, Other Resources Link are generic too.

docs.python.org pointing to py2.7 is a python-dev decision and outside scope of this bug.

I am closing this one as works for me.

----------
nosy: +orsenthil
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Jun 28 23:28:36 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 28 Jun 2012 21:28:36 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1340918916.39.0.958081555109.issue15204@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

+1 for the general idea of deprecating and eventually removing the "U"
modes.

But I agree with David, that it doesn't make sense to have separate steps
for 3.5 and 3.6/4.0. If you make the code raise an exception when "U" is
used, how is that different from what will happen when you remove the
code for processing it? Surely we want it to eventually be treated just
like any other invalid mode string?

----------

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

From report at bugs.python.org  Fri Jun 29 02:19:49 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 29 Jun 2012 00:19:49 +0000
Subject: [docs] [issue15221] os.path.is*() may return False if path can't be
	accessed
Message-ID: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

It seems a doc fix is the best way to go, in which case I leave this one to a native English speaker:
http://mail.python.org/pipermail/python-dev/2012-June/120788.html

Alternatively a new 'strict' parameter has been proposed as a workaround:
http://mail.python.org/pipermail/python-dev/2012-June/120800.html

----------
assignee: docs at python
components: Documentation
messages: 164307
nosy: christian.heimes, docs at python, eric.araujo, ezio.melotti, georg.brandl, giampaolo.rodola, ncoghlan
priority: normal
severity: normal
status: open
title: os.path.is*() may return False if path can't be accessed
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jun 29 02:43:24 2012
From: report at bugs.python.org (Cameron Simpson)
Date: Fri, 29 Jun 2012 00:43:24 +0000
Subject: [docs] [issue15221] os.path.is*() may return False if path can't be
	accessed
In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>
Message-ID: <1340930604.31.0.975935770545.issue15221@psf.upfronthosting.co.za>


Changes by Cameron Simpson <cs at zip.com.au>:


----------
nosy: +cameron

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

From report at bugs.python.org  Fri Jun 29 02:50:26 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Jun 2012 00:50:26 +0000
Subject: [docs] [issue15221] os.path.is*() may return False if path can't be
	accessed
In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>
Message-ID: <1340931026.13.0.894741475344.issue15221@psf.upfronthosting.co.za>


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

-1 on a "strict" parameter. This is a pointless obfuscation of the API.

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

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

From report at bugs.python.org  Fri Jun 29 05:54:52 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 29 Jun 2012 03:54:52 +0000
Subject: [docs] [issue15221] os.path.is*() may return False if path can't be
	accessed
In-Reply-To: <1340929189.09.0.471144924132.issue15221@psf.upfronthosting.co.za>
Message-ID: <1340942092.71.0.125281108715.issue15221@psf.upfronthosting.co.za>


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

The os.path.exists() docs already cover all the gory details of when it may be false due to limited permissions. The is* docs refer to this by their use of the word "existing", but that's probably too subtle.

I suggest adding an extra sentence to the docs of all affected functions:

"This always returns False if os.path.exists(path) returns False."

----------

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

From report at bugs.python.org  Fri Jun 29 20:17:32 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Jun 2012 18:17:32 +0000
Subject: [docs] [issue13790] In str.format an incorrect error message for
	list, tuple, dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1340993852.12.0.3688715368.issue13790@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

>>> '%d' % ([],)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: %d format: a number is required, not list

----------
nosy: +storchaka

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

From report at bugs.python.org  Fri Jun 29 20:29:26 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 29 Jun 2012 18:29:26 +0000
Subject: [docs] [issue13790] In str.format an incorrect error message for
	list, tuple, dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1340994566.92.0.459079076756.issue13790@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Serhiy: I'm not sure what you're saying. At the point that str.format() is producing its error message, it doesn't know as much as %-formatting does about the original arguments, so it can't produce a similar message.

----------

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

From report at bugs.python.org  Fri Jun 29 20:55:53 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 29 Jun 2012 18:55:53 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1340996153.92.0.439688365034.issue15148@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun 29 20:57:58 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 29 Jun 2012 18:57:58 +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: <1340996278.43.0.730417149102.issue15034@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/issue15034>
_______________________________________

From report at bugs.python.org  Sat Jun 30 09:01:10 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Jun 2012 07:01:10 +0000
Subject: [docs] [issue13790] In str.format an incorrect error message for
	list, tuple, dict, set
In-Reply-To: <1340994566.92.0.459079076756.issue13790@psf.upfronthosting.co.za>
Message-ID: <1341039690.3957.24.camel@raxxla>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Serhiy: I'm not sure what you're saying. At the point that str.format() is producing its error message, it doesn't know as much as %-formatting does about the original arguments, so it can't produce a similar message.

I'm surprised that the code of the classic and the modern formatting is
so different. Looking deeper, I saw that the issue will go away in 3.4.
I agree with you in msg151728.

----------

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

From report at bugs.python.org  Sat Jun 30 21:55:23 2012
From: report at bugs.python.org (Daniel Grace)
Date: Sat, 30 Jun 2012 19:55:23 +0000
Subject: [docs] [issue15228] os.utime() docs not clear on behavior on
	nonexistant	files
Message-ID: <1341086123.85.0.135321380132.issue15228@psf.upfronthosting.co.za>


New submission from Daniel Grace <thisgenericname at gmail.com>:

The documentation for os.utime() at http://docs.python.org/py3k/library/os.html#os.utime states:

"Set the access and modified times of the file specified by path. [...] The effect is similar to running the Unix program touch on the path.)"

Unlike 'touch', os.utime() will not create an empty file if called on a file that does not exist.  IMO the current behavior is correct, but the comparison of os.utime() to touch implies that it would create empty files.

I suggest clarifying the documentation to emphasize that os.utime() will not create new files and raises OSError in the event that the file does not exist.

----------
assignee: docs at python
components: Documentation
messages: 164422
nosy: dewin, docs at python
priority: normal
severity: normal
status: open
title: os.utime() docs not clear on behavior on nonexistant files
type: enhancement

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

From munjunga at gmail.com  Mon Jun 18 06:29:06 2012
From: munjunga at gmail.com (Isaac Munjunga)
Date: Mon, 18 Jun 2012 06:29:06 +0200
Subject: [docs] Language Missing in Python
Message-ID: <CAKUdDH-UdB1MeNaj3amBWZeVnpzr6MwP8uKyk7BJNw8uUiDStg@mail.gmail.com>

I can't find my language every time I update my Ubuntu distro. Kindly
include and update locale:

'en_ZM': 'en_GB.ISO8859-1',
'en_ZM.iso88591': 'en_GB.ISO8859-1',

I manually include that, but I know someone people may not have the time to
do it.

Thanks,

Isaac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120618/be064966/attachment-0001.html>

From alex.tzonkov at gmail.com  Mon Jun 18 16:23:52 2012
From: alex.tzonkov at gmail.com (Alex Tzonkov)
Date: Mon, 18 Jun 2012 07:23:52 -0700
Subject: [docs] Documentation issue with web site for 2.6.7
In-Reply-To: <CAB4XWXwjcEyUC_pGK2B7UZieFh+2fMREFobrFhCw=teyKwdyeA@mail.gmail.com>
References: <CACMd8DM7PA9EnXL787FcsdgDbScRE0nefKLKd=zibHUa+v2Wcw@mail.gmail.com>
	<CAB4XWXwjcEyUC_pGK2B7UZieFh+2fMREFobrFhCw=teyKwdyeA@mail.gmail.com>
Message-ID: <6F15F2A3-C7E4-4583-95BA-E30ACB39754C@gmail.com>

I agree it looks fine now. It took 3-4 days and then it was back to normal. I ended up using version 2.6.6 while it was acting up. 

Thanks!
Alex

On Jun 17, 2012, at 9:48, Sandro Tosi <sandro.tosi at gmail.com> wrote:

Hello Alex,

On Mon, Jun 11, 2012 at 6:51 PM, Intel Dork <intel.dork at gmail.com> wrote:
> It seems that the "Quick Search" for the 2.6.7 version of the documentation
> has gone missing. I see it for all other versions. Any way to restore that
> functionality?

I've just tried and it seems to work fine: can you please check again,
and in case let us know what you're exactly doing, so we can
replicate.

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

From dmoisset at machinalis.com  Mon Jun 18 20:28:42 2012
From: dmoisset at machinalis.com (Daniel Moisset)
Date: Mon, 18 Jun 2012 15:28:42 -0300
Subject: [docs] Documentation bug on
	http://docs.python.org/library/atexit.html
Message-ID: <CALuYSZUyJJYtO9+pptqDXvikcR3PQJbsVu+nL1hgtjP0HXFHPg@mail.gmail.com>

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 :)

Regards,
    D.

From jonas743 at gmail.com  Thu Jun 21 14:41:40 2012
From: jonas743 at gmail.com (Jonas Frey)
Date: Thu, 21 Jun 2012 14:41:40 +0200
Subject: [docs] error in regular expression howto.
Message-ID: <CAMmiQ_QKPwN4rqVayFrppunc2NbFBVz6_-bU-m8V4oKwGTGW3w@mail.gmail.com>

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.

Jonas

From aflanagan at mediageneral.com  Thu Jun 21 16:55:31 2012
From: aflanagan at mediageneral.com (aflanagan at mediageneral.com)
Date: Thu, 21 Jun 2012 14:55:31 +0000
Subject: [docs] BUG: Bad footnote in library/profile.html
Message-ID: <AA4CE0344DEADB4A8776358B70975101FCB77A@HANMBX1.mg.themeganet.com>

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."

From denver at sleepydragon.org  Fri Jun 22 08:04:27 2012
From: denver at sleepydragon.org (Denver Coneybeare)
Date: Fri, 22 Jun 2012 02:04:27 -0400
Subject: [docs] bug report: inconsistent use of PyUnicode_FromString and
 PyString_FromString "5.3. Pure Embedding"
Message-ID: <CALL-GrfzHhA-YD_8rSQxJ8fe=uhOH5DQJJXBTTYngX_eHb5-FA@mail.gmail.com>

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!

--Denver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120622/f62ce9df/attachment-0001.html>

From gedwards2 at gmail.com  Sat Jun 23 23:51:21 2012
From: gedwards2 at gmail.com (Greg Edwards)
Date: Sun, 24 Jun 2012 07:51:21 +1000
Subject: [docs] Sloppy example at sect 8.3 of Python 2.7.3 tutorial
Message-ID: <CAPptrgQ3GGs5wXjcz=jetrn19nJ93KwdQfBGpKv3wZwo+=YFmA@mail.gmail.com>

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.

There you go ! One Giant Leap .....

-- 
Greg Edwards,
Port Jackson Bioinformatics
gedwards2 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120624/d5725448/attachment-0001.html>

From matthew.woelfel at gmail.com  Wed Jun 27 00:32:27 2012
From: matthew.woelfel at gmail.com (Matt Woelfel)
Date: Tue, 26 Jun 2012 17:32:27 -0500
Subject: [docs] small documentation bug in multiprocessing
Message-ID: <CAOgNHrPiP3bO5qu6rmotbKTKa3_-+VVre=+PmY7RiqV7OKK_=g@mail.gmail.com>

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".

Regards,

Matt

From ianspiral at gmail.com  Wed Jun 27 20:09:37 2012
From: ianspiral at gmail.com (Ian Jeffries)
Date: Wed, 27 Jun 2012 14:09:37 -0400
Subject: [docs] do you have the Python 2.7.3 Documentation in .EPUB? thanks!
	#EOM
Message-ID: <CAA3d0CAQxi8_4iaCA+=kVwAfVjqZgmx21BAbw+ak3yuG=MkERQ@mail.gmail.com>


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

From tellamon at gmail.com  Thu Jun 28 15:40:29 2012
From: tellamon at gmail.com (=?UTF-8?B?7J6l64+Z7ZeMKERvbmdIZW9uIEphbmcp?=)
Date: Thu, 28 Jun 2012 22:40:29 +0900
Subject: [docs] bug in tutorial 7.Input and Output
Message-ID: <CAHvn7K9VcjbTp9S_J28FZMC+1VSvpkOBLwMSVOdmNx9uiRCwoA@mail.gmail.com>

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       ==>       4098Dcab       ==>       7678Sjoerd     ==>       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

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120628/12e28d3f/attachment-0001.html>

From brgreening at gmail.com  Fri Jun 29 00:15:15 2012
From: brgreening at gmail.com (bernard greening)
Date: Thu, 28 Jun 2012 15:15:15 -0700
Subject: [docs] The computation of pi in Decimal fixed point and floating
	point arithmetic
Message-ID: <4FECD773.6010109@gmail.com>

This is not a bug, its a question.

on the web page

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


  9.4 Decimal fixed point and floating point arithmetic


in the


    9.4.7. Recipes? <http://docs.python.org/library/decimal.html#recipes>

section is a function to compute the value of pi

def  pi():
     """Compute Pi to the current precision.

     >>>  print pi()
     3.141592653589793238462643383

     """
     getcontext().prec  +=  2   # extra digits for intermediate steps
     three  =  Decimal(3)       # substitute "three=3.0" for regular floats
     lasts,  t,  s,  n,  na,  d,  da  =  0,  three,  3,  1,  0,  0,  24
     while  s  !=  lasts:
         lasts  =  s
         n,  na  =  n+na,  na+8
         d,  da  =  d+da,  da+32
         t  =  (t  *  n)  /  d
         s  +=  t
     getcontext().prec  -=  2
     return  +s                # unary plus applies the new precision


I would like to ask the author what algorithm this is based upon and any references as to how it works.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120628/45d50598/attachment-0001.html>

From focajoca at sapo.pt  Fri Jun 29 17:31:15 2012
From: focajoca at sapo.pt (focajoca at sapo.pt)
Date: Fri, 29 Jun 2012 16:31:15 +0100
Subject: [docs] Python v3.2.3 - Help me!
Message-ID: <20120629163115.Horde.lCUwD3CXF3VP7cpDxRTi1BA@mail.sapo.pt>

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 resultwould be: ['10','20','30','40']

  Test2:
  >>> defdouble(x):
  ? ? ? ? return 2*x

  >>> map (double,m)
<map object at 0x01007A70>
The expected resultwould be: [20,40,60,80]

Where am Igoing wrong?Can you help?

thankin advance
   Carlos Cardoso
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120629/b555669a/attachment.html>