 boxes in the Sphinx generated html docs.

For example:
http://666kb.com/i/boxys2zktxky17vsh.png
taken on Chrome 7 on Windows.

I believe that the cause of the behaviour is a bug in the WebKit engine. If that's the case, adding "overflow-y: hidden" to the  css style would fix the issue.
"overflow-y" is not standard css, but it is understood by the affected browsers, looks ok on other modern browsers and is just ignored on older releases.

The provided patch has been tested on all major Windows browsers.

----------
assignee: docs at python
components: Documentation
files: webkit.patch
keywords: patch
messages: 123338
nosy: davide.rizzo, docs at python
priority: normal
severity: normal
status: open
title: WebKit browsers show superfluous scrollbars in html docs
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19936/webkit.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec  4 12:39:28 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 04 Dec 2010 11:39:28 +0000
Subject: [docs] [issue10622] WebKit browsers show superfluous scrollbars in
	html docs
In-Reply-To: <1291462354.78.0.0263278148003.issue10622@psf.upfronthosting.co.za>
Message-ID: <1291462768.18.0.0462765805448.issue10622@psf.upfronthosting.co.za>

Gregory P. Smith  added the comment:

r87027 has it for py3k / 3.2.  needs backporting to the other branches.

----------
nosy: +gregory.p.smith
versions:  -Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec  4 14:08:14 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 04 Dec 2010 13:08:14 +0000
Subject: [docs] =?utf-8?q?=5Bissue10623=5D_What=E2=80=99s_New_In_Python_3?=
 =?utf-8?q?=2E2_document_refers_to_PEP_382=3A_Defining_a_Stable_ABI?=
In-Reply-To: <1291468094.37.0.919975926538.issue10623@psf.upfronthosting.co.za>
Message-ID: <1291468094.37.0.919975926538.issue10623@psf.upfronthosting.co.za>

New submission from Daniel Urban :

But "Defining a Stable ABI" is PEP 384: http://www.python.org/dev/peps/pep-0384/
(PEP 382 is "Namespace Packages")

----------
assignee: docs at python
components: Documentation
messages: 123345
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: What?s New In Python 3.2 document refers to PEP 382: Defining a Stable ABI
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec  4 14:50:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 04 Dec 2010 13:50:17 +0000
Subject: [docs] =?utf-8?q?=5Bissue10623=5D_What=E2=80=99s_New_In_Python_3?=
 =?utf-8?q?=2E2_document_refers_to_PEP_382=3A_Defining_a_Stable_ABI?=
In-Reply-To: <1291468094.37.0.919975926538.issue10623@psf.upfronthosting.co.za>
Message-ID: <1291470617.19.0.746130586403.issue10623@psf.upfronthosting.co.za>

Martin v. L?wis  added the comment:

Thanks for the report. Fixed in r87042

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From eliben at gmail.com  Sat Dec  4 14:54:26 2010
From: eliben at gmail.com (Eli Bendersky)
Date: Sat, 4 Dec 2010 15:54:26 +0200
Subject: [docs] official place to document list's methods
Message-ID: 

Hello docs at python,

I'm currently working on issue 10516 (adding the .clear and .copy methods to
list, for Python 3.3) and I'm wondering where in the documentation I should
describe these new methods. The closest place I found that looks like it's
listing the methods of a list is sections 3.3.6 and 4.6.4. In particular
4.6.4 looks suitable, but it talks about bytearray too. Can you recommend
how to proceed with this?

Thanks in advance,
Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From merwok at netwok.org  Sat Dec  4 15:46:55 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 04 Dec 2010 15:46:55 +0100
Subject: [docs] [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1291471680.1.0.121919939415.issue10516@psf.upfronthosting.co.za>
References: <1291471680.1.0.121919939415.issue10516@psf.upfronthosting.co.za>
Message-ID: <4CFA545F.9040004@netwok.org>

Hi Eli,

I think the right place is 4.6.4,
http://docs.python.org/dev/library/stdtypes#mutable-sequence-types

It starts with ?List and bytearray objects support additional operations
that allow in-place modification of the object?.

For methods not supported by bytearray, you can use the fake footnote
(8) and edit its texte (?sort() is not supported by bytearray objects?).

Regards

From report at bugs.python.org  Sat Dec  4 16:16:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 04 Dec 2010 15:16:14 +0000
Subject: [docs] [issue10609] dbm documentation example doesn't work
	(iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1291475774.61.0.0396510601656.issue10609@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Arg, the internal classes returned by dbm.*.open have keys but not necessarily items.  See #9523, #6045 and #5736.

The docs should be fixed independently of that, with the less non-idiomatic code that we can find.  Do you want to check the dbm docs for other similar broken examples?  I?ll review the patch.

----------
assignee: docs at python -> eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec  5 18:57:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Dec 2010 17:57:25 +0000
Subject: [docs] [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1291571845.32.0.769522607117.issue9101@psf.upfronthosting.co.za>

Changes by ?ric Araujo :

----------
status: closed -> open
versions:  -Python 2.6

_______________________________________
Python tracker 

_______________________________________

From reese at ece.msstate.edu  Sat Dec  4 15:06:55 2010
From: reese at ece.msstate.edu (Bob Reese)
Date: Sat, 4 Dec 2010 08:06:55 -0600 (CST)
Subject: [docs] Python Doc bug, 5.3 Pure Emebedding
Message-ID: <14882134.113461291471615666.JavaMail.root@zimbra.ece.msstate.edu>

FYI (great job on documentation!!) 

5.3 Pure Embedding code example. 

This is a good example but under 2.3 and 2.6 on my Linux systems, the example fails to run because the sys.path variable does not have the current working directory ('[]') on it, so the module is not found (the python code is in the cwd). I am not sure why this occurs, because if the normal python interpreter is executed and the sys.path variable printed, the current working directory is on that path. 

I don't know why starting up the interpreter under C code control produces a different sys.path value from starting up the Python interpret from a shell command line (everything is the same except for the cwd being present). 

Somebody else in web land has also experienced this problem, as evidenced by (this is the same behavior that I see): 
http://coding.derkeiler.com/Archive/Python/comp.lang.python/2006-10/msg01029.html 

The real fix would be to identify what is causing this difference in sys.path values, but I have not been able to do this. It is probable that this is just an environment issue of some kind, but I don't know what it is. 

My bogus fix is to modify the example to add the current working directory to the sys.path variable as follows: 

void fixSysPath(void) { 
PyObject *pSysModule; 
PyObject *pSysPath; 
PyObject *pCwd; 
int i; 

pSysModule = PyImport_ImportModule("sys"); 
if (pSysModule == NULL) { 
myErr("Import of sys module failed"); 
exit(-1); 
} 

pSysPath = PyObject_GetAttrString(pSysModule, "path"); 
if (!pSysPath) { 
myErr("Cannot find 'sys.path'"); 
exit(-1); 
} 
pCwd = PyString_FromString(""); //null string represents cwd 
PyList_Insert(pSysPath,0,pCwd); 

} 

And in the example....: 
Py_Initialize(); 
fixSysPath(); //<<<<---Added 

Thanks. Great job on the documentation! 

---------------------------------------------------------------- 
Bob Reese 662/325-3154 (voice) 
reese at ece.msstate.edu 662/325-2298 (fax) 
http://www.ece.msstate.edu/~reese 
Associate Prof/Electrical & Computer Engineering 
Mississippi State University 
US Mail Address: 
Box 9571, Miss State, MS 39762 
Street Address: 
309 Simrall Hall, Hardy Street, Miss State, MS 39762 
---------------------------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From silleknarf at hotmail.com  Sun Dec  5 19:14:31 2010
From: silleknarf at hotmail.com (Frank Ellis)
Date: Sun, 5 Dec 2010 18:14:31 +0000
Subject: [docs] Possible bug in 3.2 Accumulate Function
Message-ID: 

Quoting from the http://docs.python.org/dev/py3k/whatsnew/3.2.html page:
The itertools module has a new function, accumulate() modeled on APL?s scan operator and on Numpy?s accumulate function:>>> list(accumulate(8, 2, 50))
[8, 10, 60]
>>> prob_dist = [0.1, 0.4, 0.2, 0.3]
>>> list(accumulate(prob_dist))      # cumulative probability distribution
[0.1, 0.5, 0.7, 1.0]                                                                       I'm not sure if this is a bug as I'm not sure if this is how the function actually behaves. Should the first function not take a list? For example:>>> list(accumulate([8, 2, 50]))
[8, 10, 60]Notice the square brackets. I have not actually tested the function personally but it seems like something worth noting.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Mon Dec  6 00:14:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 05 Dec 2010 23:14:55 +0000
Subject: [docs] [issue8910] Write a text file explaining why Lib/test/data
	exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1291590895.85.0.481941096399.issue8910@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Temporarily reopening so that Martin can decide whether he wants to add Lib/test/data/README to msi.py

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec  6 00:32:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Dec 2010 23:32:48 +0000
Subject: [docs] [issue8910] Write a text file explaining why Lib/test/data
	exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1291591968.56.0.501018866419.issue8910@psf.upfronthosting.co.za>

Martin v. L?wis  added the comment:

All README files are automatically packages, and so is this one.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 21:25:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:25:04 +0000
Subject: [docs] [issue10545] remove or rewrite "Using Backslash to
	Continue	Statements" anti-idiom
In-Reply-To: <1290804632.88.0.494003444216.issue10545@psf.upfronthosting.co.za>
Message-ID: <1291839904.94.0.938818796969.issue10545@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

This is essentially a duplicate of #7391 where it is already agreed that a change should be made to that section.

----------
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> Re-title the "Using Backslash to Continue Statements" anti-idiom

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 21:41:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:41:06 +0000
Subject: [docs] [issue10546] UTF-16-LE and UTF-16-BE support non-BMP
	characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291840866.6.0.995294025724.issue10546@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

Marc or Alexander, can you confirm that the patch is correct?

----------
assignee: docs at python -> cgw
nosy: +belopolsky, cgw, lemburg, terry.reedy
stage:  -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 21:57:07 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:57:07 +0000
Subject: [docs] [issue10546] UTF-16-LE and UTF-16-BE support non-BMP
	characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291841827.77.0.0326034295369.issue10546@psf.upfronthosting.co.za>

Changes by Terry J. Reedy :

----------
assignee: cgw -> 

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 21:57:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 08 Dec 2010 20:57:30 +0000
Subject: [docs] [issue10546] UTF-16-LE and UTF-16-BE support non-BMP
	characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291841850.18.0.183730071187.issue10546@psf.upfronthosting.co.za>

Changes by Terry J. Reedy :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 22:48:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 21:48:17 +0000
Subject: [docs] [issue10546] UTF-16-LE and UTF-16-BE support non-BMP
	characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291844897.23.0.205752165721.issue10546@psf.upfronthosting.co.za>

Alexander Belopolsky  added the comment:

If Victor says so ...

Someone needs to check that it works on a UCS4 build, but on a narrow build I don't think UTF-16-XX encodings need to do anything special - they just encode the surrogates as ordinary code units.

>>> '\U00010000'.encode('UTF-16-BE').decode('UTF-16-BE') == '\U00010000'
True
>>> '\U00010000'.encode('UTF-16-LE').decode('UTF-16-LE') == '\U00010000'
True

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 23:04:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 22:04:14 +0000
Subject: [docs] [issue10546] UTF-16-LE and UTF-16-BE support non-BMP
	characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291845853.98.0.131129667867.issue10546@psf.upfronthosting.co.za>

Alexander Belopolsky  added the comment:

I have verified that UTF-16-XX encodings work on wide build.  The doc change LGTM.  Bonus points for checking that we have unit tests for these encodings that include non-BMP characters.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 23:05:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 22:05:50 +0000
Subject: [docs] [issue10546] UTF-16-LE and UTF-16-BE support non-BMP
	characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291845950.18.0.0482810746016.issue10546@psf.upfronthosting.co.za>

Changes by Alexander Belopolsky :

----------
components: +Unicode

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 23:08:34 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 08 Dec 2010 22:08:34 +0000
Subject: [docs] [issue9738] Document the encoding of functions bytes
	arguments of the	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1291846114.47.0.869837071226.issue9738@psf.upfronthosting.co.za>

Dave Malcolm  added the comment:

A (probably crazy) idea that just occurred to me:
  typedef char utf8_bytes;
  typedef char iso8859_1_bytes;
  typedef char fsenc_bytes;

then specify the encoding in the type signature of the API e.g.:
- int PyRun_SimpleFile(FILE *fp, const char *filename)
+ int PyRun_SimpleFile(FILE *fp, const fsenc_bytes *filename)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 23:26:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Dec 2010 22:26:35 +0000
Subject: [docs] [issue10546] UTF-16-LE and UTF-16-BE support non-BMP
	characters
In-Reply-To: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>
Message-ID: <1291847195.17.0.286348078618.issue10546@psf.upfronthosting.co.za>

STINNER Victor  added the comment:

Fixed by r87135.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec  8 23:55:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 08 Dec 2010 22:55:11 +0000
Subject: [docs] [issue9738] Document the encoding of functions bytes
	arguments of the	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1291848911.44.0.756446519525.issue9738@psf.upfronthosting.co.za>

Alexander Belopolsky  added the comment:

> A (probably crazy) idea that just occurred to me:
>  typedef char utf8_bytes;
>  typedef char iso8859_1_bytes;
>  typedef char fsenc_bytes;

I like it!  Let's see how far we can get without iso8859_1_bytes, though.  (It is likely to be locale_bytes anyways.)  There are a few places where we'll need ascii_bytes.

The added benefit is that we can make these typedefs unsigned char and avoid char signness being ambiguous.  We will also need to give the typedefs the Py_ prefix.

And an obligatory bikesheding comment: if we typedef char, we should use singular form.  Or we can typedef char* Py_utf8_bytes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 13:11:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 09 Dec 2010 12:11:29 +0000
Subject: [docs] [issue10658] Link to source code is broken
In-Reply-To: <1291896689.57.0.983903414359.issue10658@psf.upfronthosting.co.za>
Message-ID: <1291896689.57.0.983903414359.issue10658@psf.upfronthosting.co.za>

New submission from anatoly techtonik :

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

----------
assignee: docs at python
components: Documentation
messages: 123677
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Link to source code is broken
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 13:13:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Dec 2010 12:13:49 +0000
Subject: [docs] [issue10658] Link to source code is broken
In-Reply-To: <1291896689.57.0.983903414359.issue10658@psf.upfronthosting.co.za>
Message-ID: <1291896829.94.0.421601720399.issue10658@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Fixed in r87143.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 14:20:33 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 09 Dec 2010 13:20:33 +0000
Subject: [docs] [issue10659] Hook scripts for immediate doc build system
In-Reply-To: <1291900833.32.0.658396193822.issue10659@psf.upfronthosting.co.za>
Message-ID: <1291900833.32.0.658396193822.issue10659@psf.upfronthosting.co.za>

New submission from anatoly techtonik :

When a new revision is committed to documentation, it will be nice to have hook scripts that start documentation build process on development server. 

Another hook script may also analyze commit message, extract ticket number, branch and revision from it. Then post a comment with a link to development version of documentation and close the ticket.

See how it works on Google Code http://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control

----------
assignee: docs at python
components: Documentation
messages: 123680
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Hook scripts for immediate doc build system

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 15:49:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 09 Dec 2010 14:49:15 +0000
Subject: [docs] [issue10659] Hook scripts for immediate doc build system
In-Reply-To: <1291900833.32.0.658396193822.issue10659@psf.upfronthosting.co.za>
Message-ID: <1291906155.79.0.0807608625741.issue10659@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

The development docs are rebuilt twice a day; that should be enough.

As for tracker integration with version control, that is already an issue for the meta tracker at http://psf.upfronthosting.co.za/roundup/meta/issue20 (which you should know, since you commented there.)

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 22:31:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 21:31:16 +0000
Subject: [docs] [issue10665] Update and expand unicodedata module
	documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>

New submission from Alexander Belopolsky :

unicodedata module documentation has not been updated to reflect transition to 6.0.  Attached patch fixes the version and unicode.org links and starts making the documentation rely less on the unicode.org pages for basic understanding of the provided functionality.

I am posting work in progress to solicit feedback on how much of the Unicode Standard information we would want to present here.

On of the goals of this patch is to provide a standard reference that can be used throughout the library manual for basic Unicode concepts without sending the reader over to unicode.org.

----------
assignee: docs at python
components: Documentation
files: unicodedata-doc.diff
keywords: patch
messages: 123700
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Update and expand unicodedata module documentation
versions: Python 3.2
Added file: http://bugs.python.org/file19990/unicodedata-doc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 22:34:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 21:34:32 +0000
Subject: [docs] [issue10665] Update and expand unicodedata module
	documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291930472.26.0.831334132016.issue10665@psf.upfronthosting.co.za>

Changes by Alexander Belopolsky :

----------
components: +Unicode

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 23:27:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 22:27:02 +0000
Subject: [docs] [issue10665] Update and expand unicodedata module
	documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291933622.69.0.226915907811.issue10665@psf.upfronthosting.co.za>

Alexander Belopolsky  added the comment:

Added more tables semi-automatically produced from http://www.unicode.org/Public/UNIDATA/PropertyValueAliases.txt

----------
Added file: http://bugs.python.org/file19991/unicodedata-doc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec  9 23:27:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Dec 2010 22:27:07 +0000
Subject: [docs] [issue10665] Update and expand unicodedata module
	documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291933627.92.0.757963572863.issue10665@psf.upfronthosting.co.za>

Changes by Alexander Belopolsky :

Removed file: http://bugs.python.org/file19990/unicodedata-doc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 00:10:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 09 Dec 2010 23:10:07 +0000
Subject: [docs] [issue10665] Update and expand unicodedata module
	documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1291936207.07.0.529673515989.issue10665@psf.upfronthosting.co.za>

Martin v. L?wis  added the comment:

Please, one issue per report and checkin, and no work-in-progress on the tracker. The issue of factually correcting claims about the unicodedata module and elaborations on how it works are unrelated issues.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 09:16:54 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 10 Dec 2010 08:16:54 +0000
Subject: [docs] [issue10670] Provide search scope limits
In-Reply-To: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>
Message-ID: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>

New submission from anatoly techtonik :

When searching docs (e.g. for http://docs.python.org/dev/search.html?q=unicode&check_keywords=yes&area=default) I'd like to filter out C API.

----------
assignee: docs at python
components: Documentation
messages: 123719
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Provide search scope limits

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 13:48:27 2010
From: report at bugs.python.org (Mayweed)
Date: Fri, 10 Dec 2010 12:48:27 +0000
Subject: [docs] [issue10672] ["with"] new in version 2.6 instead of 2.5
In-Reply-To: <1291985307.04.0.397255362186.issue10672@psf.upfronthosting.co.za>
Message-ID: <1291985307.04.0.397255362186.issue10672@psf.upfronthosting.co.za>

New submission from Mayweed :

In the documentation, the statement "with" is marked as:
"New in version 2.5."
(http://docs.python.org/reference/compound_stmts.html#the-with-statement)

This new statement is new in version 2.6 !

----------
assignee: docs at python
components: Documentation
messages: 123731
nosy: docs at python, karmaguedon
priority: normal
severity: normal
status: open
title: ["with"] new in version 2.6 instead of 2.5
versions: Python 2.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 14:24:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 10 Dec 2010 13:24:44 +0000
Subject: [docs] [issue10672] ["with"] new in version 2.6 instead of 2.5
In-Reply-To: <1291985307.04.0.397255362186.issue10672@psf.upfronthosting.co.za>
Message-ID: <1291987483.99.0.136681826985.issue10672@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

It is in fact new in 2.5, but only available when using "from __future__ import with_statement", which the note near the end of the section details.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 18:22:23 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Dec 2010 17:22:23 +0000
Subject: [docs] [issue10669] Remove Deprecation Warnings
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292001743.79.0.976652675386.issue10669@psf.upfronthosting.co.za>

Changes by Ezio Melotti :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 19:31:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 10 Dec 2010 18:31:18 +0000
Subject: [docs] [issue10665] Expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: 

Alexander Belopolsky  added the comment:

On Thu, Dec 9, 2010 at 6:10 PM, Martin v. L?wis  wrote:
..
> Please, one issue per report and checkin,

The s/5.2/6.0/ issue is hardly worth a tracker ticket.   I've
committed these changes in r87159.  (Sorry for the unrelated changes -
reverted in the next checkin.)

> and no work-in-progress on the tracker.

Why?  I thought "release early, release often" was a good thing.   I
wanted to get an early feedback because we certainly don't want to
replicate the Unicode Standard in the Python documentation, but I
think at least for the category() method that returns cryptic 2-letter
codes, we should include a table explaining them.   I am not so sure
about bidirectional() or asian_width().

> The issue of factually correcting claims about the unicodedata module and elaborations on how it works are unrelated issues.

I am changing the title of the issue to make it cover only the latter.
>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
title: Update and expand unicodedata module documentation -> Expand unicodedata module documentation

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 19:42:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 10 Dec 2010 18:42:27 +0000
Subject: [docs] [issue10665] Expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1292006547.1.0.922736268862.issue10665@psf.upfronthosting.co.za>

Changes by Alexander Belopolsky :

----------
nosy: +ezio.melotti, haypo, lemburg

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 21:25:46 2010
From: report at bugs.python.org (Philip Bober)
Date: Fri, 10 Dec 2010 20:25:46 +0000
Subject: [docs] [issue10676] Confusing note in Numeric Types
In-Reply-To: <1292012746.16.0.939598765846.issue10676@psf.upfronthosting.co.za>
Message-ID: <1292012746.16.0.939598765846.issue10676@psf.upfronthosting.co.za>

New submission from Philip Bober :

In the Python Standard Library reference, section 5.4: Numeric Types, the table of operators/functions has the following unclear note:

(4)Complex floor division operator, modulo operator, and divmod().
   Deprecated since version 2.3: Instead convert to float using abs() if appropriate.

The intention of this note is to indicate that //,%, and divmod shouldn't be used with complex numbers, but the phrasing is bad and the note being on generic operators makes it sound like the operators themselves are deprecated, not just for complex numbers. 

There was an earlier bugfix (621708, on the previous tracker. Archive: http://mail.python.org/pipermail/python-bugs-list/2002-October/013913.html) which fixed this bad wording elsewhere in the docs (Section 5.6 Binary arithmetic operations in the Python Reference Manual) but it seems the same wording was in both documents and it was only patched in one of them. 

It was replaced with:
"Deprecated since version 2.3: The floor division operator, the modulo operator, and the divmod() function are no longer defined for complex numbers. Instead, convert to a floating point number using the abs() function if appropriate."

----------
assignee: docs at python
components: Documentation
messages: 123750
nosy: Philip.Bober, docs at python
priority: normal
severity: normal
status: open
title: Confusing note in Numeric Types
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 10 22:23:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 10 Dec 2010 21:23:11 +0000
Subject: [docs] [issue10665] Expand unicodedata module documentation
In-Reply-To: <1291930276.17.0.60709403086.issue10665@psf.upfronthosting.co.za>
Message-ID: <1292016190.46.0.950604496476.issue10665@psf.upfronthosting.co.za>

Alexander Belopolsky  added the comment:

In issue10665.diff, I completed the character examples in the general categories table.

----------
Added file: http://bugs.python.org/file20002/issue10665.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 00:04:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 10 Dec 2010 23:04:41 +0000
Subject: [docs] [issue10665] Expand unicodedata module documentation
In-Reply-To: 
Message-ID: <4D02B206.4060905@v.loewis.de>

Martin v. L?wis  added the comment:

> Why?  I thought "release early, release often" was a good thing.

Create a branch for that, or post an issue on Rietveld. W-I-P IMO
confuses people reviewing the patches, running into the same ones
over-and-over again, only to find out every time "it's not ready yet".
So the natural reaction is to close it as rejected, for it being
incomplete.

Regards,
Martin

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 05:18:10 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Dec 2010 04:18:10 +0000
Subject: [docs] [issue10669] Document Deprecation Warnings and how to fix
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292041090.49.0.0713191155362.issue10669@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

The issue is not the specific warnings Rusi got but how, in general, one can get more information when the warnings are too cryptic to deal with.

One response might be that DeprecationWarnings should be much wordier than they are -- a paragraph of a few sentences rather than just a minimal sentence. Another might be that each release have a HOW-TO doc or What's New section with a paragraph for each one added to that release.

Currently, information is scattered among pydev posts, tracker issues, commit messages, News entries, and maybe What's new.

----------
nosy: +rhettinger, terry.reedy
title: Remove Deprecation Warnings -> Document Deprecation Warnings and how to fix
versions: +Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 07:55:04 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 11 Dec 2010 06:55:04 +0000
Subject: [docs] [issue10669] Document Deprecation Warnings and how to fix
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292050504.73.0.205212664116.issue10669@psf.upfronthosting.co.za>

Ezio Melotti  added the comment:

The deprecation notes in the doc should be quite easy to find and can be more verbose, but there are a few cases where the deprecation is not about a specific function but something more "abstract" (e.g. some syntax change, or the "Overriding __eq__ blocks inheritance of __hash__ in 3.x" reported by the OP).
Listing new deprecations in the what's new it's a good idea, but otherwise a clear message (that also suggests how to fix the problem) and a deprecation note in the doc (using the '.. deprecated::' directive) should be enough.

----------

_______________________________________
Python tracker 

_______________________________________

From wonjohn.choi at gmail.com  Fri Dec 10 09:28:46 2010
From: wonjohn.choi at gmail.com (Wonjohn Choi)
Date: Fri, 10 Dec 2010 03:28:46 -0500
Subject: [docs] Bug on
	http://docs.python.org/tutorial/introduction.html#numbers
Message-ID: 

7/3 should result in the exact value.
7//3 will output a floor value.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From report at bugs.python.org  Sat Dec 11 09:10:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 11 Dec 2010 08:10:46 +0000
Subject: [docs] [issue10676] Confusing note in Numeric Types
In-Reply-To: <1292012746.16.0.939598765846.issue10676@psf.upfronthosting.co.za>
Message-ID: <1292055046.66.0.0302368328058.issue10676@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Thanks, fixed in r87169.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From georg at python.org  Sat Dec 11 09:05:26 2010
From: georg at python.org (Georg Brandl)
Date: Sat, 11 Dec 2010 09:05:26 +0100
Subject: [docs] Bug
	on	http://docs.python.org/tutorial/introduction.html#numbers
In-Reply-To: 
References: 
Message-ID: <4D0330C6.5060702@python.org>

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

Am 10.12.2010 09:28, schrieb Wonjohn Choi:
> 7/3 should result in the exact value.
> 7//3 will output a floor value.

Hi Wonjohn,

In Python 2.x, which is the version of the documentation you refer to, 7/3
does floor division; you have to use "from __future__ import division" to
activate the float division feature.

In Python 3.x, / always does. float division.

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

iEYEARECAAYFAk0DMMUACgkQN9GcIYhpnLA6RwCeL80pQipuGUgbR/ZbtHLlyY+A
awUAoKPeflMlvcpccSA66JU77DEC9t7c
=m395
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sat Dec 11 19:12:59 2010
From: report at bugs.python.org (Phil Thompson)
Date: Sat, 11 Dec 2010 18:12:59 +0000
Subject: [docs] [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>

New submission from Phil Thompson :

In Python v3.2b1 the type of the first argument of PySlice_GetIndices() and PySlice_GetIndicesEx() has changed from PySliceObject* to PyObject*.

The documentation does not reflect this change.

Which is correct, the source code or the documentation?

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 123809
nosy: Phil.Thompson, docs at python
priority: normal
severity: normal
status: open
title: PySlice_GetIndices() signature changed
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 19:17:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 11 Dec 2010 18:17:54 +0000
Subject: [docs] [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292091474.28.0.430709852771.issue10681@psf.upfronthosting.co.za>

Martin v. L?wis  added the comment:

The source is correct. Fixed in r87171.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 20:10:31 2010
From: report at bugs.python.org (Phil Thompson)
Date: Sat, 11 Dec 2010 19:10:31 +0000
Subject: [docs] [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292094631.68.0.249535499148.issue10681@psf.upfronthosting.co.za>

Phil Thompson  added the comment:

You might want to add a "Changed in Python v3.2" because as it is an incompatible change.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 11 20:23:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 11 Dec 2010 19:23:38 +0000
Subject: [docs] [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292095418.32.0.833887657784.issue10681@psf.upfronthosting.co.za>

Martin v. L?wis  added the comment:

It's not an incompatible change, but I added the versionchanged anyway in r87173.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 12 02:38:04 2010
From: report at bugs.python.org (Phil Thompson)
Date: Sun, 12 Dec 2010 01:38:04 +0000
Subject: [docs] [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1292117884.06.0.876574314269.issue10681@psf.upfronthosting.co.za>

Phil Thompson  added the comment:

It's source level incompatible - my extension modules compiled fine with v3.2a but failed with v3.2b1.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 12 08:35:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Dec 2010 07:35:22 +0000
Subject: [docs] [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292117884.06.0.876574314269.issue10681@psf.upfronthosting.co.za>
Message-ID: <4D047B36.7050206@v.loewis.de>

Martin v. L?wis  added the comment:

> It's source level incompatible - my extension modules compiled fine with v3.2a but failed with v3.2b1.

That's because you are using C++, right? In C, there shouldn't be any
problems.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 13:47:12 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Dec 2010 12:47:12 +0000
Subject: [docs] [issue10693] error in documentation
	of	distutils.archive_util.make_zipfile
In-Reply-To: <1292244432.84.0.973297010856.issue10693@psf.upfronthosting.co.za>
Message-ID: <1292244432.84.0.973297010856.issue10693@psf.upfronthosting.co.za>

New submission from Eli Bendersky :

The documentation of:

distutils.archive_util.make_zipfile(base_name, base_dir[, verbose=0, dry_run=0]) 

Says:

  Create a zip file from all files in and under base_dir. The output zip file will be named base_dir + .zip. 

This isn't correct, as the name of the output file is "base_name + .zip"

The error exists both in the docstring of make_zipfile in distutils/archive_util.py and in the ReST documentation of the function

----------
assignee: tarek
components: Distutils, Documentation
keywords: easy
messages: 123872
nosy: docs at python, eli.bendersky, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: error in documentation of distutils.archive_util.make_zipfile
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 19:48:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 13 Dec 2010 18:48:17 +0000
Subject: [docs] [issue10665] Expand unicodedata module documentation
In-Reply-To: <4D02B206.4060905@v.loewis.de>
Message-ID: 

Alexander Belopolsky  added the comment:

On Fri, Dec 10, 2010 at 6:04 PM, Martin v. L?wis  wrote:
..
>> Why? ?I thought "release early, release often" was a good thing.
>
> Create a branch for that, or post an issue on Rietveld.

Martin,

This is a documentation patch affecting a single HTML page.  An svn
branch for something like this is certainly an overkill.  Maybe when
branches become more user-friendly with Hg, it will make sense to do
something like this in a branch.   Rietveld is great for code reviews,
but for doc patches its is sometimes desirable to post a rendered page
for a review.  In this particular case, however the reST in diff is
quite readable.

> W-I-P IMO
> confuses people reviewing the patches, running into the same ones
> over-and-over again, only to find out every time "it's not ready yet".

I posted this patch with a specific question: "how much of the Unicode
Standard information we would want to present?"   The patch included
several tables similar to what a determined reader can find at
unicode.org.   I think it is useful to present this information in the
Python docs for several reasons:

1. It makes the information more readily accessible to someone who
just want to figure out what the code returned by
unicodedata.category() means.

2. We can present examples using Python notation and focus on what is
relevant to Python users.  For example, what are the digits other than
0-9, or what is the difference between a digit and a decimal.

3. Other parts of the documentation can refer to this information more
easily.  For example, str.isdigit() can refer to 'Nd' general
category.

The downside is that we may need to update this info when Unicode
Standard changes.  Given the pace of change for this info, I don't
think this is serious burden and most of the data can be
auto-generated from UCD files.

> So the natural reaction is to close it as rejected, for it being
> incomplete.

Are you going to reject say issue2636 on this basis? :-)   Has *any*
patch ever been rejected as incomplete?

Seriously, I had a specific reason to post an incomplete patch for
review: formatting reST tables is tedious and if others think we
should not include this info in Python docs, I don't want to spend
more time polishing the patch.  On the other hand, an incomplete patch
is helpful because it demonstrates how much information I am proposing
to include.  If I just posted a request without a patch, a natural
reaction would be: do you have a patch?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 21:30:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 20:30:47 +0000
Subject: [docs] [issue10697] host and port attributes not documented well in
	function	urllib.parse.urlparse and urlsplit
In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za>
Message-ID: <1292272246.93.0.323397223006.issue10697@psf.upfronthosting.co.za>

R. David Murray  added the comment:

The repr gives the primary components defined by the URL.  The subfields are provided as attributes of the result.  This is documented in the example at the top of the chapter, but it is not, IMO, well documented in the rest of the chapter.

I'm not sure when this feature was introduced, so I'm leaving 3.1 in the versions for now.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, orsenthil, r.david.murray
stage:  -> needs patch
title: port not split in function urllib.parse.urlparse -> host and port attributes not documented well in function urllib.parse.urlparse and urlsplit
versions: +Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 21:43:44 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 13 Dec 2010 20:43:44 +0000
Subject: [docs] [issue10697] host and port attributes not documented well in
	function	urllib.parse.urlparse and urlsplit
In-Reply-To: <1292272246.93.0.323397223006.issue10697@psf.upfronthosting.co.za>
Message-ID: 

Fred L. Drake, Jr.  added the comment:

These attributes were added in Python 2.5.

Documentation improvements should be backported to 2.7 and 3.1.

----------
nosy: +fdrake

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 21:44:25 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 13 Dec 2010 20:44:25 +0000
Subject: [docs] [issue10697] host and port attributes not documented well in
	function	urllib.parse.urlparse and urlsplit
In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za>
Message-ID: <1292273065.93.0.103069660231.issue10697@psf.upfronthosting.co.za>

Changes by Fred L. Drake, Jr. :

----------
versions: +Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 21:48:40 2010
From: report at bugs.python.org (JTMoon79)
Date: Mon, 13 Dec 2010 20:48:40 +0000
Subject: [docs] [issue10697] host and port attributes not documented well in
	function	urllib.parse.urlparse and urlsplit
In-Reply-To: <1292271440.42.0.107945784803.issue10697@psf.upfronthosting.co.za>
Message-ID: <1292273320.3.0.621697909597.issue10697@psf.upfronthosting.co.za>

JTMoon79  added the comment:

Doh!  I feel a bit silly.
I didn't notice 'hostname' and 'port' in 
>>> dir(urllib.parse.urlparse(r'http://foo.bar.com:80/blarg?a=1&b=2'))
[... 'count', 'fragment', 'geturl', 'hostname', 'index'
, 'netloc', 'params', 'password', 'path', 'port', 'query', 'scheme', 'username']

I agree, some clarity in the documentation for these overlapping fields (,,) would help.

-J_Tom_Moon_79

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 22:38:56 2010
From: report at bugs.python.org (Andrew Dalke)
Date: Mon, 13 Dec 2010 21:38:56 +0000
Subject: [docs] [issue10698] doctest load_tests() typo
In-Reply-To: <1292276336.42.0.386145725492.issue10698@psf.upfronthosting.co.za>
Message-ID: <1292276336.42.0.386145725492.issue10698@psf.upfronthosting.co.za>

New submission from Andrew Dalke :

doctest.html Section 24.2.5 "Unittest API" says:

def load_tests(loader, tests, ignore):
    tests.addTests(doctest.DocTestSuite(my_module_with_doctests))
    return test

That last line should be "return tests"

----------
assignee: docs at python
components: Documentation
messages: 123904
nosy: dalke, docs at python
priority: normal
severity: normal
status: open
title: doctest load_tests() typo
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 23:26:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 13 Dec 2010 22:26:56 +0000
Subject: [docs] [issue10665] Expand unicodedata module documentation
In-Reply-To: 
Message-ID: <4D069DAD.7020909@v.loewis.de>

Martin v. L?wis  added the comment:

> Are you going to reject say issue2636 on this basis? :-)   Has *any*
> patch ever been rejected as incomplete?

I certainly did close patches for that reason. Before that, I keep
asking people not to post W-I-P. As for issue2636, I have been really
tempted to, see msg83277, msg83411. In one case, the conversation ended
with the user being banned from the tracker. I personally feel fairly
strongly that it is abuse to post things that you know are incomplete.
I won't review any such code.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 13 23:51:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Dec 2010 22:51:17 +0000
Subject: [docs] [issue10698] doctest load_tests() typo
In-Reply-To: <1292276336.42.0.386145725492.issue10698@psf.upfronthosting.co.za>
Message-ID: <1292280677.29.0.072428687553.issue10698@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Thanks.  Fixed in r87216.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 00:07:12 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Mon, 13 Dec 2010 23:07:12 +0000
Subject: [docs] [issue10699] [patch] fix incorrect help doc with time.tzset
In-Reply-To: <1292281632.56.0.898289640731.issue10699@psf.upfronthosting.co.za>
Message-ID: <1292281632.56.0.898289640731.issue10699@psf.upfronthosting.co.za>

New submission from Garrett Cooper :

The following patch fixes the help docstring as time.tzset when called doesn't require any arguments (as noted in the source and also in the library documentation).

The patch produced was against trunk, but this appears to be an issue on release-maint26 and release-maint27 (and the patch applies cleanly) as the text is the same.

----------
assignee: docs at python
components: Documentation
files: fix-timemodule-helpdoc.patch
keywords: patch
messages: 123908
nosy: docs at python, yaneurabeya
priority: normal
severity: normal
status: open
title: [patch] fix incorrect help doc with time.tzset
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file20033/fix-timemodule-helpdoc.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 01:57:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 00:57:44 +0000
Subject: [docs] [issue10699] [patch] fix incorrect help doc with time.tzset
In-Reply-To: <1292281632.56.0.898289640731.issue10699@psf.upfronthosting.co.za>
Message-ID: <1292288264.71.0.545081605436.issue10699@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Thanks.  Fixed in py3k in r87221.  I'll backport it when I backport my other doc updates.

FYI, 'trunk' is no longer a live branch.  Development trunk is now py3k.  2.6 only gets security fixes.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 01:58:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 00:58:01 +0000
Subject: [docs] [issue10699] fix incorrect help doc with time.tzset
In-Reply-To: <1292281632.56.0.898289640731.issue10699@psf.upfronthosting.co.za>
Message-ID: <1292288281.61.0.401207694914.issue10699@psf.upfronthosting.co.za>

Changes by R. David Murray :

----------
title: [patch] fix incorrect help doc with time.tzset -> fix incorrect help doc with time.tzset

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 02:56:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 01:56:56 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1292291816.26.0.67642172966.issue6696@psf.upfronthosting.co.za>

Changes by R. David Murray :

----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 03:55:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 02:55:30 +0000
Subject: [docs] [issue10670] Provide search scope limits
In-Reply-To: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>
Message-ID: <1292295330.59.0.954805718451.issue10670@psf.upfronthosting.co.za>

R. David Murray  added the comment:

This feature request should be submitted to the Sphinx tracker, since the docs search facility is provided by Sphinx.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 10:30:00 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 14 Dec 2010 09:30:00 +0000
Subject: [docs] [issue10670] Provide search scope limits
In-Reply-To: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>
Message-ID: <1292319000.58.0.563857303634.issue10670@psf.upfronthosting.co.za>

anatoly techtonik  added the comment:

label:interop

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 16:42:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 15:42:17 +0000
Subject: [docs] [issue10587] Document the meaning of str methods
In-Reply-To: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>
Message-ID: <1292341337.1.0.503200318795.issue10587@psf.upfronthosting.co.za>

Alexander Belopolsky  added the comment:

I am attaching a patch that expands the documentation of isalnum, isalpha, isdecimal, isdigit, isnumeric, islower, isupper, and isspace.  I did not change isidentifier or isprintable because their docs were already complete.  I also left out istitle because I could not figure out how to deal with the  confusion between Python and Unicode notions of titlecase.

I would also like to note that it appears that isdigit and isdecimal imply isnumeric, so s.isalnum() is equivalent to all(c.isalpha() or c.isnumeric() for c in s).  However the actual code does have redundant checks for isdecimal() and isdigit().  I think the documentation should reflect what the code does for an off-chance that someone would replace unicodedata with their own database with which these checks are not redundant.

----------
assignee: docs at python -> belopolsky
keywords: +patch
stage:  -> commit review
Added file: http://bugs.python.org/file20039/issue10587.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 18:26:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 14 Dec 2010 17:26:04 +0000
Subject: [docs] [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>

New submission from Alexander Belopolsky :

Library reference manual has a section dedicated to string methods [1], but similar methods of bytes and bytearray types are not documented.  Adding two new sections would probably be too repetitious, so I wonder if it would make sense to add notes about byte/bytearray methods to the matching string methods' entries.  See also issue10587.

[1] http://docs.python.org/dev/py3k/library/stdtypes.html#string-methods

----------
assignee: docs at python
components: Documentation
messages: 123960
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: bytes and bytearray methods are not documented
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 18:59:34 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Dec 2010 17:59:34 +0000
Subject: [docs] [issue8040] It would be nice if documentation pages linked
	to other	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1292349574.46.0.682459288712.issue8040@psf.upfronthosting.co.za>

Changes by Daniel Stutzbach :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 20:22:43 2010
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Tue, 14 Dec 2010 19:22:43 +0000
Subject: [docs] [issue10705] HTTPConnection.set_debuglevel has no
	information about	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>

New submission from J_Tom_Moon_79 :

Function HTTPConnection.set_debuglevel(level)
There is no range of acceptable debug levels.
What should be the difference in set_debuglevel(1) and set_debuglevel(1000)?
If the documentation lists the levels this would save users from needing to do tedious trial-error experimentation.

From
http://docs.python.org/py3k/library/http.client.html#http.client.HTTPConnection.set_debuglevel

----------
assignee: docs at python
components: Documentation
messages: 123974
nosy: JTMoon79, docs at python
priority: normal
severity: normal
status: open
title: HTTPConnection.set_debuglevel has no information about level range
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 14 20:44:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Dec 2010 19:44:13 +0000
Subject: [docs] [issue10705] HTTPConnection.set_debuglevel has no
	information about	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292355853.83.0.375482288639.issue10705@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Or, since this is Python, they could look at the code and find out that all levels above zero are equivalent.  (If I had to guess I'd say 'level' was either future proofing or designed for the use of subclasses).

But you are right, this should be mentioned in the documentation.  Care to propose a patch?

----------
nosy: +r.david.murray
type:  -> behavior
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 00:33:35 2010
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Tue, 14 Dec 2010 23:33:35 +0000
Subject: [docs] [issue10705] HTTPConnection.set_debuglevel has no
	information about	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292369615.14.0.910161418262.issue10705@psf.upfronthosting.co.za>

J_Tom_Moon_79  added the comment:

Hi David,
Currently the 3.1 documentation reads:
"""HTTPConnection.set_debuglevel(level)?
    Set the debugging level (the amount of debugging output printed). The default debug level is 0, meaning no debugging output is printed."""
How about:
"""HTTPConnection.set_debuglevel(level)?
    Set the debug level.  The debug level is the amount of debugging output printed. 
The default debug level is 0, meaning no debugging output is printed.
Currently, any debug level value greater than 0 prints the same amount of debugging output.
debugging output is printed to stdout."""

Information is from the file C:\Python\ActivePython3.1.2.3\Lib\http\client.py

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 00:35:56 2010
From: report at bugs.python.org (J_Tom_Moon_79)
Date: Tue, 14 Dec 2010 23:35:56 +0000
Subject: [docs] [issue10705] HTTPConnection.set_debuglevel has no
	information about	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292369756.84.0.067720304127.issue10705@psf.upfronthosting.co.za>

J_Tom_Moon_79  added the comment:

> Care to propose a patch?
oops.  I just found http://www.python.org/dev/patches/
I'll get around to creating a PEP sometime soon.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 02:41:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Dec 2010 01:41:31 +0000
Subject: [docs] [issue10705] HTTPConnection.set_debuglevel has no
	information about	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292377291.1.0.0582618954779.issue10705@psf.upfronthosting.co.za>

R. David Murray  added the comment:

I think a PEP is a bit of overkill for a small doc update :)  A patch would be fine...but I can also just make the change.  I'll probably tweak your wording a bit.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 03:20:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 15 Dec 2010 02:20:38 +0000
Subject: [docs] [issue10705] HTTPConnection.set_debuglevel has no
	information about	level range
In-Reply-To: <1292354563.46.0.385713602006.issue10705@psf.upfronthosting.co.za>
Message-ID: <1292379638.34.0.0719833056243.issue10705@psf.upfronthosting.co.za>

R. David Murray  added the comment:

I've committed a fix in r87256.  I looked at the code some more and tried to be a precise as possible without getting too wordy.  (The fix will get backported by and by.)

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 04:22:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 15 Dec 2010 03:22:51 +0000
Subject: [docs] [issue8040] It would be nice if documentation pages linked
	to other	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1292383371.7.0.0868416997834.issue8040@psf.upfronthosting.co.za>

Ezio Melotti  added the comment:

If you want to work on this you should also consider that the URLs used on docs.python.org don't necessary match the directory structure present when building the doc locally. For example here it would be:
.../py3k/library/fractions.html
.../release31-maint/library/fractions.html
.../release27-maint/library/fractions.html
.../release26-maint/library/fractions.html

This could be addressed with a config file that is not kept under version control (and possibly with default values used when this file is not present).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 10:24:03 2010
From: report at bugs.python.org (Michael Buckley)
Date: Wed, 15 Dec 2010 09:24:03 +0000
Subject: [docs] [issue8040] It would be nice if documentation pages linked
	to other	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1292405043.58.0.0460845624588.issue8040@psf.upfronthosting.co.za>

Michael Buckley  added the comment:

You might want to check out what Django does, as they have the working well.  http://docs.djangoproject.com/en/dev/

----------
nosy: +codefisher

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 16:50:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 15:50:56 +0000
Subject: [docs] [issue10709] Misc/AIX-NOTES needs updating
In-Reply-To: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>
Message-ID: <1292428256.05.0.89055748757.issue10709@psf.upfronthosting.co.za>

New submission from Antoine Pitrou :

S?bastien, would you like to provide an updated version of that file? The current contents look hopelessly outdated.

----------
assignee: docs at python
components: Documentation
messages: 124024
nosy: docs at python, pitrou, sable
priority: normal
severity: normal
stage: needs patch
status: open
title: Misc/AIX-NOTES needs updating
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 19:29:59 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 18:29:59 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>

New submission from Daniel Stutzbach :

Attached is a patch to add documentation for Py_ReprEnter and Py_ReprLeave.  Assigning to docs at python for review.

----------
assignee: stutzbach -> docs at python
keywords: +needs review, patch
nosy: +docs at python
stage: needs patch -> patch review
Added file: http://bugs.python.org/file20054/repr.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 19:37:49 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 15 Dec 2010 18:37:49 +0000
Subject: [docs] [issue10693] error in documentation
	of	distutils.archive_util.make_zipfile
In-Reply-To: <1292244432.84.0.973297010856.issue10693@psf.upfronthosting.co.za>
Message-ID: <1292438269.52.0.00613188202336.issue10693@psf.upfronthosting.co.za>

Eli Bendersky  added the comment:

Attaching a fix for Doc/distutils/apiref.rst and Lib/distutils/archive_util.py in Python 3.2

If it's OK I will backport to other versions as well.

----------
keywords: +patch
Added file: http://bugs.python.org/file20055/issue10693.py32.1.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 19:40:55 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 15 Dec 2010 18:40:55 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292438455.46.0.106409411242.issue9264@psf.upfronthosting.co.za>

Eli Bendersky  added the comment:

Guys, this issue is pending for a long time. Anything else needed before a commit is done?

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 19:43:47 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 15 Dec 2010 18:43:47 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292438627.33.0.903583175179.issue9264@psf.upfronthosting.co.za>

Changes by Eli Bendersky :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 20:13:40 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Dec 2010 19:13:40 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292440420.06.0.421817357927.issue9264@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

Since ?ric grabbed Assigned To:, I was expecting him to ;=). But since he is doing enough other stuff, I will unless there are conflicts in the .rst I do not know how to fix.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 20:16:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 19:16:08 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292440568.31.0.849453871969.issue9264@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

My current schedule is a bit crazy and I?ve had no time for Python bugs.

I changed ?programming? to ?programmatic?, slightly tweaked the phrasing for the --ignore-* options to make them hopefully more understandable and similar, and committed in r87271.

I?m currently rewrapping long lines and migrating the class/method constructs to be nested.  I will then backport the parts of both commits that apply to 3.1 and 2.7.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 20:27:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 15 Dec 2010 19:27:52 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292441272.67.0.949817277595.issue9264@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

?ric beat me. Better that he finish.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 20:32:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 19:32:20 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292441540.64.0.917578138696.issue9264@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Minor whitespace and markup edits make r87273.  Please review and tell me if it?s okay for backport or if there are further improvements to be done first.  I promise I won?t beat anyone ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 20:36:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 19:36:12 +0000
Subject: [docs] [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292441772.69.0.761637050459.issue10702@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

I was persuaded there was already a bug open with a patch adding bytes and bytearray in the sequence methods table, but I can?t find it.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 20:48:37 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 15 Dec 2010 19:48:37 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292442517.78.0.197657421158.issue9264@psf.upfronthosting.co.za>

Eli Bendersky  added the comment:

?ric,

The nested methods are nice, though a bit unusual IMHO. Is this the recommended new way to markup methods of objects? [Because AFAIK it's not used much in other docs]

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 21:05:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 15 Dec 2010 20:05:02 +0000
Subject: [docs] [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292443502.29.0.95173238155.issue10702@psf.upfronthosting.co.za>

Alexander Belopolsky  added the comment:

> I was persuaded there was already a bug open with a patch adding
> bytes and bytearray in the sequence methods table, but I can?t find it.

I can't find it either, but this issue is different.  I propose renaming "String Methods" to "String, bytes and bytearray methods" and 

str.capitalize()
bytes.capitalize()
bytearray.capitalize()

Return a copy of the string with its first character capitalized and the rest lowercased.  [Discuss Unicode vs bytes details.]

BTW, the "For 8-bit strings, this method is locale-dependent." part is probably out of date because bytes.capitalize() seems to pass non-ASCII bytes through:

>>> bytes([ord('?')]).capitalize()[0] == ord('?')
True

and for unicode strings the operation is *not* locale dependent.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 21:40:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 20:40:16 +0000
Subject: [docs] [issue10693] error in documentation
	of	distutils.archive_util.make_zipfile
In-Reply-To: <1292244432.84.0.973297010856.issue10693@psf.upfronthosting.co.za>
Message-ID: <1292445616.56.0.811019819308.issue10693@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Patch extended to cover shutil, which has gained _make_{tar,zip}file in 2.7 and 3.2, and committed in all three branches in r87277 to r87279.

Will be fixed in distutils2 the next time I synchronize d2._backport.shutil.

----------
assignee: tarek -> eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 23:29:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 22:29:05 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292452145.64.0.730639832628.issue9264@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

The nesting allows logical grouping in source and output, saves a bit of typing, and has been added to a number of files by Benjamin Peterson.  I?d say it?s recommended :)

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 23:35:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 22:35:11 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292452511.68.0.458565158076.issue8753@psf.upfronthosting.co.za>

Antoine Pitrou  added the comment:

I think this is a bit misleading. These functions are only needed if you are implementing a container. For the general case where you don't display another Python object in your repr() (or you only display objects which are themselves atomic, such as strings and integers), these functions are not necessary.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 23:39:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 22:39:47 +0000
Subject: [docs] [issue8851] pkgutil documentation needs more markup
In-Reply-To: <1275107900.09.0.840689685245.issue8851@psf.upfronthosting.co.za>
Message-ID: <1292452787.47.0.758378762417.issue8851@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Missing markup for one ``None`` added in r87289 and following revisions for maintenance branches.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 23:42:16 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 22:42:16 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292452936.53.0.674395409169.issue8753@psf.upfronthosting.co.za>

Daniel Stutzbach  added the comment:

Good point.  My perspective is skewed by all of the time that I spend working on container types. :-)

How about if I change the first sentence to the following?

    Properly implementing :attr:`tp_repr` for container types requires
    special recursion handling.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 23:54:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Dec 2010 22:54:26 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292452936.53.0.674395409169.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292453662.3665.1.camel@localhost.localdomain>

Antoine Pitrou  added the comment:

> How about if I change the first sentence to the following?
> 
>     Properly implementing :attr:`tp_repr` for container types requires
>     special recursion handling.

This looks good to me.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 23:57:11 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 22:57:11 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292453831.76.0.302992435819.issue8753@psf.upfronthosting.co.za>

Changes by Daniel Stutzbach :

Added file: http://bugs.python.org/file20071/repr-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 15 23:58:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 22:58:32 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292453912.27.0.165711684515.issue8753@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Possibly related: #9840

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 00:05:08 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 15 Dec 2010 23:05:08 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292454308.46.0.194923764698.issue8753@psf.upfronthosting.co.za>

Daniel Stutzbach  added the comment:

Thanks.  New patch attached with a cross-reference to reprlib.recursive_repr.

----------
Added file: http://bugs.python.org/file20072/repr-3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 00:07:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 15 Dec 2010 23:07:30 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292454450.1.0.382342930777.issue8753@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Patch LGTM, except for ?As examples? which I?ve never read before (but I?m not a native speaker).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 02:05:35 2010
From: report at bugs.python.org (Ralph Corderoy)
Date: Thu, 16 Dec 2010 01:05:35 +0000
Subject: [docs] [issue10713] re module doesn't describe string boundaries
	for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>

New submission from Ralph Corderoy :

The re module defines \b in a regexp to need \w one side and \W the other.  What about when the end of the string or line is involved?  perlre(1) says that's treated as a \W.  Python should precisely document that case too.

----------
assignee: docs at python
components: Documentation
messages: 124097
nosy: docs at python, ralph.corderoy
priority: normal
severity: normal
status: open
title: re module doesn't describe string boundaries for \b

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 02:21:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 01:21:13 +0000
Subject: [docs] [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292462473.19.0.817282850744.issue10559@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

New wording:

 When known to the interpreter, the script name and additional arguments
 thereafter are passed to the script in the variable ``sys.argv``, which is a
-list of strings.  Its length is at least one; when no script and no arguments
+list of strings.  You have to execute ``import sys`` before you can use that
+list.  Its length is at least one; when no script and no arguments
 are given, ``sys.argv[0]`` is an empty string.  When the script name is given as
 ``'-'`` (meaning  standard input), ``sys.argv[0]`` is set to ``'-'``.  When
 :option:`-c` *command* is used, ``sys.argv[0]`` is set to ``'-c'``.  When

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 02:28:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 01:28:37 +0000
Subject: [docs] [issue10609] dbm documentation example doesn't work
	(iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1292462917.69.0.733007312539.issue10609@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

IMO, wrapping db in a dict defeats the purpose of dbm implementing a mapping interface.  I would use the most natural mapping idioms:

-   for k, v in db.iteritems():
-       print(k, '\t', v)
+   for k in db:
+       print(k, '\t', db[k])

The downside of this example is that it does not explicitely call methods, making the comment about ?Other dictionary methods? strange.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 04:55:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 03:55:22 +0000
Subject: [docs] [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <1292471722.48.0.967817047292.issue9312@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

I removed one instance of unnecessary markup in r87294 (pointed by Michael Foord on IRC) and made other minor changes in r87296, r87300 and r87302.

Those eight commits are now merged in 3.1 as r87305 and 2.7 as r87308.  Please let me know if you find any merge glitches.  Happily closing.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 10:04:51 2010
From: report at bugs.python.org (Tan Zong Xuan)
Date: Thu, 16 Dec 2010 09:04:51 +0000
Subject: [docs] [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1292490291.69.0.256290903882.issue9938@psf.upfronthosting.co.za>

Tan Zong Xuan  added the comment:

I am also trying to use argparse interactively, but in this case by combining it with the cmd module. So I'm doing something like below:

class MyCmd(cmd.Cmd):

    parser = argparse.ArgumentParser(prog='addobject')
    parser.add_argument('attribute1')
    parser.add_argument('attribute2')
    parser.add_argument('attribute3')

    def do_addobject(self, line):
        args = MyCmd.parser.parse_args(line.split())
        newobject = object(args.attribute1, args.attribute2, args.attribute3)
        myobjects.append(newobject)

I'm faced with the same problem that when given invalid input, parse_args exits the program completely, instead of exiting just to the Cmd shell. 

I have the feeling that this use case is sufficiently common such that it would be good if people did not have to override the exit method themselves, and instead an alternative to parse_args was provided that only raises exceptions for the surrounding code to handle rather than exiting the program entirely.

----------
nosy: +ZOMGxuan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 10:09:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Dec 2010 09:09:02 +0000
Subject: [docs] [issue10669] Document Deprecation Warnings and how to fix
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292490542.22.0.267198673516.issue10669@psf.upfronthosting.co.za>

Raymond Hettinger  added the comment:

FWIW, whatsnew is not primary documentation -- it should not be the sole or central source of anything except a highlevel overview and examples for the author's choice of selected version differences to highlight. 

A howto document would work best as a central place to list all deprecations and advice on what to do about them.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 14:48:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 13:48:41 +0000
Subject: [docs] [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1292507321.34.0.2817094162.issue9938@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

You can always catch SystemExit.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 14:53:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 13:53:20 +0000
Subject: [docs] [issue10669] Document Deprecation Warnings and how to fix
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292507600.05.0.313613675551.issue10669@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

PEP 4 and PEP 290 are related to this subject, but not comprehensive, not on docs.python.org, and not tutorial-like.

I think we could try Ezio?s idea.  Sphinx can produce a document containing only version* directives (?make changes?).  If such a document is clear enough and has links to the longer docs, there would be no need to write separate howtos.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 14:56:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 13:56:22 +0000
Subject: [docs] [issue10669] Document Deprecation Warnings and how to fix
In-Reply-To: <1291959647.89.0.597449973256.issue10669@psf.upfronthosting.co.za>
Message-ID: <1292507782.71.0.813740167447.issue10669@psf.upfronthosting.co.za>

Changes by ?ric Araujo :

----------
components:  -2to3 (2.x to 3.0 conversion tool)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 17:41:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 16:41:38 +0000
Subject: [docs] [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1292517698.63.0.173397211981.issue10454@psf.upfronthosting.co.za>

Changes by ?ric Araujo :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 20:02:07 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 16 Dec 2010 19:02:07 +0000
Subject: [docs] [issue8040] It would be nice if documentation pages linked
	to other	versions of the same document
In-Reply-To: <1292383371.7.0.0868416997834.issue8040@psf.upfronthosting.co.za>
Message-ID: 

Daniel Stutzbach  added the comment:

On Tue, Dec 14, 2010 at 7:22 PM, Ezio Melotti  wrote:
> If you want to work on this you should also consider that the URLs used on docs.python.org don't necessary match the directory structure present when building the doc locally. For example here it would be:
> .../py3k/library/fractions.html
> .../release31-maint/library/fractions.html
> .../release27-maint/library/fractions.html
> .../release26-maint/library/fractions.html

Will this directory structure change as part of the hg migration?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 16 20:05:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Dec 2010 19:05:15 +0000
Subject: [docs] [issue8040] It would be nice if documentation pages linked
	to other	versions of the same document
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1292526315.43.0.5391193604.issue8040@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

No, because with Subversion or Mercurial you?re free to clone/checkout any branch in a directory with an arbitrary name.  For the py3k branch, Ezio?s checkout is named py3k but mine is 3.2, there is no way to put knowledge about that in the doc itself.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 01:07:23 2010
From: report at bugs.python.org (flashk)
Date: Fri, 17 Dec 2010 00:07:23 +0000
Subject: [docs] [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>

New submission from flashk :

The "Built-in Exceptions" page of the Python 2.7 documentation is missing descriptions for BufferError, IndentationError, and TabError.

I've gone ahead and added a brief description of each error to the page.

----------
assignee: docs at python
components: Documentation
files: exceptions.rst
messages: 124165
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: Undocumented built-in exceptions
versions: Python 2.7
Added file: http://bugs.python.org/file20084/exceptions.rst

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 01:24:28 2010
From: report at bugs.python.org (flashk)
Date: Fri, 17 Dec 2010 00:24:28 +0000
Subject: [docs] [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292545468.64.0.335235476332.issue10723@psf.upfronthosting.co.za>

flashk  added the comment:

Just realized I previously attached the entire file. Here is the diff instead.

----------
keywords: +patch
Added file: http://bugs.python.org/file20085/exceptions.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 01:26:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Dec 2010 00:26:28 +0000
Subject: [docs] [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292545588.79.0.944615922531.issue10723@psf.upfronthosting.co.za>

Changes by Antoine Pitrou :

----------
stage:  -> patch review
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 02:15:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 01:15:28 +0000
Subject: [docs] [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1292548527.72.0.735957897786.issue10454@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Here is a proposed patch to both docs and help output.  The help output now looks like this:

usage: compileall.py [-h] [-l] [-f] [-q] [-b] [-d DESTDIR] [-x REGEXP]
                     [-i FILE]
                     [FILE|DIR [FILE|DIR ...]]

Utilities to support installing Python libraries.

positional arguments:
  FILE|DIR    zero or more file and directory names to compile; if no
              arguments given, defaults to the equivalent of -l sys.path

optional arguments:
  -h, --help  show this help message and exit
  -l          don't recurse into subdirectories
  -f          force rebuild even if timestamps are up to date
  -q          output only error messages
  -b          use legacy (pre-PEP3147) compiled file locations
  -d DESTDIR  directory to prepend to file paths for use in compile time
              tracebacks and in runtime tracebacks in cases where the source
              file is unavailable
  -x REGEXP   skip files matching the regular expression. The regexp is
              searched for in the full path to each file considered for
              compilation.
  -i FILE     add all the files and directories listed in FILE to the list
              considered for compilation. If "-", names are read from stdin.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 16:42:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:42:30 +0000
Subject: [docs] [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1292600550.5.0.170469577694.issue10454@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

+1 -- Didn't read through all of the diff, but in general I trust you enough to believe that the new version is better than the old :)

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 16:44:29 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:44:29 +0000
Subject: [docs] [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292600669.76.0.840679877012.issue10723@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Basically fine, but the docs for indentation and tab error should document their inheritance more explicitly.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 16:51:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:51:40 +0000
Subject: [docs] [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292601100.39.0.53275616686.issue10559@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

"Use that list" doesn't make me happy, what about "access"?

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 16:53:31 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:53:31 +0000
Subject: [docs] [issue10609] dbm documentation example doesn't work
	(iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1292601211.57.0.835796249899.issue10609@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Why not replace it with an example that uses get() or setdefault() then?

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 16:58:04 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 17 Dec 2010 15:58:04 +0000
Subject: [docs] [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1292601483.99.0.153251138845.issue9938@psf.upfronthosting.co.za>

Steven Bethard  added the comment:

In the short term, just catch the SystemExit.

In the slightly longer term, we could certainly provide a subclass, say, ErrorRaisingArgumentParser, that overrides .exit and .error to do nothing but raise an exception with the message they would have printed. We'd probably have to introduce a new Exception subclass though, maybe ArgumentParserExit or something like that.

Anyway if you're interested in this, please file a new ticket (preferably  with a patch). Regardless of whether we ever provide the subclass, we certainly need to patch the documentation to tell people how to override error and exit.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 16:58:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:58:42 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292601522.83.0.699486535813.issue8753@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Yep, looks good, please commit.

----------
assignee: docs at python -> eric.araujo
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 16:59:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 15:59:36 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1292601576.1.0.192143176714.issue9264@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Yes, it's the new recommended style.  (Please add to documenting/ when convenient :)

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 17:06:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:06:25 +0000
Subject: [docs] [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292601985.51.0.432693662616.issue10559@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Attached diff provides another suggested rewording that I think is clearer.

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file20093/tut_argv.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 17:07:29 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 17 Dec 2010 16:07:29 +0000
Subject: [docs] [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292602049.42.0.457237393676.issue10559@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

+1.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 17:09:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:09:00 +0000
Subject: [docs] [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292602140.69.0.915615664689.issue10559@psf.upfronthosting.co.za>

Changes by R. David Murray :

Removed file: http://bugs.python.org/file20093/tut_argv.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 17:09:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:09:18 +0000
Subject: [docs] [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292602158.63.0.933204801631.issue10559@psf.upfronthosting.co.za>

Changes by R. David Murray :

Added file: http://bugs.python.org/file20094/tut_argv.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 17:12:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:12:22 +0000
Subject: [docs] [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1292602342.3.0.662338989107.issue10559@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Committed in r87337.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 17:31:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Dec 2010 16:31:18 +0000
Subject: [docs] [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1292603478.12.0.826919725087.issue10454@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Committed in r87338.  Backporting the relevant bits will be a bit of a pain, anyone who feels like doing it is welcome to.  I may or may not get to it myself.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 17:36:31 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Dec 2010 16:36:31 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292603791.54.0.132315964059.issue8753@psf.upfronthosting.co.za>

Daniel Stutzbach  added the comment:

Committed in r87339.  Thanks everyone for the feedback!

----------
assignee: eric.araujo -> stutzbach
keywords:  -needs review
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 20:11:11 2010
From: report at bugs.python.org (flashk)
Date: Fri, 17 Dec 2010 19:11:11 +0000
Subject: [docs] [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292613071.86.0.0172362038006.issue10723@psf.upfronthosting.co.za>

flashk  added the comment:

I just attached a new patch that explicitly mentions the inheritance of IndentationError and TabError.

----------
Added file: http://bugs.python.org/file20099/exceptions_2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 23:17:57 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Dec 2010 22:17:57 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292624277.35.0.972825094934.issue8753@psf.upfronthosting.co.za>

Amaury Forgeot d'Arc  added the comment:

Err... in r87339 there is a typo in all occurrences of 'Py_ReprEntr': Py_ReprEnter of course!

----------
nosy: +amaury.forgeotdarc
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 23:29:22 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Dec 2010 22:29:22 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292624962.77.0.0725985928959.issue8753@psf.upfronthosting.co.za>

Daniel Stutzbach  added the comment:

On Fri, Dec 17, 2010 at 2:17 PM, Amaury Forgeot d'Arc wrote wrote:
> Err... in r87339 there is a typo in all occurrences of
> 'Py_ReprEntr': Py_ReprEnter of course!

Well, that's embarrassing.  Fixed in r87354.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 17 23:31:27 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Dec 2010 22:31:27 +0000
Subject: [docs] [issue8753] Py_ReprEnter and Py_ReprLeave are undocumented
In-Reply-To: <1292437799.74.0.970357675204.issue8753@psf.upfronthosting.co.za>
Message-ID: <1292625087.44.0.440563428071.issue8753@psf.upfronthosting.co.za>

Changes by Daniel Stutzbach :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 00:31:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Dec 2010 23:31:46 +0000
Subject: [docs] [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292628706.43.0.262486156576.issue10702@psf.upfronthosting.co.za>

Changes by Terry J. Reedy :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 00:43:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Dec 2010 23:43:43 +0000
Subject: [docs] [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292629423.06.0.0409103048119.issue10723@psf.upfronthosting.co.za>

Changes by Terry J. Reedy :

Removed file: http://bugs.python.org/file20084/exceptions.rst

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 05:09:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 04:09:27 +0000
Subject: [docs] [issue10728] argparse.ArgumentParser.print_help uses
	sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292645367.34.0.807495842474.issue10728@psf.upfronthosting.co.za>

R. David Murray  added the comment:

I think this is a documentation bug, since IMO help should print on stdout, not stderr[1].  I would expect print_usage to do likewise, but for the error to tell print_usage to write to stderr when it calls it...which is exactly what the code does.

[1] I know some unix commands print help to stderr, and this really annoys me when I pipe long help output to less....and it *still* scrolls off the screen.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 05:09:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 04:09:55 +0000
Subject: [docs] [issue10728] argparse.ArgumentParser.print_help uses
	sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292645395.99.0.346919122893.issue10728@psf.upfronthosting.co.za>

Changes by R. David Murray :

----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 05:24:13 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 18 Dec 2010 04:24:13 +0000
Subject: [docs] [issue10659] Hook scripts for immediate doc build system
In-Reply-To: <1291900833.32.0.658396193822.issue10659@psf.upfronthosting.co.za>
Message-ID: <1292646253.23.0.947227905431.issue10659@psf.upfronthosting.co.za>

Changes by Ezio Melotti :

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

_______________________________________
Python tracker 

_______________________________________

From linux at kenjackson.us  Mon Dec 13 15:27:44 2010
From: linux at kenjackson.us (Ken Jackson)
Date: Mon, 13 Dec 2010 09:27:44 -0500
Subject: [docs] Epub version of documentation?
Message-ID: <4D062D60.1000709@kenjackson.us>

Hi,

I am very pleased to see there are downloadable versions of the 
documentation at:
http://docs.python.org/download.html

But it sure would be great if you could also offer an .epub version so 
we could
study Python on our eReaders.

-Ken Jackson

From albl500 at york.ac.uk  Mon Dec 13 21:21:04 2010
From: albl500 at york.ac.uk (Alex Leach)
Date: Mon, 13 Dec 2010 20:21:04 +0000
Subject: [docs] multiprocessing 'bug'
Message-ID: <201012132021.04532.albl500@york.ac.uk>

Dear Python developers,

I've been using the multiprocessing module for a month or two now and I love 
the speed improvements that come with it. However I find it quite hard to 
optimise memory usage amongst the processes. I've tried to avoid using the 
'shared state' as much as possible, but every time I start a new process 
everything in the parent process's global memory gets duplicated for the child 
process, which is totally unnecessary (for me). I understand that this comes 
as a side-effect of using os.fork(), which I was totally unaware of until I 
read quite a nice article on the IBM website.

When I first started using the multiprocessing module, I would start a process 
every time I needed to, which was inside the innermost loop. I later realised 
this is completely inefficient because of the time penalties associated with 
process creation, and the fact that my program accumulates data as it runs, so 
each time a new mult...Process() is started in this manner, it'll always use 
slightly more memory than the previous process; i.e. exactly as much memory as 
the parent process currently has. This still gave a remarkable performance 
improvement on just a single-thread.

So now I initiate all the Processes as close to the start of the main program 
as possible. Still, the processes use a lot more memory than they require, and 
I'd just rather they didn't... This program I'm currently working on uses the 
parent process to create a list of worker Processes, as well as a separate 
mult...Process instance I use as a kind of database; it's the only part of the 
program that I allow to read from a >20GB text file, sending chunks from that 
via a mult..Pipe() to the main process and then down to one of the workers. I 
can't figure out which processes to start first though... Whichever process(es) 
is/are created first get copied into the global memory of the other 
process(es), which isn't ideal.

As I currently subclass multiprocessing.Process, would it be advisable to add 
a section to the __init__ function to delete all of the global variables? 
Before I figured out why all the processes were using all this memory, I spent 
ages minimising the child processes' need for data needed by the parent 
process, ensuring any info that the children do need would be passed over in a 
pipe or queue. Deleting stuff from global memory doesn't seem like a 
recommendable way of doing things, as doesn't stop the memory duplication in 
the first place, and could be quite dangerous if I'm deleting subclasses of 
Process I've given __del__ functions to ensure that all pipes and queues get 
closed (this worked around an earlier problem of having too many open file 
handles).

I guess the problem is that I've got nearly every function, class & Process 
written into the same .py file; using subprocess would get around this memory 
duplication problem, but that would require a lot of painstaking back-tracking 
and creating a load of extra .py files. But I also need to pass dictionaries 
around, so that wouldn't even work with the subprocess pipes.

I'm using python v2.6.6 btw, on Ubuntu 10.10 server with KDE. Any advice with 
this would be greatly appreciated! And sorry about the lengthy email!

Thanks for any help, and kind regards,
Alex Leach

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sromanow at commercecorp.com  Wed Dec 15 22:33:42 2010
From: sromanow at commercecorp.com (Steve Romanow)
Date: Wed, 15 Dec 2010 16:33:42 -0500
Subject: [docs] typo in python 2.7.1 docs
Message-ID: 

find string?zinfo_or_acrname in teh zipfile module docs.
I think?zinfo_or_arcname is intended.

--

Steve Romanow

Application Developer

Commerce Corporation

4660 East Paris Ave * Grand Rapids, MI 49512

616-871-9215 * 443-986-8341 (Cell)

sromanow at commercecorp.com

Dial HELP (4357) or email help at commercecorp.com for all your IS needs.

From report at bugs.python.org  Sat Dec 18 11:41:39 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 18 Dec 2010 10:41:39 +0000
Subject: [docs] [issue10728] argparse.ArgumentParser.print_help uses
	sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292668899.62.0.786345837879.issue10728@psf.upfronthosting.co.za>

Steven Bethard  added the comment:

Yep, this is a documentation bug. Help is definitely intended to print to stdout.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 17:40:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 16:40:10 +0000
Subject: [docs] [issue10728] argparse.ArgumentParser.print_help uses
	sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292690410.53.0.261357077986.issue10728@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Fixed in r87372.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 18:51:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 18 Dec 2010 17:51:49 +0000
Subject: [docs] [issue10723] Undocumented built-in exceptions
In-Reply-To: <1292544442.85.0.606374266637.issue10723@psf.upfronthosting.co.za>
Message-ID: <1292694709.08.0.283169189935.issue10723@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Committed in r87378.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 18 20:43:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 18 Dec 2010 19:43:48 +0000
Subject: [docs] [issue10622] WebKit browsers show superfluous scrollbars in
	html docs
In-Reply-To: <1291462354.78.0.0263278148003.issue10622@psf.upfronthosting.co.za>
Message-ID: <1292701428.59.0.114175688245.issue10622@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Backport done in r87387 and r87388.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 19 14:25:05 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 19 Dec 2010 13:25:05 +0000
Subject: [docs] [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1292765105.27.0.948543754444.issue9938@psf.upfronthosting.co.za>

Changes by Xuanji Li :

----------
nosy: +xuanji

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 19 14:27:37 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 19 Dec 2010 13:27:37 +0000
Subject: [docs] [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292765257.46.0.903157017212.issue10702@psf.upfronthosting.co.za>

Changes by Xuanji Li :

----------
nosy: +xuanji

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 19 15:14:29 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 19 Dec 2010 14:14:29 +0000
Subject: [docs] [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1292768069.88.0.290792063182.issue10702@psf.upfronthosting.co.za>

Xuanji Li  added the comment:

Hi, it seems to me that section 4.6.5. Bytes and Byte Array Methods covers this already. It says:

Bytes and bytearray objects, being ?strings of bytes?, have all methods found on strings, with the exception of encode(), format() and isidentifier(), which do not make sense with these types. For converting the objects to strings, they have a decode() method.

Wherever one of these methods needs to interpret the bytes as characters (e.g. the is...() methods), the ASCII character set is assumed.

This section covers belpolsky's needs, ie a reader can, from this, understand that bytes have a capitalize method. However, I support

1) Expanding this section to explain more clearly what the methods do to bytes
2) Discuss unicode vs bytes details
3) Mention bytes and bytearrays in 4.6.1 String Methods, because it is quite far away from 4.6.5

As for the suggestion of renaming, if we rename the section, we have to decide what to call a string/byte/bytearray object because it now says, for example, str.something(); also we have to document the encode and decode methods seperately because they are not common to strings and bytes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 19 17:47:54 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 19 Dec 2010 16:47:54 +0000
Subject: [docs] [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1292777274.68.0.505208944356.issue10461@psf.upfronthosting.co.za>

Changes by SilentGhost :

Removed file: http://bugs.python.org/file19671/logging.rst.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 19 18:43:24 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 19 Dec 2010 17:43:24 +0000
Subject: [docs] [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1292780603.92.0.0893553014591.issue10461@psf.upfronthosting.co.za>

SilentGhost  added the comment:

following re-organization of the logging docs, I'm attaching updated patch.

----------
nosy: +vinay.sajip
Added file: http://bugs.python.org/file20112/logging-cookbook.rst.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 00:19:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 Dec 2010 23:19:12 +0000
Subject: [docs] [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1292800752.08.0.202701493442.issue10461@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

Vinay, you should look at the logging-cookbook patch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 00:35:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Dec 2010 23:35:57 +0000
Subject: [docs] [issue10728] argparse.ArgumentParser.print_help uses
	sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292801757.58.0.268693184152.issue10728@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

This apparently lacks a 2.7 backport.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 02:24:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 01:24:45 +0000
Subject: [docs] [issue10728] argparse.ArgumentParser.print_help uses
	sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292808285.87.0.131620492022.issue10728@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Like Georg, I'll get to that when I do a mass backport of all my doc fixes.  My apologies for missing the beta2 deadline on doing that, but there aren't many of them.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 08:29:17 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 20 Dec 2010 07:29:17 +0000
Subject: [docs] [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>

New submission from Ross Lagerwall :

On Windows, creating a subprocess does not work when stdin (or stdout or stderr) is set as a file object created from socket.makefile(). An IOError is thrown.

This works fine on Unix so I assume it is a platform limitation rather than a Python bug.

If this is so then this should be documented under the subprocess module.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: test.py
messages: 124382
nosy: docs at python, rosslagerwall
priority: normal
severity: normal
status: open
title: Subprocess behavior on Windows
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file20115/test.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 08:30:14 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 20 Dec 2010 07:30:14 +0000
Subject: [docs] [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292830214.86.0.111198866684.issue10739@psf.upfronthosting.co.za>

Ross Lagerwall  added the comment:

Attached is a patch to document this.

----------
keywords: +patch
Added file: http://bugs.python.org/file20116/subprocessdoc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 10:35:25 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 20 Dec 2010 09:35:25 +0000
Subject: [docs] [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1292837725.48.0.829548294702.issue10461@psf.upfronthosting.co.za>

Vinay Sajip  added the comment:

I've already made the change, Terry, just holding off committing it because Georg has frozen the py3k branch until 3.2b2 is released.

There are a few other changes I'm making, will commit these soon after 3.2b2 is released.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 14:40:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 13:40:14 +0000
Subject: [docs] [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292852414.48.0.219463658316.issue10739@psf.upfronthosting.co.za>

R. David Murray  added the comment:

This might be an example of the general problem that on windows, sockets and files don't mix well.  You can't use a file in a select call, either.

I think there are two possibilities here: either makefile doesn't produce anything very useful on windows, or there's a bug in either makefile or subprocess.  If the former, the proper place to document it would be in the makefile docs.

----------
assignee: docs at python -> 
nosy: +brian.curtin, gregory.p.smith, r.david.murray, tim.golden
versions: +Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 16:07:22 2010
From: report at bugs.python.org (Ross Lagerwall)
Date: Mon, 20 Dec 2010 15:07:22 +0000
Subject: [docs] [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292857642.86.0.104789519846.issue10739@psf.upfronthosting.co.za>

Ross Lagerwall  added the comment:

Since the code in subprocess gets the underlying fileno of the file-like object (line 819 of subprocess.py), I presume it is an example of the general problem of files and sockets not mixing very well on Windows.

So, I have attached a patch to document this in socket.makefile().

However, I also see that *it* is documented in select.select() that it will not work with Windows file-like objects. Maybe there should still be a note in subprocess.Popen() as per the first patch?

----------
Added file: http://bugs.python.org/file20117/socketdoc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 19:09:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Dec 2010 18:09:52 +0000
Subject: [docs] [issue10741] PyGILState_GetThisThreadState() lacks a doc
	entry
In-Reply-To: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>
Message-ID: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>

New submission from Antoine Pitrou :

PyGILState_GetThisThreadState() is "documented" in Include/pystate.h but not in the official docs. It should be documented along PyGILState_Ensure() and friends.

----------
assignee: docs at python
components: Documentation
messages: 124394
nosy: docs at python, haypo, pitrou
priority: normal
severity: normal
status: open
title: PyGILState_GetThisThreadState() lacks a doc entry
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 19:14:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Dec 2010 18:14:57 +0000
Subject: [docs] [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1292868897.34.0.0283289362229.issue10739@psf.upfronthosting.co.za>

R. David Murray  added the comment:

I think I'll leave that decision up to the doc crew.  My thought was that makefile was supposedly returning a file, therefore it was appropriate to document there that it wasn't really a file on windows, whereas subprocess docs are only talking about files, and it only just so happens that you can pass it a socket on unix by using makefile.

----------
assignee:  -> docs at python
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 20:25:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Dec 2010 19:25:08 +0000
Subject: [docs] [issue10728] argparse.ArgumentParser.print_help uses
	sys.stdout
In-Reply-To: <1292641856.45.0.125469009304.issue10728@psf.upfronthosting.co.za>
Message-ID: <1292873108.25.0.578150391343.issue10728@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Alright, I didn?t know you were doing mass merges.  I personally prefer to leave reports open until backported, now I?ll know your habits.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 20:27:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Dec 2010 19:27:07 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1292873227.47.0.930357286449.issue8145@psf.upfronthosting.co.za>

Changes by ?ric Araujo :

Removed file: http://bugs.python.org/file17940/unnamed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 20 22:33:42 2010
From: report at bugs.python.org (flashk)
Date: Mon, 20 Dec 2010 21:33:42 +0000
Subject: [docs] [issue10742] memoryview.readonly attribute is not documented
In-Reply-To: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>
Message-ID: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>

New submission from flashk :

The 'readonly' attribute is not explicitly described, even though it is used in the sample code for the memoryview type.

I've attached a patch that adds a description of the 'readonly' attribute.

----------
assignee: docs at python
components: Documentation
files: stdtypes.diff
keywords: patch
messages: 124403
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: memoryview.readonly attribute is not documented
versions: Python 2.7
Added file: http://bugs.python.org/file20121/stdtypes.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 17:30:28 2010
From: report at bugs.python.org (Ian Stevens)
Date: Tue, 21 Dec 2010 16:30:28 +0000
Subject: [docs] [issue10748] zipfile does not write empty ZIP structure if
	close()	called after __init__() as doc suggests
In-Reply-To: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>
Message-ID: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>

New submission from Ian Stevens :

The zipfile documentation (http://docs.python.org/library/zipfile.html) states:

"If the file is created with mode 'a' or 'w' and then close()d without adding any files to the archive, the appropriate ZIP structures for an empty archive will be written to the file."

This is not the case, eg.::

    >>> from StringIO import StringIO
    >>> import zipfile
    >>> s = StringIO()
    >>> z = zipfile.ZipFile(s, 'w')
    >>> z.close()
    >>> s.len
    0

The code for zipfile (http://svn.python.org/projects/python/trunk/Lib/zipfile.py) does not support the documentation either. The ending records are written only if ZipFile._didModify is True, and that attribute is only set to True if writestr() or write() are called.

Either the code should be fixed to support writing the ending records on an empty zip, or the documentation should be changed to reflect the existing behaviour.

Test case (for Lib/test/test_zipfile)::

    def test_close_empty_zip_creates_valid_zip(self):
        # Test that close() called on a ZipFile without write creates a valid ZIP.
        zf = zipfile.ZipFile(TESTFN, "w")
        zf.close()
        chk = zipfile.is_zipfile(TESTFN)
        self.assertTrue(chk)

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 124433
nosy: Ian.Stevens, docs at python
priority: normal
severity: normal
status: open
title: zipfile does not write empty ZIP structure if close() called after __init__() as doc suggests
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 17:48:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Dec 2010 16:48:20 +0000
Subject: [docs] [issue10748] zipfile does not write empty ZIP structure if
	close()	called after __init__() as doc suggests
In-Reply-To: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>
Message-ID: <1292950100.51.0.239619952148.issue10748@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

This has been fixed in Python 2.7.1 (which the online docs refer to).  I assume that you're using 2.6 or an earlier version.

As for the code in SVN, the "trunk" is currently not in use; development happens in the "release27-maint", "release31-maint" and "py3k" branches (the latter being the actual trunk of development).  This irritation will go away soon once we have migrated to Hg.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 17:59:26 2010
From: report at bugs.python.org (Ian Stevens)
Date: Tue, 21 Dec 2010 16:59:26 +0000
Subject: [docs] [issue10748] zipfile does not write empty ZIP structure if
	close()	called after __init__() as doc suggests
In-Reply-To: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>
Message-ID: <1292950766.37.0.988710704924.issue10748@psf.upfronthosting.co.za>

Ian Stevens  added the comment:

Yes, I'm using 2.6. 

If this is not the expected behaviour in 2.6, the doc should reflect that with a "New in version 2.7" note.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 18:51:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 17:51:36 +0000
Subject: [docs] [issue10742] memoryview.readonly attribute is not documented
In-Reply-To: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>
Message-ID: <1292953896.48.0.799917032578.issue10742@psf.upfronthosting.co.za>

Changes by Antoine Pitrou :

----------
nosy: +mark.dickinson, ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 18:58:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Dec 2010 17:58:21 +0000
Subject: [docs] [issue10748] zipfile does not write empty ZIP structure if
	close()	called after __init__() as doc suggests
In-Reply-To: <1292949028.6.0.314113507916.issue10748@psf.upfronthosting.co.za>
Message-ID: <1292954301.5.0.618867790923.issue10748@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

We usually don't do this for bugfixes, but here it makes sense I guess. r87414.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 19:39:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Dec 2010 18:39:18 +0000
Subject: [docs] [issue10749] lots of warnings when generating logging docs
In-Reply-To: <1292956739.84.0.250201293355.issue10749@psf.upfronthosting.co.za>
Message-ID: <1292956758.47.0.427168338839.issue10749@psf.upfronthosting.co.za>

Changes by Antoine Pitrou :

----------
nosy: +docs at python

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 21 19:46:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Dec 2010 18:46:14 +0000
Subject: [docs] [issue10749] lots of warnings when generating logging docs
In-Reply-To: <1292956739.84.0.250201293355.issue10749@psf.upfronthosting.co.za>
Message-ID: <1292957174.33.0.502311992815.issue10749@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Will vanish after a full rebuild; the duplicate detection is a bit buggy in Sphinx when the documents are read in the wrong order.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 22 23:58:24 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 22 Dec 2010 22:58:24 +0000
Subject: [docs] [issue10587] Document the meaning of str methods
In-Reply-To: <1292341337.1.0.503200318795.issue10587@psf.upfronthosting.co.za>
Message-ID: <20101222225810.GA1109@rubuntu>

Senthil Kumaran  added the comment:

...
> redundant checks for isdecimal() and isdigit().  I think the
> documentation should reflect what the code does for an off-chance
> that someone would replace unicodedata with their own database with
> which these checks are not redundant.

+1 for making these changes. Helps clarify meaning of these methods with
respect to Unicode strings.

----------
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 23 04:02:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 23 Dec 2010 03:02:13 +0000
Subject: [docs] [issue10587] Document the meaning of str methods
In-Reply-To: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>
Message-ID: <1293073333.48.0.375848193468.issue10587@psf.upfronthosting.co.za>

Alexander Belopolsky  added the comment:

Committed r87443 (3.2) and r87444 (3.1).

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 24 01:29:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Dec 2010 00:29:40 +0000
Subject: [docs] [issue9063] TZ examples in datetime.rst are incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1293150580.78.0.605044579404.issue9063@psf.upfronthosting.co.za>

Alexander Belopolsky  added the comment:

Committed in r87463 (3.2), r87464 (2.7) and r87465 (3.1).

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 24 04:32:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 24 Dec 2010 03:32:05 +0000
Subject: [docs] [issue10767] Lib/test/crashers/README is out of date
In-Reply-To: <1293161525.36.0.778982454407.issue10767@psf.upfronthosting.co.za>
Message-ID: <1293161525.36.0.778982454407.issue10767@psf.upfronthosting.co.za>

New submission from Alexander Belopolsky :

Among other things, README says:

"""
Each test should have a link to the bug report:

        # http://python.org/sf/BUG#

"""

but the only such link is found in crashers/infinite_loop_re.py and points to a closed issue 1541697.

It looks like the purpose of Lib/test/crashers has changed from being a repository of outstanding bugs to a repository of crashers that are not considered to be bugs.

----------
assignee: docs at python
components: Documentation, Tests
messages: 124586
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Lib/test/crashers/README is out of date

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 24 19:36:26 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Dec 2010 18:36:26 +0000
Subject: [docs] [issue10767] Lib/test/crashers/README is out of date
In-Reply-To: <1293161525.36.0.778982454407.issue10767@psf.upfronthosting.co.za>
Message-ID: <1293215786.51.0.790389572896.issue10767@psf.upfronthosting.co.za>

Brett Cannon  added the comment:

That's a fair assessment. A lot of the bugs that are easy to fix got closed out a couple of years back. The rest are (I think) considered too difficult and too marginal to worry about.

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

_______________________________________
Python tracker 

_______________________________________

From sandro.tosi at gmail.com  Fri Dec 24 19:51:35 2010
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 24 Dec 2010 19:51:35 +0100
Subject: [docs] typo in python 2.7.1 docs
In-Reply-To: 
References: 
Message-ID: 

Hi Steve,

On Wed, Dec 15, 2010 at 22:33, Steve Romanow  wrote:
> find string?zinfo_or_acrname in teh zipfile module docs.
> I think?zinfo_or_arcname is intended.

Thanks for your report, I've reported to the python issue tracker as
http://bugs.python.org/issue10770

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

From report at bugs.python.org  Fri Dec 24 21:02:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Dec 2010 20:02:04 +0000
Subject: [docs] [issue10768] Bug in scrolledtext
In-Reply-To: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>
Message-ID: <1293220924.24.0.954909313232.issue10768@psf.upfronthosting.co.za>

R. David Murray  added the comment:

Where is this example?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
type: crash -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 24 21:15:36 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 24 Dec 2010 20:15:36 +0000
Subject: [docs] [issue10768] Bug in scrolledtext
In-Reply-To: <1293184993.54.0.348627616611.issue10768@psf.upfronthosting.co.za>
Message-ID: <1293221736.73.0.383188231487.issue10768@psf.upfronthosting.co.za>

Daniel Urban  added the comment:

I don't think, that this is in an example (but probably there is an example somewhere, that crashes because of this). I found the code in Lib/tkinter/scrolledtext.py

----------

_______________________________________
Python tracker 

_______________________________________

From sandro.tosi at gmail.com  Fri Dec 24 21:57:05 2010
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 24 Dec 2010 21:57:05 +0100
Subject: [docs] Epub version of documentation?
In-Reply-To: <4D062D60.1000709@kenjackson.us>
References: <4D062D60.1000709@kenjackson.us>
Message-ID: 

Hi Ken,
thank for your email

On Mon, Dec 13, 2010 at 15:27, Ken Jackson  wrote:
> But it sure would be great if you could also offer an .epub version so we
> could
> study Python on our eReaders.

there's already an issue filed in the tracker for python:
http://bugs.python.org/issue10130 - I'll see if I can get a working
prototype, will you be able to provide some "real" tests (on a reader)
when ready?

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  Fri Dec 24 22:38:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Dec 2010 21:38:52 +0000
Subject: [docs] [issue10742] memoryview.readonly attribute is not documented
In-Reply-To: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>
Message-ID: <1293226732.07.0.336842631359.issue10742@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

I agree with addition. Patch look OK to my limited .rst knowledge.

To be more parallel to the other entries, the text might say
"A bool indicating whether ..."

----------
nosy: +terry.reedy
stage:  -> patch review
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Dec 25 06:05:54 2010
From: report at bugs.python.org (Devin Jeanpierre)
Date: Sat, 25 Dec 2010 05:05:54 +0000
Subject: [docs] [issue10771] descriptor protocol documentation has two
	different	definitions of "owner" class
In-Reply-To: <1293253554.32.0.921681514845.issue10771@psf.upfronthosting.co.za>
Message-ID: <1293253554.32.0.921681514845.issue10771@psf.upfronthosting.co.za>

New submission from Devin Jeanpierre :

In trunk/Doc/reference/datamodel.rst , under _Implementing Descriptors_, the documentation states: 

`The following methods only apply when an instance of the class containing the method (a so-called *descriptor* class) appears in the class dictionary of another new-style class, known as the *owner* class. [...]`

Immediately below, in the documentation for __get__, it says, `*owner* is always the owner class [...]`.

These two uses of "the owner class" are incompatible, because there is only one class which matches the first use: the class where the descriptor was initially assigned to a class attribute; however, for the second use, any descendant class may be called "the owner class". This is demonstrated in the attached doctest file.

It is kind of hard to create a better definition for "owner" as used in `__get__`, though. It can't be said to be the class with the descriptor in its class dict, because it can be present in the class dict of some class in the MRO of the owner. It can't be said to be an attribute, because it has to be in a class dict of an ancestor node.

It might be possible to change the definition to call the owner class something like, "the class from which the descriptor was invoked", and if that isn't clear enough, provide examples (TypeDescriptor from the attached doctest file might work as an example); however, this would involve reworking the structure of the paragraph substantially. I personally would prefer this option. The paragraph is already badly structured; for example, it defines two terms in a single and rather complex sentence, and should probably be split up into a list of definitions rather than an explanatory jumble paragraph. In addition, this paragraph is the only place in the documentation where this idea of "the owner class" is used in this way. In the descriptions of the descriptor protocol methods below it, "the owner class" always refers to the class from which the attribute was accessed, or the type from which an instance had the attribute accessed.

Alternatively, it could be simpler to replace all references below from "the owner class" to "any class with the owner class in the MRO".

----------
assignee: docs at python
components: Documentation
files: descriptor.py.doctest
messages: 124630
nosy: Devin Jeanpierre, docs at python
priority: normal
severity: normal
status: open
title: descriptor protocol documentation has two different definitions of "owner" class
versions: Python 2.7
Added file: http://bugs.python.org/file20160/descriptor.py.doctest

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 02:33:04 2010
From: report at bugs.python.org (ipatrol)
Date: Sun, 26 Dec 2010 01:33:04 +0000
Subject: [docs] [issue10772] Several actions for argparse arguments missing
	from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>

New submission from ipatrol :

I actually noticed this while trying to free the -h option for my program. The actions not mentioned are count, help, and parsers. Also for nargs, '...' and 'A...' are not documented either in the Sphinx docs or the leading docstring for the Action class.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 124654
nosy: docs at python, ipatrol
priority: normal
severity: normal
status: open
title: Several actions for argparse arguments missing from docs
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 02:44:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 01:44:32 +0000
Subject: [docs] [issue10415] readline.insert_text documentation incomplete
In-Reply-To: <1289718734.94.0.0887962692453.issue10415@psf.upfronthosting.co.za>
Message-ID: <1293327872.04.0.270109938828.issue10415@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Hi Justin, thanks for the report and patch.  Would you like to turn your suggestion into a patch?  Guidelines are at http://www.python.org/dev/patches/

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 02:46:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 01:46:24 +0000
Subject: [docs] [issue1705393] Select() failure (race condition)
Message-ID: <1293327984.88.0.73240276353.issue1705393@psf.upfronthosting.co.za>

Changes by ?ric Araujo :

----------
nosy:  -BreamoreBoy
stage: unit test needed -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 02:50:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 01:50:37 +0000
Subject: [docs] [issue7436] Define 'object with assignable attributes'
In-Reply-To: <1259961781.03.0.33355289278.issue7436@psf.upfronthosting.co.za>
Message-ID: <1293328237.65.0.0464810881402.issue7436@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

We?d have to be careful to distinguish attributes defined to be not assignable and CPython implementation details.  In the absence of a definition in the doc, there is a chicken-and-egg problem, so I think a patch would have to be discussed on python-dev to get answers from the language designers.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 02:59:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 01:59:00 +0000
Subject: [docs] [issue7678] subprocess.Popen pipeline example code in
	the	documentation is lacking
In-Reply-To: <1263245210.2.0.116487607425.issue7678@psf.upfronthosting.co.za>
Message-ID: <1293328740.75.0.204805336955.issue7678@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

As a non-expert user of subprocess, calling close before communicate seems strange to me.  Does the example code with a bug work if close is called after communicate?

In the 3.2 docs, we could update the example to use a with statement, unless it is deemed a distraction for this simple introductory section.

----------
nosy: +eric.araujo, gregory.p.smith -georg.brandl
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 03:11:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 02:11:08 +0000
Subject: [docs] [issue8648] The UTF-7 codec functions are undocumented
In-Reply-To: <1273248636.7.0.217932609429.issue8648@psf.upfronthosting.co.za>
Message-ID: <1293329468.56.0.991585503848.issue8648@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

FTR, typo fixed in r83977.

----------
nosy: +eric.araujo
stage: needs patch -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 03:27:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 02:27:16 +0000
Subject: [docs] [issue9891] Minor doc typo at datamodel.rst: "list" ->
	"alist"
In-Reply-To: <1284801081.96.0.0540649030597.issue9891@psf.upfronthosting.co.za>
Message-ID: <1293330436.36.0.455362062707.issue9891@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Fixed in r87486 (py3k), r87487 (3.1) and r87488 (2.7), thanks!

----------
nosy: +eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 03:41:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 02:41:56 +0000
Subject: [docs] [issue3216] Scarce msilib documentation
In-Reply-To: <1214577470.61.0.590067451474.issue3216@psf.upfronthosting.co.za>
Message-ID: <1293331315.94.0.263257601894.issue3216@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

Nonexistent parameter removed from the doc in r87489 and following.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 03:52:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 26 Dec 2010 02:52:19 +0000
Subject: [docs] [issue9196] Improve docs for string interpolation "%s" re
	Unicode	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1293331939.74.0.774086678048.issue9196@psf.upfronthosting.co.za>

?ric Araujo  added the comment:

I?m not sure how much effort should be put into a patch here, considering that the horrible bytes/text confusion and implicit conversion should stop in Python 3, and %-formatting is mildly deprecated.  Ezio, what do you think?

Craig, could you attach your test_object class and test code?  I wonder if the mixed behavior is still present in 3.x.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 10:35:52 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 26 Dec 2010 09:35:52 +0000
Subject: [docs] [issue7436] Define 'object with assignable attributes'
In-Reply-To: <1259961781.03.0.33355289278.issue7436@psf.upfronthosting.co.za>
Message-ID: <1293356152.04.0.687909158107.issue7436@psf.upfronthosting.co.za>

Changes by Daniel Urban :

----------
nosy: +durban

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 11:49:20 2010
From: report at bugs.python.org (Craig McQueen)
Date: Sun, 26 Dec 2010 10:49:20 +0000
Subject: [docs] [issue9196] Improve docs for string interpolation "%s" re
	Unicode	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1293360560.48.0.998569345569.issue9196@psf.upfronthosting.co.za>

Craig McQueen  added the comment:

I should be able to attach my test code. But it is at my work, and I'm on holidays for 2 more weeks. Sorry 'bout that!

I do assume that Python 3 greatly simplifies this.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Dec 26 18:27:44 2010
From: report at bugs.python.org (Thorsten Behrens)
Date: Sun, 26 Dec 2010 17:27:44 +0000
Subject: [docs] [issue10773] "Building C and C++ Extensions on Windows"
	documentation	shows 2.x way of initializing module
In-Reply-To: <1293384464.17.0.166913159604.issue10773@psf.upfronthosting.co.za>
Message-ID: <1293384464.17.0.166913159604.issue10773@psf.upfronthosting.co.za>

New submission from Thorsten Behrens :

The documentation titled "Building C and C++ Extensions on Windows" at http://docs.python.org/py3k/extending/windows.html shows a Python 2.x way of handling static type object initializers, to whit:

>>
If your module creates a new type, you may have trouble with this line:

PyVarObject_HEAD_INIT(&PyType_Type, 0)

Static type object initializers in extension modules may cause compiles to fail with an error message like ?initializer not a constant?. This shows up when building DLL under MSVC. Change it to:

PyVarObject_HEAD_INIT(NULL, 0)

and add the following to the module initialization function:

MyObject_Type.ob_type = &PyType_Type;

>>

That last line will not function in Python 3.x. However, PyType_Ready will fill in the ob_type field if it is empty, if I understand PyType_Ready correctly. Therefore, the last few lines of this documentation snippet can become:

>>
and add the following to the module initialization function:

if (PyType_Ready(&MyObject_Type) < 0)
    return NULL;
>>

----------
assignee: docs at python
components: Documentation
messages: 124667
nosy: docs at python, thorsten.behrens
priority: normal
severity: normal
status: open
title: "Building C and C++ Extensions on Windows" documentation shows 2.x way of initializing module
versions: Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 02:51:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 01:51:00 +0000
Subject: [docs] [issue9738] Document the encoding of functions bytes
	arguments of the	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1293414660.52.0.0629579671719.issue9738@psf.upfronthosting.co.za>

STINNER Victor  added the comment:

r87504 documents encodings of error functions.
r87505 documents encodings of unicode functions.
r87506 documents encodings of AST, compiler, parser and PyRun functions.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 03:07:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Dec 2010 02:07:08 +0000
Subject: [docs] [issue9738] Document the encoding of functions bytes
	arguments of the	C API
In-Reply-To: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>
Message-ID: <1293415628.13.0.0740127619912.issue9738@psf.upfronthosting.co.za>

STINNER Victor  added the comment:

While documenting encodings, I found two issues: #10778 and #10779.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 10:32:27 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Dec 2010 09:32:27 +0000
Subject: [docs] [issue10771] descriptor protocol documentation has two
	different	definitions of "owner" class
In-Reply-To: <1293253554.32.0.921681514845.issue10771@psf.upfronthosting.co.za>
Message-ID: <1293442347.24.0.101506559147.issue10771@psf.upfronthosting.co.za>

Raymond Hettinger  added the comment:

I agree that the "owner" terminology imprecise.
Will work on a doc fix when I get chance.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 17:02:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 27 Dec 2010 16:02:33 +0000
Subject: [docs] [issue10781] minidom Node.writexml method doesn't manage
	encoding	parameter correctly
In-Reply-To: <1293464173.75.0.623330823257.issue10781@psf.upfronthosting.co.za>
Message-ID: <1293465753.6.0.0110812917227.issue10781@psf.upfronthosting.co.za>

Martin v. L?wis  added the comment:

The documentation is incorrect; writexml does not support an encoding parameter. Only Document nodes support the encoding parameter in writexml, and it is intentional that its only effect is to fill out the XML declaration.

I don't understand the last sentence in your report: what is it that you want to see supported, and how is that related to this issue?

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 17:07:10 2010
From: report at bugs.python.org (Goffi)
Date: Mon, 27 Dec 2010 16:07:10 +0000
Subject: [docs] [issue10781] minidom Node.writexml method doesn't manage
	encoding	parameter correctly
In-Reply-To: <1293464173.75.0.623330823257.issue10781@psf.upfronthosting.co.za>
Message-ID: <1293466030.22.0.60137538393.issue10781@psf.upfronthosting.co.za>

Goffi  added the comment:

Thanks for your quick reply

The last sentence has nothing to do with the report, it was just a general remark that it would be nice if minidom could support unicode string directly.

Should I send a mail to docs at python.org to report the doc issue, or this one is sufficient ?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Dec 27 18:05:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 27 Dec 2010 17:05:55 +0000
Subject: [docs] [issue10781] minidom Node.writexml method doesn't manage
	encoding	parameter correctly
In-Reply-To: <1293466030.22.0.60137538393.issue10781@psf.upfronthosting.co.za>
Message-ID: <4D18C76F.9020103@v.loewis.de>

Martin v. L?wis  added the comment:

> The last sentence has nothing to do with the report, it was just a general remark that 
> it would be nice if minidom could support unicode string directly.

minidom most certainly supports Unicode directly. All element names,
attribute names, and text nodes carry Unicode objects.

> Should I send a mail to docs at python.org to report the doc issue, 
> or this one is sufficient ?

This one is sufficient.

----------

_______________________________________
Python tracker 

_______________________________________

From jurko.gospodnetic at pke.hr  Tue Dec 21 16:29:14 2010
From: jurko.gospodnetic at pke.hr (=?windows-1250?Q?Jurko_Gospodneti=E6?=)
Date: Tue, 21 Dec 2010 16:29:14 +0100
Subject: [docs] Missing action='help' documentation for the argparse module.
Message-ID: <4D10C7CA.7020502@pke.hr>

   Hi.

   In Python 3.2 beta1 & Python 2.7 documentation for the 'argparse' 
module the special value 'help' is not listed for the 
ArgumentParser.add_argument() function's 'action' parameter.

   It causes the argument it is specified for to trigger displaying the 
argument parser's help message and also prevents the parser from 
complaining about any missing or extra command-line parameters.

   Without using this action value it is possible to print out the help 
message programmatically using ArgumentParser.print_help() but there is 
no way to cause the argument parser to not complaing about missing or 
extra command-line parameters.

   Best regards,
     Jurko Gospodneti?

From whlavina at ncbi.nlm.nih.gov  Thu Dec 23 22:06:05 2010
From: whlavina at ncbi.nlm.nih.gov (Hlavina, Wratko (NIH/NLM/NCBI) [C])
Date: Thu, 23 Dec 2010 16:06:05 -0500
Subject: [docs] Suggestion to document sublte difference between os.execlp,
 os.execlpe vs native library
Message-ID: 

A subtle issue of a missing shebang in an executable script revealed how Python's platform-independent versions of os.execlp, os.execlpe deviate from the native operating system implementation (in my case, Linux CentOS and SuSE). Googling during a debug session didn't provide an obvious answer to the issue (observed in a call to subproces.Popen), and this caused a little head-scratching before figuring out the cause.

I have no objection to the difference in behavior (in fact, I believe the Python behavior is safer!), but I do believe a clear warning in the documentation for os.execlp and os.execlpe is in order, stating that they do not necessarily behave the same way as the underlying OS implementation, and that, in particular, header processing (shebang #! lines) is different: presumably, the executable "must  be either a binary executable, or a script starting with a line of the form "#! interpreter [arg]".

This comes from forwarding the family of os.exec* functions to os._execvpe, which itself forwards to posix.execve or posix.execv, instead of the underlying operating system versions of execlp and execvp (neither of which are available from the posix module).

Thank you and kind regards,

$ man execve

[...]
       filename  must  be either a binary executable, or a script
       starting with a line of the form "#!  interpreter  [arg]".
[...]

$ man execlp

[...]

       Some of these functions have special semantics.

       The functions execlp and execvp will duplicate the actions
       of  the  shell  in searching for an executable file if the
       specified file name does not contain a slash  (/)  charac
       ter.   The  search path is the path specified in the envi
       ronment by the PATH  variable.   If  this  variable  isn't
       specified,  the  default  path ``:/bin:/usr/bin'' is used.
       In addition, certain errors are treated specially.

       If permission is denied for a file (the  attempted  execve
       returned  EACCES), these functions will continue searching
       the rest of the search path.  If no other file  is  found,
       however,  they  will return with the global variable errno
       set to EACCES.

       If the header of a file isn't  recognized  (the  attempted
       execve returned ENOEXEC), these functions will execute the
       shell with the path of the file  as  its  first  argument.
       (If this attempt fails, no further searching is done.)

--
Wratko HLAVINA
Office NCBI Building 45 Floor 4 Room AS13D-121
       301-402-9730 voice, 301-480-2484 fax
Urgent? cc:urgent at hlavina.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From eastdao at eastdao.com  Sat Dec 25 06:12:55 2010
From: eastdao at eastdao.com (=?UTF-8?B?5Lic5bKb572R?=)
Date: Sat, 25 Dec 2010 13:12:55 +0800 (CST)
Subject: [docs] Python Organization,Hello!
Message-ID: <1d6efe9.10a3.12d1bf19dac.Coremail.eastdao@eastdao.com>

Python Software Foundation, Hello!

  I am a programmer from China. Because China has no official Python tutorial books,So I want to translate the official Python tutorial books and posted on the Internet, can it?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From cht at tyrael.eu  Sat Dec 25 23:33:49 2010
From: cht at tyrael.eu (Christian Taylor)
Date: Sat, 25 Dec 2010 23:33:49 +0100
Subject: [docs] sys.maxint in Python 3.2 range() documentation
Message-ID: <201012252333.49388.cht@tyrael.eu>

Hello everyone,

just a minor nitpick:

The documentation for Python 3.2 (beta) refers to sys.maxint when describing 
the range function at http://docs.python.org/dev/library/functions.html#range:
"Ranges containing absolute values larger than sys.maxint are permitted but 
some features (such as len()) will raise OverflowError."

If I'm not mistaken, this should refer to sys.maxsize.

Kind regards,
Christian

From suzen at acm.org  Sun Dec 26 11:53:09 2010
From: suzen at acm.org (Suzen, Mehmet)
Date: Sun, 26 Dec 2010 12:53:09 +0200
Subject: [docs] 2.1. Invoking the Interpreter
Message-ID: 

Hi,

There is a bug or an ambiguity on

http://docs.python.org/tutorial/interpreter.html

It says "Note that there is a difference between 'python file' and
'python 
References: <201012252333.49388.cht@tyrael.eu>
Message-ID: <4D19AAB2.9010907@python.org>

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

Am 25.12.2010 23:33, schrieb Christian Taylor:
> Hello everyone,
> 
> just a minor nitpick:
> 
> The documentation for Python 3.2 (beta) refers to sys.maxint when describing 
> the range function at http://docs.python.org/dev/library/functions.html#range:
> "Ranges containing absolute values larger than sys.maxint are permitted but 
> some features (such as len()) will raise OverflowError."
> 
> If I'm not mistaken, this should refer to sys.maxsize.

Hi Christian,

you're right; that should indeed by sys.maxsize.  This is fixed now in the
development docs.

regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk0ZqrEACgkQN9GcIYhpnLATxgCfTchcK5kKvMeGzAcGcSF8XS64
EZ4AoKmI8DVzyMrNKj1bIQWaKrCnFH1/
=a8yF
-----END PGP SIGNATURE-----

From report at bugs.python.org  Tue Dec 28 10:30:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 09:30:51 +0000
Subject: [docs] [issue10773] "Building C and C++ Extensions on Windows"
	documentation	shows 2.x way of initializing module
In-Reply-To: <1293384464.17.0.166913159604.issue10773@psf.upfronthosting.co.za>
Message-ID: <1293528651.8.0.727119724523.issue10773@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Thanks, fixed in r87524.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From georg at python.org  Tue Dec 28 10:26:04 2010
From: georg at python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 10:26:04 +0100
Subject: [docs] 2.1. Invoking the Interpreter
In-Reply-To: 
References: 
Message-ID: <4D19AD2C.30806@python.org>

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

Am 26.12.2010 11:53, schrieb Suzen, Mehmet:
> Hi,
> 
> There is a bug or an ambiguity on
> 
> http://docs.python.org/tutorial/interpreter.html
> 
> It says "Note that there is a difference between 'python file' and
> 'python  program,..."
> 
> Must read as follows;
>  Execute statements from a file (inputs requested from stdin)
> $ python file.py
>  Execute statements from a file (inputs requested from file)
> $ python file.py < input
> 
> 
> While python  (r265:79063, Apr 16 2010, 13:09:56)
> [GCC 4.4.3] on linux2.

Hi Mehmet,

this is indeed a confusing paragraph; it is however correct as written.
The intention is to tell the reader that

python < file

will read the code from *file* and doesn't allow any input to stdin
afterwards.

I've removed the paragraph completely since it is definitely not material
for a tutorial anyway.

regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk0ZrSsACgkQN9GcIYhpnLCV4ACcC27gi93aCewd2ZLsiNL5nFCs
bB4AnjbiBfRj6AU4iY0kqjAqxDorslUF
=Le+y
-----END PGP SIGNATURE-----

From georg at python.org  Tue Dec 28 10:32:01 2010
From: georg at python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 10:32:01 +0100
Subject: [docs] Python Organization,Hello!
In-Reply-To: <1d6efe9.10a3.12d1bf19dac.Coremail.eastdao@eastdao.com>
References: <1d6efe9.10a3.12d1bf19dac.Coremail.eastdao@eastdao.com>
Message-ID: <4D19AE91.4070707@python.org>

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

Am 25.12.2010 06:12, schrieb ???:
> 
> Python Software Foundation, Hello!
> 
>   I am a programmer from China. Because China has no official Python tutorial
> books,So I want to translate the official Python tutorial books and posted on
> the Internet, can it?

Hi,

the docs are subject to the Python license; a short answer would be: yes, you
may translate the Python tutorial and post it online, provided that the
original copyright notices (in the file copyright.rst) are kept.

regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk0ZrpEACgkQN9GcIYhpnLB0VQCdEQfDLChGCGFnFMgJi7OB1tLE
cisAn1RpR16JR5aQCBVy9+zHGq02PcHF
=MQ6m
-----END PGP SIGNATURE-----

From report at bugs.python.org  Tue Dec 28 12:06:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:06:16 +0000
Subject: [docs] [issue10767] Lib/test/crashers/README is out of date
In-Reply-To: <1293161525.36.0.778982454407.issue10767@psf.upfronthosting.co.za>
Message-ID: <1293534376.17.0.744265116154.issue10767@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Fixed in r87530.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 12:08:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:08:43 +0000
Subject: [docs] [issue10742] memoryview.readonly attribute is not documented
In-Reply-To: <1292880822.31.0.13421483923.issue10742@psf.upfronthosting.co.za>
Message-ID: <1293534523.6.0.580176391739.issue10742@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Added in r87531.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 12:16:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:16:23 +0000
Subject: [docs] [issue10781] minidom Node.writexml method doesn't manage
	encoding	parameter correctly
In-Reply-To: <1293464173.75.0.623330823257.issue10781@psf.upfronthosting.co.za>
Message-ID: <1293534983.55.0.523210878692.issue10781@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Fixed in r87532.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 12:50:05 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:50:05 +0000
Subject: [docs] [issue10739] Subprocess behavior on Windows
In-Reply-To: <1292830157.42.0.278273587536.issue10739@psf.upfronthosting.co.za>
Message-ID: <1293537005.15.0.519625119303.issue10739@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

I agree that this belongs in the makefile docs.  Fixed in r87535.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 12:51:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:51:11 +0000
Subject: [docs] [issue10670] Provide search scope limits
In-Reply-To: <1291969014.77.0.923672343154.issue10670@psf.upfronthosting.co.za>
Message-ID: <1293537071.15.0.147970234326.issue10670@psf.upfronthosting.co.za>

Changes by Georg Brandl :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 12:53:35 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 28 Dec 2010 11:53:35 +0000
Subject: [docs] [issue10609] dbm documentation example doesn't work
	(iteritems())
In-Reply-To: <1291323126.35.0.13869122255.issue10609@psf.upfronthosting.co.za>
Message-ID: <1293537215.47.0.0699153835217.issue10609@psf.upfronthosting.co.za>

Georg Brandl  added the comment:

Fixed in r87536.

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 17:48:38 2010
From: report at bugs.python.org (David Kremer)
Date: Tue, 28 Dec 2010 16:48:38 +0000
Subject: [docs] [issue10787] [random.gammavariate] Add the expression of
	the	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>

New submission from David Kremer :

Could you please add the exact form of the distribution, because it's rather confusing in the current form.

In this url, the role of k and theta is precised with a formula :
[http://tinyurl.com/24jxfrk]*

It seems that in 
[http://docs.python.org/library/random.html#random.gammavariate] , alpha is playing the role of k and beta is playing the role of theta.

But it's still not clear, because one can confuse beta with 1/beta and vice et versa, like there is two usual representation for the gamma distribution [http://en.wikipedia.org/wiki/Gamma_distribution]

[http://docs.scipy.org/doc/numpy-1.5.x/reference/generated/numpy.random.gamma.html#numpy.random.gamma]*

Please update the documentation to avoid this ambiguity.

I provide an indicative patch which is updating the doc string in random.py

----------
assignee: docs at python
components: Documentation
files: patch_documentation_random.py.diff
keywords: patch
messages: 124803
nosy: David.Kremer, docs at python
priority: normal
severity: normal
status: open
title: [random.gammavariate] Add the expression of the distribution in a comprehensive form for random.gammavariate
versions: Python 2.7
Added file: http://bugs.python.org/file20181/patch_documentation_random.py.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Dec 28 18:52:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 28 Dec 2010 17:52:28 +0000
Subject: [docs] [issue10787] [random.gammavariate] Add the expression of
	the	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293558748.0.0.48577224068.issue10787@psf.upfronthosting.co.za>

Changes by ?ric Araujo :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 29 10:15:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 29 Dec 2010 09:15:44 +0000
Subject: [docs] [issue10787] [random.gammavariate] Add the expression of
	the	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293614144.49.0.54523386067.issue10787@psf.upfronthosting.co.za>

Changes by Mark Dickinson :

----------
nosy: +mark.dickinson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Dec 29 18:41:18 2010
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Wed, 29 Dec 2010 17:41:18 +0000
Subject: [docs] [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>

New submission from Jyrki Pulliainen :

In threading module, the Lock.acquire documentation is misleading. The signature suggests that the blocking can be given as a keyword argument but that would lead to an TypeError, as thread.lock.acquire does not accept keyword arguments.

The signature in documentation should be formatted as in thread.lock.acquire.

----------
assignee: docs at python
components: Documentation
messages: 124861
nosy: Jyrki.Pulliainen, docs at python
priority: normal
severity: normal
status: open
title: Lock.acquire documentation is misleading
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 01:24:32 2010
From: report at bugs.python.org (Thorsten Behrens)
Date: Thu, 30 Dec 2010 00:24:32 +0000
Subject: [docs] [issue10793] hashlib.hash.digest() documentation incorrect
	re return	type
In-Reply-To: <1293668672.17.0.948063108001.issue10793@psf.upfronthosting.co.za>
Message-ID: <1293668672.17.0.948063108001.issue10793@psf.upfronthosting.co.za>

New submission from Thorsten Behrens :

The documentation for hashlib.hash.digest() states that digest() will "[r]eturn the digest of the data passed to the update() method so far. This is a bytes array of size digest_size[...]".

The returned object is of class 'bytes', not 'bytearray'. Documentation should reflect this.

----------
assignee: docs at python
components: Documentation
messages: 124892
nosy: docs at python, thorsten.behrens
priority: normal
severity: normal
status: open
title: hashlib.hash.digest() documentation incorrect re return type
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 01:41:35 2010
From: report at bugs.python.org (SilentGhost)
Date: Thu, 30 Dec 2010 00:41:35 +0000
Subject: [docs] [issue10793] hashlib.hash.digest() documentation incorrect
	re return	type
In-Reply-To: <1293668672.17.0.948063108001.issue10793@psf.upfronthosting.co.za>
Message-ID: <1293669695.57.0.594332558513.issue10793@psf.upfronthosting.co.za>

SilentGhost  added the comment:

One-word patch attached.

----------
keywords: +patch
nosy: +SilentGhost
Added file: http://bugs.python.org/file20191/hashlib.rst.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 08:21:35 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 30 Dec 2010 07:21:35 +0000
Subject: [docs] [issue10793] hashlib.hash.digest() documentation incorrect
	re return	type
In-Reply-To: <1293668672.17.0.948063108001.issue10793@psf.upfronthosting.co.za>
Message-ID: <1293693694.94.0.389116739413.issue10793@psf.upfronthosting.co.za>

Senthil Kumaran  added the comment:

Fixed in r87573 and r87574

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 18:40:39 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 30 Dec 2010 17:40:39 +0000
Subject: [docs] [issue10681] PySlice_GetIndices() signature changed
In-Reply-To: <1292091179.71.0.567873924052.issue10681@psf.upfronthosting.co.za>
Message-ID: <1293730839.12.0.811998888225.issue10681@psf.upfronthosting.co.za>

Dave Malcolm  added the comment:

For reference, this seems to affect SWIG, specifically, I'm seeing build failures using:
  /usr/share/swig/2.0.1/python/pycontainer.swg
from swig-2.0.1

See downstream build failure report for znc, which uses swig to generate python 3 bindings:
  https://bugzilla.redhat.com/show_bug.cgi?id=666429

----------
nosy: +dmalcolm

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Dec 30 20:55:31 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 30 Dec 2010 19:55:31 +0000
Subject: [docs] [issue10787] [random.gammavariate] Add the expression of
	the	distribution in a comprehensive form for random.gammavariate
In-Reply-To: <1293554918.75.0.546382725998.issue10787@psf.upfronthosting.co.za>
Message-ID: <1293738931.5.0.151123944822.issue10787@psf.upfronthosting.co.za>

Changes by Raymond Hettinger :

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 31 18:44:46 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 31 Dec 2010 17:44:46 +0000
Subject: [docs] [issue9370] Add reader redirect from test package docs to
	unittest	module
In-Reply-To: <1279968547.11.0.280770421062.issue9370@psf.upfronthosting.co.za>
Message-ID: <1293817485.97.0.780531085784.issue9370@psf.upfronthosting.co.za>

Sandro Tosi  added the comment:

Hi Nick,
the "See also" section already points to unittest module; are you asking to extend its description to mention that's the tool people should use for their unittest suites?

Cheers,
Sandro

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 31 23:33:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 22:33:06 +0000
Subject: [docs] [issue10771] descriptor protocol documentation has two
	different	definitions of "owner" class
In-Reply-To: <1293253554.32.0.921681514845.issue10771@psf.upfronthosting.co.za>
Message-ID: <1293834786.62.0.332615857223.issue10771@psf.upfronthosting.co.za>

Terry J. Reedy  added the comment:

For future reference, the 'trunk' branch was frozen with the release of 2.7 in June 2010. However, this particular text is unchanged since in 2.7.1 and still in 3.2b2 (except for removal of 'new style'.)

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

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Dec 31 23:35:16 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Dec 2010 22:35:16 +0000
Subject: [docs] [issue10772] Several actions for argparse arguments missing
	from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1293834916.07.0.768539394459.issue10772@psf.upfronthosting.co.za>

Changes by Terry J. Reedy :

----------
nosy: +bethard
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker 

_______________________________________