From report at bugs.python.org  Wed Sep  1 03:49:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 01:49:09 +0000
Subject: [docs] [issue9728] Docs point to FAQ Section 3,
	but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In Doc/extending/windows.rst, there's the following text:

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

   PyVarObject_HEAD_INIT(&PyType_Type, 0)

Change it to::

   PyVarObject_HEAD_INIT(NULL, 0)

and add the following to the module initialization function::

   MyObject_Type.ob_type = &PyType_Type;

Refer to section 3 of the `Python FAQ <http://www.python.org/doc/faq>`_ for
details on why you must do this.
------------------------------------------------------------------------

If I assume that Section 3 means, the third link on the FAQ page, I can't find the FAQ that's being alluded to here.  There's a comment in Include/pyport.h that I believe to be related:

            /* Under Cygwin, auto-import functions to prevent compilation */
            /* failures similar to http://python.org/doc/FAQ.html#3.24 */

However, that link no longer goes to a particular question and I can't tell which question it once referred to.

I ran into this because I'm trying to understand the cause of the issue which I suspect is related to Issue #6672.

----------
assignee: docs at python
components: Documentation
messages: 115285
nosy: brian.curtin, docs at python, stutzbach, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: Docs point to FAQ Section 3, but FAQs are not numbered

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

From report at bugs.python.org  Wed Sep  1 05:44:26 2010
From: report at bugs.python.org (JingCheng LIU)
Date: Wed, 01 Sep 2010 03:44:26 +0000
Subject: [docs] [issue9730] base64 encoding takes in bytes rather than
	string.
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>


New submission from JingCheng LIU <liuexp at gmail.com>:

http://docs.python.org/py3k/library/base64.html?highlight=base64
the examples given doesn't work

----------
assignee: docs at python
components: Documentation
messages: 115287
nosy: Dmitry.Jemerov, JingCheng.LIU, docs at python, ezio.melotti, orsenthil, pitrou
priority: normal
severity: normal
status: open
title: base64 encoding takes in bytes rather than string.
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Sep  1 13:56:49 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 01 Sep 2010 11:56:49 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283342209.16.0.00907370316584.issue9730@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

The example can be fixed by placing a "b" before the two string literals.

However, pretty much the whole document refers to "strings" and should refer to "byte sequences" or the "bytes" type.

I thought there were automated tests that exercised the documentation examples.  Am I wrong about that?

----------
nosy: +stutzbach
resolution:  -> accepted
stage:  -> needs patch
title: base64 encoding takes in bytes rather than string. -> base64 docs refers to strings instead of bytes
versions: +Python 3.2

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

From report at bugs.python.org  Wed Sep  1 20:58:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Sep 2010 18:58:38 +0000
Subject: [docs] [issue9735] cheatsheet outdated
In-Reply-To: <1283367518.76.0.51890574432.issue9735@psf.upfronthosting.co.za>
Message-ID: <1283367518.76.0.51890574432.issue9735@psf.upfronthosting.co.za>


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

The Misc/cheatsheet file is totally outdated (the title ?Python 2.3 Quick Reference? already gives you a hint).
It is also not clear if it is meant for plain text viewing, or should be formatted using an external program...

----------
assignee: docs at python
components: Documentation
messages: 115325
nosy: docs at python, pitrou, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: cheatsheet outdated
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Sep  1 21:19:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Sep 2010 19:19:14 +0000
Subject: [docs] [issue9735] cheatsheet outdated
In-Reply-To: <1283367518.76.0.51890574432.issue9735@psf.upfronthosting.co.za>
Message-ID: <1283368754.35.0.718948497827.issue9735@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Misc/cheatsheet needs updating

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

From report at bugs.python.org  Wed Sep  1 21:20:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 01 Sep 2010 19:20:39 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1283368839.28.0.570171247117.issue4819@psf.upfronthosting.co.za>


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

Merging nosy from duplicate report.

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

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

From report at bugs.python.org  Wed Sep  1 21:31:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Sep 2010 19:31:09 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1283369469.31.0.574769631714.issue4819@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


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

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

From report at bugs.python.org  Wed Sep  1 23:03:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 01 Sep 2010 21:03:03 +0000
Subject: [docs] [issue9677] "Global Module Index" link dead
In-Reply-To: <1282685163.07.0.524302094141.issue9677@psf.upfronthosting.co.za>
Message-ID: <1283374983.15.0.47054882952.issue9677@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r84407.

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

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

From report at bugs.python.org  Thu Sep  2 00:41:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Sep 2010 22:41:36 +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: <1283380895.91.0.777071955411.issue9738@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Many C functions have bytes argument (char* type) but the encoding is not documented. If would not be a problem if the encoding was always the same, but it is not. Examples:
 - format of PyUnicode_FromFormat() should be encoded as ISO-8859-1
 - filename of PyParser_ASTFromString() should be encoded as utf-8
 - filename of PyErr_SetFromErrnoWithFilename() should be encoded to the filesystem encoding (with strict error handler, and not surrogateescape)
 - 's' argument of PyParser_ASTFromString() should be encoded as utf-8 if PyPARSE_IGNORE_COOKIE flag is set, otherwise the parser checks for #coding:xxx cookie (if there is no cookie, utf-8 is used)

Attached patch is a try to document most low level functions. I choosed to add the name of function arguments in the headers because I consider that a header can be used as a quick documentation. I only touched .c files to change argument names.

It is hard to get the right encoding, so I cannot ensure that my patch is correct. My patch is just a draft.

I don't know if "encoded to utf-8" is the right expression. Or should it be "decoded as utf-8"?

----------
assignee: docs at python
components: Documentation, Interpreter Core, Unicode
files: encodings.patch
keywords: patch
messages: 115339
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Document the encoding of functions bytes arguments of the C API
versions: Python 3.2
Added file: http://bugs.python.org/file18705/encodings.patch

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

From report at bugs.python.org  Thu Sep  2 08:51:01 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 02 Sep 2010 06:51:01 +0000
Subject: [docs] [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283410261.28.0.275436167586.issue9739@psf.upfronthosting.co.za>


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

Aren't there tools that extract only the first line of help?

----------
assignee:  -> docs at python
components: +Documentation -Extension Modules
nosy: +amaury.forgeotdarc, docs at python

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

From report at bugs.python.org  Thu Sep  2 10:55:16 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 02 Sep 2010 08:55:16 +0000
Subject: [docs] [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283417716.02.0.46002281205.issue9739@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Thu Sep  2 21:19:27 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 02 Sep 2010 19:19:27 +0000
Subject: [docs] [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

In the list of operations supported by all sequence types, the .index and .count methods should be included.  They are defined by the collections.Sequence ABC that all sequences support.

(except for range objects, but that will be fixed in Issue9213)

----------
assignee: docs at python
components: Documentation
messages: 115397
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: All sequence types support .index and .count
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Sep  2 22:20:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Sep 2010 20:20:52 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283458852.05.0.424116430434.issue9730@psf.upfronthosting.co.za>


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

See issue 4769, which would partially fix this problem if implemented correctly.  The docs should still be given a thorough review to use the appropriate bytes/string language.

There is a way to do automated testing of the code in the docs, but nobody has done the work to automate it yet.  Sphinx only recently got 3.x support, before which it wasn't even possible.  To run it by hand, do 'make doctest' in the Doc subdirectory of the checkout...the first step will be to fix all the failures....

----------
dependencies: +b64decode should accept strings or bytes
nosy: +r.david.murray

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

From report at bugs.python.org  Thu Sep  2 22:53:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 02 Sep 2010 20:53:14 +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: <1283460794.51.0.445894929075.issue9738@psf.upfronthosting.co.za>


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

I think either of these is correct:
- a UTF-8-encoded string
- a string encoded in UTF-8

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

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

From report at bugs.python.org  Thu Sep  2 23:13:14 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 02 Sep 2010 21:13:14 +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: <1283461994.22.0.157742760148.issue9738@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> I think either of these is correct:
> - a UTF-8-encoded string
> - a string encoded in UTF-8

Possibly use the word "buffer" here, rather than "string", as "string" may suggest the "str" type.

Or even: "NUL-terminated buffer of UTF-8-encoded bytes", or whatnot.

(sorry for bikeshedding)

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

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

From report at bugs.python.org  Fri Sep  3 04:06:09 2010
From: report at bugs.python.org (Neil Tallim)
Date: Fri, 03 Sep 2010 02:06:09 +0000
Subject: [docs] [issue9747] os.getresgid() documentation mentions "user ids",
	not "group ids"
In-Reply-To: <1283479568.94.0.540639670687.issue9747@psf.upfronthosting.co.za>
Message-ID: <1283479568.94.0.540639670687.issue9747@psf.upfronthosting.co.za>


New submission from Neil Tallim <red.hamsterx at gmail.com>:

Super-low-priority (it's obvious from context and unlike to confuse anyone who knows what they're looking at), but the os module's description for getresgid() is "Return a tuple (rgid, egid, sgid) denoting the current process?s real, effective, and saved user ids."

It should be "Return a tuple (rgid, egid, sgid) denoting the current process?s real, effective, and saved group ids."

----------
assignee: docs at python
components: Documentation
messages: 115411
nosy: Red HamsterX, docs at python
priority: normal
severity: normal
status: open
title: os.getresgid() documentation mentions "user ids", not "group ids"
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Sep  3 05:25:50 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Fri, 03 Sep 2010 03:25:50 +0000
Subject: [docs] [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283484350.26.0.371901300111.issue9739@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

According to PEP 7, the first line of the doc string should contain the signature of the function, then there should be a blank line, and then the rest of the doc string. There may be tools that extract the signature line. The patch just decreases the line length of the remaining lines of the doc string so they don't wrap when displayed on an 80 character wide terminal window.

For an example, look at the text for modf(...) in help(math).

I just noticed that the math module uses "modf(x)" for the signature line but PEP 7 recommends including the return type, say "modf(x) -> (frac, int)".

The simplest change would be to fix the wrapping issue and leave the signature line alone. It would be more effort to make all the doc strings PEP 7 compliant by standardizing the signature line to include the return type.

I'm willing to work through the standard library and create patches for either option.

----------

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

From report at bugs.python.org  Fri Sep  3 12:52:20 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Sep 2010 10:52:20 +0000
Subject: [docs] [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1283511140.18.0.429977986765.issue8649@psf.upfronthosting.co.za>


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

For this one, I suggest adding something to http://docs.python.org/dev/c-api/unicode.html#plain-py-unicode

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

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

From report at bugs.python.org  Fri Sep  3 13:44:30 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 03 Sep 2010 11:44:30 +0000
Subject: [docs] [issue9755] Fix refcounting details in Py3k C API
	documentation
In-Reply-To: <1283514224.53.0.325600320074.issue9755@psf.upfronthosting.co.za>
Message-ID: <1283514270.98.0.240849705629.issue9755@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep  3 18:33:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 16:33:06 +0000
Subject: [docs] [issue9723] pipes.quote() needs to be documented
In-Reply-To: <1283262014.72.0.527039259842.issue9723@psf.upfronthosting.co.za>
Message-ID: <1283531585.36.0.886282994674.issue9723@psf.upfronthosting.co.za>


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

Eric referred to this thread: http://mail.python.org/pipermail/stdlib-sig/2010-May/thread.html

----------
nosy: +eric.araujo
versions:  -Python 2.5, Python 2.6, Python 3.3

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

From report at bugs.python.org  Fri Sep  3 19:40:01 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 03 Sep 2010 17:40:01 +0000
Subject: [docs] [issue9755] Fix refcounting details in Py3k C API
	documentation
In-Reply-To: <1283514224.53.0.325600320074.issue9755@psf.upfronthosting.co.za>
Message-ID: <1283535601.01.0.434295192387.issue9755@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I thought Fred Drake wrote the code that generated that file, but that
was a long time ago in a galaxy far, far away.  Perhaps Georg has
subsumed it into his Sphinx/Python doc workflow?

(making Fred "nosy" so he sees this thread...)

S

----------
nosy: +fdrake, skip.montanaro

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

From report at bugs.python.org  Fri Sep  3 19:51:35 2010
From: report at bugs.python.org (Jason Baker)
Date: Fri, 03 Sep 2010 17:51:35 +0000
Subject: [docs] [issue9760] Suggestion for improving with documentation
In-Reply-To: <1283536295.47.0.948659460721.issue9760@psf.upfronthosting.co.za>
Message-ID: <1283536295.47.0.948659460721.issue9760@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

http://docs.python.org/reference/compound_stmts.html#with

This documentation refers to "context expressions" in two places.  However, it never really defines what a context expression is.  The formal syntax that's presented is this:

with_stmt ::=  "with" with_item ("," with_item)* ":" suite
with_item ::=  expression ["as" target]

As best I can tell, the context expression is essentially the with_item.  If that's the case, I propose one of the following:

 1) The formal syntax is changed so that "with_item" becomes "context_expression".
 2) References to "context expression" change to "with item".
 3) The "context expression" is defined to be the with_item in the formal syntax at some point in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 115478
nosy: Jason.Baker, docs at python
priority: normal
severity: normal
status: open
title: Suggestion for improving with documentation
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  3 21:14:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 19:14:28 +0000
Subject: [docs] [issue9717] operator module - "in place" operators
	documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1283541268.23.0.479208479524.issue9717@psf.upfronthosting.co.za>


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

I agree that the docs for augmented assignments and the corresponding method and funciton can and should be improved.

But I do not like this as is. In particular, Python does not have in-place operators; it has methods that optionally do an operation in-place if the first argument (self) is mutable. I think adding "" is insufficient to avoid the confusion of the incorrect term. What I think should be said is that the ixxx methods and the corresponding operator.ixxx functions implement the operation part of operation-augmented assignments.

For the operator doc, I think we should expand the initial paragraph ("The operator module ...") a bit so that less needs to said specifically for the ixxx functions.

Also, most of your explanation is really about augmented assignment and the .__ixxx__ special methods, not specifically about operator.ixxx functions, and might better be added to the subsection 3.3.6. Emulating numeric typesof the special methods section (and cross-referenced from the operator doc) or even used to improve 6.2.1. Augmented assignment statements, and not buried in the operator doc. If people are confused about the .ixxx functions, they are probably confused also about a.a. and .__ixxx__ methods.

So I would like to attack the whole problem and expand this issue to "Improve operator-augmented assginment docs." and cover all three relevant doc areas, starting with
6.2.1. Augmented assignment statements. As already hinted, I would like to expand the title to "Operator-augmented assignment statements.".

I would like there to be a prototype example near the top: either "target_arg op= arg", with op explained as one of +-*/... or "target_arg += arg" as a specific example, or both. Since the target is also an arg reference, it obviously must refer to a single existing object. Then discuss the two cases of target immutable and mutable, as the current doc and your proposal does.

Otherwise in this section, I am mystified by the reference of "(See section Primaries for the syntax definitions for the last three symbols.)". I have also forgotten the meaning of "With the exception of assigning to tuples "; i should just be stated.

As already stated, I also believe the explanation of .__ixxx__ methods in 3.3.6. Emulating numeric types could be improved a bit.

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

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

From report at bugs.python.org  Fri Sep  3 21:31:33 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Sep 2010 19:31:33 +0000
Subject: [docs] [issue9717] operator module - "in place" operators
	documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1283542292.72.0.789973584388.issue9717@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Consider breaking the operator module documents into sections, grouping all of the in-place ops into the last section.  Start that section with a full description of how in-place works in python and show some examples of successful way to use the in-place operators.

Right now, the docs are somewhat misleading because they imply that the i-functions can be used in the same was as their counterparts.

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

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

From report at bugs.python.org  Fri Sep  3 21:32:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Sep 2010 19:32:01 +0000
Subject: [docs] [issue9717] operator module - "in place" operators
	documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1283542321.11.0.378963513945.issue9717@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


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

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

From report at bugs.python.org  Fri Sep  3 21:54:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 19:54:52 +0000
Subject: [docs] [issue9728] Docs point to FAQ Section 3,
	but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1283543692.41.0.780662382884.issue9728@psf.upfronthosting.co.za>


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

As I remember, the FAQ was once that, *the* (giant) FAQ, with numbered sections. When broken into pieces, the order may have been re-arranged.

Given that the broken reference is in extending/windows, I would look in both the Extending and Windows FAQs. However, I found neither 'PyType_Type' nor 'PyVarObject_HEAD_INIT' nor 'initialization' in either.

Besides removing the dead reference, you could either look through the revision history of the file or ask on pydev if you need the info.

The split-up FAQs first appear in a release doc set in Python 2.6.4, documentation released on 25 October 2009. I do not know if the earlier, unitary FAQ is in the repository or not.

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

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

From report at bugs.python.org  Fri Sep  3 22:55:35 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 20:55:35 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283547334.94.0.598926205062.issue9730@psf.upfronthosting.co.za>


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

PATCH
Specifically, in section 17.6. base64..., near bottom, example should be

>>> import base64
>>> encoded = base64.b64encode(b'data to be encoded') #hang
>>> encoded
b'ZGF0YSB0byBiZSBlbmNvZGVk'
>>> data = base64.b64decode(encoded)
>>> data
b'data to be encoded'

with the first and third 'b' prefixes added.

I confirmed that doctest works with above.

I am a bit puzzled about Sphinx and 3.x comment, as doctest just need a plain ascii file and does not care how it was produced. (I used browser Save As text file function.) However, moot now.

----------
keywords: +patch
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Sep  3 23:32:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 21:32:52 +0000
Subject: [docs] [issue9767] Failures in json doc examples
In-Reply-To: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>
Message-ID: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

I ran doctest on LibRef 17.2 json saved as .txt. There are 4 failures: 2 are clearly doc issues, the other 2 I do not know. I hope someone reads this who is already familiar

DOC PATCHES
    dumps(2 + 1j, cls=ComplexEncoder)
should be
    json.dumps(2 + 1j, cls=ComplexEncoder)
and
    JSONEncoder().encode({"foo": ["bar", "baz"]})
should be
    json.JSONEncoder().encode({"foo": ["bar", "baz"]})

Needing similar additions in example code (not caught by doctest) are
           return JSONEncoder.default(self, o)
        for chunk in JSONEncoder().iterencode(bigobject):

Those fixes leave 2 failures I an unclear about and hope a json expert will comment on.

1.'''
Failed example:
    print(json.dumps({'4': 5, '6': 7}, sort_keys=True, indent=4))
Expected:
    {
        "4": 5,
        "6": 7
    }
Got:
    {
        "4": 5, 
        "6": 7
    }
'''
The difference is that json puts a trailing space after '5,'. Should it? or should one be added to the doc?

2. '''
Failed example:
    list(ComplexEncoder().iterencode(2 + 1j))
Expected:
    ['[', '2.0', ', ', '1.0', ']']
Got:
    ['[2.0', ', 1.0', ']']
'''
Without knowing how the default iterencode interacts with the overwridden .default() method, I have no idea.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 115512
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Failures in json doc examples
type: behavior

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

From report at bugs.python.org  Fri Sep  3 23:47:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 21:47:05 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283550424.55.0.449047417082.issue9730@psf.upfronthosting.co.za>


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

As an experiment, I ran doctest on 17.2 json saved as .txt, See #9767
4 failures, 2 obvious doc faults, 2 unclear to me.
Their were 2 similar doc faults in non-interactive code examples, so doctest is not enough to catch all bad code.

We clearly need to do this for the entire doc, preferably before 3.2 is released. A master issue is the wrong format, at least by itself. What I think is needed is a repository doc like Misc/maintainers.rst, call it Misc/doctests or Misc/docdoctests. It should have a line for each doc section with current status (blank for unchecked, n/a for no interactive example, issue number for fixes in progress). A master issue could then be a place where non-committers can report changes that committers could apply. What do you others think?

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

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

From report at bugs.python.org  Sat Sep  4 00:21:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 22:21:05 +0000
Subject: [docs] [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283552464.97.0.558432683918.issue9739@psf.upfronthosting.co.za>


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

Although this is not a problem in IDLE where the window can easily be expanded beyond 80 chars, I am in favor of the idea for other uses. The command line interpreter on Windows defaults to 80 chars and is not so easy to change, and one must be admin to make the change 'permanent' (until the next install reverts the change). In particular, the 82 char line for math.trun results in 'd.' of 'method.' wrapped to a line by itself with no indent. Pretty ugly.

However, I am puzzled why you edited the 74 char line for math.modf, which displays as 78 chars with a 4 char indent. This
'''\    
    Return the fractional and integer parts of x.  Both results carry the sign'''
displays fine on one line as is. The tracker, unfortunately, displays
123456789012345678901234567890123456789012345678901234567890123456789012 only 72 chars.
    of x and are floats.

I agree that
    trunc(x:Real) -> Integral
is more helpful (and therefore better) than
    modf(x)

For something like
-"T.index(value, [start, [stop]]) -> integer -- return first index of value.\n"

I personally think '->' and 'return are redundant, so I would argue that this could be shortened to
-"T.index(value, [start, [stop]]) -> integer (first index of value).\n"
instead of by wrapping.

Since I am not yet in a position to apply patches, I am not (yet) in a position to tell you whether or how to produce more patches.

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

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

From report at bugs.python.org  Sat Sep  4 00:29:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 22:29:14 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283552954.47.0.946257612507.issue9730@psf.upfronthosting.co.za>


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

It seems there are three ways of testing the docs:

1) ./python -m doctest Doc/library/json.rst
2) make doctest (a.k.a. sphinx-build -b doctest)
3) http://sphinx.pocoo.org/ext/doctest.html

Manually running 1) or 2) and fixing things seems okay for a first step, and when everything is fixed, we could add automation to prevent regressions. Georg is in the best place to say how to do it (through a thin test_docs.py integration layer between doctest and regrtest, with sphinx.ext.doctest, or by editing the test target of the makefile to run make doctest -C Doc).

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

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

From report at bugs.python.org  Sat Sep  4 00:30:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 22:30:56 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283553056.41.0.724115438314.issue9730@psf.upfronthosting.co.za>


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

Note also that some docs (turtle) require running Tcl, which may be unwanted on headless machines like buildbots.

----------

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

From report at bugs.python.org  Sat Sep  4 00:38:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:38:23 +0000
Subject: [docs] [issue9767] Failures in json doc examples
In-Reply-To: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>
Message-ID: <1283553503.14.0.508973836805.issue9767@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

r84481 should fix all except the whitespace one.  I don't think this is worth fixing; I will not add a trailing whitespace to the docs, and adding a "doctest: NORMALIZE_WHITESPACE" directive does not help readability, especially since nobody actually runs these doctest-like examples.

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

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

From report at bugs.python.org  Sat Sep  4 00:38:39 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 22:38:39 +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: <1283553519.84.0.638183558151.issue9738@psf.upfronthosting.co.za>


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

Better specifying requirements is good. A few comments:

-   The second argument is an error message; it is converted to a string object.
+   The second argument is an error message; it is decoded to a string object
+   with ``'utf-8'`` encoding.
 
I would write the change as
+   The second argument is a utf-8 encoded error message; it is decoded to a string object. 

I the second part (what the function will do with the arg) really needed? I think in the current version, it serves to indirectly specify that the arg in not to be a string, but bytes. If the specific encoding required is specified, that also says bytes, making 'will be decoded' redundant and irrelevant.
-------------------------------

+   a Python exception (class, not an instance). *format* should be a string
+   encoded to ISO-8859-1, containing format codes, 

*format* should be ISO-8859-1 encoded bytes containing format codes,

although I am not clear about the implications of that. Are not all format code ascii chars?
--------------------------------

I do not really like 'encoded to', but 'decoded to' is wrong. 'will be decoded from xxx bytes' is better. I think there should be a general discussion somewhere about bytes arguments and the terminology that will be used.

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

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

From report at bugs.python.org  Sat Sep  4 00:40:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:40:38 +0000
Subject: [docs] [issue9760] Suggestion for improving with documentation
In-Reply-To: <1283536295.47.0.948659460721.issue9760@psf.upfronthosting.co.za>
Message-ID: <1283553638.76.0.351729801039.issue9760@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Actually, the with_item contains the context expression *and* the optional "as target" clause, so they are not equivalent

I committed a clarification in r84482.

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

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

From report at bugs.python.org  Sat Sep  4 00:45:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:45:24 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283553924.23.0.945278993936.issue9730@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Generally: +1 on making sure examples in the docs are up to date.  If someone wants to do the tedious work of making sure that a "make doctest" succeeds, I'm all for it, it may involve adding a few (in HTML output invisible) testsetup blocks.

Eric: I'm not sure what the difference between your methods 2 and 3 is :)

As Terry already mentioned, by far not all example code is covered by that, and I don't think there's anything we can do about it.  We can of course try converting more doc examples to doctest format, however:

a) for longer examples and especially function/class definitions this really hurts readability and usability (think copy/paste)

b) many examples are also not easily runnable (Tk is a good example, many more can be found in those for network services)

----------

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

From smckean83 at gmail.com  Fri Sep  3 05:30:49 2010
From: smckean83 at gmail.com (Sean McKean)
Date: Thu, 2 Sep 2010 20:30:49 -0700
Subject: [docs] Documentation bug for Python 3.x
Message-ID: <AANLkTi=_yH3j99f+EPD1fMBrtc3RiAa3bo47Ocx2EtVJ@mail.gmail.com>

Greetings,
I found a one-letter-missing bug on the page <
http://docs.python.org/py3k/reference/simple_stmts.html > .
Near the end of "The import statement," there is text declaring
"import" as "imprt."
Context:?"from?..subpkg2?imprt?mod" : html character 69441 of 88220, byte
 69454 of 88236

From report at bugs.python.org  Sat Sep  4 00:51:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Sep 2010 22:51:25 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283553924.23.0.945278993936.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283554281.3223.4.camel@localhost.localdomain>


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

> Generally: +1 on making sure examples in the docs are up to date.  If
> someone wants to do the tedious work of making sure that a "make
> doctest" succeeds, I'm all for it, it may involve adding a few (in
> HTML output invisible) testsetup blocks.

I'm not sure that's a good idea. It may add a lot of spurious imports
which only make the examples longer and less readable.

----------

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

From report at bugs.python.org  Sat Sep  4 00:54:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 22:54:29 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283554469.28.0.018992090132.issue9730@psf.upfronthosting.co.za>


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

2) works without changing anything, 3) requires using specific directives IIUC.

----------

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

From report at bugs.python.org  Sat Sep  4 00:57:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:57:17 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283554637.01.0.167836774867.issue9730@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

>> Generally: +1 on making sure examples in the docs are up to date.  If
>> someone wants to do the tedious work of making sure that a "make
>> doctest" succeeds, I'm all for it, it may involve adding a few (in
>> HTML output invisible) testsetup blocks.
> 
> I'm not sure that's a good idea. It may add a lot of spurious imports
> which only make the examples longer and less readable.

That's why I said to use "testsetup" directives -- they are not visible in the HTML/PDF/... output, but used when running the tests.

----------

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

From report at bugs.python.org  Sat Sep  4 00:57:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 03 Sep 2010 22:57:48 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283554668.59.0.333733823367.issue9730@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> 2) works without changing anything, 3) requires using specific directives IIUC.

No.  The doctest extension is what "make doctest" calls.

----------

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

From report at bugs.python.org  Sat Sep  4 01:00:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 03 Sep 2010 23:00:36 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283554836.45.0.632599429741.issue9730@psf.upfronthosting.co.za>


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

Thanks for clearing this misunderstanding of mine.

----------

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

From report at bugs.python.org  Sat Sep  4 01:19:21 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Sep 2010 23:19:21 +0000
Subject: [docs] [issue9767] Failures in json doc examples
In-Reply-To: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>
Message-ID: <1283555961.51.0.163007751306.issue9767@psf.upfronthosting.co.za>


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

Well, anyone who does try that example will see the correct output and not notice the trailing whitespace difference. It will only be an issue if and when automated doc doctests are run repeatedly. Worry about it then. Thanks for the quick response.

----------

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

From report at bugs.python.org  Sat Sep  4 01:53:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Sep 2010 23:53:47 +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: <1283558027.24.0.678070537645.issue9738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About PyErr_Format() and PyUnicode_FromFormat*() encoding: it's not exactly ISO-8859-1... there is a bug => issue #9769.

----------

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

From report at bugs.python.org  Sat Sep  4 02:06:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 04 Sep 2010 00:06:59 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1283558819.57.0.659129999335.issue6916@psf.upfronthosting.co.za>


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


----------
assignee: josiahcarlson -> giampaolo.rodola
stage:  -> patch review
versions:  -Python 3.0, Python 3.1

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

From report at bugs.python.org  Sat Sep  4 17:49:34 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 04 Sep 2010 15:49:34 +0000
Subject: [docs] [issue9747] os.getresgid() documentation mentions "user ids",
	not "group ids"
In-Reply-To: <1283479568.94.0.540639670687.issue9747@psf.upfronthosting.co.za>
Message-ID: <1283615374.87.0.232306379182.issue9747@psf.upfronthosting.co.za>


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

This mistake is also in the docstring, I've attached a path to fix both.

----------
keywords: +patch
nosy: +bbrazil
Added file: http://bugs.python.org/file18748/getresgid_group_not_user.patch

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

From report at bugs.python.org  Sat Sep  4 17:57:08 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 04 Sep 2010 15:57:08 +0000
Subject: [docs] [issue9776] Inconsistent spacing in fcntl.fcntl docstring
In-Reply-To: <1283615828.17.0.964870505124.issue9776@psf.upfronthosting.co.za>
Message-ID: <1283615828.17.0.964870505124.issue9776@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

The spacing in fcntl.fcntl's docstring isn't consistent, the attached patch fixes this.

----------
assignee: docs at python
components: Documentation
files: fcntl_docstring_spacing.patch
keywords: patch
messages: 115582
nosy: bbrazil, docs at python
priority: normal
severity: normal
status: open
title: Inconsistent spacing in fcntl.fcntl docstring
versions: Python 3.2
Added file: http://bugs.python.org/file18749/fcntl_docstring_spacing.patch

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

From report at bugs.python.org  Sat Sep  4 20:14:08 2010
From: report at bugs.python.org (Arnaud Delobelle)
Date: Sat, 04 Sep 2010 18:14:08 +0000
Subject: [docs] [issue9717] operator module - "in place" operators
	documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1283624047.97.0.345207248895.issue9717@psf.upfronthosting.co.za>


Arnaud Delobelle <arnodel at googlemail.com> added the comment:

Terry: I agree that augmented assignement should be described better in the language reference.  I guess that would warrant opening another issue?

However I tend to think that the term "in-place operation" is a good one.

BTW:

- the reference of "(See section Primaries for the syntax definitions for the last three symbols.)" is probably there to point to the definition of what can go on the left side of the augmented assignement symbol (what used to be called an "lvalue")

- "With the exception of assigning to tuples ": this refers to the fact that whereas x, y, z = l is correct syntax, x, y, z += l isn't.

Raymond: I agree that the operator doc would be clearer if better structured.

So I put forward another patch to operator.rst, structuring it more clearly and providing a more detailed introduction to the "In-place operations" section, but not trying to detail the workings of augmented assignement in general.

----------
Added file: http://bugs.python.org/file18752/operator_structured.diff

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

From report at bugs.python.org  Sat Sep  4 20:31:59 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Sep 2010 18:31:59 +0000
Subject: [docs] [issue9717] operator module - "in place" operators
	documentation
In-Reply-To: <1283194174.19.0.42398116416.issue9717@psf.upfronthosting.co.za>
Message-ID: <1283625119.52.0.537123069419.issue9717@psf.upfronthosting.co.za>


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

Since Raymond has grabbed this, I will let him decide on its scope.
I agree with sectioning the operator doc and intended to suggest that.

The term 'in-place operation' is fine when accurate. The term 'in-place operator', which is what you wrote and what I criticized, is not as it is never accurate and has confused and mislead people. For one thing, it leads them to forget that augmented assignment statements are statements that *always* do an assignment. For another, they forget that the operation can only be in-place for mutables. That is my observation based on years of reading c.l.p./python-list. An 'in-place operator' would do an operation in-place without any assighment and would only work for mutables. Python has neither operators nor functions nor syntax with those characteristics.

----------

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

From report at bugs.python.org  Sun Sep  5 09:06:08 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 07:06:08 +0000
Subject: [docs] [issue9767] Failures in json doc examples
In-Reply-To: <1283549572.36.0.344374385965.issue9767@psf.upfronthosting.co.za>
Message-ID: <1283670367.77.0.0539087271816.issue9767@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

FWIW if something is fixed, it should be the json output.  However, I can imagine (without looking at the code) that this would mean a lot of special casing.

----------

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

From report at bugs.python.org  Sun Sep  5 18:47:39 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sun, 05 Sep 2010 16:47:39 +0000
Subject: [docs] [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1283705259.49.0.246416945725.issue9739@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I edited the doc string for math.modf since an indent of 8 spaces is used for the doc string with help(math). An indent of 4 spaces is used with help(math.modf).

I've attached a new patch for just the math module that includes the return type as part of signature line, corrects the width issues, and uses a consistent format for defining the doc strings.

----------
Added file: http://bugs.python.org/file18761/math_docstring.diff

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

From report at bugs.python.org  Sun Sep  5 19:07:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 17:07:36 +0000
Subject: [docs] [issue9747] os.getresgid() documentation mentions "user ids",
	not "group ids"
In-Reply-To: <1283479568.94.0.540639670687.issue9747@psf.upfronthosting.co.za>
Message-ID: <1283706456.78.0.965545409697.issue9747@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r84530.

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

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

From report at bugs.python.org  Sun Sep  5 19:09:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 05 Sep 2010 17:09:27 +0000
Subject: [docs] [issue9776] Inconsistent spacing in fcntl.fcntl docstring
In-Reply-To: <1283615828.17.0.964870505124.issue9776@psf.upfronthosting.co.za>
Message-ID: <1283706567.89.0.0325978378124.issue9776@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r84531.

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

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

From report at bugs.python.org  Mon Sep  6 02:11:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 06 Sep 2010 00:11:23 +0000
Subject: [docs] [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

According to the documentation:
"The fill character can be any character other than ?}? (which signifies the end of the field)."
http://docs.python.org/dev/library/string.html#format-specification-mini-language


However the format() builtin accepts both '{' and '}' characters:

>>> format(42, '}^6')
'}}42}}'

>>> format(42, '{^6')
'{{42{{'


And the string method rejects both characters.

>>> '{:}^6}'.format(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Single '}' encountered in format string

>>> '{:{^6}'.format(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmatched '{' in format

----------
assignee: docs at python
components: Documentation
messages: 115678
nosy: docs at python, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: fill character cannot be '{'
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Sep  6 03:04:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 01:04:46 +0000
Subject: [docs] [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283735085.87.0.231193137415.issue9780@psf.upfronthosting.co.za>


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

Looks more like a behavior bug than a doc bug to me. Does the doc comply with the PEP?

----------
nosy: +eric.araujo, eric.smith

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

From report at bugs.python.org  Mon Sep  6 03:21:30 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 06 Sep 2010 01:21:30 +0000
Subject: [docs] [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283736090.19.0.854974367939.issue9780@psf.upfronthosting.co.za>


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

The PEP 3101 does not prohibit any character for the 'fill' argument.

Another example which just works:

>>> '{:{fill}^6}'.format(42, fill='{')
'{{42{{'

>>> '{:{fill}^6}'.format(42, fill='}')
'}}42}}'


I don't care if '{' and '}' are prohibited when using simple formatting syntax.  This is not a common use case, and there are workarounds (either using format() builtin or the recursive formatting).

A documentation fix could be enough.

----------

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

From report at bugs.python.org  Mon Sep  6 03:57:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 06 Sep 2010 01:57:39 +0000
Subject: [docs] [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283738259.04.0.576124658715.issue9780@psf.upfronthosting.co.za>


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

Thanks for clarifying.

----------

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

From report at bugs.python.org  Mon Sep  6 08:50:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 06 Sep 2010 06:50:17 +0000
Subject: [docs] [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283755817.01.0.757437345656.issue9780@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed docs in r84553.

(That builtin format() supports this is no surprise, and has no influence on the validity in format strings.)

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

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

From report at bugs.python.org  Mon Sep  6 14:41:03 2010
From: report at bugs.python.org (Arialdo Martini)
Date: Mon, 06 Sep 2010 12:41:03 +0000
Subject: [docs] [issue9781] Dead link
In-Reply-To: <1283776862.85.0.667935106717.issue9781@psf.upfronthosting.co.za>
Message-ID: <1283776862.85.0.667935106717.issue9781@psf.upfronthosting.co.za>


New submission from Arialdo Martini <arialdo.martini at gmail.com>:

In the Italian version of the Official  Turorial, the link to  Python Bug Tracker is dead.

----------
assignee: docs at python
components: Documentation
messages: 115698
nosy: Arialdo.Martini, docs at python
priority: normal
severity: normal
status: open
title: Dead link
type: resource usage

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

From report at bugs.python.org  Mon Sep  6 14:42:09 2010
From: report at bugs.python.org (Arialdo Martini)
Date: Mon, 06 Sep 2010 12:42:09 +0000
Subject: [docs] [issue9781] Dead link in Italian Tutorial
In-Reply-To: <1283776862.85.0.667935106717.issue9781@psf.upfronthosting.co.za>
Message-ID: <1283776929.75.0.244069746428.issue9781@psf.upfronthosting.co.za>


Changes by Arialdo Martini <arialdo.martini at gmail.com>:


----------
title: Dead link -> Dead link in Italian Tutorial

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

From report at bugs.python.org  Mon Sep  6 16:03:59 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 06 Sep 2010 14:03:59 +0000
Subject: [docs] [issue9781] Dead link in Italian Tutorial
In-Reply-To: <1283776862.85.0.667935106717.issue9781@psf.upfronthosting.co.za>
Message-ID: <1283781839.67.0.538735971131.issue9781@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We don't maintain an Italian version of the tutorial. You'll have to contact its maintainer.

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

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

From report at bugs.python.org  Mon Sep  6 17:09:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 06 Sep 2010 15:09:03 +0000
Subject: [docs] [issue9780] fill character cannot be '{'
In-Reply-To: <1283731883.01.0.461973913755.issue9780@psf.upfronthosting.co.za>
Message-ID: <1283785742.97.0.849974007776.issue9780@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Sorry to respond late.

The reason for this is that the parsing of the string (as delimited by "{" and "}") happens before the results are then interpreted as format specifiers. There's no way around it, short of the parser understanding every object's formatting language, which is of course not possible. It could be special cased for string, int, and float format specifiers, but that doesn't make much sense.

I think the doc change is good.

----------

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

From mark at qtrac.eu  Tue Sep  7 09:02:21 2010
From: mark at qtrac.eu (Mark Summerfield)
Date: Tue, 7 Sep 2010 08:02:21 +0100
Subject: [docs] What's New in Python 3.2: missing entry "argparse module"
Message-ID: <20100907080221.14603380@dino>

Hi,

The online Python 3.2a2 docs list the argparse module in the global
module index but it isn't mentioned in the What's New section's New,
Improved, and Deprecated Modules section.

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
        "Advanced Qt Programming" - ISBN 0321635906
            http://www.qtrac.eu/aqpbook.html

From merwok at netwok.org  Tue Sep  7 13:56:04 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Tue, 07 Sep 2010 13:56:04 +0200
Subject: [docs] What's New in Python 3.2: missing entry "argparse module"
In-Reply-To: <20100907080221.14603380@dino>
References: <20100907080221.14603380@dino>
Message-ID: <4C862854.1000204@netwok.org>

Hello

Thanks for the report. There is now a stub that will certainly be filled
shortly.

Regards


From report at bugs.python.org  Tue Sep  7 17:27:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Sep 2010 15:27:02 +0000
Subject: [docs] [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1283873222.65.0.0694267409761.issue9730@psf.upfronthosting.co.za>


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

I hope the trivial 2-byte fix does not get lost in the general issue.

----------

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

From report at bugs.python.org  Tue Sep  7 22:14:25 2010
From: report at bugs.python.org (Dag Odenhall)
Date: Tue, 07 Sep 2010 20:14:25 +0000
Subject: [docs] [issue9793] Typo fix in What's New for 3.2: dynmaic ->
	dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>


New submission from Dag Odenhall <dag.odenhall at gmail.com>:

Spotted a typo reading the What's New for 3.2a2 and thought I should give contributing a fix a try. Please excuse me if I failed to follow some procedure; this is my first contribution to the core source tree.

----------
assignee: docs at python
components: Documentation
files: dynmaic.patch
keywords: patch
messages: 115800
nosy: dag.odenhall, docs at python
priority: normal
severity: normal
status: open
title: Typo fix in What's New for 3.2: dynmaic -> dynamic
versions: Python 3.2
Added file: http://bugs.python.org/file18786/dynmaic.patch

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

From report at bugs.python.org  Tue Sep  7 23:41:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 21:41:51 +0000
Subject: [docs] [issue9793] Typo fix in What's New for 3.2: dynmaic ->
	dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283895711.39.0.12550690048.issue9793@psf.upfronthosting.co.za>


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

Fixed in r84602, thanks.

Note that for such small things, you don?t have to make a patch, it?s actually faster to just open the file at the right line and fix it than download and apply a patch. You can also send an email to docs at python.org instead of opening a bug, whatever is easier for you.

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

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

From report at bugs.python.org  Wed Sep  8 00:41:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 07 Sep 2010 22:41:07 +0000
Subject: [docs] [issue9793] Typo fix in What's New for 3.2: dynmaic ->
	dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283899267.67.0.618598506477.issue9793@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep  8 01:15:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Sep 2010 23:15:13 +0000
Subject: [docs] [issue9608] Re-phrase best way of using exceptions in
	doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1283901312.89.0.891980412233.issue9608@psf.upfronthosting.co.za>


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

Here is a more extensive rewrite that I think makes things clearer and (I hope) makes the text read better.  I also updated the preceding section per the confusion expressed in issue 8518.

Note that this patch is somewhat Python3 specific, since it assumes that all non-BaseException exceptions inherit from Exception.  If someone wants to backport it to 2.7 a paragraph or footnote should be added about that problem.

Opinions welcome.

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file18791/doanddont-except.patch

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

From report at bugs.python.org  Wed Sep  8 02:04:22 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Sep 2010 00:04:22 +0000
Subject: [docs] [issue9793] Typo fix in What's New for 3.2: dynmaic ->
	dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283904261.79.0.681445255407.issue9793@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The sort of editing should be done *much* later.
I expect to be updating the file every few days
and occasionally running the out through a spelling
and grammar checker.  Right now, it's a work in progress
that doesn't benefit from micro-edits.

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

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

From report at bugs.python.org  Wed Sep  8 02:07:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:07:00 +0000
Subject: [docs] [issue9793] Typo fix in What's New for 3.2: dynmaic ->
	dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1283904420.58.0.299356349848.issue9793@psf.upfronthosting.co.za>


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

Sorry about that. I wanted to give a quick response to Dag, so I grepped for other instances of the same typo and committed; it was hasty.

----------

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

From report at bugs.python.org  Wed Sep  8 02:49:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 00:49:56 +0000
Subject: [docs] [issue9608] Re-phrase best way of using exceptions in
	doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1283906996.33.0.0622228061386.issue9608@psf.upfronthosting.co.za>


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

Your rewrite makes the text much clearer in my opinion. Here are some nits for you to grind, cheers :)

1) I?d say ?using a bare ``except:``? and maybe add an index entry for ?bare except? referring to that section, to make indexing and maybe googling find this.

2) To make the bad examples clearer, I would remove the second inline comment (?will be changed as soon as we run it?). The wording is confusing: Does that mean the code will be changed by Python at runtime? The text after this code example is clear enough, this comment doesn?t help.

3) ?except catches all errors, including GeneratorExit which is not even an error?: Isn?t this confusing for beginners?

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

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

From report at bugs.python.org  Wed Sep  8 03:16:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Sep 2010 01:16:42 +0000
Subject: [docs] [issue9608] Re-phrase best way of using exceptions in
	doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1283908602.26.0.881794173078.issue9608@psf.upfronthosting.co.za>


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

(1) and (2) are good ideas.  For (3), would it be clear enough if it read "``except:`` catches *all* exceptions, [...] and GeneratorExit (which is not an error and should not normally be caught by user code)."

----------

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

From report at bugs.python.org  Wed Sep  8 03:58:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 08 Sep 2010 01:58:31 +0000
Subject: [docs] [issue9608] Re-phrase best way of using exceptions in
	doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1283911111.9.0.341831628223.issue9608@psf.upfronthosting.co.za>


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

It would.

----------

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

From report at bugs.python.org  Wed Sep  8 15:02:57 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 08 Sep 2010 13:02:57 +0000
Subject: [docs] [issue5416] str.replace does strange things when given a
	negative	count
In-Reply-To: <1236163931.77.0.818123555808.issue5416@psf.upfronthosting.co.za>
Message-ID: <1283950977.36.0.711985058813.issue5416@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Reverted the changes in r84626 (release27-maint), r84629(py3k), r84630 (release31-maint).

- Minor doc clarification included wherein maxreplace is the argument instead of maxsplit in py27.

- Also, did not bother to remove -1 in maxreplace. It is used as sentinel value for an optional argument. As it is not explicitly documented, the negative value for arg should not be relied upon.

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

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

From report at bugs.python.org  Wed Sep  8 21:30:31 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Wed, 08 Sep 2010 19:30:31 +0000
Subject: [docs] [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>


New submission from Matthew Woodcraft <matthew at woodcraft.me.uk>:

In CPython, the builtin max() and min() have the property that if there are items with equal keys, the first item is returned. From a quick look at their source, I think this is true for Jython and IronPython too.

I propose making this a documented guarantee.

On Python-dev, Raymond Hettinger said:
<<
That seems like a reasonable request. This behavior has been around for a very long time is unlikely to change. Elsewhere, we've made efforts to document sort stability (i.e. sorted(), heapq.nlargest(), heapq.nsmallest, merge(), etc).
>>
(<http://mail.python.org/pipermail/python-dev/2010-September/103543.html>)

I'm attaching a patch with a concrete suggestion for a change to
functions.rst, modelled on the documentation of heapq.nlargest().

----------
assignee: docs at python
components: Documentation
files: maxmin.patch
keywords: patch
messages: 115892
nosy: docs at python, mattheww
priority: normal
severity: normal
status: open
title: Document 'stability' of builtin min() and max()
type: feature request
Added file: http://bugs.python.org/file18802/maxmin.patch

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

From report at bugs.python.org  Wed Sep  8 22:52:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Sep 2010 20:52:10 +0000
Subject: [docs] [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1283979130.47.0.636947330453.issue9802@psf.upfronthosting.co.za>


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

Thanks for the patch!

Comments:

(1) Shouldn't 'reverse=True' be omitted in the second doc addition?

(2) I'd also suggest adding a brief comment about what this means for distinct, but equal, objects;  otherwise it's not really obvious what the point of the doc addition is.

(3) As a matter of clarity, perhaps replace "this is" with "max(iterable, key=key) is", and similarly for min.

As an aside, I still like Jeffrey Yasskin's suggestion on the python-dev mailing list that the sensible definition for max would maintain the invariant that max(iterable) be equivalent to sorted(iterable)[-1];  see Alexander Stepanov's writings in e.g., http://www.cs.rpi.edu/~musser/gsd/notes-on-programming-2006-10-13.pdf for more.  But that's (a) another issue, and (b) perhaps not a significant enough benefit to be worth changing Python's semantics for.

----------
nosy: +jyasskin, mark.dickinson, rhettinger

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

From report at bugs.python.org  Thu Sep  9 00:06:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Sep 2010 22:06:45 +0000
Subject: [docs] [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1283983605.34.0.735105592879.issue9802@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


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

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

From report at bugs.python.org  Thu Sep  9 00:08:38 2010
From: report at bugs.python.org (Ken Basye)
Date: Wed, 08 Sep 2010 22:08:38 +0000
Subject: [docs] [issue9805] Documentation on old-style formatting of dicts
	is overly	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>


New submission from Ken Basye <ken.basye at gmail.com>:

>From http://docs.python.org/library/stdtypes.html#string-formatting-operations :

"When the right argument is a dictionary (or other mapping type), then the formats in the string must include a parenthesised mapping key into that dictionary inserted immediately after the '%' character."  
(with emphasis on 'must' in the HTML, BTW).  

This isn't correct:  "%s" % dict() is a perfectly legal expression with a dictionary as the right argument and no mapping key in the formats.  Indeed, if the current doc were correct, there would apparently be no way to format an empty dictionary.

How about this one-word fix:

"When the right argument is a dictionary (or other mapping type), then the formats in the string may include ..." and so on into the next sentence, and no emphasis on 'may'.






P.S. Not sure about the Type of this issue, and it's present in both 2.7 and current 3.X doc.

----------
assignee: docs at python
components: Documentation
messages: 115907
nosy: Ken.Basye, docs at python
priority: normal
severity: normal
status: open
title: Documentation on old-style formatting of dicts is overly restrictive
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep  9 00:29:00 2010
From: report at bugs.python.org (Ken Basye)
Date: Wed, 08 Sep 2010 22:29:00 +0000
Subject: [docs] [issue9805] Documentation on old-style formatting of dicts
	is overly	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283984940.33.0.465087277404.issue9805@psf.upfronthosting.co.za>


Ken Basye <ken.basye at gmail.com> added the comment:

If someone's going to fix this, perhaps they might consider also adding the following clarification sentence after 'The mapping key selects the value to be formatted from the mapping.'  

The mapping key is interpreted as a string; a key error is raised if the dictionary does not have a matching string key. 

I don't think it's worth adding it, but consider this example:
>>> d = {2:2, '2':'two'}
>>> '%(2)s' % d
'two'

----------

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

From report at bugs.python.org  Thu Sep  9 00:56:41 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 08 Sep 2010 22:56:41 +0000
Subject: [docs] [issue9805] Documentation on old-style formatting of dicts
	is overly	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283986601.09.0.383675303584.issue9805@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Sep  9 04:15:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Sep 2010 02:15:41 +0000
Subject: [docs] [issue9805] Documentation on old-style formatting of dicts
	is overly	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283998538.57.0.159508718882.issue9805@psf.upfronthosting.co.za>


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

Python 3.2a2+ (py3k:84613, Sep  7 2010, 19:17:31) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "%s %(abc)s" % dict(abc=2)
"{'abc': 2} 2"

I did not expect this result.  Looks like a bug to me.

>>> "%s %(abc)s" % (dict(abc=2), 4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: format requires a mapping
>>> "%d %(abc)s" % dict(abc=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: %d format: a number is required, not dict
>>> "%s %s %(abc)s" % dict(abc=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: not enough arguments for format string

So, the only case which "works" (but is arguably buggy) is a single %s mixed in with dict lookups.  'may' does not adequately describe this reality.  'must' is much closer.  If it weren't a backward incompatible change I'd suggest making a single dict (i.e.: non-tuple) argument to % with non-dict-lookup patterns an error.  As it is, we'll just live with the quirk, and probably with the bug as well.

I'm not sure it is worth explaining all these quirks in the main docs.  Perhaps in a footnote?

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Sep  9 04:32:40 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 09 Sep 2010 02:32:40 +0000
Subject: [docs] [issue9805] Documentation on old-style formatting of dicts
	is overly	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1283999560.76.0.282253799723.issue9805@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think this might be a dupe of issue 1467929.

----------

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

From report at bugs.python.org  Thu Sep  9 14:47:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Sep 2010 12:47:27 +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: <1284036447.49.0.742048160117.issue9738@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

#6543 changed the encoding of the filename argument of PyRun_SimpleFileExFlags() (and all functions based on PyRun_SimpleFileExFlags) and c_filename attribute of the compiler (private) structure in Python 3.1.3: use utf-8 in strict mode instead of filesystem encoding with surrogateescape.

----------

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

From report at bugs.python.org  Thu Sep  9 16:23:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Sep 2010 14:23:34 +0000
Subject: [docs] [issue9811] strftime strips '%' from unknown format codes on
	OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284042214.18.0.386728866619.issue9811@psf.upfronthosting.co.za>


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

Python's strftime is a thin wrapper around the system strftime.  This means, for example, that a slightly different set of % codes is supported on windows vs linux.  So, from Python's point of view this is at *most* a doc bug.

That said, I think there have been some rumblings about writing our own strftime, but I don't know if anyone is serious about it.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +belopolsky, docs at python, r.david.murray
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Sep  9 16:33:11 2010
From: report at bugs.python.org (Ken Basye)
Date: Thu, 09 Sep 2010 14:33:11 +0000
Subject: [docs] [issue9805] Documentation on old-style formatting of dicts
	is overly	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1284042791.11.0.984204676726.issue9805@psf.upfronthosting.co.za>


Ken Basye <ken.basye at gmail.com> added the comment:

I think Eric is correct; it's a dupe.  And I was wrong about not otherwise being able to format an empty dictionary - "%s" % (d,) will always work and is arguably the right thing to do anyway.

----------
type: behavior -> 
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Sep  9 17:29:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Sep 2010 15:29:46 +0000
Subject: [docs] [issue9805] Documentation on old-style formatting of dicts
	is overly	restrictive
In-Reply-To: <1283983718.4.0.736400654813.issue9805@psf.upfronthosting.co.za>
Message-ID: <1284046186.48.0.590846006303.issue9805@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> %-formatting and dicts

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

From report at bugs.python.org  Thu Sep  9 17:47:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 09 Sep 2010 15:47:49 +0000
Subject: [docs] [issue9811] strftime strips '%' from unknown format codes on
	OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284047269.19.0.615941948435.issue9811@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I think there have been some rumblings about writing our own strftime

Yes, see issue #3173.

Another related issue is #9650 which discusses how to properly document strftime codes.

----------

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

From report at bugs.python.org  Thu Sep  9 21:05:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:05:54 +0000
Subject: [docs] [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1284059154.32.0.401401312418.issue8556@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep  9 21:13:34 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:13:34 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1284059614.31.0.900684763864.issue8913@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep  9 21:15:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 09 Sep 2010 19:15:15 +0000
Subject: [docs] [issue9195] Link in docs from "String Formatting Operations"
	to	"Template Strings"
In-Reply-To: <1278571007.55.0.304215462236.issue9195@psf.upfronthosting.co.za>
Message-ID: <1284059715.19.0.756375622147.issue9195@psf.upfronthosting.co.za>


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


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

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

From cristian.ciupitu at yahoo.com  Sun Sep  5 17:21:53 2010
From: cristian.ciupitu at yahoo.com (Cristian Ciupitu)
Date: Sun, 5 Sep 2010 08:21:53 -0700 (PDT)
Subject: [docs] tutorial: "The Module Search Path" section is ambiguous
Message-ID: <680236.5599.qm@web110805.mail.gq1.yahoo.com>

"The Module Search Path"[1] section of the tutorial starts with the
following text:

  When a module named spam is imported, the interpreter searches for a
  file named spam.py in the current directory, and then in the list of
  directories specified by the environment variable PYTHONPATH.

It mentions the "current directory" in the first paragraph, although
it's not necessarily about the current working directory just as the
second paragraph clarifies things. I think that the text should be
rephrased to make it less ambiguous. Maybe mention right from the
beginning what's really going on?

Kind regards,
Cristian

[1] http://docs.python.org/tutorial/modules.html#the-module-search-path


      

From ericr789 at gmail.com  Mon Sep  6 08:38:03 2010
From: ericr789 at gmail.com (Eric Redekopp)
Date: Mon, 6 Sep 2010 00:38:03 -0600
Subject: [docs] Quotation Mark Syntax Error?
Message-ID: <DA614DB4-C8A4-4222-9986-17FF1751745A@gmail.com>

I just downloaded python onto my mac and it's trying to tell me that the second quotation mark after I tell it to print something is a syntax error. For example:

print "I am sending an email" 

And that second quote will be called a syntax error. But also, if you don't put the quote it doesn't work either. What's up with that? 


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

From jddcef at gmail.com  Wed Sep  8 10:02:55 2010
From: jddcef at gmail.com (David e Freitas)
Date: Wed, 8 Sep 2010 10:02:55 +0200
Subject: [docs] Search page not showing progress
Message-ID: <AANLkTikbO6BoRrGT-9UZqEn=hfBTQg2iQy9ZnN+eWkvi@mail.gmail.com>

Hi there,

When I do a search on the docs site, e.g:
http://docs.python.org/search.html?q=dict

The results take very long to return, at which point the page just looks
empty, i.e. there is no progress indicator or anything.
i.e. the *<div id="search-results">...</div>* section is not shown until
some data has started to be returned.

The progress indicator should show up before any data has started to return.

The results aren't worth waiting for though, perhaps provide the google site
search function as the main search function rather?

Good work to all involved!

Cheers,


David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100908/1e04722a/attachment.html>

From rkasl at rx.umaryland.edu  Thu Sep  9 02:45:22 2010
From: rkasl at rx.umaryland.edu (Ronald Kasl)
Date: Wed, 08 Sep 2010 20:45:22 -0400
Subject: [docs] python2.7 uninstall
Message-ID: <4C882E22.5090908@rx.umaryland.edu>

Hello, how do I get remove python from Linux Ubuntu 10.04? .. it was
installed ./config , then make install  .. make unistall dos not work --
please help , if you can  ... it would be good to have something in the
doc about how to uninstall python .

Thank you,
rk

From mpguarda-one at yahoo.ca  Fri Sep 10 05:47:01 2010
From: mpguarda-one at yahoo.ca (mpguarda-one at yahoo.ca)
Date: Thu, 9 Sep 2010 20:47:01 -0700 (PDT)
Subject: [docs] Tutorials vs. Windows  OS
Message-ID: <468975.41222.qm@web88108.mail.re2.yahoo.com>

Hi,

I think that people who work with Windows deserve to be noticed. 

I am going through tutorials, and so far, it seems to be impossible to follow 
them up on a Windows operating system. I work with computers since 1967 
(perforated tape input), worked such things as  Monte Carlo simulation of hot 
electron behaviour and co-wrote a paper on Mars landing, but did not have an 
opportunity to learn what Unix Shell is. Am I doomed, or somebody can tell me 
where I can find tutorials in which it will is explained where to find an 
interpreter I have downloaded a single line one), how to install an editor, and 
how I can run Python code in Windows 7 or Windows Server 2008 R2?
 Best regards,

Michael Polubinski
905-580-0855
________________________________
Ce courrier ?lectronique et les fichiers qui y sont annex?s peuvent renfermer 
des renseignements privil?gi?s et confidentiels ? l'intention exclusive du 
destinataire. Si vous n'?tes pas le destinataire, vous n'?tes pas autoris?(e) ? 
utiliser, ? copier ou ? divulguer ? un tiers le contenu de ce courrier 
?lectronique ni des fichiers joints. Si vous avez re?u ce courrier ?lectronique 
par erreur, veuillez en aviser l'exp?diteur imm?diatement par courrier 
?lectronique et d?truire ce message ainsi que les fichiers en annexe.

This electronic mail message, and any attachments, may contain 
privileged/confidential information, intended only for the use of the addressee. 
If you are not the addressee, you may not use, copy or disclose to a third party 
the content of this message or its attachments. If you have received this 
message by mistake, please notify us immediately by e-mail and destroy this 
message, along with all attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100909/ac97adae/attachment.html>

From report at bugs.python.org  Sat Sep 11 02:20:13 2010
From: report at bugs.python.org (Chris Leary)
Date: Sat, 11 Sep 2010 00:20:13 +0000
Subject: [docs] [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>


New submission from Chris Leary <christopher.leary at cornell.edu>:

I tried to clear this section up a bit in light of the confusion here: http://stackoverflow.com/q/3687864/3594

Not sure if it applies to 3k trunk.

First documentation patch, be sure to lmk what I'm doing wrong! :-)

----------
assignee: docs at python
components: Documentation
files: pyloggingdoc.diff
keywords: patch
messages: 116067
nosy: cdleary, docs at python
priority: normal
severity: normal
status: open
title: Clarify LogRecord documentation
versions: Python 2.7
Added file: http://bugs.python.org/file18842/pyloggingdoc.diff

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

From report at bugs.python.org  Sat Sep 11 02:39:06 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 11 Sep 2010 00:39:06 +0000
Subject: [docs] [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284165545.97.0.186514019245.issue9827@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep 11 04:43:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Sep 2010 02:43:58 +0000
Subject: [docs] [issue9608] Re-phrase best way of using exceptions in
	doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1284173038.68.0.776881510127.issue9608@psf.upfronthosting.co.za>


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

Here is another edit pass, incorporating ?ric's suggestions and adding some additional tweaks.  In particular, I eliminated the anti-pattern of catching (IOError, OSError) in one of the earlier examples in favor of the correct EnvironmentError, and also improved the error message generated in that case :)

----------
Added file: http://bugs.python.org/file18843/doanddont-except.patch

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

From report at bugs.python.org  Sat Sep 11 12:27:30 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 11 Sep 2010 10:27:30 +0000
Subject: [docs] [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284200849.87.0.404993203557.issue9827@psf.upfronthosting.co.za>


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

Chris, thanks for the patch. I applied it to release27-maint and py3k branches with only minor changes (listed attributes in alphabetical order, and expanded on getMessage a bit).

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

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

From report at bugs.python.org  Sat Sep 11 20:55:12 2010
From: report at bugs.python.org (Chris Leary)
Date: Sat, 11 Sep 2010 18:55:12 +0000
Subject: [docs] [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284231312.09.0.316996460398.issue9827@psf.upfronthosting.co.za>


Chris Leary <christopher.leary at cornell.edu> added the comment:

Okay, neat! I put them in that order so that they would correspond to the parameters to ``LogRecord.__init__`` -- do we usually do alphabetical instead?

----------

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

From report at bugs.python.org  Sat Sep 11 20:59:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 11 Sep 2010 18:59:12 +0000
Subject: [docs] [issue9608] Re-phrase best way of using exceptions in
	doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1284231552.43.0.45581207265.issue9608@psf.upfronthosting.co.za>


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

Committed in r84719 and r84720, backported to 2.7 in r84721 with the addition of a sentence admitting that sometimes you need a bare except to catch third-party exceptions that don't inherit from Exception.

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

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

From report at bugs.python.org  Sat Sep 11 21:11:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 19:11:22 +0000
Subject: [docs] [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284232282.73.0.791761327806.issue9827@psf.upfronthosting.co.za>


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

Vinay, would you mind adding references to the commits (in the form ?rNNN?) so that roundup makes a link?  Thanks in advance.  Also, is this not fixed in 3.1?

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

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

From report at bugs.python.org  Sat Sep 11 21:14:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 19:14:35 +0000
Subject: [docs] [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1284232475.41.0.772298602375.issue9746@psf.upfronthosting.co.za>


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

For the person wanting to make a patch: Beware that the abstract collections.Sequence.index method does not support the start and stop arguments, even though concrete methods may (list.index, tuple.index and str.index for example).

----------
keywords: +easy
nosy: +eric.araujo

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

From report at bugs.python.org  Sun Sep 12 01:26:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 11 Sep 2010 23:26:31 +0000
Subject: [docs] [issue9811] strftime strips '%' from unknown format codes on
	OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284247590.89.0.0602725713943.issue9811@psf.upfronthosting.co.za>


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

I think supporting different specifiers is one thing, dropping the % character is another.  This is how I understand the bug report.

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

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

From report at bugs.python.org  Sun Sep 12 02:00:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:00:57 +0000
Subject: [docs] [issue9728] Docs point to FAQ Section 3,
	but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284249656.85.0.739403994866.issue9728@psf.upfronthosting.co.za>


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

I tried to find the old FAQ in the Debian package for 2.5 but failed.  It looks like this require a fair bit of version control exploration.

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

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

From report at bugs.python.org  Sun Sep 12 02:27:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:27:34 +0000
Subject: [docs] [issue9608] Re-phrase best way of using exceptions in
	doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1284251253.97.0.782830742589.issue9608@psf.upfronthosting.co.za>


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

Nice, thanks!

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

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

From report at bugs.python.org  Sun Sep 12 02:28:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 00:28:01 +0000
Subject: [docs] [issue9608] Re-phrase best way of using exceptions in
	doanddont.rst
In-Reply-To: <1281875025.64.0.398474348151.issue9608@psf.upfronthosting.co.za>
Message-ID: <1284251281.09.0.441349386507.issue9608@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep 12 02:54:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 12 Sep 2010 00:54:59 +0000
Subject: [docs] [issue9811] strftime strips '%' from unknown format codes on
	OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284252898.91.0.896417865952.issue9811@psf.upfronthosting.co.za>


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

But if it is a bug, it is a bug in OS/X, not in Python.  Python could potentially fix it for python programs by providing our own strftime, but until someone does that the best we can do is a doc mention of this platform quirk.

----------

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

From report at bugs.python.org  Sun Sep 12 03:04:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 01:04:10 +0000
Subject: [docs] [issue9811] strftime strips '%' from unknown format codes on
	OS X
In-Reply-To: <1284026345.38.0.190320909092.issue9811@psf.upfronthosting.co.za>
Message-ID: <1284253449.87.0.441068892156.issue9811@psf.upfronthosting.co.za>


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

Ah, I understand your first reply now.  Thanks.  Agreed on all your points.

----------

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

From report at bugs.python.org  Sun Sep 12 13:24:03 2010
From: report at bugs.python.org (Marien Zwart)
Date: Sun, 12 Sep 2010 11:24:03 +0000
Subject: [docs] [issue8652] Minor improvements to the "Handling Exceptions"
	part of	the tutorial
In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>
Message-ID: <1284290643.1.0.683496424344.issue8652@psf.upfronthosting.co.za>


Marien Zwart <m_zwart at 123mail.org> added the comment:

Sorry for forgetting about this for so long.

The attached patch makes the following changes:

Removes the two instances I noticed of treating exception instances as sequences. This no longer works in python 3 and is not very useful in python 2, so best avoided.

Adds a warning explaining ``except FooException, BarException:`` does not do what you might think. I think this is a good warning to have (because you *can* omit those parens in many other places) and it mentions the pre-python 2.6 syntax for "as" by side effect.

There are two things I'm not entirely happy about:

I initially wrote ``print "I/O error({0.errno}): {0.strerror}".format(e)``, but then noticed this string formatting trick is not mentioned in the previous chapter of the tutorial. Dict access (``"{0[foo]}".format(d)``) is, but attribute access is not. Is this worth adding to that chapter, so it can be used here?

Binding an exception instance to a variable (using "as") is explained near the bottom of the section on catching exceptions, well before it is used. Perhaps this could do with a bit of reordering? I felt it better to keep my initial patch more minimal though.

Comments? :)

----------
keywords: +patch
Added file: http://bugs.python.org/file18857/errors.patch

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

From report at bugs.python.org  Sun Sep 12 13:48:02 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Sep 2010 11:48:02 +0000
Subject: [docs] [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284292082.71.0.88418111397.issue9827@psf.upfronthosting.co.za>


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

@Chris: I just thought that as the list was so long, alphabetic might be easier for people when they remember the attribute name but don't remember exactly what it is.

@Eric: Fair comment, I usually do but sometimes I forget. I have now also updated release31-maint, see r84732.

----------

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

From report at bugs.python.org  Sun Sep 12 13:49:17 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Sep 2010 11:49:17 +0000
Subject: [docs] [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284292157.9.0.541856627489.issue9827@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

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

From report at bugs.python.org  Sun Sep 12 13:51:42 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Sep 2010 11:51:42 +0000
Subject: [docs] [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284292302.33.0.517000844748.issue9827@psf.upfronthosting.co.za>


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

@Chris: I just thought that as the list was so long, alphabetic might be easier for people when they remember the attribute name but don't remember exactly what it is.

@Eric: Fair comment, I usually do but sometimes I forget. I have now also updated release31-maint, see r84733.

----------

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

From report at bugs.python.org  Sun Sep 12 14:44:30 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Sun, 12 Sep 2010 12:44:30 +0000
Subject: [docs] [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1284295469.83.0.35749936124.issue9802@psf.upfronthosting.co.za>


Matthew Woodcraft <matthew at woodcraft.me.uk> added the comment:

> (1) Shouldn't 'reverse=True' be omitted in the second doc
> addition?

Yes, of course, sorry.

> (2) I'd also suggest adding a brief comment about what this
> means for distinct, but equal, objects; otherwise it's not
> really obvious what the point of the doc addition is.

> (3) As a matter of clarity, perhaps replace "this is" with
> "max(iterable, key=key) is", and similarly for min.

I've attached a new patch incorporating these suggestions.

----------
Added file: http://bugs.python.org/file18858/functions.rst.patch

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

From report at bugs.python.org  Sun Sep 12 14:52:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 12 Sep 2010 12:52:39 +0000
Subject: [docs] [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1284295959.07.0.532242446739.issue9802@psf.upfronthosting.co.za>


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

> As an aside, I still like Jeffrey Yasskin's suggestion on the
> python-dev mailing list that the sensible definition for max would
> maintain the invariant that max(iterable) be equivalent to
> sorted(iterable)[-1]

What's interesting is the practical consequence that:

x, y = min(x, y), max(x, y)

cannot give you twice the same object.

Of course, there are subtle implications of how it will be implemented (especially with objects which have a partial order relationship to each other). Since max() is supposed to work on any iterator, we probably don't want to build an intermediate sequence and fetch elements in reverse order; instead perhaps use (not Py_LT) instead of Py_GT.

----------
nosy: +pitrou
versions: +Python 3.2

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

From report at bugs.python.org  Sun Sep 12 16:02:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 12 Sep 2010 14:02:33 +0000
Subject: [docs] [issue9793] Typo fix in What's New for 3.2: dynmaic ->
	dynamic
In-Reply-To: <1283890465.04.0.275401316638.issue9793@psf.upfronthosting.co.za>
Message-ID: <1284300153.07.0.722655752077.issue9793@psf.upfronthosting.co.za>


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

Dag: thanks again for the patch. You did everything correctly; Eric's remarks were just in case you plan to submit contributions in an ongoing manner.

Raymond: that it makes users go through the hoops of getting a tracker account, doing a checkout and creating a patch is an indication that spell-editing should *not* be postponed until much later. Some people are very sensitive to typos (I know I am, for German), so we will continue to get reports about that whenever we release stuff with typos. If you can, it would be good if you could do a spell-check before every alpha/beta release (if you can't, we just have to wait for the users to tell us).

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

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

From report at bugs.python.org  Mon Sep 13 01:11:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 12 Sep 2010 23:11:13 +0000
Subject: [docs] [issue9827] Clarify LogRecord documentation
In-Reply-To: <1284164412.99.0.558219134609.issue9827@psf.upfronthosting.co.za>
Message-ID: <1284333073.44.0.465616836982.issue9827@psf.upfronthosting.co.za>


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

Thanks!

----------
stage:  -> committed/rejected

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

From report at bugs.python.org  Mon Sep 13 02:05:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 00:05:24 +0000
Subject: [docs] [issue9842] Document ... used in recursive repr of containers
In-Reply-To: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>
Message-ID: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>


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

Built-in containers like dict use an ellipsis to represent a recursive item.  In the symbols index, ?...? only links to the secondary prompt; I think it should also link to a paragraph explaining the display of recursive containers.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 116256
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Document ... used in recursive repr of containers
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Sep 13 02:19:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 13 Sep 2010 00:19:56 +0000
Subject: [docs] [issue901727] extra_path kwarg to setup() undocumented
Message-ID: <1284337196.1.0.770240616927.issue901727@psf.upfronthosting.co.za>


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

This strict freeze policy has been decided by Tarek.  The less work there is on distutils? side, the less synchronization we?ll have to do in distutils2.  We do fix doc bugs, we can also fix markup or add links, but that?s it.  Improving docs is for distutils2.

Note that at first I wanted to improve distutils docs even though the code was frozen, but I now agree with Tarek that it would take up a lot of time that is better spent in distutils2.  (Regarding the options parameter, a Montreal-Python contributor added a test for it and a TODO note about lack of documentation.  See, things get better one step at a time :)

I hope this answers your question without sounding too dictatorial.  I understand your viewpoint but ultimately agree with the freeze.

----------

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

From report at bugs.python.org  Mon Sep 13 02:55:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Sep 2010 00:55:43 +0000
Subject: [docs] [issue9842] Document ... used in recursive repr of containers
In-Reply-To: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>
Message-ID: <1284339343.24.0.957047542067.issue9842@psf.upfronthosting.co.za>


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

... is also the Ellipsis object, and it is probably even more important that the index cross reference that usage :)

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

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

From report at bugs.python.org  Mon Sep 13 03:22:05 2010
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 13 Sep 2010 01:22:05 +0000
Subject: [docs] [issue9843] imp documentation redundancy with acquire_lock
	and	release_lock
In-Reply-To: <1284340925.23.0.318731794312.issue9843@psf.upfronthosting.co.za>
Message-ID: <1284340925.23.0.318731794312.issue9843@psf.upfronthosting.co.za>


New submission from Demur Rumed <junkmute at hotmail.com>:

http://docs.python.org/dev/library/imp.html

acquire_lock and release_lock are listed twice. The first iteration of acquire_lock repeats "On platforms without threads, this function does nothing." twice and advises release, while the latter does not

----------
assignee: docs at python
components: Documentation
messages: 116267
nosy: docs at python, serprex
priority: normal
severity: normal
status: open
title: imp documentation redundancy with acquire_lock and release_lock

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

From report at bugs.python.org  Mon Sep 13 03:26:59 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 13 Sep 2010 01:26:59 +0000
Subject: [docs] [issue9843] imp documentation redundancy with acquire_lock
	and	release_lock
In-Reply-To: <1284340925.23.0.318731794312.issue9843@psf.upfronthosting.co.za>
Message-ID: <1284341219.69.0.147508574024.issue9843@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r84754

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

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

From report at bugs.python.org  Mon Sep 13 03:31:41 2010
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 13 Sep 2010 01:31:41 +0000
Subject: [docs] [issue9843] imp documentation redundancy with acquire_lock
	and	release_lock
In-Reply-To: <1284340925.23.0.318731794312.issue9843@psf.upfronthosting.co.za>
Message-ID: <1284341501.74.0.17824702833.issue9843@psf.upfronthosting.co.za>


Demur Rumed <junkmute at hotmail.com> added the comment:

That doesn't appear to remove the repetition of their listing. Something I failed to mention: The duplication occurs after imp.reload

----------

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

From report at bugs.python.org  Mon Sep 13 19:03:25 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Sep 2010 17:03:25 +0000
Subject: [docs] [issue1397474] timeit execution enviroment
Message-ID: <1284397405.9.0.706913933532.issue1397474@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep 13 19:23:52 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 13 Sep 2010 17:23:52 +0000
Subject: [docs] [issue1397474] timeit execution enviroment
Message-ID: <1284398631.92.0.455482343294.issue1397474@psf.upfronthosting.co.za>


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

Terry,

I'm attaching a patch for 2.7, however it's more proof-of-concept than final, because I have a few comments. The patch generally implements your documentation suggestion without the `import *` warning and without adding the final example. The latter for a couple of reasons:

1) My tests show that passing the callable instead of the string 'test()' actually takes longer to run.

2) When the callable is passed, the setup of importing 'test' from '__main__' is necessary, because the timed code doesn't have to lookup the 'test' symbol. If you want to leave that example in, the setup string can be ditched.

Let me know your thoughts and I will update the patch.

----------
Added file: http://bugs.python.org/file18871/issue1397474.py27.1.patch

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

From report at bugs.python.org  Mon Sep 13 21:38:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Sep 2010 19:38:00 +0000
Subject: [docs] [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1284406680.29.0.770071846012.issue9802@psf.upfronthosting.co.za>


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

> Of course, there are subtle implications of how it will be implemented

Indeed.  Ideally, as you mention, the implementation would only use __lt__ (as with sort and bisect).  I think that constraint only leaves one reasonable choice: namely, max and min for multiple args would be functionally equivalent to max_list and min_list below:

def min2(x, y):
    return y if y < x else x

def max2(x, y):
    return x if y < x else y

def min_list(xs):
    return reduce(min2, xs)

def max_list(xs):
    return reduce(max2, xs)

----------

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

From report at bugs.python.org  Tue Sep 14 17:33:51 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Sep 2010 15:33:51 +0000
Subject: [docs] [issue9728] Docs point to FAQ Section 3,
	but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284478431.43.0.573478359905.issue9728@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Where does/did the FAQ live in the version control tree?

----------

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

From report at bugs.python.org  Tue Sep 14 17:47:43 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Sep 2010 15:47:43 +0000
Subject: [docs] [issue9728] Docs point to FAQ Section 3,
	but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284479263.71.0.267790156676.issue9728@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

It looks like the FAQ used be generated using Tools/faqwiz/faqwiz.py (which no longer exists).  According to that file:

-----------------------------------------------------------------------
This is a CGI program that maintains a user-editable FAQ.  It uses RCS
to keep track of changes to individual FAQ entries.  It is fully
configurable; everything you might want to change when using this
program to maintain some other FAQ than the Python FAQ is contained in
the configuration module, faqconf.py.
-----------------------------------------------------------------------

In other words, while the FAQ was under version control, it wasn't the regular repository.

I'll ask on python-dev is anyone has a copy.

----------

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

From report at bugs.python.org  Tue Sep 14 17:49:15 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Sep 2010 15:49:15 +0000
Subject: [docs] [issue9728] Docs point to FAQ Section 3,
	but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284479355.75.0.827651027353.issue9728@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Nevermind... archive.org has it. :-)

----------

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

From report at bugs.python.org  Tue Sep 14 18:11:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 14 Sep 2010 16:11:09 +0000
Subject: [docs] [issue9728] Docs point to FAQ Section 3,
	but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284480669.44.0.584703081936.issue9728@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Fixed in r84810, r84811, and 84812.

For anyone curious, the old FAQ entry is here:
http://web.archive.org/web/20010203161100/http://www.python.org/doc/FAQ.html#3.24

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Sep 14 23:22:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 14 Sep 2010 21:22:06 +0000
Subject: [docs] [issue9728] Docs point to FAQ Section 3,
	but FAQs are not numbered
In-Reply-To: <1283305749.34.0.483172641002.issue9728@psf.upfronthosting.co.za>
Message-ID: <1284499326.49.0.780839544357.issue9728@psf.upfronthosting.co.za>


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

Thanks for the investigation!

----------

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

From report at bugs.python.org  Wed Sep 15 01:14:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 14 Sep 2010 23:14:48 +0000
Subject: [docs] [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1284506088.36.0.767725993251.issue9802@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Documented the current behavior in r84822.

Mark, if you're free on IRC at some point, I would like to discuss further.

----------

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

From report at bugs.python.org  Wed Sep 15 21:30:01 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 15 Sep 2010 19:30:01 +0000
Subject: [docs] [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1284579001.2.0.971309730594.issue9746@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep 16 18:37:18 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 16:37:18 +0000
Subject: [docs] [issue6893] defaultdict example in py3 doc should mention
	the new	Counter class
In-Reply-To: <1252724623.36.0.815888015467.issue6893@psf.upfronthosting.co.za>
Message-ID: <1284655038.57.0.420609321713.issue6893@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep 16 21:25:54 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Sep 2010 19:25:54 +0000
Subject: [docs] [issue6893] defaultdict example in py3 doc should mention
	the new	Counter class
In-Reply-To: <1252724623.36.0.815888015467.issue6893@psf.upfronthosting.co.za>
Message-ID: <1284665153.98.0.123214413504.issue6893@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This example needs to stay.  It was one of the principal motiviating use cases for defaultdict and it is a good, simple, understandable example of how to use it.

Also, I don't want to cross-link these two tools because they a subtly different (the default dict approach inserts a zero for missing elements while the Counter approach returns zero but does not insert it).

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

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

From report at bugs.python.org  Thu Sep 16 22:59:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 16 Sep 2010 20:59:22 +0000
Subject: [docs] [issue1660009] continuing problem with httplib multiple
	set-cookie	headers
Message-ID: <1284670762.75.0.57858624317.issue1660009@psf.upfronthosting.co.za>


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


----------
assignee: georg.brandl -> docs at python
nosy: +docs at python
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Sep 16 23:32:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 16 Sep 2010 21:32:29 +0000
Subject: [docs] [issue1665333] Documentation missing for OptionGroup class
	in optparse
Message-ID: <1284672749.69.0.237163656219.issue1665333@psf.upfronthosting.co.za>


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

Adding docs@ to nosy. amk: Please reassign to docs@ if you don?t intend to work on this.

----------
nosy: +docs at python, eric.araujo
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Sep 17 14:13:26 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 17 Sep 2010 12:13:26 +0000
Subject: [docs] [issue9886] Make operator.itemgetter/attrgetter/methodcaller
	easier	to discover
In-Reply-To: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>
Message-ID: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The observation has been made that there are some idioms related to key functions passed to various methods and functions that aren't particularly easy to discover.

One suggestion is to create a "key function" glossary entry that provides examples of standard library operations that exist primarily for use as key functions (i.e. the three functions mentioned in the issue title), as well as mentioning some of the APIs that accept key functions (e.g. sorted, list.sort, min, max). The documentation of these various could then cross link to the "key function" glossary entry to make this idioms more discoverable without needing to repeat ourselves in the documentation of every method that accepts a key function.

As per discussion on python-ideas, including the glossary entry suggestion from Terry Reedy:
http://mail.python.org/pipermail/python-ideas/2010-September/008093.html

----------
assignee: docs at python
components: Documentation
messages: 116658
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Make operator.itemgetter/attrgetter/methodcaller easier to discover
versions: Python 3.2

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

From report at bugs.python.org  Fri Sep 17 14:39:26 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 17 Sep 2010 12:39:26 +0000
Subject: [docs] [issue9886] Make operator.itemgetter/attrgetter/methodcaller
	easier	to discover
In-Reply-To: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>
Message-ID: <1284727166.01.0.0678205753145.issue9886@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

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

From report at bugs.python.org  Fri Sep 17 15:58:23 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 13:58:23 +0000
Subject: [docs] [issue1705393] Select() failure (race condition)
Message-ID: <1284731903.44.0.312657277687.issue1705393@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

I've changed things in reply to msg85311, feel free to alter things again if you disagree.

----------
assignee:  -> docs at python
components: +Documentation -Extension Modules, Library (Lib)
nosy: +BreamoreBoy, docs at python
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

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

From report at bugs.python.org  Fri Sep 17 20:26:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Sep 2010 18:26:02 +0000
Subject: [docs] [issue9886] Make operator.itemgetter/attrgetter/methodcaller
	easier	to discover
In-Reply-To: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>
Message-ID: <1284747962.66.0.163321163098.issue9886@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


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

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

From report at bugs.python.org  Fri Sep 17 20:27:12 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Sep 2010 18:27:12 +0000
Subject: [docs] [issue1753718] base64 "legacy" functions violate RFC 3548
Message-ID: <1284748032.34.0.822105086377.issue1753718@psf.upfronthosting.co.za>


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


----------
assignee: barry -> docs at python
nosy: +docs at python
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Fri Sep 17 20:58:23 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 17 Sep 2010 18:58:23 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284749902.85.0.0912884895974.issue6627@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

@Swapnil: the rules you quote are correct for the C extension, but do not apply when using ctypes, because ctypes is doing the required initializations automatically.

However, if Amaury is correct, ctypes performs the initializations in a way that break the threading.local functionality. 

I think the best way to address this bug would therefore be to add a warning to the ctypes documentation that C created threads will not support threading.local().

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

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

From report at bugs.python.org  Fri Sep 17 20:58:31 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 17 Sep 2010 18:58:31 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284749911.06.0.3625357294.issue6627@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep 17 22:49:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 20:49:25 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284756565.71.0.0674315477993.issue6627@psf.upfronthosting.co.za>


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

> ctypes performs the initializations in a way that break the
> threading.local functionality. 

Not quite. ctypes (or more exactly: the PyGILState_Ensure() and PyGILState_Release() functions, which are the standard API to do this) is in a situation where it must call Python code from a thread which has no PyThreadState.  So it creates a thread state, runs the code, and destroys the thread state; is this wrong?

If you want to keep Python state during your C thread, there are 4 lines to add to your function:

void *async_cb(void *dummy)
{
    PyGILState_STATE gstate = PyGILState_Ensure();
    Py_BEGIN_ALLOW_THREADS
    (*callback_fn)();
    (*callback_fn)();
    Py_END_ALLOW_THREADS
    PyGILState_Release(gstate);
    pthread_exit(NULL);
}

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Fri Sep 17 23:10:21 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 17 Sep 2010 21:10:21 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284757821.67.0.444558864846.issue6627@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

No, I am not saying that the behaviour of ctypes is wrong. It just happens to have some effects on threading.local that I think should be documented. That's why I reassigned this as a documentation bug. 

Please reconsider closing this bug. I'm also happy to change the type to "Feature request".


As an aside: I think in most cases one uses ctypes to call functions that are already compiled, so changing the source is not an option.

----------

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

From report at bugs.python.org  Fri Sep 17 23:16:10 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 17 Sep 2010 21:16:10 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284758170.03.0.525759141973.issue6627@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

To be a bit more constructive, why not add something like this in paragraph to http://docs.python.org/library/ctypes.html#callback-functions:

"Note that if the callback function is called in a new thread that has been created outside of Python's control (i.e., by the foreign code that calls the callback), ctypes creates a new dummy Python thread on every invocation. That means that values stored with `threading.local` will *not* survive across different callbacks.

----------

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

From report at bugs.python.org  Sat Sep 18 00:13:23 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 17 Sep 2010 22:13:23 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284761602.77.0.326757434443.issue6627@psf.upfronthosting.co.za>


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

This is not specific to ctypes.
Please read http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock
specially the paragraph that says "...when threads are created from C...".
Is it explicit enough? How would you change it?

----------

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

From report at bugs.python.org  Sat Sep 18 00:29:17 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 17 Sep 2010 22:29:17 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284762557.34.0.565606147859.issue6627@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

One point of ctypes is to save the user the trouble of having to create a full blown C extension, so I don't think it's reasonable to expect a ctypes user to have read the full C API documentation as well. Only a very small subset of the page that you gave is actually relevant for use with ctypes. Why not put this information where a ctypes user can find it easily?

----------

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

From report at bugs.python.org  Sat Sep 18 04:20:38 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 18 Sep 2010 02:20:38 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1284776438.15.0.270829513259.issue6627@psf.upfronthosting.co.za>


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

The suggestion in http://bugs.python.org/issue6627#msg116722 is a good one.

This a case where the user may legitimately not realise that threading.local is stored in the *temporary* state created by ctypes rather than in something more persistent inside the interpreter.

Since the ctypes state is per callback, it won't persist across calls, even when they're made from the same thread.

Suggested wording:
"""Note that if the callback function is called in a new thread that has been created outside of Python's control (i.e., by the foreign code that calls the callback), ctypes creates a new dummy Python thread on every invocation, including recreation of the thread local storage area. While this is correct for most purposes, it does mean that values stored with `threading.local` will *not* survive across different callbacks, even when those calls are made from the same C thread."""

----------
keywords: +easy
resolution: works for me -> 
stage: committed/rejected -> needs patch
status: closed -> open
type: behavior -> feature request

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

From report at bugs.python.org  Sat Sep 18 05:14:54 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Sep 2010 03:14:54 +0000
Subject: [docs] [issue9842] Document ... used in recursive repr of containers
In-Reply-To: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>
Message-ID: <1284779694.98.0.101000075005.issue9842@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep 18 11:11:22 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sat, 18 Sep 2010 09:11:22 +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: <1284801081.96.0.0540649030597.issue9891@psf.upfronthosting.co.za>


New submission from Rodrigo Bernardo Pimentel <rbp at isnomore.net>:

The "Built-in methods" item of the "The standard type hierarchy" section of Doc/reference/datamodels.rst uses a list instance called "alist" as an example, and it says "__self__ is set to the object denoted by *list*." It should read "the object denoted by *alist*"

This affects all releases, so I've marked them all. But I suppose we don't care about 2.5 anymore. All the others are listed on docs.python.org (or are "trunk"), and I think should be fixed.

It's a trivial fix, and a single patch works 2.x and another for 3.x.

----------
assignee: docs at python
components: Documentation
files: alist_doc-2.x.patch
keywords: patch
messages: 116757
nosy: docs at python, rbp
priority: normal
severity: normal
status: open
title: Minor doc typo at datamodel.rst: "list" -> "alist"
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18914/alist_doc-2.x.patch

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

From report at bugs.python.org  Sat Sep 18 11:11:46 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sat, 18 Sep 2010 09:11:46 +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: <1284801106.97.0.788975291095.issue9891@psf.upfronthosting.co.za>


Changes by Rodrigo Bernardo Pimentel <rbp at isnomore.net>:


Added file: http://bugs.python.org/file18915/alist_doc-3.x.patch

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

From report at bugs.python.org  Sat Sep 18 15:50:37 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 13:50:37 +0000
Subject: [docs] [issue1215] Python hang when catching a segfault
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1284817836.91.0.791814404183.issue1215@psf.upfronthosting.co.za>


Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:

There are several suggestions inline as how how the docs should be changed.

----------
assignee:  -> docs at python
nosy: +BreamoreBoy, docs at python

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

From report at bugs.python.org  Sat Sep 18 20:38:01 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 18 Sep 2010 18:38:01 +0000
Subject: [docs] [issue1722] Undocumented urllib functions
In-Reply-To: <1199298780.6.0.893928826633.issue1722@psf.upfronthosting.co.za>
Message-ID: <1284835081.17.0.610876388577.issue1722@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep 19 21:17:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 19 Sep 2010 19:17:24 +0000
Subject: [docs] [issue9119] Python download page needs to mention crypto
	code	in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1284923844.73.0.926049588689.issue9119@psf.upfronthosting.co.za>


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

Yes, everything under docs.python.org is generated from files from the Doc directory of a CPython checkout.  s/.html/.rst/ and you have your filename.

----------

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

From report at bugs.python.org  Sun Sep 19 23:43:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Sep 2010 21:43:25 +0000
Subject: [docs] [issue9119] Python download page needs to mention crypto
	code	in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1284932605.76.0.322342736786.issue9119@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not quite everything (index.html and download.html are special, in that they're not generated from reST), but otherwise that is correct.

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

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

From gspnjt at gmail.com  Thu Sep 16 05:30:58 2010
From: gspnjt at gmail.com (gspnjt at gmail.com)
Date: Wed, 15 Sep 2010 23:30:58 -0400
Subject: [docs] possible syntax error
Message-ID: <4C918F72.2050904@gmail.com>

  http://docs.python.org/py3k/tutorial/datastructures.html
5.4. Sets

"Curly braces or the set() function can be _use_ to create sets."

error: use
fix: used
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100915/10b008e6/attachment.html>

From bholmberg at broadcom.com  Fri Sep 17 19:24:33 2010
From: bholmberg at broadcom.com (Bob Holmberg)
Date: Fri, 17 Sep 2010 10:24:33 -0700
Subject: [docs] Add % "string formatting" description to precedence table
Message-ID: <C28713F579DB094D828AF937C214266A138AA09F59@SJEXCHCCR01.corp.ad.broadcom.com>

Hello,

I am unsure of the precedence of the '%' operator when used as the string formatting operator.  I rely on the precedence chart/table in section 5.15 on page http://docs.python.org/reference/expressions.html .

I must assume that the precedence of '%', described as "remainder" in the Description column also holds for that operator's use for string formatting.  It would be a great help if "string formatting" were added to the description column to make this use of the '%' operator clear and explicit.

Thanks,
Bob Holmberg

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

From report at bugs.python.org  Mon Sep 20 09:45:08 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 07:45:08 +0000
Subject: [docs] [issue1865] Bytes alias for 2.6
In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
Message-ID: <1284968708.3.0.0605275391985.issue1865@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep 20 15:59:36 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 20 Sep 2010 13:59:36 +0000
Subject: [docs] [issue1944] Documentation for PyUnicode_AsString (et al.)
	missing.
In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za>
Message-ID: <1284991176.52.0.506113479984.issue1944@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep 20 17:06:05 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 20 Sep 2010 15:06:05 +0000
Subject: [docs] [issue1865] Bytes alias for 2.6
In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
Message-ID: <1284995165.16.0.232163167318.issue1865@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Mon Sep 20 21:21:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Sep 2010 19:21:03 +0000
Subject: [docs] [issue1865] Document bytes alias for 2.7
In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
Message-ID: <1285010463.26.0.528472167012.issue1865@psf.upfronthosting.co.za>


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

Changing title to match current issue status.

DOC PATCH

Grammar section: As near as I can tell, the alternatives for 

stringprefix    ::=  "r" | "u" | "ur" | "R" | "U" | "UR" | "Ur" | "uR"

should simply be augmented with

                     | "b" | "B" | "br" | "Br" | "bR" | "BR"

(on a separate line, indented as indicated).

Text section: At the end of the second paragraph, *replace*

"The two prefix characters may be combined; in this case, 'u' must appear before 'r'."

with

"A prefix of 'b' or 'B' is ignored in Python2; it indicates that the literal should become a bytes object in Python 3. A 'u' or 'b' prefix may be followed (but not preceded) by an 'r' prefix."

----------
components:  -Interpreter Core
resolution: fixed -> 
title: Bytes alias for 2.6 -> Document bytes alias for 2.7

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

From report at bugs.python.org  Mon Sep 20 22:33:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 20:33:31 +0000
Subject: [docs] [issue9650] format codes in time.strptime docstrings
In-Reply-To: <1282319380.5.0.724924373031.issue9650@psf.upfronthosting.co.za>
Message-ID: <1285014811.52.0.283197011999.issue9650@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep 21 00:20:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 20 Sep 2010 22:20:18 +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: <1285021218.78.0.465455427027.issue9891@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.5, Python 2.6, Python 3.3

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

From report at bugs.python.org  Tue Sep 21 01:40:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Sep 2010 23:40:38 +0000
Subject: [docs] [issue9583] Document startup option/environment interaction
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285026038.91.0.964779124393.issue9583@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
title: PYTHONOPTIMIZE = 0 is not honored -> Document startup option/environment interaction
type: behavior -> 

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

From report at bugs.python.org  Tue Sep 21 02:07:23 2010
From: report at bugs.python.org (Buck Golemon)
Date: Tue, 21 Sep 2010 00:07:23 +0000
Subject: [docs] [issue9583] Document startup option/environment interaction
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285027643.61.0.115557453846.issue9583@psf.upfronthosting.co.za>


Buck Golemon <buck.golemon at amd.com> added the comment:

If I understand this code, it means that PYTHONOPTIMIZE set to 1 or 2 works as expected, but set to 0, gives a flag value of 1.

static int
add_flag(int flag, const char *envs)
{
        int env = atoi(envs);
        if (flag < env)
                flag = env;
        if (flag < 1)
                flag = 1;
        return flag;
}


Read literally, the man page indicates that any integer value will give a flag value of 2. 

I agree my shell script is probably unusual, but I believe setting this environment value to zero and expecting the feature to be off (given no contradicting options) is reasonable.

I petition to remove the second if statement above (environment value of "0" yields no flag).

I'd also love to provide a numeric argument to -O, to dynamically set this value more readily, but that is lower importance.

I can implement these and run the unit tests if required.

----------

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

From report at bugs.python.org  Tue Sep 21 03:45:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Sep 2010 01:45:05 +0000
Subject: [docs] [issue9583] Document startup option/environment interaction
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285033505.37.0.105345068012.issue9583@psf.upfronthosting.co.za>


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

I understood the documentation snippet Terry quoted as saying exactly what you say the code does.  The doc could be clearer by replacing "multiple times" with "that number of times".  Not that more than two has any meaning currently...

Changing the behavior of PYTHONOPTIMIZE as you suggest would be a backward compatibility change that would probably require a deprecation cycle.  (And the message would have to not really be a DeprecationWarning, since DeprecationWarnings are now silent by default but this is a user-triggered event, not a developer-triggered event and so should be user visible.)

Unsetting an environment variable to remove its effect is a fairly common idiom.  So I don't think it is worth the effort of making the change you suggest, even though I agree it would be more intuitive if PYTHONOPTIMIZE=0 meant what you thought it meant.

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

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

From report at bugs.python.org  Tue Sep 21 03:50:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Sep 2010 01:50:03 +0000
Subject: [docs] [issue9583] Document startup option/environment interaction
In-Reply-To: <1281653669.29.0.363654611831.issue9583@psf.upfronthosting.co.za>
Message-ID: <1285033803.88.0.722082865474.issue9583@psf.upfronthosting.co.za>


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

I do not deny that the behavior described in the doc is a bit strange (keying off of type, ignoring value) is a bit bizarre and contrary to reasonable expectation based on other programs. But to alter behavior before 3.2 or later would require a clearly demonstrated discrepancy between doc and behavior, which I do not see. For startup behavior, some discussion on pydev or python-ideas lists would probably be needed.

If the C code you posted is a quote from the Python source, please give the file path, preferably for current trunk version (the py3k branch). The second 'if' looks a bit strange at first glance, but I will not judge without seeing more.

> I believe setting this environment value to zero and expecting the feature to be off (given no contradicting options) is reasonable.

Optimization is off by default. So there is no need to have a environment value that means to keep it off.  Just do not set it. Or unset it if needed.

That said, the code you showed suggests that the option/environment interaction is more complicated than I thought, at least for this pair.

----------

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

From report at bugs.python.org  Tue Sep 21 04:11:37 2010
From: report at bugs.python.org (Buck Golemon)
Date: Tue, 21 Sep 2010 02:11:37 +0000
Subject: [docs] [issue9583] Document startup option/environment interaction
In-Reply-To: <1285033505.37.0.105345068012.issue9583@psf.upfronthosting.co.za>
Message-ID: <7691DC9FC60C9E4F88A0BBCA628F55FF043E8DE5F2@sausexmbp02.amd.com>


Buck Golemon <buck.golemon at amd.com> added the comment:

"that number of times" isn't exactly accurate either, since "0" is effectively interpreted as "1".

This change would only adversely affect people who use no -O option, set PYTHONOPTIMIZE to '0', and need optimization.
I feel like that falls into the realm of version differences, but that's your decision.

----------

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

From report at bugs.python.org  Tue Sep 21 04:20:28 2010
From: report at bugs.python.org (Buck Golemon)
Date: Tue, 21 Sep 2010 02:20:28 +0000
Subject: [docs] [issue9583] Document startup option/environment interaction
In-Reply-To: <1285033803.88.0.722082865474.issue9583@psf.upfronthosting.co.za>
Message-ID: <7691DC9FC60C9E4F88A0BBCA628F55FF043E8DE602@sausexmbp02.amd.com>


Buck Golemon <buck.golemon at amd.com> added the comment:

The file is here:
   http://svn.python.org/view/python/trunk/Python/pythonrun.c?view=markup

The second if statement is doing exactly what I find troubling: set the flag even if the incoming value is 0.
I guess this is to handle the empty string case, such as:

setenv PYTHONDEBUG
./myscript.py

----------

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

From report at bugs.python.org  Tue Sep 21 06:39:04 2010
From: report at bugs.python.org (Swapnil Talekar)
Date: Tue, 21 Sep 2010 04:39:04 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1285043943.16.0.816529286647.issue6627@psf.upfronthosting.co.za>


Swapnil Talekar <swapnil.st at gmail.com> added the comment:

Nick, the last statement,
"While this is correct for most purposes, it does mean that..."
can be simplified to, 
"It means...". 
I had to read it several times before I realized, there is no "not" after "does" :) 
BTW, since this particular arrangement of having a temporary thread state during the callback is particularly useful for ctypes (I cannot imagine any other usecase) and also it sort-of breaks things, a potential feature request could be to have consistent thread state during the lifetime of a C thread. I don't have much idea how to do that or whether it is even possible? Would anyone like to give a thought?

----------

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

From report at bugs.python.org  Tue Sep 21 13:45:20 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 21 Sep 2010 11:45:20 +0000
Subject: [docs] [issue9119] Python download page needs to mention crypto
	code	in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1285069520.48.0.698827094119.issue9119@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Added OpenSSL license to Python 2.7, 3.1 and 3.2 in r84938, r84939, r84940 resp.

Now we'll only need to add a mention of the fact that we ship OpenSSL in the Windows installers on the download page.

Terry, would you like to move this forward with the Python.org webmasters ?

----------

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

From report at bugs.python.org  Tue Sep 21 15:03:24 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 21 Sep 2010 13:03:24 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1285043943.16.0.816529286647.issue6627@psf.upfronthosting.co.za>
Message-ID: <AANLkTinUvBcUhxZmy8L_HCWhogM3b3jDG87Fcp4NWWwW@mail.gmail.com>


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

On Tue, Sep 21, 2010 at 2:39 PM, Swapnil Talekar <report at bugs.python.org> wrote:
> Swapnil Talekar <swapnil.st at gmail.com> added the comment:
> Nick, the last statement,
> "While this is correct for most purposes, it does mean that..."
> can be simplified to,
> "It means...".
> I had to read it several times before I realized, there is no "not" after "does" :)

The shorter version doesn't mean the same thing though - the ctypes
arrangement *really is* correct for most purposes. The only issue is
that threading.local won't persist, since the storage is blown away as
soon as the callback returns.

> BTW, since this particular arrangement of having a temporary thread state during the callback is particularly useful for ctypes (I cannot imagine any other usecase) and also it sort-of breaks things, a potential feature request could be to have consistent thread state during the lifetime of a C thread. I don't have much idea how to do that or whether it is even possible? Would anyone like to give a thought?

There's no easy way to make the thread state persist between calls, as
ctypes needs to destroy the thread state it creates at some point to
avoid a memory leak. Since it has no way of knowing when the
underlying C thread is no longer in use, it is forced to assume that
every call is going to be the last one from that thread and kill the
thread state.

----------

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

From report at bugs.python.org  Tue Sep 21 16:43:01 2010
From: report at bugs.python.org (DSM)
Date: Tue, 21 Sep 2010 14:43:01 +0000
Subject: [docs] [issue9911] doc copyedits
In-Reply-To: <1285080181.79.0.899000794299.issue9911@psf.upfronthosting.co.za>
Message-ID: <1285080181.79.0.899000794299.issue9911@psf.upfronthosting.co.za>


New submission from DSM <dsm001 at users.sourceforge.net>:

Various typo fixes for the docs.  As usual, I left historical documents alone (except for 3.1 whatsnew: fixed the spelling of Jack Diederich's name).  Fixing ~30 means I probably introduced ~3 problems of my own, but that should still be a net win..

Patch against py3k r84944.

----------
assignee: docs at python
components: Documentation
files: typos.patch
keywords: patch
messages: 117052
nosy: docs at python, dsm001
priority: normal
severity: normal
status: open
title: doc copyedits
versions: Python 3.3
Added file: http://bugs.python.org/file18947/typos.patch

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

From report at bugs.python.org  Tue Sep 21 16:48:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 21 Sep 2010 14:48:43 +0000
Subject: [docs] [issue9911] doc copyedits
In-Reply-To: <1285080181.79.0.899000794299.issue9911@psf.upfronthosting.co.za>
Message-ID: <1285080523.45.0.567791249932.issue9911@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks! Committed as r84945.

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

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

From report at bugs.python.org  Tue Sep 21 17:57:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 21 Sep 2010 15:57:48 +0000
Subject: [docs] [issue9913] Misc/SpecialBuilds.txt  is out of date
In-Reply-To: <1285084668.56.0.665403194927.issue9913@psf.upfronthosting.co.za>
Message-ID: <1285084668.56.0.665403194927.issue9913@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

It looks like Misc/SpecialBuilds.txt has not been updated since 2.4.

This file is referenced from C-API documentation [1], but is not accessible as a hyperlink.

Some of the recommendations in this file are out of date, in particular those that recommend setting make variables where a configure switch is available.

I believe it would be best to retire Misc/SpecialBuilds.txt and move still relevant sections to proper .rst files.


[1] http://docs.python.org/dev/py3k/c-api/intro.html#debugging-builds

----------
assignee: docs at python
components: Documentation
messages: 117076
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Misc/SpecialBuilds.txt  is out of date
versions: Python 3.2

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

From report at bugs.python.org  Tue Sep 21 19:20:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Sep 2010 17:20:25 +0000
Subject: [docs] [issue9119] Python download page needs to mention crypto
	code	in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1285089624.89.0.546250291776.issue9119@psf.upfronthosting.co.za>


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

I sent an email.

----------

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

From report at bugs.python.org  Tue Sep 21 23:31:14 2010
From: report at bugs.python.org (John J Lee)
Date: Tue, 21 Sep 2010 21:31:14 +0000
Subject: [docs] [issue1660009] continuing problem with httplib multiple
	set-cookie	headers
Message-ID: <1285104673.96.0.0149300993437.issue1660009@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

What I said in 2007 re commas could be well out of date (might well have been so even then, in fact).  Somebody should check what browsers do now...

----------

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

From report at bugs.python.org  Wed Sep 22 22:47:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Sep 2010 20:47:47 +0000
Subject: [docs] [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1285188467.18.0.265267728197.issue9921@psf.upfronthosting.co.za>


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

Since changing the implementation would be a backward incompatible behavior change to a behavior that has existed for a long time, it's the docs that should be updated.

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

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

From report at bugs.python.org  Thu Sep 23 12:34:04 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Thu, 23 Sep 2010 10:34:04 +0000
Subject: [docs] [issue9582] documentation line needs rewording
In-Reply-To: <1281650622.86.0.310513887463.issue9582@psf.upfronthosting.co.za>
Message-ID: <1285238044.56.0.252381964721.issue9582@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

uploaded patch. 

patch could be applied to 2.7-maint and p3k successfuly. single word insert.

----------
nosy: +ruseel
Added file: http://bugs.python.org/file18973/issue9582.patch

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

From report at bugs.python.org  Thu Sep 23 15:48:51 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 23 Sep 2010 13:48:51 +0000
Subject: [docs] [issue9582] documentation line needs rewording
In-Reply-To: <1281650622.86.0.310513887463.issue9582@psf.upfronthosting.co.za>
Message-ID: <1285249730.96.0.957104315556.issue9582@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed in r84971 and r84972. Thanks.

----------
assignee: docs at python -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage: needs patch -> committed/rejected

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

From report at bugs.python.org  Thu Sep 23 15:57:53 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Sep 2010 13:57:53 +0000
Subject: [docs] [issue9582] documentation line needs rewording
In-Reply-To: <1281650622.86.0.310513887463.issue9582@psf.upfronthosting.co.za>
Message-ID: <1285250273.01.0.486727445684.issue9582@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep 23 21:14:51 2010
From: report at bugs.python.org (Brian Brazil)
Date: Thu, 23 Sep 2010 19:14:51 +0000
Subject: [docs] [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1285269291.45.0.185788006973.issue9921@psf.upfronthosting.co.za>


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

The behaviour is a bit more nuanced:
>>> os.path.join('x', '')
'x/'
>>> os.path.join('x', '', 'y')
'x/y'
>>> os.path.join('x', '', 'y', '', '')
'x/y/'
>>> os.path.join('', 'x')
'x'

I'm unsure how to word this best, maybe "non-trailing empty paths are ignored"?

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

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

From report at bugs.python.org  Fri Sep 24 02:02:08 2010
From: report at bugs.python.org (Retro)
Date: Fri, 24 Sep 2010 00:02:08 +0000
Subject: [docs] [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

http://docs.python.org/distutils/sourcedist.html#manifest-related-options

Please visit the above link and note the typo in:
-o is a sortcut for --manifest-only.

Should be:
-o is a shortcut for --manifest-only.

The word "sortcut" is a typo. Please fix it to "shortcut". Thanks.

----------
assignee: docs at python
components: Documentation
messages: 117248
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Python Docs Typo
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Sep 24 02:49:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Sep 2010 00:49:39 +0000
Subject: [docs] [issue9933] os module does not have the documented
	EX_NOTFOUND	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285289378.94.0.163660153129.issue9933@psf.upfronthosting.co.za>


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

Perhaps this constant existed at some point on some linux systems...google found one comment about it referencing posix.2.  I also found it mentioned in a specific version of sendmail, and in bash.  When it appears it seems to most often have the value 127.

I suspect the mention of this constant should just be deleted from the docs.  Google code search finds no mention of it in any sysexits.h file anywhere it has searched, so the chances are this constant will never be defined by Python.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, r.david.murray
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Fri Sep 24 02:56:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Sep 2010 00:56:47 +0000
Subject: [docs] [issue9933] os module does not have the documented
	EX_NOTFOUND	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285289807.21.0.174250677472.issue9933@psf.upfronthosting.co.za>


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

s/linux/unix/

----------

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

From report at bugs.python.org  Fri Sep 24 02:57:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 24 Sep 2010 00:57:53 +0000
Subject: [docs] [issue9933] os module does not have the documented
	EX_NOTFOUND	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285289873.4.0.833928641774.issue9933@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

+1 for removing it from the docs.

----------

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

From report at bugs.python.org  Fri Sep 24 06:11:10 2010
From: report at bugs.python.org (Kamil Kisiel)
Date: Fri, 24 Sep 2010 04:11:10 +0000
Subject: [docs] [issue9933] os module does not have the documented
	EX_NOTFOUND	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285301469.87.0.664096459822.issue9933@psf.upfronthosting.co.za>


Kamil Kisiel <kisielk at users.sourceforge.net> added the comment:

I mostly wanted to just report the issue rather than propose a solution, so I'm in favor of whatever everyone feels is best.

As for how I came across the issue, it was mostly curiosity, I wanted to see the numerical value of all the os.EX_* constants and was printing them out on the screen when I stumbled upon this.

If there's no chance of it working, which seems to be the case, I agree it should probably be just removed from the documentation.

----------

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

From report at bugs.python.org  Fri Sep 24 07:05:23 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Fri, 24 Sep 2010 05:05:23 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1285304722.59.0.232308491305.issue459007@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


----------
nosy: +ruseel

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

From report at bugs.python.org  Fri Sep 24 07:51:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 24 Sep 2010 05:51:52 +0000
Subject: [docs] [issue9933] os module does not have the documented
	EX_NOTFOUND	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285307511.83.0.933608611072.issue9933@psf.upfronthosting.co.za>


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

I fail to see the issue. The documentation clearly says, above the block of all the EX_* constants:

Note

Some of these may not be available on all Unix platforms, since there is some variation. These constants are defined where they are defined by the underlying platform.

That seems to explain the situation well, no?

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

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

From report at bugs.python.org  Fri Sep 24 09:10:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 24 Sep 2010 07:10:40 +0000
Subject: [docs] [issue9933] os module does not have the documented
	EX_NOTFOUND	attribute
In-Reply-To: <1285285715.98.0.332304645374.issue9933@psf.upfronthosting.co.za>
Message-ID: <1285312240.31.0.316257091404.issue9933@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree with Martin.

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

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

From report at bugs.python.org  Fri Sep 24 16:31:30 2010
From: report at bugs.python.org (Jay T)
Date: Fri, 24 Sep 2010 14:31:30 +0000
Subject: [docs] [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>


New submission from Jay T <jaytula at gmail.com>:

I want to create a custom interactive shell where I continually do 
parse_args.  Like the following: 
parser = argparse.ArgumentParser() 
command = raw_input() 
while(True): 
  args = parser.parse_args(shlex.split(command)) 
  # Do some magic stuff 
  command = raw_input() 
The problem is that if I give it invalid input, it errors and exits 
with a help message.

I learned from argparse-users group that you can override the exit method like the following:

class MyParser(ArgumentParser): 
  def exit(self, status=0, message=None): 
    # do whatever you want here 

I would be nice to have this usage documented perhaps along with best practices for doing help messages in this scenario.

----------
assignee: docs at python
components: Documentation
messages: 117287
nosy: docs at python, jayt
priority: normal
severity: normal
status: open
title: Documentation for argparse interactive use
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 24 17:13:43 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Fri, 24 Sep 2010 15:13:43 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1285341223.17.0.858743932495.issue459007@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

I made patch which move comment from PC/getpathp.c to Doc/using/windows.rst. And did a little editing, reST markup.

http://codereview.appspot.com/2211046

----------
keywords: +patch
Added file: http://bugs.python.org/file18997/comment_move_to_windows_rst.patch

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

From report at bugs.python.org  Fri Sep 24 22:29:42 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 24 Sep 2010 20:29:42 +0000
Subject: [docs] [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1285360182.39.0.611878290772.issue9938@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


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

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

From report at bugs.python.org  Fri Sep 24 23:29:31 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Sep 2010 21:29:31 +0000
Subject: [docs] [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285363771.12.0.72692374861.issue9934@psf.upfronthosting.co.za>


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


----------
keywords: +easy, patch
stage:  -> needs patch
versions:  -Python 2.5, Python 2.6, Python 3.3

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

From report at bugs.python.org  Fri Sep 24 23:30:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Sep 2010 21:30:24 +0000
Subject: [docs] [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285363824.55.0.945830167727.issue9934@psf.upfronthosting.co.za>


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

Agreed. Should happen sometime. Thanks for catching this.

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

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

From report at bugs.python.org  Sat Sep 25 00:15:44 2010
From: report at bugs.python.org (Jon Clements)
Date: Fri, 24 Sep 2010 22:15:44 +0000
Subject: [docs] [issue9944] Typo in doc for itertools recipe of consume
In-Reply-To: <1285366544.01.0.313980902629.issue9944@psf.upfronthosting.co.za>
Message-ID: <1285366544.01.0.313980902629.issue9944@psf.upfronthosting.co.za>


New submission from Jon Clements <joncle at googlemail.com>:

Very low priority.

def consume(iterator, n):
    "Advance the iterator n-steps ahead. If n is none, consume entirely."
    # Use functions that consume iterators at C speed.
    if n is None:
        # feed the entire iterator into a zero-length deque
        collections.deque(iterator, maxlen=0)
    else:
        # advance to the emtpy slice starting at position n
        next(islice(iterator, n, n), None)

Hardly a show stoppper, and not me worth submitting a patch, but "emtpy" should be "empty". Just thought I'd make note of it before I forgot.

----------
assignee: docs at python
components: Documentation
messages: 117339
nosy: docs at python, joncle
priority: normal
severity: normal
status: open
title: Typo in doc for itertools recipe of consume
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Sep 25 04:40:34 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 25 Sep 2010 02:40:34 +0000
Subject: [docs] [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285382433.78.0.27396611772.issue9934@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r85002. This was taken care of on py3k a while ago.

----------
assignee: docs at python -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Sep 25 15:23:07 2010
From: report at bugs.python.org (Jan-Philip Gehrcke)
Date: Sat, 25 Sep 2010 13:23:07 +0000
Subject: [docs] [issue6634] sys.exit() called from threads other than the
	main one:	undocumented behaviour
In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
Message-ID: <1285420987.43.0.0682498030093.issue6634@psf.upfronthosting.co.za>


Jan-Philip Gehrcke <jgehrcke at gmail.com> added the comment:

Sorry for the delay.

Before suggesting a doc change to correct/complete the description of the *current* situation, we actually should consider changing this situation. I think this is reasonable and I feel encouraged by Gabriel Genellina:

> I see no reason for sys.exit("msg") NOT to write to stderr
> inside a child thread.

This patch enables printing to stderr from child threads and clones the behavior of `sys.exit(arg)` called from the main thread:

# PATCH BEGIN
--- C:/Python27/Lib/threading.py    Sat Apr 10 18:55:48 2010
+++ C:/python_sys_exit_issue/threading.py    Sat Sep 25 14:50:24 2010
@@ -531,6 +531,15 @@
 except SystemExit:
     if __debug__:
         self._note("%s.__bootstrap(): raised SystemExit", self)
+    # Now get and handle the "exit code", given by the user via
+    # the second expression after `raise` or via the argument of 
+    # sys.exit().
+    code = self.__exc_info()[1].code
+    # Ignore None and integer exit code. Print any other object
+    # to stderr as it is the behavior of sys.exit(arg) called
+    # from the main thread.
+    if code is not None and not isinstance(code, int):
+        _sys.stderr.write("%s\n" % code)
 except:
     if __debug__:
         self._note("%s.__bootstrap(): unhandled exception", self)
# PATCH END

A script with different testcases including output is attached.

What do you think?

All the best,

Jan-Philip Gehrcke

----------
Added file: http://bugs.python.org/file19006/thread_sys_exit_test.py

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

From feral.and.abberrant at gmail.com  Thu Sep 23 03:22:54 2010
From: feral.and.abberrant at gmail.com (Michael Shannon)
Date: Wed, 22 Sep 2010 18:22:54 -0700
Subject: [docs] possible error on http://docs.python.org/library/struct.html
Message-ID: <AANLkTinkK_AZdjMMnFu2-FnVGdUmcUgn5Ezh4DGXUPW8@mail.gmail.com>

I was trying the example 7.3.2.3 - and when I tried:
>>> unpack( 'hhl', '\x00\x01\x00\x02\x00\x00\x00\x03')

I got the following error:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' does not support the buffer interface

However, if I declared the second string to be a byte array:
>>> unpack( 'hhl', b'\x00\x01\x00\x02\x00\x00\x00\x03')
(256, 512, 50331648)
... it works :-)


I'm running:
aMac:~ mike$ python3 -V
Python 3.1.2
aMac:~ mike$ uname -a
Darwin dd-wrt.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:27:12
PDT 2010; root:xnu-1504.7.4~1/RELEASE_X86_64 x86_64

So to summarize; I think that the example 7.3.2.3 needs a 'b' char added to
the beginning of the second string, to declare it to be a byte array.

cheers,

m i k e

ps - here's some other *possibly relevant" examples of how it works on this
platform:
>>> calcsize( 'hhl' )
8
>>> unpack( 'hhl', b'\x01\x00\x02\x00\x03\x00\x00\x00')
(1, 2, 3)
>>> unpack( '<hhl', b'\x00\x01\x00\x02\x00\x00\x00\x03')
(256, 512, 50331648)
>>> unpack( '>hhl', b'\x00\x01\x00\x02\x00\x00\x00\x03')
(1, 2, 3)
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100922/429bff13/attachment-0001.html>

From jj.dormard at free.fr  Thu Sep 23 11:14:37 2010
From: jj.dormard at free.fr (Jean-Jacques DORMARD)
Date: Thu, 23 Sep 2010 11:14:37 +0200 (CEST)
Subject: [docs] http://docs.python.org/library/compiler.html
Message-ID: <2131778968.3726011285233277600.JavaMail.root@spooler8-g27.priv.proxad.net>

Hi, 

(very) little syntax error here " It uses the built-in parser and standard parser module to generate d a concrete syntax tree" 

More importantly, it is mentioned that the package is deprecated. Can you give the name of a valid equivalent package? 

Congratulations for the excellent work ;) 
JJ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100923/053e7b58/attachment-0001.html>

From crocodilelll at gmail.com  Sat Sep 25 00:45:41 2010
From: crocodilelll at gmail.com (Lili Luo)
Date: Fri, 24 Sep 2010 15:45:41 -0700
Subject: [docs] 2.7 tutorial section 6.2
In-Reply-To: <AANLkTimQy_=2aEYk2GpbNc4ZqZ3xtnX=b-4LX0bXDY8O@mail.gmail.com>
References: <AANLkTimQy_=2aEYk2GpbNc4ZqZ3xtnX=b-4LX0bXDY8O@mail.gmail.com>
Message-ID: <AANLkTimhU=i57R57LShGBGnFPCd71D0d-FcUA0G=Wkwc@mail.gmail.com>

Sorry about the previous message. It works in the command line, not the GUI.
Thanks.

--Lili

On Fri, Sep 24, 2010 at 3:40 PM, Lili Luo <crocodilelll at gmail.com> wrote:

>  * *
>
> *This doesn?t work. It appears that sys does not have the method.*
>
> * *
>
> * *
>
> *>>> **import* *sys*
>
> *>>> *sys.ps1
>
> '>>> '
>
> *>>> *sys.ps2
>
> '... '
>
> *>>> *sys.ps1 = 'C> '
>
> C> print 'Yuck!'
>
> Yuck!
>
> C>
>
> Thanks.
>
> --Lili
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100924/ef443f18/attachment-0001.html>

From crocodilelll at gmail.com  Sat Sep 25 00:40:55 2010
From: crocodilelll at gmail.com (Lili Luo)
Date: Fri, 24 Sep 2010 15:40:55 -0700
Subject: [docs] 2.7 tutorial section 6.2
Message-ID: <AANLkTimQy_=2aEYk2GpbNc4ZqZ3xtnX=b-4LX0bXDY8O@mail.gmail.com>

* *

*This doesn?t work. It appears that sys does not have the method.*

* *

* *

*>>> **import* *sys*

*>>> *sys.ps1

'>>> '

*>>> *sys.ps2

'... '

*>>> *sys.ps1 = 'C> '

C> print 'Yuck!'

Yuck!

C>

Thanks.

--Lili
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100924/1aee3cd4/attachment.html>

From sweettoother at gmail.com  Sat Sep 25 04:16:10 2010
From: sweettoother at gmail.com (Sweet Toother)
Date: Fri, 24 Sep 2010 19:16:10 -0700
Subject: [docs] Link Error
Message-ID: <AANLkTim7gQtQjycgsq+8kGKo0iwh51W7QJX5Z5hk=Ut3@mail.gmail.com>

Hi,

just want to let you all know that the links to download all the
documents from the 2.6.1 download page
(http://docs.python.org/release/2.6.1/download.html) are incorrect.
They link to the doc/current subdir of the FTP site, instead of the
doc/2.6.1 subdir.

BTW, I navigated to the 2.6.1 download page from the Versions page (
http://www.python.org/doc/versions/ ).

Take care.

From aoramire at dipalme.org  Sat Sep 25 13:12:46 2010
From: aoramire at dipalme.org (=?ISO-8859-1?Q?Andr=E9s_Orencio_Ram=EDrez_P=E9rez?=)
Date: Sat, 25 Sep 2010 13:12:46 +0200
Subject: [docs] Documentation for ebook
Message-ID: <AANLkTi=HJnf0yzG-tmu7FanRnhC_dQJGoM9OVEzM4oud@mail.gmail.com>

Is possible get documentation in ebook format (epub for example) o A5 size?

It would be fatastic to have a link for download from documentation web
page.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100925/7098b18e/attachment-0001.html>

From renan at aestesis.org  Sat Sep 25 14:08:01 2010
From: renan at aestesis.org (renan)
Date: Sat, 25 Sep 2010 14:08:01 +0200
Subject: [docs] python27.dll
Message-ID: <4C9DE621.3040106@aestesis.org>

  hi,

why they don't provide python27.lib (dynamic version)
this is just a wrapper that do all the load and functions linking, and 
can be renamed python27dyn.lib

it is created automatically by msvc when the python27.dll is built.
it will be a lot more easy to link to the dll

regards,
renan jegouzo


From report at bugs.python.org  Sat Sep 25 15:30:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 13:30:20 +0000
Subject: [docs] [issue9944] Typo in doc for itertools recipe of consume
In-Reply-To: <1285366544.01.0.313980902629.issue9944@psf.upfronthosting.co.za>
Message-ID: <1285421420.39.0.677922734243.issue9944@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r85008.

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

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

From georg at python.org  Sat Sep 25 15:37:26 2010
From: georg at python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 15:37:26 +0200
Subject: [docs] Link Error
In-Reply-To: <AANLkTim7gQtQjycgsq+8kGKo0iwh51W7QJX5Z5hk=Ut3@mail.gmail.com>
References: <AANLkTim7gQtQjycgsq+8kGKo0iwh51W7QJX5Z5hk=Ut3@mail.gmail.com>
Message-ID: <4C9DFB16.5090105@python.org>

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

Am 25.09.2010 04:16, schrieb Sweet Toother:
> Hi,
> 
> just want to let you all know that the links to download all the
> documents from the 2.6.1 download page
> (http://docs.python.org/release/2.6.1/download.html) are incorrect.
> They link to the doc/current subdir of the FTP site, instead of the
> doc/2.6.1 subdir.
> 
> BTW, I navigated to the 2.6.1 download page from the Versions page (
> http://www.python.org/doc/versions/ ).

Hi,

thanks for the heads up, this should now be fixed (for all 2.6.x releases).

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

iEYEARECAAYFAkyd+xYACgkQN9GcIYhpnLCcNgCgrEzFhi6n8x2N4wKWJVtQRqWn
N4YAnRioJlGV1oVLSwiqGfhgMb1DvrX4
=VZbA
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sat Sep 25 15:46:54 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 13:46:54 +0000
Subject: [docs] [issue1865] Document bytes alias for 2.7
In-Reply-To: <1200673415.11.0.353515189605.issue1865@psf.upfronthosting.co.za>
Message-ID: <1285422413.94.0.686765206471.issue1865@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85010.

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

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

From georg at python.org  Sat Sep 25 15:33:34 2010
From: georg at python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 15:33:34 +0200
Subject: [docs] possible error on
	http://docs.python.org/library/struct.html
In-Reply-To: <AANLkTinkK_AZdjMMnFu2-FnVGdUmcUgn5Ezh4DGXUPW8@mail.gmail.com>
References: <AANLkTinkK_AZdjMMnFu2-FnVGdUmcUgn5Ezh4DGXUPW8@mail.gmail.com>
Message-ID: <4C9DFA2E.4070509@python.org>

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

Am 23.09.2010 03:22, schrieb Michael Shannon:
> I was trying the example 7.3.2.3 - and when I tried:
>>>> unpack( 'hhl', '\x00\x01\x00\x02\x00\x00\x00\x03')
> 
> I got the following error:
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'str' does not support the buffer interface
> 
> However, if I declared the second string to be a byte array:
>>>> unpack( 'hhl', b'\x00\x01\x00\x02\x00\x00\x00\x03')
> (256, 512, 50331648)
> ... it works :-)
> 
> 
> I'm running:
> aMac:~ mike$ python3 -V
> Python 3.1.2
> aMac:~ mike$ uname -a
> Darwin dd-wrt.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:27:12 PDT
> 2010; root:xnu-1504.7.4~1/RELEASE_X86_64 x86_64

Hey Mike,

you're looking at the 2.7 docs, which necessarily has examples that don't
work on Python 3.  Please refer to http://docs.python.org/py3k/ for the
current Python 3 docs.

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

iEYEARECAAYFAkyd+i4ACgkQN9GcIYhpnLCLGACgjnMTx+cNSb88o9SAbiFTKfDG
3k4AoKpCfpJdK5wsHf2DEYDDt9rhAs2k
=LHOt
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sat Sep 25 18:20:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Sep 2010 16:20:43 +0000
Subject: [docs] [issue6634] sys.exit() called from threads other than the
	main one:	undocumented behaviour
In-Reply-To: <1249327311.32.0.926815032903.issue6634@psf.upfronthosting.co.za>
Message-ID: <1285431643.55.0.412298924756.issue6634@psf.upfronthosting.co.za>


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

I do not use threads so I cannot comment on the technical issue.

Since the current behavior is not clearly a bug, I do not think a change would or know that it should be applied to 2.7/3.1. So I suggest that you both

1. Suggest a doc patch on this issue. That should not controversial and might be quickly applied.

2. Submit a separate feature request issue to change behavior in 3.2 or beyond. You could request that the change be backported to 2.7 and try to make a case for doing so.

Unless you can quickly write a tested patch, such a change in unlikely to make it into 3.2 anyway. And even then, no guarantee.

----------

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

From report at bugs.python.org  Sat Sep 25 18:50:32 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 25 Sep 2010 16:50:32 +0000
Subject: [docs] [issue9562] Slightly misleading wording in documentation
	of	dict.update
In-Reply-To: <1281473403.13.0.50491902338.issue9562@psf.upfronthosting.co.za>
Message-ID: <1285433432.43.0.996858583034.issue9562@psf.upfronthosting.co.za>


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

Hello,
does the attached patch contains the expected wording?

Thanks,
Sandro

----------
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19013/issue9562-py3k.patch

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

From report at bugs.python.org  Sat Sep 25 18:56:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Sep 2010 16:56:48 +0000
Subject: [docs] [issue9562] Slightly misleading wording in documentation
	of	dict.update
In-Reply-To: <1281473403.13.0.50491902338.issue9562@psf.upfronthosting.co.za>
Message-ID: <1285433808.5.0.924721967444.issue9562@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed original suggestion as r85011.

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

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

From report at bugs.python.org  Mon Sep 27 01:44:29 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 26 Sep 2010 23:44:29 +0000
Subject: [docs] [issue9956] memoryview type documentation lacks versionadded
In-Reply-To: <1285544669.44.0.903225365456.issue9956@psf.upfronthosting.co.za>
Message-ID: <1285544669.44.0.903225365456.issue9956@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

Title says all, attached is a patch against trunk (2.7). I'm not familiar with what version is correct for the Python 3 documentation.

----------
assignee: docs at python
components: Documentation
files: stdtypes-memoryview-2.7.patch
keywords: patch
messages: 117432
nosy: Trundle, docs at python, pitrou
priority: normal
severity: normal
status: open
title: memoryview type documentation lacks versionadded
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19025/stdtypes-memoryview-2.7.patch

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

From report at bugs.python.org  Mon Sep 27 01:49:31 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 26 Sep 2010 23:49:31 +0000
Subject: [docs] [issue9956] memoryview type documentation lacks versionadded
In-Reply-To: <1285544669.44.0.903225365456.issue9956@psf.upfronthosting.co.za>
Message-ID: <1285544971.62.0.198309297736.issue9956@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85022

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

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

From report at bugs.python.org  Mon Sep 27 20:27:57 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 27 Sep 2010 18:27:57 +0000
Subject: [docs] [issue1665333] Documentation missing for OptionGroup class
	in optparse
Message-ID: <1285612077.29.0.56562107678.issue1665333@psf.upfronthosting.co.za>


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

I will work on it, it noone objects.

Cheers,
Sandro

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

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

From report at bugs.python.org  Mon Sep 27 21:17:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 19:17:34 +0000
Subject: [docs] [issue9934] Python Docs Typo
In-Reply-To: <1285286528.33.0.133742788875.issue9934@psf.upfronthosting.co.za>
Message-ID: <1285615054.74.0.476674902815.issue9934@psf.upfronthosting.co.za>


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

Ported to distutils2 in 2f460982b025, thanks!

----------
components: +Distutils2
nosy: +eric.araujo

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

From report at bugs.python.org  Mon Sep 27 22:01:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 20:01:04 +0000
Subject: [docs] [issue9956] memoryview type documentation lacks versionadded
In-Reply-To: <1285544669.44.0.903225365456.issue9956@psf.upfronthosting.co.za>
Message-ID: <1285617663.87.0.79191947071.issue9956@psf.upfronthosting.co.za>


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

Python 3.1 is considered a new start, so there is no versionadded:: 3.1.  The directive is used for things new in 3.2 and later versions.  Thanks for the patch!

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

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

From report at bugs.python.org  Mon Sep 27 22:10:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 27 Sep 2010 20:10:28 +0000
Subject: [docs] [issue1703592] have a way to ignore nonexisting locales
	in	locale.setlocale
Message-ID: <1285618228.16.0.0688389320409.issue1703592@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep 28 15:22:00 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 13:22:00 +0000
Subject: [docs] [issue9970] PyMemoryView_FromBuffer is not documented
In-Reply-To: <1285680120.22.0.180975662294.issue9970@psf.upfronthosting.co.za>
Message-ID: <1285680120.22.0.180975662294.issue9970@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

PyMemoryView_FromBuffer() in Include/memoryobject.h is undocumented.

The function name seems to indicate that it intended to be a public API.

----------
assignee: docs at python
components: Documentation
messages: 117518
nosy: docs at python, ronaldoussoren
priority: normal
severity: normal
status: open
title: PyMemoryView_FromBuffer is not documented
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Sep 28 17:35:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Sep 2010 15:35:41 +0000
Subject: [docs] [issue9970] PyMemoryView_FromBuffer is not documented
In-Reply-To: <1285680120.22.0.180975662294.issue9970@psf.upfronthosting.co.za>
Message-ID: <1285688141.06.0.562141135125.issue9970@psf.upfronthosting.co.za>


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

Fixed, thank you.

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

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

From report at bugs.python.org  Tue Sep 28 17:46:39 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 15:46:39 +0000
Subject: [docs] [issue812750] OSA support for properties broken
Message-ID: <1285688799.33.0.433136456665.issue812750@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've applied the documentation patch that Ned suggests in r

I'm furthermore closing this issue as "Won't Fix" because the OSA bindings are no longer developed and we'll therefore not implement the new feature that Jack mentions.

----------
nosy: +ronaldoussoren
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Sep 28 17:47:42 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 28 Sep 2010 15:47:42 +0000
Subject: [docs] [issue812750] OSA support for properties broken
Message-ID: <1285688862.09.0.73105483931.issue812750@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Sent the message too soon... the documentation update is in r85069.

----------

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

From report at bugs.python.org  Tue Sep 28 19:15:20 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 28 Sep 2010 17:15:20 +0000
Subject: [docs] [issue9666] 'hasattr' fix to suppress only AttributeError
In-Reply-To: <1282618571.72.0.746588634044.issue9666@psf.upfronthosting.co.za>
Message-ID: <1285694120.79.0.714223118306.issue9666@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Tue Sep 28 22:14:52 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 28 Sep 2010 20:14:52 +0000
Subject: [docs] [issue1665333] Documentation missing for OptionGroup class
	in optparse
Message-ID: <1285704892.65.0.984792809574.issue1665333@psf.upfronthosting.co.za>


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

Hello,
attached is a patch to improve the OptionGroup documentation. I've also changed usage->Usage and options->Options in the examples output, since now the code tries to guess the lower case word and rewrites with the capitalized one.

I'm willing to improve the patch in case there's something not good (and I bet there is, since it's my first complex patch for Python documentation) so please be nice :) and point me to parts that can be improved.

Thanks in advance,
Sandro

----------
keywords: +patch
Added file: http://bugs.python.org/file19051/issue1665333-py3k.patch

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

From report at bugs.python.org  Tue Sep 28 22:34:02 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 28 Sep 2010 20:34:02 +0000
Subject: [docs] [issue1665333] Documentation missing for OptionGroup class
	in optparse
Message-ID: <1285706042.4.0.60377975326.issue1665333@psf.upfronthosting.co.za>


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

sorry, I forgot to wrap at column 80, this patch just changes that.

----------
Added file: http://bugs.python.org/file19052/issue1665333-py3k-v2.patch

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

From report at bugs.python.org  Wed Sep 29 13:11:42 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:11:42 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

please add a large NOTE explaining that urllib does not perform any ssl validation.

----------
assignee: docs at python
components: Documentation
messages: 117596
nosy: db, docs at python
priority: normal
severity: normal
status: open
title: please add a large NOTE explaining that urllib does not perform any ssl validation
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep 29 13:12:10 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:12:10 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758730.59.0.656379503498.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

--> (out of the box)

----------

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

From report at bugs.python.org  Wed Sep 29 13:13:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:13:11 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758791.56.0.750974853584.issue9983@psf.upfronthosting.co.za>


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

Sounds reasonable to me.
(although I would like that to change, see issue1589)

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

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

From report at bugs.python.org  Wed Sep 29 13:13:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:13:36 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758816.58.0.8355492438.issue9983@psf.upfronthosting.co.za>


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


----------
nosy: +orsenthil
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Sep 29 13:14:04 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:14:04 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285758843.9.0.544065139159.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

This is issue is in respect to https connections :)

----------

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

From report at bugs.python.org  Wed Sep 29 13:16:54 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:16:54 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285759014.52.0.307888445885.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

Hi pitrou, that bug you linked to is really long can state a summary of any changes made to python and their impact - alternatively the lack of (changes) and their impact.

----------

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

From report at bugs.python.org  Wed Sep 29 13:18:21 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:18:21 +0000
Subject: [docs] [issue9984] please add a large NOTE explaining that urllib2
	does not	perform any ssl validation
In-Reply-To: <1285759058.32.0.409782287474.issue9984@psf.upfronthosting.co.za>
Message-ID: <1285759101.93.0.536919019401.issue9984@psf.upfronthosting.co.za>


Changes by david <db.pub.mail at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 2.7

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

From report at bugs.python.org  Wed Sep 29 13:22:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:22:45 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285759014.52.0.307888445885.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285759360.3168.0.camel@localhost.localdomain>


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

> Hi pitrou, that bug you linked to is really long can state a summary
> of any changes made to python and their impact - alternatively the
> lack of (changes) and their impact.

No changes yet unfortunately. As for the impact, you already know it,
since you filed this very issue :/

----------

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

From report at bugs.python.org  Wed Sep 29 13:32:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:32:12 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285759931.91.0.202122448829.issue9983@psf.upfronthosting.co.za>


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

I've added warnings for httplib, urllib, urllib2 in r85101, r85102 and r85103. The changes can take a day or two to appear online.

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

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

From report at bugs.python.org  Wed Sep 29 13:32:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:32:45 +0000
Subject: [docs] [issue9984] please add a large NOTE explaining that urllib2
	does not	perform any ssl validation
In-Reply-To: <1285759058.32.0.409782287474.issue9984@psf.upfronthosting.co.za>
Message-ID: <1285759965.26.0.694515314545.issue9984@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> please add a large NOTE explaining that urllib does not perform any ssl validation

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

From report at bugs.python.org  Wed Sep 29 13:41:40 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 11:41:40 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285760500.68.0.800730068202.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

thank you :)

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

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

From report at bugs.python.org  Wed Sep 29 13:42:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 11:42:32 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285760552.09.0.595405108287.issue9983@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep 29 15:07:20 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 13:07:20 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285765640.77.0.351320281403.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

@pitrou you should also put an example of how to ACTUALLY establish a connection that can't be MITMed. Because lots of people are getting this wrong....

----------

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

From report at bugs.python.org  Wed Sep 29 15:11:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 13:11:56 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285765640.77.0.351320281403.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285765909.3168.13.camel@localhost.localdomain>


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

> @pitrou you should also put an example of how to ACTUALLY establish a
> connection that can't be MITMed. Because lots of people are getting
> this wrong....

It would require writing the code for checking hostnames that the ssl
module currently lacks, so if I write that code I'd rather add it to the
ssl module rather than as an example in the docs :)

But, yes, I agree that the situation is quite unsatisfying right now.

----------

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

From report at bugs.python.org  Wed Sep 29 16:32:10 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 14:32:10 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285765909.3168.13.camel@localhost.localdomain>
Message-ID: <AANLkTinWkSQQxzuwJJO94PC7XOTDjqeG0qAcuZCvKzCi@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

Yes totally imho these modules should get fixed to actually do ssl checking.
This means that most users of these methods, even if they think they
are doing it properly as per the ssl module page, are still vulnerable
to attack.

I will add this comment to the bug you linked to above.
As an example, it only took a few minutes to confirm that the default
bzr install on ubuntu is vulnerable ->
https://bugs.edge.launchpad.net/bzr/+bug/651161
(bzr is only vulnerable if pycurl isn't installed but pycurl is only a
suggestion not a dependency ... ).

----------

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

From report at bugs.python.org  Wed Sep 29 17:07:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 29 Sep 2010 15:07:52 +0000
Subject: [docs] [issue9986] PDF files of python docs have text missing
In-Reply-To: <1285772054.59.0.857308007062.issue9986@psf.upfronthosting.co.za>
Message-ID: <1285772872.51.0.386008627253.issue9986@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python
type:  -> behavior

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

From report at bugs.python.org  Wed Sep 29 20:27:38 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 29 Sep 2010 18:27:38 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285784858.16.0.178342867934.issue9983@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Wed Sep 29 22:26:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 29 Sep 2010 20:26:32 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285791992.13.0.189907405344.issue9983@psf.upfronthosting.co.za>


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

Please don't say that "urllib does not perform any ssl validation". It certainly *does* perform ssl validation, namely it validates whether the payload received over ssl matches the certificate received from the server.

What it does not do is to validate the server certificate in any form (AFAIU).

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

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

From report at bugs.python.org  Wed Sep 29 22:31:10 2010
From: report at bugs.python.org (david)
Date: Wed, 29 Sep 2010 20:31:10 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285792270.43.0.898818387896.issue9983@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

@loewis yes.. that is assumed imho.
This ticket is closed, is this a real issue?

----------

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

From report at bugs.python.org  Wed Sep 29 22:40:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 29 Sep 2010 20:40:20 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285791992.13.0.189907405344.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285792813.3194.46.camel@localhost.localdomain>


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

> What it does not do is to validate the server certificate in any form (AFAIU).

The warning I have added says ?When opening HTTPS (or FTPS) URLs, it is
not attempted to validate the server certificate.?
(see http://docs.python.org/library/urllib.html )

So I don't think we have a disagreement here.

----------

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

From report at bugs.python.org  Wed Sep 29 23:15:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 29 Sep 2010 21:15:39 +0000
Subject: [docs] [issue9983] please add a large NOTE explaining that urllib
	does not	perform any ssl validation
In-Reply-To: <1285758702.65.0.712846452634.issue9983@psf.upfronthosting.co.za>
Message-ID: <1285794939.33.0.368774612269.issue9983@psf.upfronthosting.co.za>


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

Yes, the new text is fine.

----------

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

From report at bugs.python.org  Thu Sep 30 01:43:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 29 Sep 2010 23:43:42 +0000
Subject: [docs] [issue901727] extra_path kwarg to setup() undocumented
Message-ID: <1285803822.44.0.446070415699.issue901727@psf.upfronthosting.co.za>


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


----------
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Sep 30 04:02:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 02:02:20 +0000
Subject: [docs] [issue8255] step-by-step tutorial
In-Reply-To: <1269787637.04.0.463586986817.issue8255@psf.upfronthosting.co.za>
Message-ID: <1285812140.92.0.191919580673.issue8255@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep 30 17:17:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 30 Sep 2010 15:17:20 +0000
Subject: [docs] [issue9986] PDF files of python docs have text missing
In-Reply-To: <1285772054.59.0.857308007062.issue9986@psf.upfronthosting.co.za>
Message-ID: <1285859840.51.0.874876142535.issue9986@psf.upfronthosting.co.za>


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

It looks like this should be solved in Sphinx.  Can you report this on its tracker at Bitbucket?  Thanks.

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

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

From report at bugs.python.org  Thu Sep 30 20:36:44 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 30 Sep 2010 18:36:44 +0000
Subject: [docs] [issue9112] argparse missing documentation for error() method
In-Reply-To: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>
Message-ID: <1285871804.3.0.0874884182621.issue9112@psf.upfronthosting.co.za>


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

Hello,
attached a patch that adds the exiting methods (exit() and error()) to argparse documentation.

Regards,
Sandro

----------
keywords: +patch
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19070/issue9112-py3k.patch

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

From jh45dev at gmail.com  Mon Sep 27 06:54:22 2010
From: jh45dev at gmail.com (John Hensby)
Date: Mon, 27 Sep 2010 14:54:22 +1000
Subject: [docs] master list of file properties
Message-ID: <4CA0237E.6070207@gmail.com>

The TextIOWrapper has a name attribute,
but that fact not easily discovered because
name is mentioned only under 15.2.3. *Raw* File I/O.

Would it be a good idea to make a list of all the
properties that are possessed by most normal files,
and put it where the user-in-a-hurry can find it easily.
Linking to it from the builtin open function may help too.

Sorry I don't have time to do it myself.

-- jh



From public.marvin at gmail.com  Mon Sep 27 14:49:28 2010
From: public.marvin at gmail.com (Marvin Greenberg)
Date: Mon, 27 Sep 2010 08:49:28 -0400
Subject: [docs] logging.Formatter processName added in 2.7
Message-ID: <4CA092D8.4040107@gmail.com>

  But the documentation does not say that, although it does say that funcName 
was added in 2.5

From michaelweaser at gmail.com  Mon Sep 27 20:29:18 2010
From: michaelweaser at gmail.com (michael weaser)
Date: Mon, 27 Sep 2010 14:29:18 -0400
Subject: [docs] 2.6 documentation
Message-ID: <AANLkTik5DXwqtemu54rqbP-mXLkXnkDiEHmyGfnOAh+B@mail.gmail.com>

i cant download the 2.6 documentation from docs.python.org/release/2.6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100927/c08bdeae/attachment-0001.html>

From development at alexander-behringer-online.de  Tue Sep 28 00:11:11 2010
From: development at alexander-behringer-online.de (Alexander Behringer)
Date: Tue, 28 Sep 2010 00:11:11 +0200
Subject: [docs] little mistake in documentation of dis.opmap in the dis
	module
Message-ID: <201009280011.11264.development@alexander-behringer-online.de>

Hello,

I think I have discovered a little mistake in the documentation of the 
disassembler module. There it says [1, 2, 3]:

> dis.opmap
>      Dictionary mapping bytecodes to operation names.

But for me it looks more like a mapping of operation names to bytecodes.

[1] http://docs.python.org/library/dis.html#dis.opmap
[2] http://docs.python.org/py3k/library/dis.html#dis.opmap
[3] http://docs.python.org/dev/py3k/library/dis.html#dis.opmap

Sincerely,
Alexander

From thaakir.stegmann at gmail.com  Tue Sep 28 16:53:42 2010
From: thaakir.stegmann at gmail.com (Muhammad Thaakir Stegmann)
Date: Tue, 28 Sep 2010 16:53:42 +0200
Subject: [docs] programming
Message-ID: <AANLkTin8PQnL32J56gkvQEAvQZn1K9WN86LJpUFCJUpU@mail.gmail.com>

My name is Muhammad Thaakir Stegmann and I am 13 years old.I started
programming with python at the start of the year with a man named neil.I
have python on my computer and I was wondering if you could point me in the
right direction as to how I can download the libraries for python.Can you
please help me out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100928/2dceb975/attachment-0001.html>

From thaakir.stegmann at gmail.com  Tue Sep 28 17:07:10 2010
From: thaakir.stegmann at gmail.com (Muhammad Thaakir Stegmann)
Date: Tue, 28 Sep 2010 17:07:10 +0200
Subject: [docs] portable python
Message-ID: <AANLkTincwzczUHb7XrUcX9q2NBH8sRrOSG1tv8+8Y+9w@mail.gmail.com>

I have also done a 3 day course at UCT with python.I was also wondering how
i should go about downloading portable python?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100928/189746ec/attachment-0001.html>

From njvack at wisc.edu  Tue Sep 28 18:27:28 2010
From: njvack at wisc.edu (Nate Vack)
Date: Tue, 28 Sep 2010 11:27:28 -0500
Subject: [docs] Example values for dict()
Message-ID: <AANLkTim4YGNtF6JAZ+QwRo==J48d3gYOFLWThgesy5TA@mail.gmail.com>

Hi all,

The docs on creating new dicts found here:

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

just warped my mind a little bit. They all create the dict {'one': 2,
'two', 3} -- creating {'one': 1, 'two': 2} would make a little more
sense.

Cheers,
-Nate

From eric.takada at embraer.com.br  Tue Sep 28 17:53:37 2010
From: eric.takada at embraer.com.br (eric.takada at embraer.com.br)
Date: Tue, 28 Sep 2010 12:53:37 -0300
Subject: [docs] Algorithm error
Message-ID: <OF8FC09F79.3BEA45C8-ON832577AC.0056C3DF-832577AC.00574EB7@embraer.com.br>

Hi, 

in section "4.4 break and continue Statements, and else Clauses on Loops" 
there is an error in the example code. The "range" in "for x in range(2, 
n): " shall be changed to "range(1,n):" in order to produce the output 
described in the example, since "range[2,2]" produces a null result.

Regards,

Eric Takada

This message is intended solely for the use of its addressee and may 
contain privileged or confidential information. All information contained 
herein shall be treated as confidential and shall not be disclosed to any 
third party without Embraer?s prior written approval. If you are not the 
addressee you should not distribute, copy or file this message. In this 
case, please notify the sender and destroy its contents immediately.
Esta mensagem ? para uso exclusivo de seu destinat?rio e pode conter 
informa??es privilegiadas e confidenciais. Todas as informa??es aqui 
contidas devem ser tratadas como confidenciais e n?o devem ser divulgadas 
a terceiros sem o pr?vio consentimento por escrito da Embraer. Se voc? n?o 
? o destinat?rio n?o deve distribuir, copiar ou arquivar a mensagem. Neste 
caso, por favor, notifique o remetente da mesma e destrua imediatamente a 
mensagem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100928/c068c1f5/attachment-0001.html>

From i.amber.jain at gmail.com  Tue Sep 28 19:27:27 2010
From: i.amber.jain at gmail.com (Amber Jain)
Date: Tue, 28 Sep 2010 13:27:27 -0400
Subject: [docs] PDF files of python docs have text missing
Message-ID: <AANLkTikebP8kMGgx1wk8xGMBXmSJmQ6SRfiu0Haa6QAk@mail.gmail.com>

Hello,

I'm new to python and I was planning to print the official python tutorial:
http://docs.python.org/tutorial/index.html.
So, I went over to Download page: http://docs.python.org/download.html and
downloaded the PDF file. But the PDF have some missing text due to width of
page being less than number of chars to put on a line.
For example, please have a look at page-21 (Section 3.1.3 titled "Unicode
Strings"). It has an incomplete line from HTML documentation.
Here's a screenshot of what I see (and mean):
http://amberj.devio.us/pub/screenshots/pdfdoc.png

There's a line somewhere in the middle of screenshot which goes out of
boundary of PDF document and fails to put out-of-boundary text on newline.
>From what I had read, it seems that this happens only with 'code snippets'
in tutorial. This is probably a problem with convertor (HTML to PDF?).

Can you guys please fix it?
Thanks a lot.

-- 
Amber Jain
i.amber.jain at gmail.com
http://amberj.devio.us/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100928/f1768ccf/attachment.html>