From report at bugs.python.org  Thu Mar  1 01:00:48 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 01 Mar 2012 00:00:48 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
Message-ID: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>


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

After an intro, the tkinter docs start with a traditional 'Hello World'.
http://docs.python.org/py3k/library/tkinter.html#a-simple-hello-world-program

Problem 1. The example ends with 
root.destroy
John Salerno, today, on python-list thread "Is it necessary to call Tk() when writing a GUI app with Tkinter?", reported the following, which I verified. On Windows, at least, closing the unlabelled Tk window by clicking the normal [X} close button on the frame causes

_tkinter.TclError: can't invoke "destroy" command:  application has been destroyed

This does not happen if one instead clicks the QUIT button inside the frame (as that does not destroy the app).

Question 1a. Does the example work the same with current tcl/tk on *nix and mac?

I assume it should, but I do not know if the example was buggy from the beginning or if something changes. In any case, I do not want to commit a solution that is not tested on more than my Win7.

Question 1b. How do we most simply fix this part of the example?

In '''self.QUIT["command"] = self.quit''', I changed 'quit' to 'destroy' and the result is to destroy the widgets but leave the outer frame and continue the mainloop.

I tried another solution based on adding
        self.protocol("WM_DELETE_WINDOW", self.onDestroyWindow)
to __init__(), but while this worked for Rick Johnson's class App(tk.Tk) example in his response to Salerno, it does not work for this class Application(Frame) example as the latter has no .protocol attribute.
---

Problem 2. A 'Hello World' example should say 'Hello World' instead of just 'hello'. So I make the trivial edit and tk add braces and displays '{Hello World}'. What??? Adding '\n' does not trigger brace addition, so  "Hello_World\n(click_me)" works as expected.

Queston 2. How does one put a space in a button label with triggering addition of braces, or is this impossible?
---

Problem and Solution 3. The example currently puts a loud capital red QUIT button first, and the quiet lowercase blass hello button second. This is backwards in both placement and emphasis. Putting the expanded hello buttom on top and QUIT under looks better to me.
---

Problem 4 (in the intro, before the example): There is a lot that could be changed or added to the doc, but I think revising 

to use Tkinter all you need is a simple import statement:
import tkinter
Or, more often:
from tkinter import *

(3.x version) to add what I think is the best option, 'import tkinter as tk', as at least equal to the '*' option, should be done soon. I am thinking of something like

to use Tkinter, use one of these import statements:
import tkinter
import tkinter as tk
from tkinter import *

----------
assignee: docs at python
components: Documentation, Tkinter
messages: 154669
nosy: docs at python, ned.deily, serwy, terry.reedy
priority: normal
severity: normal
status: open
title: tkinter: problems with hello doc example
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Mar  1 06:15:53 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 01 Mar 2012 05:15:53 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <1330578953.52.0.868207573808.issue14163@psf.upfronthosting.co.za>


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

Rick Johnson anwered question 1b on python-list: simply move root.destroy to the button. I make other changes also: use import...as; show that options can be set in constructor call. File uploaded.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file24693/tk_hello.py

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

From report at bugs.python.org  Thu Mar  1 06:23:20 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Mar 2012 05:23:20 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330579400.03.0.704162786959.issue11379@psf.upfronthosting.co.za>


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

I?m not sure I would use note markup, though (cf. Raymond?s aversion to littering the doc with note and warning boxes).

----------

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

From report at bugs.python.org  Thu Mar  1 07:33:51 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 01 Mar 2012 06:33:51 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1330579400.03.0.704162786959.issue11379@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-pvjW9d==TPxm96Zu-rVdmW1GtYB_+ffjozhG9H45UBA@mail.gmail.com>


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

>
> I?m not sure I would use note markup, though (cf. Raymond?s aversion to
> littering the doc with note and warning boxes).
>

I also dislike box littering, but this one seems like a really good fit for
a note, since it's completely outside the flow of that documentation page.

----------

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

From report at bugs.python.org  Thu Mar  1 08:04:25 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 01 Mar 2012 07:04:25 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330585465.57.0.136913857414.issue11379@psf.upfronthosting.co.za>


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

This is a reasonable case for a note.

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

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

From report at bugs.python.org  Thu Mar  1 12:04:20 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Mar 2012 11:04:20 +0000
Subject: [docs] [issue14155] Deja vu in re's documentation
In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>
Message-ID: <1330599860.68.0.195125895917.issue14155@psf.upfronthosting.co.za>


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

Do you think I should mention that you can still use match and a regex that starts to ^ in combination with the start argument of r.match to match at the beginning of a line?
I'm not sure that's necessary.

----------

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

From report at bugs.python.org  Thu Mar  1 13:25:26 2012
From: report at bugs.python.org (John Napster)
Date: Thu, 01 Mar 2012 12:25:26 +0000
Subject: [docs] [issue14164] my little contribution to the docs
Message-ID: <1330604725.79.0.785320238353.issue14164@psf.upfronthosting.co.za>


New submission from John Napster <john.napnap at gmail.com>:

This patch fixes some small grammar things in the docs. Hope you like my contribution.

----------
assignee: docs at python
components: Documentation
files: patch.diff
keywords: patch
messages: 154688
nosy: docs at python, joenapnap
priority: normal
severity: normal
status: open
title: my little contribution to the docs
type: enhancement
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file24695/patch.diff

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

From report at bugs.python.org  Thu Mar  1 13:32:13 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 01 Mar 2012 12:32:13 +0000
Subject: [docs] [issue14164] my little contribution to the docs
In-Reply-To: <1330604725.79.0.785320238353.issue14164@psf.upfronthosting.co.za>
Message-ID: <1330605133.68.0.0899079719235.issue14164@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
versions: +Python 3.3

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

From report at bugs.python.org  Thu Mar  1 14:07:01 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 01 Mar 2012 13:07:01 +0000
Subject: [docs] [issue14164] my little contribution to the docs
In-Reply-To: <1330604725.79.0.785320238353.issue14164@psf.upfronthosting.co.za>
Message-ID: <1330607220.99.0.33476546337.issue14164@psf.upfronthosting.co.za>


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

See also #13868 by Retro.

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

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

From report at bugs.python.org  Thu Mar  1 14:52:36 2012
From: report at bugs.python.org (Sven Marnach)
Date: Thu, 01 Mar 2012 13:52:36 +0000
Subject: [docs] [issue14165] The new shlex.quote() function should be marked
	"New in	version 3.3"
Message-ID: <1330609956.34.0.635238408021.issue14165@psf.upfronthosting.co.za>


New submission from Sven Marnach <sven at marnach.net>:

The function shlex.quotes() [1] does not yet exist in Python 3.2 [2], so it should be marked "New in version 3.3." in the docs.

I double-checked that it really does not yet exist in 3.2 and is not only missing from the 3.2 documentation.

[1]: http://docs.python.org/dev/library/shlex.html#shlex.quote
[2]: http://docs.python.org/py3k/library/shlex.html

----------
assignee: docs at python
components: Documentation
messages: 154693
nosy: docs at python, smarnach
priority: normal
severity: normal
status: open
title: The new shlex.quote() function should be marked "New in version 3.3"
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar  1 15:10:06 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 01 Mar 2012 14:10:06 +0000
Subject: [docs] [issue14164] my little contribution to the docs
In-Reply-To: <1330604725.79.0.785320238353.issue14164@psf.upfronthosting.co.za>
Message-ID: <1330611006.89.0.938486887186.issue14164@psf.upfronthosting.co.za>


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

John, thanks for the contribution, however this is not a valid fix. 

See the Wikipedia page for floating point: http://en.wikipedia.org/wiki/Floating_point

No dash! 

There is no need to go over the Python docs fixing such "mistakes". If you have time to contribute to Python, there's *plenty* of opportunities to do so in a useful way.

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

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

From report at bugs.python.org  Thu Mar  1 15:54:50 2012
From: report at bugs.python.org (Matthew Johnson)
Date: Thu, 01 Mar 2012 14:54:50 +0000
Subject: [docs] [issue14164] my little contribution to the docs
In-Reply-To: <1330604725.79.0.785320238353.issue14164@psf.upfronthosting.co.za>
Message-ID: <1330613690.6.0.0807622940868.issue14164@psf.upfronthosting.co.za>


Matthew Johnson <mat.joh123 at gmail.com> added the comment:

I think he's right to fix those "mistakes". Just see the first sentence @ http://docs.python.org/tutorial/floatingpoint.html#floating-point-arithmetic-issues-and-limitations

It reads: "Floating-point numbers are represented in [...]"

So as you can see, there are places in the docs where the hyphen/dash is there, other places where it is not. I, personally, don't get the whole "some places yes, someplaces no" philosophy. I think the patch should be applied. I think he was just trying to make some consistentcy in the docs as his first contribution.

I must also point out that I don't understand the whole "some places title-case, other places sentence-case" titles in the docs. It's kind of confusing.

What are your thoughts about all this?

----------
nosy: +Matthew.Johnson

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

From report at bugs.python.org  Thu Mar  1 16:07:09 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 01 Mar 2012 15:07:09 +0000
Subject: [docs] [issue14167] document return statement in finally blocks
Message-ID: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

I think that the documentation should put more emphasis on the `return` statement in a `finally` block.

Example:

  def test():
      try:
          1/0
      finally:
          return 10

  >>> test()
  10

I think we need to add a warning, or at least a note, that 'return' masks exceptions, if any occurred.

----------
assignee: docs at python
components: Documentation
messages: 154697
nosy: Yury.Selivanov, docs at python, georg.brandl, rhettinger
priority: normal
severity: normal
status: open
title: document return statement in finally blocks
type: enhancement
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Mar  1 17:44:16 2012
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 01 Mar 2012 16:44:16 +0000
Subject: [docs] [issue5626] misleading comment in socket.gethostname()
	documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1330620256.01.0.167454579277.issue5626@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file24698/issue5626_v1.diff

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

From report at bugs.python.org  Thu Mar  1 17:44:33 2012
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 01 Mar 2012 16:44:33 +0000
Subject: [docs] [issue5626] misleading comment in socket.gethostname()
	documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1330620273.72.0.620069165595.issue5626@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Thu Mar  1 17:57:35 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 01 Mar 2012 16:57:35 +0000
Subject: [docs] [issue14165] The new shlex.quote() function should be marked
	"New in	version 3.3"
In-Reply-To: <1330609956.34.0.635238408021.issue14165@psf.upfronthosting.co.za>
Message-ID: <1330621055.29.0.535642124933.issue14165@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/issue14165>
_______________________________________

From report at bugs.python.org  Thu Mar  1 18:08:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Mar 2012 17:08:08 +0000
Subject: [docs] [issue14165] The new shlex.quote() function should be marked
	"New in	version 3.3"
In-Reply-To: <1330609956.34.0.635238408021.issue14165@psf.upfronthosting.co.za>
Message-ID: <E1S39U6-00035o-LA@dinsdale.python.org>


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

New changeset 73be78d21003 by Eli Bendersky in branch 'default':
Add missing 'versionadded' for shlex.quote; closes #14165
http://hg.python.org/cpython/rev/73be78d21003

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

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

From report at bugs.python.org  Thu Mar  1 19:08:45 2012
From: report at bugs.python.org (poq)
Date: Thu, 01 Mar 2012 18:08:45 +0000
Subject: [docs] [issue14164] my little contribution to the docs
In-Reply-To: <1330604725.79.0.785320238353.issue14164@psf.upfronthosting.co.za>
Message-ID: <1330625325.05.0.905835305825.issue14164@psf.upfronthosting.co.za>


poq <poq at gmx.com> added the comment:

It is generally considered more correct to write "floating-point number", because "floating-point" is a compound adjective here. The hyphen clarifies that it should be parsed as ((floating point) number) instead of (floating (point number)).

However, in practice "floating point number" is also commonly used. I completely agree with Eli that this is just nitpicking, and not a productive use of Python developers' time.

----------
nosy: +poq

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

From report at bugs.python.org  Thu Mar  1 19:20:30 2012
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 01 Mar 2012 18:20:30 +0000
Subject: [docs] [issue14164] Hyphenation suggestions -
	floating-point/floating point
In-Reply-To: <1330604725.79.0.785320238353.issue14164@psf.upfronthosting.co.za>
Message-ID: <1330626030.39.0.393643080307.issue14164@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:

Hyphenation changes are not going to be made unless the current text is actually incorrect, confusing, or leads to people misunderstanding what is meant.

----------
nosy: +brian.curtin
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed
title: my little contribution to the docs -> Hyphenation suggestions - floating-point/floating point

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

From report at bugs.python.org  Thu Mar  1 20:13:10 2012
From: report at bugs.python.org (Andrew Smith)
Date: Thu, 01 Mar 2012 19:13:10 +0000
Subject: [docs] [issue14164] Hyphenation suggestions -
	floating-point/floating point
In-Reply-To: <1330604725.79.0.785320238353.issue14164@psf.upfronthosting.co.za>
Message-ID: <1330629190.67.0.338139668085.issue14164@psf.upfronthosting.co.za>


Andrew Smith <smith.cookies123 at gmail.com> added the comment:

I think he was trying to say that there is inconsistency in the docs... And since you guys are all about consistency... Why the punch below the belt?

----------
nosy: +Andrew.Smith

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

From report at bugs.python.org  Thu Mar  1 20:14:46 2012
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 01 Mar 2012 19:14:46 +0000
Subject: [docs] [issue14164] Hyphenation suggestions -
	floating-point/floating point
In-Reply-To: <1330604725.79.0.785320238353.issue14164@psf.upfronthosting.co.za>
Message-ID: <1330629286.99.0.280310938923.issue14164@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

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

From report at bugs.python.org  Thu Mar  1 20:51:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Mar 2012 19:51:21 +0000
Subject: [docs] [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <E1S3C24-0002YP-5k@dinsdale.python.org>


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

New changeset d2cf730de195 by Petri Lehtinen in branch '2.7':
sqlite3: Port relevant documentation changes from 3.2
http://hg.python.org/cpython/rev/d2cf730de195

New changeset 5f492397ccb8 by Petri Lehtinen in branch '3.2':
sqlite3: Port documentation changes from the 2.7 branch
http://hg.python.org/cpython/rev/5f492397ccb8

New changeset 82032c64dd89 by Petri Lehtinen in branch 'default':
Merge branch '3.2'
http://hg.python.org/cpython/rev/82032c64dd89

----------

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

From report at bugs.python.org  Thu Mar  1 20:53:54 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 01 Mar 2012 19:53:54 +0000
Subject: [docs] [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1330631634.86.0.797902296114.issue13491@psf.upfronthosting.co.za>


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

All patches applied, thanks everybody!

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

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

From report at bugs.python.org  Thu Mar  1 22:53:37 2012
From: report at bugs.python.org (py.user)
Date: Thu, 01 Mar 2012 21:53:37 +0000
Subject: [docs] [issue14155] Deja vu in re's documentation
In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>
Message-ID: <1330638817.43.0.533117578274.issue14155@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

this sentence was deleted:
http://docs.python.org/py3k/library/re.html#matching-vs-searching
"The ?match? operation succeeds only if the pattern matches
at the start of the string regardless of mode,
or at the starting position given by the optional pos argument
regardless of whether a newline precedes it."

this sentence exists now:
http://docs.python.org/dev/library/re.html#re.match
"Note that even in MULTILINE mode, re.match() will only match at the beginning of the string
and not at the beginning of each line."


but the multiline mode affects on regex.match()
a reader may confuse re.match() and regex.match(), although regex.match() cites to regex.search()

----------

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

From report at bugs.python.org  Thu Mar  1 22:53:51 2012
From: report at bugs.python.org (py.user)
Date: Thu, 01 Mar 2012 21:53:51 +0000
Subject: [docs] [issue14155] Deja vu in re's documentation
In-Reply-To: <1330481540.05.0.869825762197.issue14155@psf.upfronthosting.co.za>
Message-ID: <1330638831.22.0.464816631329.issue14155@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

I won't open another topic:
1)
http://docs.python.org/py3k/library/re.html#regular-expression-syntax
"Most of the standard escapes supported by Python string literals
are also accepted by the regular expression parser:

\a      \b      \f      \n
\r      \t      \v      \x
\\
"


\b can be used only in character set [], when others can be used without it

2)
http://docs.python.org/py3k/library/re.html#regular-expression-syntax
"Octal escapes are included in a limited form.
If the first digit is a 0, or if there are three octal digits,
it is considered an octal escape. Otherwise, it is a group reference.
As for string literals, octal escapes are always at most three digits in length."

http://docs.python.org/py3k/library/re.html#regular-expression-syntax
description of the back refference:
"\number
    Matches the contents of the group of the same number.
    Groups are numbered starting from 1. For example, (.+) \1 matches 'the the' or '55 55',
    but not 'the end' (note the space after the group).
    This special sequence can only be used to match one of the first 99 groups.
    If the first digit of number is 0, or number is 3 octal digits long,
    it will not be interpreted as a group match, but as the character with octal value number.
    Inside the '[' and ']' of a character class, all numeric escapes are treated as characters."


a duplicate

----------

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

From report at bugs.python.org  Fri Mar  2 04:38:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Mar 2012 03:38:24 +0000
Subject: [docs] [issue14165] The new shlex.quote() function should be marked
	"New in	version 3.3"
In-Reply-To: <1330609956.34.0.635238408021.issue14165@psf.upfronthosting.co.za>
Message-ID: <1330659504.77.0.123564892141.issue14165@psf.upfronthosting.co.za>


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

Thanks, I forgot that :)  shlex.quote used to be pipes.quote, an undocumented but used function; do you think this should be mentioned in shlex.quote?s doc to let people know thaw if they used pipes.quote they have an official upgrade path, or should we just leave it at that?

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

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

From report at bugs.python.org  Fri Mar  2 05:38:57 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Mar 2012 04:38:57 +0000
Subject: [docs] [issue14167] document return statement in finally blocks
In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za>
Message-ID: <1330663137.72.0.781566627988.issue14167@psf.upfronthosting.co.za>


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

This behavior surprised me for a second, but it makes sense.  An example in the docs is certainly appropriate.  Would you like to suggest a place and phrasing for it?

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

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

From report at bugs.python.org  Fri Mar  2 06:06:05 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Mar 2012 05:06:05 +0000
Subject: [docs] [issue14164] Hyphenation suggestions -
	floating-point/floating point
In-Reply-To: <1330604725.79.0.785320238353.issue14164@psf.upfronthosting.co.za>
Message-ID: <1330664765.77.0.306212029082.issue14164@psf.upfronthosting.co.za>


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

Python has a lot of known and unknown bugs that need to be fixed, many missing features needing to be implemented, and a lot of room for improvement in its documentation.  That?s why we welcome people who want to help.

You?re not the first one to propose a trivial typographic patch that is rejected.  I?m writing this long-ish message to serve as a reference for future rejections.

Maybe you thought it would be a risk-free way to become a contributor, but as it turns out, this kind of patches is not helpful.  All Python developers are volunteers, and we review bugs and patches on our limited free time.  It is worthwhile to fix clear errors, ambiguities, outdated facts and wrong advice in the documentation; it is not worthwhile to add or remove a few commas and hyphens just for consistency?s sake.  (Moreover, hyphens in English don?t have rules as clear as we commonly think, like poq pointed.)

There is no ?some places title-case, other places sentence-case? philosophy; different people wrote various parts of the documentation, and we just live with it.  We fix bugs, improve code, add examples, think about missing features, read specifications, reply to email, improve wordings; we just don?t have the time to care about questionable changes that don?t add any value for us or our users.  Consistency is a design principle; it does not mean obsessive polishing.  There are also other principles that are equally valid, and also pure pragmatic constraints.

John and Matthew, you are more than welcome to report bugs you find, or to work on fixing a bug, from the long list of bugs that really would improve people?s life when fixed.  If you are unsure about the process or about your patch, please join http://mail.python.org/mailman/listinfo/core-mentorship mailing list to ask any question you might have: we will help you.

Hope this clarifies things without hurting anyone?s feelings.

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

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

From report at bugs.python.org  Fri Mar  2 06:21:45 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 02 Mar 2012 05:21:45 +0000
Subject: [docs] [issue14165] The new shlex.quote() function should be marked
	"New in	version 3.3"
In-Reply-To: <1330609956.34.0.635238408021.issue14165@psf.upfronthosting.co.za>
Message-ID: <1330665705.1.0.251491943008.issue14165@psf.upfronthosting.co.za>


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

IMHO just leave it. The documentation is mainly for reference, i.e. describing in the best way possible what's available *now*. If you want to mention an upgrade path, write a blog :)

----------

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

From report at bugs.python.org  Fri Mar  2 06:44:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Mar 2012 05:44:09 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <E1S3LHj-0002BN-5X@dinsdale.python.org>


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

New changeset 81e606862a89 by Eli Bendersky in branch '3.2':
Issue #11379: add a note in xml.dom.minidom suggesting to use etree in some cases
http://hg.python.org/cpython/rev/81e606862a89

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

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

From report at bugs.python.org  Fri Mar  2 06:46:18 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Mar 2012 05:46:18 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <E1S3LJo-0002ZB-M1@dinsdale.python.org>


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

New changeset ccd16ad37544 by Eli Bendersky in branch '2.7':
Issue #11379: add a note in xml.dom.minidom suggesting to use etree in some cases
http://hg.python.org/cpython/rev/ccd16ad37544

----------

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

From report at bugs.python.org  Fri Mar  2 06:47:12 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 02 Mar 2012 05:47:12 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330667232.3.0.935257701309.issue11379@psf.upfronthosting.co.za>


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

Committed to 2.7, 3.2 and 3.3

I suppose this issue can be closed now?

----------

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

From report at bugs.python.org  Fri Mar  2 08:27:52 2012
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 02 Mar 2012 07:27:52 +0000
Subject: [docs] [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1330673271.87.0.126837327995.issue8890@psf.upfronthosting.co.za>


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

I think this issue was closed too hastily. Only the logging documentation has been fixed.

@grubert: I agree with the assumption that /tmp is mostly used because it's writable. In my opinion, the directory could just be left out and only leave the file name.

----------
nosy: +petri.lehtinen
status: closed -> open
versions: +Python 3.3 -Python 3.1

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

From report at bugs.python.org  Fri Mar  2 10:54:09 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 02 Mar 2012 09:54:09 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330682049.53.0.774891635832.issue11379@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Thanks Eli.

What about the "Lightweight DOM implementation", though? Following Martin's comment that performance characteristics (like "fast", "memory friendly" or "lightweight") should normally not be documented, I'm still suggesting to replace it with a less easily misinterpreted phrase like "W3C DOM implementation".

----------

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

From report at bugs.python.org  Fri Mar  2 11:46:41 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 02 Mar 2012 10:46:41 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330685201.69.0.807993779963.issue11379@psf.upfronthosting.co.za>


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

Stefan, frankly I'm not familiar enough with either xml.dom or xml.dom.minidom to have a solid opinion at this point.

----------

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

From report at bugs.python.org  Fri Mar  2 11:51:31 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Mar 2012 10:51:31 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330685491.26.0.626883732291.issue11379@psf.upfronthosting.co.za>


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

I think I?ve always understood ?lightweight? to mean ?minimal?.  xml.dom provides minidom, a basic implementation, pulldom, a different implementation, and other libraries such as 4Dom are full-fledged implementations.  So ?lightweight? is not a problem to me (but I acknowledge that it might be misleading for other people), especially given that I think that DOM itself is not elegant or lightweight (as in ?conceptually small?).

----------

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

From report at bugs.python.org  Fri Mar  2 15:51:55 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 02 Mar 2012 14:51:55 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330699915.02.0.650009607879.issue11379@psf.upfronthosting.co.za>


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

> I think I?ve always understood ?lightweight? to mean ?minimal?.

Then how about saying "minimal" instead of "lightweight"?
(also, it seems it really means "incomplete" or "partial", which are of course less positive sounding)

----------

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

From report at bugs.python.org  Fri Mar  2 15:58:52 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Mar 2012 14:58:52 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330700332.14.0.170941892574.issue11379@psf.upfronthosting.co.za>


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

"Minimal" sounds good to me, it also matches the name of the module.

----------

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

From report at bugs.python.org  Fri Mar  2 16:40:20 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Mar 2012 15:40:20 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330702819.94.0.737322908351.issue11379@psf.upfronthosting.co.za>


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

Right, patch for 3.2.  Also edited the module docstring (info taken from the docstring of xml.dom).  BTW I really think we could have avoided some verbosity by adding the recommendation to use xml.etree in the first paragraph of Doc/library/xml.dom.minidom.rst.

----------
Added file: http://bugs.python.org/file24707/minidom-desc.diff

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

From report at bugs.python.org  Fri Mar  2 16:41:35 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Mar 2012 15:41:35 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330702895.45.0.471661575303.issue11379@psf.upfronthosting.co.za>


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

s/Mininal/Minimal/ in the synopsis

----------

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

From report at bugs.python.org  Fri Mar  2 16:55:42 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 02 Mar 2012 15:55:42 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330703742.65.0.862033167655.issue11379@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Yes, I think that's better.

----------

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

From report at bugs.python.org  Fri Mar  2 17:23:36 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 02 Mar 2012 16:23:36 +0000
Subject: [docs] [issue14167] document return statement in finally blocks
In-Reply-To: <1330614429.57.0.59180427723.issue14167@psf.upfronthosting.co.za>
Message-ID: <1330705415.75.0.907884158687.issue14167@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Well, I guess the best place to put it would be http://docs.python.org/py3k/reference/compound_stmts.html#finally

I've attached the patch, please take a look.  If it's possible to make it more clear, feel free to rephrase it.  But please include the example, this behaviour needs to be emphasized.

----------
keywords: +patch
Added file: http://bugs.python.org/file24709/finally_doc.patch

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

From report at bugs.python.org  Fri Mar  2 20:13:42 2012
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 02 Mar 2012 19:13:42 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <1330715622.69.0.916346176071.issue14163@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I tried your tk_hello.py code and it works on Python 3.


The code for creating the QUIT button exceeds 80 columns. I'd insert a \n after the second argument:

        self.QUIT = tk.Button(self, text = "QUIT", 
                              fg = "red", command = root.destroy)

----------

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

From report at bugs.python.org  Fri Mar  2 20:27:28 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Mar 2012 19:27:28 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <1330716448.82.0.864144371197.issue14163@psf.upfronthosting.co.za>


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

Do you know anything about spaces in the button text causing the addition of {bra ces}? I would prefer not to have to use an underscore in Hello_World.

I fixed the long line and also updated pack calls pass options by name instead of a dict.

----------
Added file: http://bugs.python.org/file24712/tk_hello.py

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

From report at bugs.python.org  Fri Mar  2 20:27:50 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Mar 2012 19:27:50 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <1330716470.03.0.36075257663.issue14163@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file24693/tk_hello.py

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

From report at bugs.python.org  Fri Mar  2 20:40:59 2012
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 02 Mar 2012 19:40:59 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <1330717259.77.0.982701605665.issue14163@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

Ah, that's subtle. There's a comma at the end of that ["text"] line which is making the string a one-element tuple. Removing it fixes the issue.

----------

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

From report at bugs.python.org  Fri Mar  2 21:04:46 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Mar 2012 20:04:46 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <1330718686.38.0.538730193116.issue14163@psf.upfronthosting.co.za>


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

Grrrr, another but in the original ;-)
Thank you! I will incorporate into the doc now.

----------
Added file: http://bugs.python.org/file24713/tk_hello.py

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

From report at bugs.python.org  Fri Mar  2 21:04:55 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Mar 2012 20:04:55 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <1330718695.98.0.82365283893.issue14163@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file24712/tk_hello.py

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

From report at bugs.python.org  Sat Mar  3 14:31:32 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Mar 2012 13:31:32 +0000
Subject: [docs] [issue14122] operator: div() instead of truediv() in
	documention	since 3.1.2
In-Reply-To: <1330190947.0.0.577940760696.issue14122@psf.upfronthosting.co.za>
Message-ID: <1330781492.61.0.901808205399.issue14122@psf.upfronthosting.co.za>


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

This was fixed in 8de95f3b2404 (3.2) and d4b17c478e49 (default).
Thanks for the report and the patch!

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

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

From lex at shamahan.com  Thu Mar  1 13:18:29 2012
From: lex at shamahan.com (Lex Kalinkin)
Date: Thu, 1 Mar 2012 14:18:29 +0200
Subject: [docs] bug
Message-ID: <CAO0U0Ri0xC1yGj9itz=Hjicy4+bc-ku0wtn_aX_Z_DSsb+WJuA@mail.gmail.com>

Hi
*
*
*
http://docs.python.org/py3k/library/multiprocessing.html#multiprocessing.Process
*
*
*
To show the individual process IDs involved, here is an expanded example:
line 7: print('parent process:', os.getppid())

AttributeError: 'module' object has no attribute 'getppid'
*
*
-- 
WBR, Lex Kalinkin
+38-063-859-72-34
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120301/4372fcd6/attachment.html>

From brendansweb at optusnet.com.au  Thu Mar  1 07:10:10 2012
From: brendansweb at optusnet.com.au (Brendan)
Date: Thu, 01 Mar 2012 17:10:10 +1100
Subject: [docs] apparently re.compile doesn't allow flags from 2.6
Message-ID: <4F4F12C2.1060800@optusnet.com.au>

Docs page:
http://docs.python.org/library/re.html#re.compile

see (eg):
https://github.com/nathanborror/django-basic-apps/issues/20

From sandro.tosi at gmail.com  Sat Mar  3 17:27:20 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 3 Mar 2012 17:27:20 +0100
Subject: [docs] apparently re.compile doesn't allow flags from 2.6
In-Reply-To: <4F4F12C2.1060800@optusnet.com.au>
References: <4F4F12C2.1060800@optusnet.com.au>
Message-ID: <CAPdtAj2EQt473SAPUK8kCh9e+8xsaPk_cE8VyzV9r=KaJ537-A@mail.gmail.com>

Hello Brendan,
please try to be a bit more verbose next time: a terse report is
highly unlikely to generate a positive reply.

Also, this mailing list is not the one you're looking for, since it's
about bugs/enhangements in the documentation of python, you probably
want http://mail.python.org/mailman/listinfo/python-list

On Thu, Mar 1, 2012 at 07:10, Brendan <brendansweb at optusnet.com.au> wrote:
> Docs page:
> http://docs.python.org/library/re.html#re.compile
>
> see (eg):
> https://github.com/nathanborror/django-basic-apps/issues/20

Anyhow, I gave it a try and it seems to work:

$ python2.6
Python 2.6.7 (r267:88850, Aug  3 2011, 11:33:52)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> r = re.compile('as', re.I)
>>> r.findall('asdfAsdf')
['as', 'As']
>>>

$ python2.7
Python 2.7.2+ (default, Jan 20 2012, 17:51:10)
[GCC 4.6.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> r = re.compile('as', re.I)
>>> r.findall('asdfAsdf')
['as', 'As']
>>>

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

From sandro.tosi at gmail.com  Sat Mar  3 17:31:06 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 3 Mar 2012 17:31:06 +0100
Subject: [docs] bug
In-Reply-To: <CAO0U0Ri0xC1yGj9itz=Hjicy4+bc-ku0wtn_aX_Z_DSsb+WJuA@mail.gmail.com>
References: <CAO0U0Ri0xC1yGj9itz=Hjicy4+bc-ku0wtn_aX_Z_DSsb+WJuA@mail.gmail.com>
Message-ID: <CAPdtAj2L5jB4tmonz1GG6HfJQcMFJMqtJT2SCKmCigjOqebOdw@mail.gmail.com>

Hello Lex,

On Thu, Mar 1, 2012 at 13:18, Lex Kalinkin <lex at shamahan.com> wrote:
> Hi
>
> http://docs.python.org/py3k/library/multiprocessing.html#multiprocessing.Process

this documentation is for python 3.2.

> To show the individual process IDs involved, here is an expanded example:
> line 7:?print('parent process:', os.getppid())
>
> AttributeError: 'module' object has no attribute 'getppid'

what version of python are you using to run the example?

$ ./python
imPython 3.2.2+ (3.2:88522997b021, Feb 18 2012, 12:40:26)
[GCC 4.6.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getppid()
3399
>>>

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

From report at bugs.python.org  Sat Mar  3 20:57:16 2012
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 03 Mar 2012 19:57:16 +0000
Subject: [docs] [issue13951] Seg Fault in .so called by ctypes causes the
	interpreter	to Seg Fault
In-Reply-To: <1328535030.63.0.73417525944.issue13951@psf.upfronthosting.co.za>
Message-ID: <1330804636.6.0.865375441063.issue13951@psf.upfronthosting.co.za>


Westley Mart?nez <anikom15 at gmail.com> added the comment:

Hi I found this bug randomly and have made two small patches to change the documentation.  One assumes that the faulthandler module is available for 3.3.  The other patch is for earlier versions of Python.

----------
keywords: +patch
nosy: +anikom15
versions: +Python 3.3
Added file: http://bugs.python.org/file24722/cpython-13951.patch

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

From report at bugs.python.org  Sat Mar  3 20:57:35 2012
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 03 Mar 2012 19:57:35 +0000
Subject: [docs] [issue13951] Seg Fault in .so called by ctypes causes the
	interpreter	to Seg Fault
In-Reply-To: <1328535030.63.0.73417525944.issue13951@psf.upfronthosting.co.za>
Message-ID: <1330804655.21.0.581972220611.issue13951@psf.upfronthosting.co.za>


Changes by Westley Mart?nez <anikom15 at gmail.com>:


Added file: http://bugs.python.org/file24723/cpython-13951-pre3.3.patch

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

From report at bugs.python.org  Sat Mar  3 21:15:12 2012
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 03 Mar 2012 20:15:12 +0000
Subject: [docs] [issue14186] Link to PEP 3107 in "def" part of Language
	Reference
Message-ID: <1330805711.99.0.463703521532.issue14186@psf.upfronthosting.co.za>


New submission from Chris Rebert <pybugs at rebertia.com>:

The part of the Language Reference concerning the `def` statement (http://docs.python.org/dev/reference/compound_stmts.htm#function-definitions ) should include a See Also link to PEP 3107 "Function Annotations".

----------
assignee: docs at python
components: Documentation
messages: 154851
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: Link to PEP 3107 in "def" part of Language Reference
versions: Python 3.3

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

From report at bugs.python.org  Sat Mar  3 21:19:17 2012
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 03 Mar 2012 20:19:17 +0000
Subject: [docs] [issue14187] add "annotation" entry to Glossary
Message-ID: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>


New submission from Chris Rebert <pybugs at rebertia.com>:

The Glossary should include an entry for "annotation" and/or "function annotation" regarding the language feature introduced by PEP 3107.

----------
assignee: docs at python
components: Documentation
messages: 154852
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: add "annotation" entry to Glossary
versions: Python 3.3

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

From panax at zmail.lt  Sat Mar  3 22:28:49 2012
From: panax at zmail.lt (panax at zmail.lt)
Date: 03 Mar 2012 23:28:49 +0200
Subject: [docs] Bug:(
Message-ID: <20120303232849tkwm14979979464f528d11ca4d08.45050795@zmail.lt>

Hi, 
I have found an interesting thing. Let's compare two _very_ simple and  functionally identical scripts.
They both check one by one chars in the string s if they are alpha or no:
================================================================= 
s="aaaaaa"
print(s)
if s[0].isalpha():  print("0-yes")
else:  print("0-no")
if s[1].isalpha():  print("1-yes")
else:  print("1-no")
if s[2].isalpha():  print("2-yes")
else:  print("2-no")
if s[3].isalpha():  print("3-no")
else:  print("3-no")
if s[4].isalpha():  print("4-no")
else:  print("4-no")
if s[5].isalpha():  print("5-yes")
else:  print("5-no")
==============================================
 - produces (Python 2.7.2, with my comments at the right):

aaaaaa   -the string
0-yes    -it's alpha ok
1-yes
2-yes
3-no     -!!!  this 'a' is not alpha!
4-no     -!!!  and this also... 
5-yes    - ok again

Look at pos.3 and 4, those chars now are NOT alpha!
On the other hand, functionally the same script, but with not direct (not by literal, but by variable j) char addressing, performs ok:
==========================================
s="aaaaaa"
for j in range(len(s)):
  if s[j].isalpha():  print(s[j]+"- alpha")
  else:  print(s[j]+"- Not alpha")
===========================================

Seems the behaviour doesn't depend on the string content, but rather on the position of char and the addressing way (literal or no).

Would be glad to be helpful...
I use Python 2.7.2 (last),  WinXp as a host. 
One more mention - these scripts were running from files, not as dialog session.
Sorry, if this is known bug, now have no time to check through.
And don't tell me this is a feature!

Yours notes are welcome!

God bless the Py!

Peter
panax at zmail.lt



From georg at python.org  Sat Mar  3 22:59:22 2012
From: georg at python.org (Georg Brandl)
Date: Sat, 03 Mar 2012 22:59:22 +0100
Subject: [docs] Bug:(
In-Reply-To: <20120303232849tkwm14979979464f528d11ca4d08.45050795@zmail.lt>
References: <20120303232849tkwm14979979464f528d11ca4d08.45050795@zmail.lt>
Message-ID: <4F52943A.7010709@python.org>

On 03.03.2012 22:28, panax at zmail.lt wrote:
> Hi,
> I have found an interesting thing. Let's compare two _very_ simple and  functionally identical scripts.
> They both check one by one chars in the string s if they are alpha or no:
> =================================================================
> s="aaaaaa"
> print(s)
> if s[0].isalpha():  print("0-yes")
> else:  print("0-no")
> if s[1].isalpha():  print("1-yes")
> else:  print("1-no")
> if s[2].isalpha():  print("2-yes")
> else:  print("2-no")
> if s[3].isalpha():  print("3-no")
> else:  print("3-no")
> if s[4].isalpha():  print("4-no")
> else:  print("4-no")
> if s[5].isalpha():  print("5-yes")
> else:  print("5-no")
> ==============================================
>   - produces (Python 2.7.2, with my comments at the right):
>
> aaaaaa   -the string
> 0-yes    -it's alpha ok
> 1-yes
> 2-yes
> 3-no     -!!!  this 'a' is not alpha!
> 4-no     -!!!  and this also...
> 5-yes    - ok again
>
> Look at pos.3 and 4, those chars now are NOT alpha!
> On the other hand, functionally the same script, but with not direct (not by literal, but by variable j) char addressing, performs ok:
> ==========================================
> s="aaaaaa"
> for j in range(len(s)):
>    if s[j].isalpha():  print(s[j]+"- alpha")
>    else:  print(s[j]+"- Not alpha")
> ===========================================
>
> Seems the behaviour doesn't depend on the string content, but rather on the position of char and the addressing way (literal or no).
>
> Would be glad to be helpful...
> I use Python 2.7.2 (last),  WinXp as a host.
> One more mention - these scripts were running from files, not as dialog session.
> Sorry, if this is known bug, now have no time to check through.
> And don't tell me this is a feature!

It's a feature!

Look again at your code:

 > if s[3].isalpha():  print("4-no")

cheers,
Georg

From report at bugs.python.org  Sun Mar  4 05:18:59 2012
From: report at bugs.python.org (Baruch Sterin)
Date: Sun, 04 Mar 2012 04:18:59 +0000
Subject: [docs] [issue14189] Documentation for some C APIs is missing
	clear	specification of the type of reference they return
Message-ID: <1330834739.26.0.103894619612.issue14189@psf.upfronthosting.co.za>


New submission from Baruch Sterin <python at bsterin.com>:

In addition to the description text, most C API functions have a one-line, emphasized specification whether they return a new or a borrowed reference. (e.g. 'Return value: New reference.').

The following API functions are missing that. Some of them, like PyMemoryView_FromBuffer(), have descriptions that are clear, but it would still be nice to have an unambiguous statement like most other API functions have.

The list has been generated automatically, so it might contain some errors.

Doc/c-api/arg.rst:  Py_VaBuildValue
Doc/c-api/buffer.rst:  PyMemoryView_FromBuffer
Doc/c-api/buffer.rst:  PyMemoryView_FromObject
Doc/c-api/buffer.rst:  PyMemoryView_GetContiguous
Doc/c-api/bytearray.rst:  PyByteArray_Concat
Doc/c-api/bytearray.rst:  PyByteArray_FromObject
Doc/c-api/bytearray.rst:  PyByteArray_FromStringAndSize
Doc/c-api/code.rst:  PyCode_New
Doc/c-api/codec.rst:  PyCodec_BackslashReplaceErrors
Doc/c-api/codec.rst:  PyCodec_Decode
Doc/c-api/codec.rst:  PyCodec_Decoder
Doc/c-api/codec.rst:  PyCodec_Encode
Doc/c-api/codec.rst:  PyCodec_Encoder
Doc/c-api/codec.rst:  PyCodec_IgnoreErrors
Doc/c-api/codec.rst:  PyCodec_IncrementalDecoder
Doc/c-api/codec.rst:  PyCodec_IncrementalEncoder
Doc/c-api/codec.rst:  PyCodec_LookupError
Doc/c-api/codec.rst:  PyCodec_ReplaceErrors
Doc/c-api/codec.rst:  PyCodec_StreamReader
Doc/c-api/codec.rst:  PyCodec_StreamWriter
Doc/c-api/codec.rst:  PyCodec_StrictErrors
Doc/c-api/codec.rst:  PyCodec_XMLCharRefReplaceErrors
Doc/c-api/exceptions.rst:  PyUnicodeDecodeError_Create
Doc/c-api/exceptions.rst:  PyUnicodeDecodeError_GetEncoding
Doc/c-api/exceptions.rst:  PyUnicodeDecodeError_GetObject
Doc/c-api/exceptions.rst:  PyUnicodeDecodeError_GetReason
Doc/c-api/exceptions.rst:  PyUnicodeEncodeError_Create
Doc/c-api/exceptions.rst:  PyUnicodeTranslateError_Create
Doc/c-api/float.rst:  PyFloat_GetInfo
Doc/c-api/import.rst:  PyImport_GetImporter
Doc/c-api/import.rst:  PyImport_ImportModuleNoBlock
Doc/c-api/import.rst:  _PyImport_FindExtension
Doc/c-api/import.rst:  _PyImport_FixupExtension
Doc/c-api/init.rst:  PyEval_GetCallStats
Doc/c-api/int.rst:  PyInt_FromSize_t
Doc/c-api/long.rst:  PyLong_FromSize_t
Doc/c-api/long.rst:  PyLong_FromSsize_t
Doc/c-api/number.rst:  PyNumber_Index
Doc/c-api/number.rst:  PyNumber_ToBase
Doc/c-api/object.rst:  PyObject_Bytes
Doc/c-api/object.rst:  PyObject_GenericGetAttr
Doc/c-api/unicode.rst:  PyUnicode_AsUTF32String
Doc/c-api/unicode.rst:  PyUnicode_DecodeMBCSStateful
Doc/c-api/unicode.rst:  PyUnicode_DecodeUTF32
Doc/c-api/unicode.rst:  PyUnicode_DecodeUTF32Stateful
Doc/c-api/unicode.rst:  PyUnicode_DecodeUTF7
Doc/c-api/unicode.rst:  PyUnicode_DecodeUTF7Stateful
Doc/c-api/unicode.rst:  PyUnicode_EncodeUTF32
Doc/c-api/unicode.rst:  PyUnicode_EncodeUTF7
Doc/c-api/veryhigh.rst:  PyEval_EvalCodeEx
Doc/c-api/veryhigh.rst:  PyEval_EvalFrame
Doc/c-api/veryhigh.rst:  PyEval_EvalFrameEx

----------
assignee: docs at python
components: Documentation
messages: 154877
nosy: baruch.sterin, docs at python
priority: normal
severity: normal
status: open
title: Documentation for some C APIs is missing clear specification of the type of reference they return
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar  4 07:07:08 2012
From: report at bugs.python.org (Baruch Sterin)
Date: Sun, 04 Mar 2012 06:07:08 +0000
Subject: [docs] [issue14190] Minor C API documentation bugs
Message-ID: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za>


New submission from Baruch Sterin <python at bsterin.com>:

The following functions are documented, but do not exist in the code:

* PyCodec_KnownEncoding
* PyRun_SimpleFileFlags

The following function is documented and exists in the code, but is not exposed through any of the header files:

PyParser_SimpleParseStringFlagsFilename

The prototype in the documentation is incorrect:

* PyOS_stricmp returns int, not char*
* PyOS_strnicmp returns int, not char*
* PyCode_GetNumFree accepts a PyCodeObject* not PyObject*
* PyCode_NewEmpty returns a PyCodeObject* not PyObject*
* PyFile_SetBufSize accepts a PyObject*, not PyCodeObject
* PyGILState_GetThisThreadState returns PyThreadState* not PyThreadState
* PyUnicode_EncodeRawUnicodeEscape accepts 2, not 3 arguments
* PyUnicode_RichCompare returns PyObject*, not int
* PyType_IS_GC needs a PyTypeObject*, not PyObject*
* PyType_HasFeature needs a PyTypeObject*, not PyObject*

In addition, PyLong_FromSsize_t and PyLong_FromSsize_t are documented twice in long.html.

----------
assignee: docs at python
components: Documentation
messages: 154879
nosy: baruch.sterin, docs at python
priority: normal
severity: normal
status: open
title: Minor C API documentation bugs
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar  4 09:59:53 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Mar 2012 08:59:53 +0000
Subject: [docs] [issue14190] Minor C API documentation bugs
In-Reply-To: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za>
Message-ID: <1330851593.62.0.996056357249.issue14190@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/issue14190>
_______________________________________

From report at bugs.python.org  Sun Mar  4 10:02:52 2012
From: report at bugs.python.org (Baruch Sterin)
Date: Sun, 04 Mar 2012 09:02:52 +0000
Subject: [docs] [issue14190] Minor C API documentation bugs
In-Reply-To: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za>
Message-ID: <1330851772.02.0.477767917701.issue14190@psf.upfronthosting.co.za>


Baruch Sterin <python at bsterin.com> added the comment:

A few additional ones:

The prototype in the documentation is incorrect:

* PyFile_SetEncoding accepts PyObject*, not PyFileObject*
* PyFile_SetEncodingAndErrors accepts PyObject*, not PyFileObject*

PyLong_AsSsize_t is also duplicated.

----------

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

From report at bugs.python.org  Sun Mar  4 13:53:57 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 04 Mar 2012 12:53:57 +0000
Subject: [docs] [issue14193] broken link on PEP 385
Message-ID: <1330865637.77.0.994112450027.issue14193@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

The pymigr link on pep385 is broken.

----------
assignee: docs at python
components: Documentation
messages: 154890
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: broken link on PEP 385

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

From report at bugs.python.org  Sun Mar  4 14:28:48 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Mar 2012 13:28:48 +0000
Subject: [docs] [issue14193] broken link on PEP 385
In-Reply-To: <1330865637.77.0.994112450027.issue14193@psf.upfronthosting.co.za>
Message-ID: <1330867728.86.0.86071055681.issue14193@psf.upfronthosting.co.za>


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

Thanks, fixed in 636320b98756.

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

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

From report at bugs.python.org  Sun Mar  4 15:47:45 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 04 Mar 2012 14:47:45 +0000
Subject: [docs] [issue14194] typo in pep414
In-Reply-To: <1330872444.33.0.601967914335.issue14194@psf.upfronthosting.co.za>
Message-ID: <1330872465.18.0.406439174343.issue14194@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar  4 15:50:27 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Mar 2012 14:50:27 +0000
Subject: [docs] [issue14194] typo in pep414
In-Reply-To: <1330872444.33.0.601967914335.issue14194@psf.upfronthosting.co.za>
Message-ID: <1330872627.6.0.727353735495.issue14194@psf.upfronthosting.co.za>


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

Fixed, thanks.

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

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

From bookman23 at comcast.net  Sun Mar  4 17:33:35 2012
From: bookman23 at comcast.net (Scott V)
Date: Sun, 4 Mar 2012 11:33:35 -0500
Subject: [docs] python25.dll
Message-ID: <F8FD9EE8C3D74FC28492A63C105F7554@ScottPC>

I don't know if anyone has sent this in before.
I loaded the current version of Python on my computer to learn the programming and, I believe, it helps my Blender to work.  Anyway, occassionally, I get an error on the screen, before I have started running programs, that states "python25.dll" will not load or does not exist.
I have removed Python from my system to stop this error.
Anything else I can do?  This is XP system.
Scott
___________________________________________
Amazon:
Check out my over 800 items for sale on Amazon at:

http://www.amazon.com/shops/bookman236  

"I believe that everything happens for a reason.
 People change so that you can learn to let go,
 things go wrong so that you appreciate them
 when they're right, you believe lies so you 
eventually learn to trust no one but yourself, 
and sometimes good things fall apart so better
 things can fall together." -Marilyn Monroe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120304/5fa0eca3/attachment.html>

From sandro.tosi at gmail.com  Sun Mar  4 19:45:50 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 4 Mar 2012 19:45:50 +0100
Subject: [docs] python25.dll
In-Reply-To: <F8FD9EE8C3D74FC28492A63C105F7554@ScottPC>
References: <F8FD9EE8C3D74FC28492A63C105F7554@ScottPC>
Message-ID: <CAPdtAj2jSO4qX4rKca1kWL1qc85crngOLFW01Nrc=CJCjH-8Bw@mail.gmail.com>

Hello Scott,
this is not the right mailing list for such questions, it's better if
you ask on http://mail.python.org/mailman/listinfo/python-list .

As a side note, I'd strongly encourage you to use a more recent
version of python, for example 2.7 or even the Python3 (current stable
version, 3.2).

Regards,
Sandro

On Sun, Mar 4, 2012 at 17:33, Scott V <bookman23 at comcast.net> wrote:
> I don't know if anyone has sent this in before.
> I loaded the current version of Python on my computer to learn the
> programming and, I believe, it helps my Blender to work.? Anyway,
> occassionally, I get an error on the screen, before I have started running
> programs, that states "python25.dll" will not load or does not exist.
> I have removed Python from my system to stop this error.
> Anything else I can do?? This is XP system.
> Scott
> ___________________________________________
> Amazon:
> Check out my over 800 items for sale on Amazon at:
>
> http://www.amazon.com/shops/bookman236
>
> "I believe that everything happens for a reason.
> ?People change so that you can learn to let go,
> ?things go wrong so that you appreciate them
> ?when they're right, you believe lies so you
> eventually learn to trust no one but yourself,
> and sometimes good things fall apart so better
> ?things can fall together." -Marilyn Monroe
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



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

From report at bugs.python.org  Sun Mar  4 20:09:06 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Mar 2012 19:09:06 +0000
Subject: [docs] [issue1040439] Missing documentation on how to link with
	libpython
Message-ID: <1330888146.7.0.0770386695328.issue1040439@psf.upfronthosting.co.za>


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

?ric, go ahead :)

----------

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

From report at bugs.python.org  Sun Mar  4 20:11:14 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Mar 2012 19:11:14 +0000
Subject: [docs] [issue14190] Minor C API documentation bugs
In-Reply-To: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za>
Message-ID: <1330888274.94.0.573939958981.issue14190@psf.upfronthosting.co.za>


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


----------
keywords: +easy
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Mar  5 05:50:39 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 05 Mar 2012 04:50:39 +0000
Subject: [docs] [issue14189] Documentation for some C APIs is missing
	clear	specification of the type of reference they return
In-Reply-To: <1330834739.26.0.103894619612.issue14189@psf.upfronthosting.co.za>
Message-ID: <1330923039.73.0.459708408329.issue14189@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

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

From report at bugs.python.org  Mon Mar  5 05:54:43 2012
From: report at bugs.python.org (Meador Inge)
Date: Mon, 05 Mar 2012 04:54:43 +0000
Subject: [docs] [issue13951] Seg Fault in .so called by ctypes causes the
	interpreter	to Seg Fault
In-Reply-To: <1328535030.63.0.73417525944.issue13951@psf.upfronthosting.co.za>
Message-ID: <1330923283.1.0.823354344216.issue13951@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

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

From report at bugs.python.org  Mon Mar  5 06:21:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Mar 2012 05:21:21 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1330924880.72.0.730559575393.issue11379@psf.upfronthosting.co.za>


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

This alternate version of my patch (a) merges the first two paragraphs to make the intro less redundant and heavy, and (b) reorganizes a bit the list of modules in Doc/library/markup.rst to have xml.etree first and pyexpat (less interesting for most people) at the end.  Tell me if you prefer this version, or if I should commit the first one (possibly with the (b) change).

----------
Added file: http://bugs.python.org/file24732/minidom-desc-2.diff

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

From report at bugs.python.org  Mon Mar  5 07:47:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Mar 2012 06:47:46 +0000
Subject: [docs] [issue14190] Minor C API documentation bugs
In-Reply-To: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za>
Message-ID: <1330930066.2.0.0369951438561.issue14190@psf.upfronthosting.co.za>


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


----------
nosy: +haypo, loewis

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

From report at bugs.python.org  Mon Mar  5 16:26:10 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Mar 2012 15:26:10 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <E1S4ZnV-0006JZ-QZ@dinsdale.python.org>


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

New changeset d99c0a4b66f3 by ?ric Araujo in branch '3.2':
Move xml.etree higher and xml.parsers.expat lower in the markup ToC.
http://hg.python.org/cpython/rev/d99c0a4b66f3

----------

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

From report at bugs.python.org  Mon Mar  5 16:48:29 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Mar 2012 15:48:29 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <E1S4a9D-0000Wq-Rk@dinsdale.python.org>


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

New changeset fc32753feb0a by ?ric Araujo in branch '2.7':
Move xml.etree higher and xml.parsers.expat lower in the markup ToC.
http://hg.python.org/cpython/rev/fc32753feb0a

----------

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

From report at bugs.python.org  Mon Mar  5 17:25:19 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 05 Mar 2012 16:25:19 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
Message-ID: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

http://docs.python.org/dev/library/xml.dom.pulldom.html

"embarrassing" is the word I wanted to use, but it's too strong for the title ;-)

Seriously, this module is part of the stdlib, it should at least have *some* documentation.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 154959
nosy: docs at python, eli.bendersky, eric.araujo, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: The docs of xml.dom.pulldom are almost nonexistent
type: behavior
versions: Python 2.7, Python 3.3

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

From oddshocks at gmail.com  Mon Mar  5 16:29:08 2012
From: oddshocks at gmail.com (David Gay)
Date: Mon, 5 Mar 2012 10:29:08 -0500
Subject: [docs] Spelling correction
Message-ID: <CA+cuh_cGb4_oXT-SCrJFPVAvo1u-kcJj7kFyMK-nhoC5XFgTpQ@mail.gmail.com>

Hello,

A small correction in *section 6.4.1*, second-to-last paragraph, "practice"
is spelled "practise".

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

From report at bugs.python.org  Tue Mar  6 01:32:42 2012
From: report at bugs.python.org (Garrett Moore)
Date: Tue, 06 Mar 2012 00:32:42 +0000
Subject: [docs] [issue14206] multiprocessing.Queue documentation is lacking
	important	details
Message-ID: <1330993962.13.0.893864771053.issue14206@psf.upfronthosting.co.za>


New submission from Garrett Moore <garrettmoore at gmail.com>:

1) If cancel_join_thread() is called, data may be lost. This is not explicitly stated. I had multiple writers put() data in a Queue, and wanted to have the workers finish before I began consuming the data. This caused a deadlock because my Queue was not empty, and it seemed like the a way to force my workers finish was to use cancel_join_thread(). This caused data loss.

2) multiprocessing.Queue states "The Queue class is a near clone of Queue.Queue."

Queue.Queue states "If maxsize is less than or equal to zero, the queue size is infinite."

mp.Queue provides no information on queue size. It is reasonable to assume then that it inherits the property of Queue.Queue.

After discussion on IRC, it seems that mp.Queue maximum size is implementation-dependent and likely relies on how much data Pipes can hold on your platform. If this is the case there should be some mention of the fact that mp.Queue does NOT function like Queue.Queue does for maximum size.

----------
assignee: docs at python
components: Documentation
messages: 154995
nosy: Garrett.Moore, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.Queue documentation is lacking important details
versions: Python 2.6, Python 2.7

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

From senthil at uthcode.com  Tue Mar  6 02:17:17 2012
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 6 Mar 2012 09:17:17 +0800
Subject: [docs] Spelling correction
In-Reply-To: <CA+cuh_cGb4_oXT-SCrJFPVAvo1u-kcJj7kFyMK-nhoC5XFgTpQ@mail.gmail.com>
References: <CA+cuh_cGb4_oXT-SCrJFPVAvo1u-kcJj7kFyMK-nhoC5XFgTpQ@mail.gmail.com>
Message-ID: <20120306011716.GC11762@mathmagic>

Hello David!

I hope you know that "practise" can be a noun in US. However, if there
is an inconsistency, it could be looked along with other such
inconsistencies.

Thanks,
Senthil

On Mon, Mar 05, 2012 at 10:29:08AM -0500, David Gay wrote:
> Hello,
> 
> A small correction in section 6.4.1, second-to-last paragraph, "practice" is
> spelled "practise".
> 
> Thanks!
> -- David

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


From report at bugs.python.org  Tue Mar  6 08:44:57 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 06 Mar 2012 07:44:57 +0000
Subject: [docs] [issue14100] Add a missing info to PEP 393 + link from
	whatsnew 3.3
In-Reply-To: <1330009090.66.0.133471342458.issue14100@psf.upfronthosting.co.za>
Message-ID: <1331019897.76.0.561769070003.issue14100@psf.upfronthosting.co.za>


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

This is now fixed with d916145b20c3.

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

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

From report at bugs.python.org  Tue Mar  6 13:28:37 2012
From: report at bugs.python.org (sbt)
Date: Tue, 06 Mar 2012 12:28:37 +0000
Subject: [docs] [issue14206] multiprocessing.Queue documentation is lacking
	important	details
In-Reply-To: <1330993962.13.0.893864771053.issue14206@psf.upfronthosting.co.za>
Message-ID: <1331036917.64.0.574146881806.issue14206@psf.upfronthosting.co.za>


sbt <shibturn at gmail.com> added the comment:

What you were told on IRC was wrong.  By default the queue *does* have infinite size.

When a process puts an item on the queue for the first time, a background thread is started which is responsible for writing items to the underlying pipe.  This does mean that, on exit, the process should wait for the background thread to flush all the data to the pipe.  This happens automatically unless you specifically prevent it by calling cancel_join_thread() method.

If you stick to those methods supported by standard queue objects, then things should work correctly.  

(Maybe cancel_join_thread() would be better named allow_exit_without_flush().)

----------
nosy: +sbt

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

From report at bugs.python.org  Tue Mar  6 14:22:29 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 06 Mar 2012 13:22:29 +0000
Subject: [docs] [issue14006] Improve the documentation of
	xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1331040149.26.0.217232834604.issue14006@psf.upfronthosting.co.za>


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

> BTW, the issue 6488 is still opened. I did not check if there's something left to do before to close it.

The fundamental problem issue #6488 was opened for still exists - the docs use the term "path" without defining it. This should be addressed.

----------

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

From arendash at fxpal.com  Tue Mar  6 03:28:21 2012
From: arendash at fxpal.com (David Arendash)
Date: Mon, 5 Mar 2012 18:28:21 -0800
Subject: [docs] Python doc bug?
Message-ID: <2F98165D8B8D02448D5D92C5AC77897DE19FAEB616@yubin3>

http://docs.python.org/tutorial/introduction.html#lists

I'm new to Python, so I'm trying to understand this list index stuff, but it looks to me like:


>>> a = ['spam', 'eggs', 100, 1234]

>>> a

['spam', 'eggs', 100, 1234]

Like string indices, list indices start at 0, and lists can be sliced, concatenated and so on:
>>>

>>> a[0]

'spam'

>>> a[3]

1234

>>> a[-2]

100

>>> a[1:-1]

['eggs', 100]  Shouldn't that last item be 1234?

>>> a[:2] + ['bacon', 2*2]

['spam', 'eggs', 'bacon', 4]  Isn't [:2] to mean 'from start (0) to 2, thus first 3 elements, so should be 100 between eggs an bacon?

>>> 3*a[:3] + ['Boo!']

['spam', 'eggs', 100, 'spam', 'eggs', 100, 'spam', 'eggs', 100, 'Boo!'] Doesn't [:3] mean 'from 0 to 3' thus 4 items should be repeated?


It looks like whoever wrote this intended the number after the colon to mean 'count', but according to this: http://www.korokithakis.net/tutorials/python/
the number after the colon is the end-index.  If it were the count, the first line I've highlighted would make no sense at all.


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

From georg at python.org  Tue Mar  6 21:40:04 2012
From: georg at python.org (Georg Brandl)
Date: Tue, 06 Mar 2012 21:40:04 +0100
Subject: [docs] Python doc bug?
In-Reply-To: <2F98165D8B8D02448D5D92C5AC77897DE19FAEB616@yubin3>
References: <2F98165D8B8D02448D5D92C5AC77897DE19FAEB616@yubin3>
Message-ID: <4F567624.6030809@python.org>


Hi David,

you can call the second index the "end-index", but the thing to remember is
that it is never included.  You can imagine the indices being "between" the
items, like this:

x = | a | b | c | d | e |
     0   1   2   3   4   5
    -5  -4  -3  -2  -1

so x[1:3] is [b, c] and x[1:-1] is [b, c, d].

cheers,
Georg

On 06.03.2012 03:28, David Arendash wrote:
> http://docs.python.org/tutorial/introduction.html#lists
>
> I?m new to Python, so I?m trying to understand this list index stuff, but it
> looks to me like:
>
> *>>>  *a  =  ['spam',  'eggs',  100,  1234]
>
> *>>>  *a
>
> ['spam', 'eggs', 100, 1234]
>
> Like string indices, list indices start at 0, and lists can be sliced,
> concatenated and so on:
>
>> >>
>
> *>>>  *a[0]
>
> 'spam'
>
> *>>>  *a[3]
>
> 1234
>
> *>>>  *a[-2]
>
> 100
>
> *>>>  *a[1:-1]
>
> ['eggs',*100*]    Shouldn?t that last item be 1234?
>
> *>>>  *a[:2]  +  ['bacon',  2*2]
>
> ['spam', 'eggs', 'bacon', 4]    Isn?t [:2] to mean?from start (0) to 2, thus first 3 elements, so should be 100 between eggs an bacon?
>
> *>>>  *3*a[:3]  +  ['Boo!']
>
> ['spam', 'eggs', 100, 'spam', 'eggs', 100, 'spam', 'eggs', 100, 'Boo!']Doesn?t [:3] mean?from 0 to 3?  thus 4 items should be repeated?
>
> It looks like whoever wrote this intended the number after the colon to mean
> ?count?, but according to this: http://www.korokithakis.net/tutorials/python/
>
> the number after the colon is the end-index. If it were the count, the first
> line I?ve highlighted would make no sense at all.

From matrixhasu at gmail.com  Tue Mar  6 21:38:02 2012
From: matrixhasu at gmail.com (Sandro Tosi)
Date: Tue, 6 Mar 2012 21:38:02 +0100
Subject: [docs] Python doc bug?
In-Reply-To: <2F98165D8B8D02448D5D92C5AC77897DE19FAEB616@yubin3>
References: <2F98165D8B8D02448D5D92C5AC77897DE19FAEB616@yubin3>
Message-ID: <CAPdtAj31gXiN0Wi4qmT4YgY02Q=0sgtfghN3AK8DnqsFC50+5w@mail.gmail.com>

Hello David,
I think this question fits more closely to the scope of python-list:
http://mail.python.org/mailman/listinfo/python-list

Nonetheless, i'll try to answers your questions

On Tue, Mar 6, 2012 at 03:28, David Arendash <arendash at fxpal.com> wrote:
> http://docs.python.org/tutorial/introduction.html#lists
>
>
>
> I?m new to Python, so I?m trying to understand this list index stuff, but it
> looks to me like:
>
>
>
>>>> a = ['spam', 'eggs', 100, 1234]
>
>>>> a
>
> ['spam', 'eggs', 100, 1234]
>
> Like string indices, list indices start at 0, and lists can be sliced,
> concatenated and so on:

did you read the doc about strings slicing at
http://docs.python.org/tutorial/introduction.html#lists ?

>>>> a[1:-1]
>
> ['eggs', 100]? Shouldn?t that last item be 1234?

no because it selects from the second item to the last one *excluded*.

>>>> a[:2] + ['bacon', 2*2]
>
> ['spam', 'eggs', 'bacon', 4]? Isn?t [:2] to mean ?from start (0) to 2, thus
> first 3 elements, so should be 100 between eggs an bacon?

nope, the second element of the slice is excluded.

>>>> 3*a[:3] + ['Boo!']
>
> ['spam', 'eggs', 100, 'spam', 'eggs', 100, 'spam', 'eggs', 100, 'Boo!']
> Doesn?t [:3] mean ?from 0 to 3? thus 4 items should be repeated?

see above.

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

From report at bugs.python.org  Wed Mar  7 01:34:50 2012
From: report at bugs.python.org (Florian M)
Date: Wed, 07 Mar 2012 00:34:50 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331080490.25.0.364181608207.issue14202@psf.upfronthosting.co.za>


Florian M <florian.mladitsch at googlemail.com> added the comment:

I wrote some documentation with the information I found on http://wiki.python.org/moin/PullDom and some custom examples.

----------
nosy: +flomm
Added file: http://bugs.python.org/file24750/xml.dom.pulldom.rst

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

From report at bugs.python.org  Wed Mar  7 05:53:09 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 07 Mar 2012 04:53:09 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331095989.73.0.923951467283.issue14202@psf.upfronthosting.co.za>


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

Thanks, Florian - I will review the patch. At first sight it looks much better than what exists.

----------

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

From report at bugs.python.org  Wed Mar  7 09:19:11 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 07 Mar 2012 08:19:11 +0000
Subject: [docs] [issue14217] text output pretends to be code
Message-ID: <1331108351.7.0.269278733631.issue14217@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

The attached patch removes the highlighting. I hope there's a better way to do this, instead of this hack. I searched the Sphinx and docutils docs and failed to find something better.

----------
assignee: docs at python
components: Documentation
files: tis-not-code.patch
keywords: patch
messages: 155056
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: text output pretends to be code
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24751/tis-not-code.patch

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

From report at bugs.python.org  Wed Mar  7 10:13:39 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 07 Mar 2012 09:13:39 +0000
Subject: [docs] [issue14219] start the Class tutorial in a more gentle manner
Message-ID: <1331111619.2.0.272575522063.issue14219@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

Looking at Doc/tutorial/classes, the section "Python Scopes and Namespaces" is full of heavy/deep information. I expect that people who would be able to properly digest that info are people who are already advanced at Python, and therefore maybe it should be moved to some cookbook (or language reference). I would prefer something gentler, since the tutorial is for Python newbies who aren't necessarily conversant with OO concepts.

There can of course be links to heavier material for deeper understanding.

----------
assignee: docs at python
components: Documentation
messages: 155065
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: start the Class tutorial in a more gentle manner
type: enhancement

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

From report at bugs.python.org  Wed Mar  7 10:15:33 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 07 Mar 2012 09:15:33 +0000
Subject: [docs] [issue14219] start the Class tutorial in a more gentle manner
In-Reply-To: <1331111619.2.0.272575522063.issue14219@psf.upfronthosting.co.za>
Message-ID: <1331111733.11.0.921074453489.issue14219@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Mar  7 11:07:13 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 07 Mar 2012 10:07:13 +0000
Subject: [docs] [issue14219] start the Class tutorial in a more gentle manner
In-Reply-To: <1331111619.2.0.272575522063.issue14219@psf.upfronthosting.co.za>
Message-ID: <1331114833.04.0.218454290969.issue14219@psf.upfronthosting.co.za>


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

see msg155067

----------
nosy: +sandro.tosi
versions:  -Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Mar  7 12:37:42 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Mar 2012 11:37:42 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1331120262.34.0.732302308921.issue11379@psf.upfronthosting.co.za>


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

FYI, note that http://wiki.python.org/moin/MiniDom says this about minidom: ?slow and very memory hungry DOM implementation?.

As you have seen, I have applied my ToC order change.  Now in order to commit my s/lightweight/minimal/ change and close this report, can you Eli say if minidom-desc-2 is okay (I?m asking you because this patch touches text you just added, contrary to minidom-desc)?

----------

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

From report at bugs.python.org  Wed Mar  7 12:39:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Mar 2012 11:39:46 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331120386.41.0.255679936885.issue14202@psf.upfronthosting.co.za>


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

Merged Florian?s version with the original file to create a patch.

----------
Added file: http://bugs.python.org/file24752/pulldom-documentation.rst

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

From report at bugs.python.org  Wed Mar  7 12:44:38 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Mar 2012 11:44:38 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1331120262.34.0.732302308921.issue11379@psf.upfronthosting.co.za>
Message-ID: <20120307124436.Horde.3YtJfKGZi1VPV0ok77ejpgA@webmail.df.eu>


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

> FYI, note that http://wiki.python.org/moin/MiniDom says this about  
> minidom: ?slow and very memory hungry DOM implementation?.

Thanks for the notice; I have now fixed that wording.

----------

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

From report at bugs.python.org  Wed Mar  7 12:53:50 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 07 Mar 2012 11:53:50 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1331121230.48.0.918068362401.issue11379@psf.upfronthosting.co.za>


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

?ric,

I'm ok with replacing "lightweight" by "minimal", unless others have objections. Regarding the specifics of the minidom-desc-2.diff patch:

   "proficient with the DOM"

I'm not sure "the DOM" is semantically correct. "the W3C-DOM interface" is more precise.

Also, I still think that a note would be more appropriate, but I don't care enough to argue about it :)

----------

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

From report at bugs.python.org  Wed Mar  7 13:27:24 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 07 Mar 2012 12:27:24 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1331123244.75.0.904354074481.issue11379@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

Oh, right, I missed that part. I also think that a visible note is better. And +1 for "W3C DOM interface".

----------

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

From report at bugs.python.org  Wed Mar  7 16:08:30 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Mar 2012 15:08:30 +0000
Subject: [docs] [issue14201] libc.time != libc['time']
In-Reply-To: <1330957421.08.0.5889949548.issue14201@psf.upfronthosting.co.za>
Message-ID: <1331132910.71.0.150247391857.issue14201@psf.upfronthosting.co.za>


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

Item access is documented in this section: http://docs.python.org/library/ctypes#loading-shared-libraries (scroll a bit down looking for __getitem__); the wording about caching is ambiguous with respect to the current behavior.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python, eric.araujo
stage:  -> needs patch

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

From report at bugs.python.org  Wed Mar  7 16:34:01 2012
From: report at bugs.python.org (Erik Johansson)
Date: Wed, 07 Mar 2012 15:34:01 +0000
Subject: [docs] [issue14201] Documented caching for shared library's
	__getattr__ and	__getitem__ is incorrect
In-Reply-To: <1330957421.08.0.5889949548.issue14201@psf.upfronthosting.co.za>
Message-ID: <1331134441.91.0.928537627917.issue14201@psf.upfronthosting.co.za>


Erik Johansson <erik at ejohansson.se> added the comment:

Ah, I see. I modified the title to reflect this.

Perhaps adding this simple example as well can help people (e.g. me) see it?

>>> libc.time == libc.time
True
>>> libc['time'] == libc['time']
False

----------
title: libc.time != libc['time'] -> Documented caching for shared library's __getattr__ and __getitem__ is incorrect

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

From report at bugs.python.org  Wed Mar  7 18:40:31 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Mar 2012 17:40:31 +0000
Subject: [docs] [issue14187] add "annotation" entry to Glossary
In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>
Message-ID: <1331142031.81.0.350409000513.issue14187@psf.upfronthosting.co.za>


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

I'm not sure this would be a worthwhile addition.  This language feature is not widely referenced outside the docs for the feature itself.

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

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

From report at bugs.python.org  Wed Mar  7 18:41:32 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Mar 2012 17:41:32 +0000
Subject: [docs] [issue14187] add "annotation" entry to Glossary
In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>
Message-ID: <1331142092.61.0.124865987389.issue14187@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Mar  7 22:53:54 2012
From: report at bugs.python.org (Johannes Kolb)
Date: Wed, 07 Mar 2012 21:53:54 +0000
Subject: [docs] [issue14224] packaging: path description of resources is
	mixed up
Message-ID: <1331157234.71.0.528832694178.issue14224@psf.upfronthosting.co.za>


New submission from Johannes Kolb <johannes.kolb at gmx.net>:

The documentation for "files" section of the setup.cfg file causes confusion: The examples don't match the description. Obviously the order of "destination" and "source" part in the generated filenames was mixed up in some places.

----------
assignee: docs at python
components: Documentation
files: packaging-docfixes.diff
keywords: patch
messages: 155123
nosy: docs at python, jokoala
priority: normal
severity: normal
status: open
title: packaging: path description of resources is mixed up
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24754/packaging-docfixes.diff

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

From homo_laber at yahoo.de  Wed Mar  7 20:52:25 2012
From: homo_laber at yahoo.de (Hauke Rehr)
Date: Wed, 07 Mar 2012 20:52:25 +0100
Subject: [docs] copy&waste problem
Message-ID: <4F57BC79.2070603@yahoo.de>

Hello,

I found a bug on library/re.html
  -> just before subsection 7.2.2

talking about character classes, the descriptions of the complements of 
\s and \w - that is: \S and \W - should read

[?] With LOCALE, it will match any character in this set not defined as 
space in the current locale. If UNICODE is set, this will match anything 
other than [ \t\n\r\f\v] not marked as space in the Unicode character 
properties database.

instead of

[?] With LOCALE, it will match any character not in this set, and not 
defined as space in the current locale. If UNICODE is set, this will 
match anything other than [ \t\n\r\f\v] and characters marked as space 
in the Unicode character properties database.


the same holds for \W, but there?s less to fix; I won?t repeat the 
current wording this time, but only provide a correction:

[?] If UNICODE is set, this will match anything other than [0-9_] not 
marked as alphanumeric in the Unicode character properties database.


? and while we?re at it: add a sentence about what happens if both flags 
are given (I guess they don?t interfere badly but both apply as expected)


Hauke Rehr
(Jena, Germany)

From report at bugs.python.org  Wed Mar  7 23:03:08 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Mar 2012 22:03:08 +0000
Subject: [docs] [issue14224] packaging: path description of resources is
	mixed up
In-Reply-To: <1331157234.71.0.528832694178.issue14224@psf.upfronthosting.co.za>
Message-ID: <1331157788.02.0.78499070111.issue14224@psf.upfronthosting.co.za>


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

Thanks, will apply.

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

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

From report at bugs.python.org  Wed Mar  7 23:33:13 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Mar 2012 22:33:13 +0000
Subject: [docs] [issue14217] text output pretends to be code
In-Reply-To: <1331108351.7.0.269278733631.issue14217@psf.upfronthosting.co.za>
Message-ID: <1331159593.31.0.411497891189.issue14217@psf.upfronthosting.co.za>


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

Use this:

.. code-block:: none

   output etc.

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

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

From report at bugs.python.org  Thu Mar  8 11:06:17 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 08 Mar 2012 10:06:17 +0000
Subject: [docs] [issue14217] text output pretends to be code
In-Reply-To: <1331159593.31.0.411497891189.issue14217@psf.upfronthosting.co.za>
Message-ID: <CAA77j2CESOH-Pf54dE=ufukwB4r88obtheHeAgGk1NrwBfvDPg@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Use this:
>
> .. code-block:: none
>
> ? output etc.

Thanks much. I've attached a patch.

----------
Added file: http://bugs.python.org/file24757/tis-not-code-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14217>
_______________________________________
-------------- next part --------------
diff -r b8be6ac4395d Doc/tutorial/classes.rst
--- a/Doc/tutorial/classes.rst	Wed Mar 07 08:55:52 2012 +0100
+++ b/Doc/tutorial/classes.rst	Thu Mar 08 12:03:20 2012 +0200
@@ -180,7 +180,9 @@
    scope_test()
    print("In global scope:", spam)
 
-The output of the example code is::
+The output of the example code is:
+
+.. code-block:: none
 
    After local assignment: test spam
    After nonlocal assignment: nonlocal spam

From report at bugs.python.org  Thu Mar  8 11:32:57 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Mar 2012 10:32:57 +0000
Subject: [docs] [issue14217] text output pretends to be code
In-Reply-To: <1331108351.7.0.269278733631.issue14217@psf.upfronthosting.co.za>
Message-ID: <1331202777.7.0.278890415829.issue14217@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Fri Mar  9 06:00:11 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 09 Mar 2012 05:00:11 +0000
Subject: [docs] [issue14217] text output pretends to be code
In-Reply-To: <1331108351.7.0.269278733631.issue14217@psf.upfronthosting.co.za>
Message-ID: <1331269211.19.0.942330631124.issue14217@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I reviewed the patch, built the docs and found it good.
Fixed it in 3d877dee1bde and aaf45928899c 

Thanks!

----------
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.7

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

From report at bugs.python.org  Fri Mar  9 07:06:57 2012
From: report at bugs.python.org (py.user)
Date: Fri, 09 Mar 2012 06:06:57 +0000
Subject: [docs] [issue14236] In help(re) are insufficient details
Message-ID: <1331273217.26.0.527770128505.issue14236@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

1)
help(re)

"        \s       Matches any whitespace character; equivalent to [ \t\n\r\f\v].
        \S       Matches any non-whitespace character; equiv. to [^ \t\n\r\f\v]."


no info about unicode spaces

2)
help(re.split)

"split(pattern, string, maxsplit=0, flags=0)
    Split the source string by the occurrences of the pattern,
    returning a list containing the resulting substrings."


no info about behaviour with groups in pattern

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 155207
nosy: docs at python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: In help(re) are insufficient details
versions: Python 3.2

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

From senthil at uthcode.com  Fri Mar  9 09:18:00 2012
From: senthil at uthcode.com (Senthil Kumaran)
Date: Fri, 9 Mar 2012 00:18:00 -0800
Subject: [docs] copy&waste problem
In-Reply-To: <4F57BC79.2070603@yahoo.de>
References: <4F57BC79.2070603@yahoo.de>
Message-ID: <CAPOVWOTBWAD3UNg8gcjUchqXZuXj2T=Q1ze31Pu3cajg7REyhw@mail.gmail.com>

Hello Hauke,

Yeah, it was pretty confusing. Thanks for catching this. How does this
change sound?

-   When the :const:`LOCALE` and :const:`UNICODE` flags are not
specified, matches
-   any non-whitespace character; this is equivalent to the set ``[^
\t\n\r\f\v]``
-   With :const:`LOCALE`, it will match any character not in this set, and not
-   defined as space in the current locale. If :const:`UNICODE` is
set, this will
-   match anything other than ``[ \t\n\r\f\v]`` and characters marked
as space in
-   the Unicode character properties database.
+   When the :const:`LOCALE` and :const:`UNICODE` flags are not specified,
+   matches any non-whitespace character; this is equivalent to the set ``[^
+   \t\n\r\f\v]`` With :const:`LOCALE`, it will match the above set and any
+   non-space character in the current locale. If :const:`UNICODE` is set, the
+   above set ``[^ \t\n\r\f\v]`` and characters not marked as space in the
+   Unicode character properties database.

 ``\w``
    When the :const:`LOCALE` and :const:`UNICODE` flags are not
specified, matches
@@ -381,8 +381,8 @@
    any non-alphanumeric character; this is equivalent to the set
``[^a-zA-Z0-9_]``.
    With :const:`LOCALE`, it will match any character not in the set
``[0-9_]``, and
    not defined as alphanumeric for the current locale. If
:const:`UNICODE` is set,
-   this will match anything other than ``[0-9_]`` and characters marked as
-   alphanumeric in the Unicode character properties database.
+   this will match anything other than ``[0-9_]`` plus characters classied as
+   not alphanumeric in the Unicode character properties database.


Hope the rewrite is less confusing.

We can also include this sentence somewhere.

Both re.LOCALE and re.UNICODE is specified together,in that case
re.LOCALE would be matched first and the re.UNICODE.


-- 
Senthil


On Wed, Mar 7, 2012 at 11:52 AM, Hauke Rehr <homo_laber at yahoo.de> wrote:
> Hello,
>
> I found a bug on library/re.html
> ?-> just before subsection 7.2.2
>
> talking about character classes, the descriptions of the complements of \s
> and \w - that is: \S and \W - should read
>
> [?] With LOCALE, it will match any character in this set not defined as
> space in the current locale. If UNICODE is set, this will match anything
> other than [ \t\n\r\f\v] not marked as space in the Unicode character
> properties database.
>
> instead of
>
> [?] With LOCALE, it will match any character not in this set, and not
> defined as space in the current locale. If UNICODE is set, this will match
> anything other than [ \t\n\r\f\v] and characters marked as space in the
> Unicode character properties database.
>
>
> the same holds for \W, but there?s less to fix; I won?t repeat the current
> wording this time, but only provide a correction:
>
> [?] If UNICODE is set, this will match anything other than [0-9_] not marked
> as alphanumeric in the Unicode character properties database.
>
>
> ? and while we?re at it: add a sentence about what happens if both flags are
> given (I guess they don?t interfere badly but both apply as expected)
>
>
> Hauke Rehr
> (Jena, Germany)
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs

From report at bugs.python.org  Fri Mar  9 09:33:32 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Mar 2012 08:33:32 +0000
Subject: [docs] [issue14191] argparse: nargs='*' doesn't get out-of-order
	positional	parameters
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1331282012.37.0.917233936863.issue14191@psf.upfronthosting.co.za>


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

To answer Glenn's procedural question: no this is not a bug whose fix can be backported.  API changes are not allowed in maintenance releases.  Doc improvements can be backported, though, so I'm leaving versios alone (alternatively someone could split this into two bugs, one for the doc fixes for older releases, and one for adding the new capability).

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

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

From report at bugs.python.org  Fri Mar  9 18:42:31 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 09 Mar 2012 17:42:31 +0000
Subject: [docs] [issue14236] In help(re) are insufficient details
In-Reply-To: <1331273217.26.0.527770128505.issue14236@psf.upfronthosting.co.za>
Message-ID: <1331314951.37.0.448405575611.issue14236@psf.upfronthosting.co.za>


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


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

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

From freelon at aps.anl.gov  Fri Mar  9 22:42:56 2012
From: freelon at aps.anl.gov (Byron Freelon)
Date: Fri, 09 Mar 2012 15:42:56 -0600
Subject: [docs] str.lstrip(char)  takes too many characters
Message-ID: <4F5A7960.7020404@aps.anl.gov>

Hi,

I have a string     trans_11.79_1.78_133392642.sdds

if I execute

 >>  test = trans_11.79_1.78_133392642.sdds
 >> test.lstrip("trans" +  "_"  + 11.79 + "_" + 1.78 + "_").rstrip(".sdds")

I get the result
33392642


a friend verified this problem.


Thanks

From homo_laber at yahoo.de  Fri Mar  9 15:12:22 2012
From: homo_laber at yahoo.de (Hauke Rehr)
Date: Fri, 9 Mar 2012 14:12:22 +0000 (GMT)
Subject: [docs] copy&waste problem
In-Reply-To: <CAPOVWOTBWAD3UNg8gcjUchqXZuXj2T=Q1ze31Pu3cajg7REyhw@mail.gmail.com>
Message-ID: <1331302342.87978.YahooMailClassic@web171201.mail.ir2.yahoo.com>

Hello again,

I can?t agree with your rewrite either, sorry - my suggestion based on yours:

 +???When the :const:`LOCALE` and :const:`UNICODE` flags are not specified,
+???matches any non-whitespace character; this is equivalent to the set ``[^
+???\t\n\r\f\v]`` With :const:`LOCALE`, it will match those elements of the above set
+?? not defined as space in the current locale. If :const:`UNICODE` is set, those elements
+?? of ``[^ \t\n\r\f\v]`` not marked as space in the Unicode character properties database
+?? will be matched.

If I don?t get the meaning of \S (that is: anything but \s) wrong, this should be correct.
The same applies to \W:

+???this will match anything other than ``[0-9_]`` not classified as
+?? alphanumeric in the Unicode character properties database.


For the additional sentence, I?d prefer:

+?? In case both ``re.LOCALE`` and ``re.UNICODE`` are specified alongside,
+?? these character classes will behave as if the union was given.

for that?s the logic behind.

Hauke

--- Senthil Kumaran <senthil at uthcode.com> schrieb am Fr, 9.3.2012:

Von: Senthil Kumaran <senthil at uthcode.com>
Betreff: Re: [docs] copy&waste problem
An: "Hauke Rehr" <homo_laber at yahoo.de>
CC: docs at python.org
Datum: Freitag, 9. M?rz, 2012 09:18 Uhr

Hello Hauke,

Yeah, it was pretty confusing. Thanks for catching this. How does this
change sound?

-???When the :const:`LOCALE` and :const:`UNICODE` flags are not
specified, matches
-???any non-whitespace character; this is equivalent to the set ``[^
\t\n\r\f\v]``
-???With :const:`LOCALE`, it will match any character not in this set, and not
-???defined as space in the current locale. If :const:`UNICODE` is
set, this will
-???match anything other than ``[ \t\n\r\f\v]`` and characters marked
as space in
-???the Unicode character properties database.
+???When the :const:`LOCALE` and :const:`UNICODE` flags are not specified,
+???matches any non-whitespace character; this is equivalent to the set ``[^
+???\t\n\r\f\v]`` With :const:`LOCALE`, it will match the above set and any
+???non-space character in the current locale. If :const:`UNICODE` is set, the
+???above set ``[^ \t\n\r\f\v]`` and characters not marked as space in the
+???Unicode character properties database.

 ``\w``
? ? When the :const:`LOCALE` and :const:`UNICODE` flags are not
specified, matches
@@ -381,8 +381,8 @@
? ? any non-alphanumeric character; this is equivalent to the set
``[^a-zA-Z0-9_]``.
? ? With :const:`LOCALE`, it will match any character not in the set
``[0-9_]``, and
? ? not defined as alphanumeric for the current locale. If
:const:`UNICODE` is set,
-???this will match anything other than ``[0-9_]`` and characters marked as
-???alphanumeric in the Unicode character properties database.
+???this will match anything other than ``[0-9_]`` plus characters classied as
+???not alphanumeric in the Unicode character properties database.


Hope the rewrite is less confusing.

We can also include this sentence somewhere.

Both re.LOCALE and re.UNICODE is specified together,in that case
re.LOCALE would be matched first and the re.UNICODE.


-- 
Senthil

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

From report at bugs.python.org  Sat Mar 10 01:04:12 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 10 Mar 2012 00:04:12 +0000
Subject: [docs] [issue14191] argparse: nargs='*' doesn't get out-of-order
	positional	parameters
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1331337852.08.0.696657544384.issue14191@psf.upfronthosting.co.za>


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

Sad.  That means all the documentation of workarounds needs to be written, even figured out in the first place.  Steven's code, while being a nice implementation when proper arguments are provided, produces inappropriate errors, because only the positional, or only the optional, parameters are printed when errors occur.

So it would probably take a third parser, with all the parameters defined, to exist, to allow easiest generation of the usage message, but I'm not quite sure how to catch the error printing, and redirect it to the third parser.

So, I tried the classes in t17.py; they are not complete; CompatibleArgumentParser should pass through all the other APIs, and I'm not sure if all the extension semantics can be appropriately passed through when there are three classes and two objects involved.  But this is sort of a proof-of-concept wrapper for achieving intermixed optional and positional arguments, and still get proper error messages.

----------
Added file: http://bugs.python.org/file24771/t18.py

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

From report at bugs.python.org  Sat Mar 10 02:16:34 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 10 Mar 2012 01:16:34 +0000
Subject: [docs] [issue14191] argparse: nargs='*' doesn't get out-of-order
	positional	parameters
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1331342192.07.0.999930983987.issue14191@psf.upfronthosting.co.za>


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

Of course, if a "real" solution can only be shipped in 3.3, it may want to use a different API than parse_args to avoid the parameter, parse_intermixed_args, perhaps. But my t18.py uses the name parse_args, but just always does the intermixed parsing, so that is something to be aware of if building on that code at all, for the real solution or for sample code for older versions.

----------

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

From report at bugs.python.org  Sat Mar 10 03:20:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Mar 2012 02:20:18 +0000
Subject: [docs] [issue14187] add "annotation" entry to Glossary
In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>
Message-ID: <1331346018.37.0.645439386038.issue14187@psf.upfronthosting.co.za>


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

I think too that function annotations don?t need to be in the glossary; documenting them in the language reference section that talks about defining functions should be enough.  What do you think, Chris?

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

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

From report at bugs.python.org  Sat Mar 10 03:22:40 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Mar 2012 02:22:40 +0000
Subject: [docs] [issue14186] Link to PEP 3107 in "def" part of Language
	Reference
In-Reply-To: <1330805711.99.0.463703521532.issue14186@psf.upfronthosting.co.za>
Message-ID: <1331346160.53.0.00750614438134.issue14186@psf.upfronthosting.co.za>


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

Sure.  Don?t know if we should use a seealso section or just a regular link.

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

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

From report at bugs.python.org  Sat Mar 10 03:24:08 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Mar 2012 02:24:08 +0000
Subject: [docs] [issue14219] start the Class tutorial in a more gentle manner
In-Reply-To: <1331111619.2.0.272575522063.issue14219@psf.upfronthosting.co.za>
Message-ID: <1331346248.4.0.851552511674.issue14219@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Mar 10 03:27:09 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Mar 2012 02:27:09 +0000
Subject: [docs] =?utf-8?q?=5Bissue14236=5D_re=3A_Docstring_for_=5Cs_and_?=
 =?utf-8?q?=5CS_don=E2=80=99t_mention_Unicode?=
In-Reply-To: <1331273217.26.0.527770128505.issue14236@psf.upfronthosting.co.za>
Message-ID: <1331346429.75.0.108740747221.issue14236@psf.upfronthosting.co.za>


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

Please open another report for your second bug.  Thanks.

----------
nosy: +eric.araujo
title: In help(re) are insufficient details -> re: Docstring for \s and \S don?t mention Unicode
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Mar 10 03:35:41 2012
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 10 Mar 2012 02:35:41 +0000
Subject: [docs] [issue14186] Link to PEP 3107 in "def" part of Language
	Reference
In-Reply-To: <1330805711.99.0.463703521532.issue14186@psf.upfronthosting.co.za>
Message-ID: <1331346941.09.0.01624055108.issue14186@psf.upfronthosting.co.za>


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

My suggestion was a seealso to parallel those in the "The with Statement" and "Class definitions" sections of the same page.

----------

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

From report at bugs.python.org  Sat Mar 10 04:08:22 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 10 Mar 2012 03:08:22 +0000
Subject: [docs] [issue14244] No information about behaviour with groups in
	pattern in	the docstring for re.split
Message-ID: <1331348902.51.0.968875082813.issue14244@psf.upfronthosting.co.za>


New submission from Ramchandra Apte <maniandram01 at gmail.com>:

help(re.split)

"split(pattern, string, maxsplit=0, flags=0)
    Split the source string by the occurrences of the pattern,
    returning a list containing the resulting substrings."


No info is given about behaviour with groups in pattern.
Created because of http://bugs.python.org/issue14236#msg155283.

----------
assignee: docs at python
components: Documentation
messages: 155286
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: No information about behaviour with groups in pattern in the docstring for re.split

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

From report at bugs.python.org  Sat Mar 10 04:08:59 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 10 Mar 2012 03:08:59 +0000
Subject: [docs] =?utf-8?q?=5Bissue14236=5D_re=3A_Docstring_for_=5Cs_and_?=
 =?utf-8?q?=5CS_don=E2=80=99t_mention_Unicode?=
In-Reply-To: <1331273217.26.0.527770128505.issue14236@psf.upfronthosting.co.za>
Message-ID: <1331348939.27.0.823424161719.issue14236@psf.upfronthosting.co.za>


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

Done so see issue14244 .

----------
nosy: +ramchandra.apte

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

From report at bugs.python.org  Sat Mar 10 04:10:50 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 10 Mar 2012 03:10:50 +0000
Subject: [docs] [issue14244] No information about behaviour with groups in
	pattern in	the docstring for re.split
In-Reply-To: <1331348902.51.0.968875082813.issue14244@psf.upfronthosting.co.za>
Message-ID: <1331349050.01.0.905430307483.issue14244@psf.upfronthosting.co.za>


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

Oops. The link in the last sentence doesn't work.
It should be see msg155283 .

----------

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

From report at bugs.python.org  Sat Mar 10 05:52:48 2012
From: report at bugs.python.org (py.user)
Date: Sat, 10 Mar 2012 04:52:48 +0000
Subject: [docs] [issue14244] No information about behaviour with groups in
	pattern in	the docstring for re.split
In-Reply-To: <1331348902.51.0.968875082813.issue14244@psf.upfronthosting.co.za>
Message-ID: <1331355168.19.0.328928023158.issue14244@psf.upfronthosting.co.za>


Changes by py.user <port139 at yandex.ru>:


----------
components: +Regular Expressions
nosy: +ezio.melotti, mrabarnett, py.user
versions: +Python 3.2

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

From report at bugs.python.org  Sat Mar 10 09:23:28 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Mar 2012 08:23:28 +0000
Subject: [docs] [issue14244] No information about behaviour with groups in
	pattern in	the docstring for re.split
In-Reply-To: <1331348902.51.0.968875082813.issue14244@psf.upfronthosting.co.za>
Message-ID: <E1S6HaJ-0002yQ-6b@dinsdale.python.org>


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

New changeset b96251d9f36a by Georg Brandl in branch '3.2':
Closes #14244: add info about capturing groups and maxsplit to the docstring of re.split().
http://hg.python.org/cpython/rev/b96251d9f36a

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

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

From report at bugs.python.org  Sat Mar 10 09:23:28 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Mar 2012 08:23:28 +0000
Subject: [docs] [issue14186] Link to PEP 3107 in "def" part of Language
	Reference
In-Reply-To: <1330805711.99.0.463703521532.issue14186@psf.upfronthosting.co.za>
Message-ID: <E1S6HaJ-0002yQ-71@dinsdale.python.org>


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

New changeset c18d538d2ece by Georg Brandl in branch '3.2':
Closes #14186: add link to PEP 3107 (function annotations) to the function definition section.
http://hg.python.org/cpython/rev/c18d538d2ece

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

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

From report at bugs.python.org  Sat Mar 10 09:24:22 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 10 Mar 2012 08:24:22 +0000
Subject: [docs] [issue14244] No information about behaviour with groups in
	pattern in	the docstring for re.split
In-Reply-To: <1331348902.51.0.968875082813.issue14244@psf.upfronthosting.co.za>
Message-ID: <1331367862.61.0.0635531887082.issue14244@psf.upfronthosting.co.za>


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

Thank you, should be fixed now.

----------
nosy: +georg.brandl
stage: committed/rejected -> 

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

From report at bugs.python.org  Sat Mar 10 09:42:14 2012
From: report at bugs.python.org (py.user)
Date: Sat, 10 Mar 2012 08:42:14 +0000
Subject: [docs] [issue14244] No information about behaviour with groups in
	pattern in	the docstring for re.split
In-Reply-To: <1331348902.51.0.968875082813.issue14244@psf.upfronthosting.co.za>
Message-ID: <1331368934.8.0.996037634245.issue14244@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

"+    returning a list containing the resulting substrings.  If
+    capturing parentheses are used in pattern, then the text of all
+    groups in the pattern are also returned as part of the resulting
+    list."

not only text

>>> import re
>>> re.split(r'(a)(x)?', 'abcabc')
['', 'a', None, 'bc', 'a', None, 'bc']
>>>

----------

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

From report at bugs.python.org  Sat Mar 10 10:35:13 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 10 Mar 2012 09:35:13 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
Message-ID: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za>


New submission from Zbyszek Szmek <zbyszek at in.waw.pl>:

http://docs.python.org/dev/faq/design.html#why-are-floating-point-calculations-so-inaccurate

This whole paragraph is wrong since #9337 (Make float.__str__ behave identically to float.__repr__).
"""
The str() function prints fewer digits and this often results in the more sensible number that was probably intended:
>>> 1.1 - 0.9
0.20000000000000007
>>> print(1.1 - 0.9)
0.2
"""

Applies from 3.2 onwards.

----------
assignee: docs at python
components: Documentation
messages: 155300
nosy: docs at python, zbysz
priority: normal
severity: normal
status: open
title: float rounding examples in FAQ are outdated
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Mar 10 12:10:49 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Mar 2012 11:10:49 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za>
Message-ID: <1331377849.88.0.806953229713.issue14245@psf.upfronthosting.co.za>


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

Agreed.  Do you have a suggested rewrite?

That faq entry could be improved significantly in many ways;  the tutorial material is much better.  I'm wondering whether it would be better to cut down the FAQ to much something much briefer, and leave the link to the tutorial for people who want more.

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

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

From report at bugs.python.org  Sat Mar 10 12:26:28 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Mar 2012 11:26:28 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za>
Message-ID: <1331378788.28.0.772857729367.issue14245@psf.upfronthosting.co.za>


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

Proposed rewrite:




Why are floating point calculations inaccurate?
-----------------------------------------------

Users are often surprised by results like this::

   >>> 1.2 - 1.0
   0.199999999999999996

and think it is a bug in Python.  It's not.  This has little to do with Python,
and much more to do with how the underlying platform handles floating-point
numbers.

Python floats are stored internally in binary floating-point, using a fixed
precision (typically 53 bits).  Many numbers that can be written easily in
decimal notation (``1.2``, for example), cannot be expressed exactly in this
internal binary format.  After::

   >>> x = 1.2

the value stored for x is a (very good) approximation to the value ``1.2``, but
is not exactly equal to it.  (On a typical machine, the actual stored value
is::

   1.1999999999999999555910790149937383830547332763671875

which is accurate to around 16 decimal digits.)  Similarly, the result of any
floating-point operation must often be rounded to fit into the internal format,
resulting in another tiny error.

For a more detailed explanation of what's involved, please see the chapter on
:ref:`floating point arithmetic <tut-fp-issues>` in the Python tutorial.

----------

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

From report at bugs.python.org  Sat Mar 10 14:56:04 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 10 Mar 2012 13:56:04 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za>
Message-ID: <1331387764.37.0.304066628992.issue14245@psf.upfronthosting.co.za>


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

+1

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

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

From report at bugs.python.org  Sat Mar 10 15:09:48 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 10 Mar 2012 14:09:48 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <1331378788.28.0.772857729367.issue14245@psf.upfronthosting.co.za>
Message-ID: <4F5B609F.9050407@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

On 03/10/2012 12:26 PM, Mark Dickinson wrote:
>
> Mark Dickinson<dickinsm at gmail.com>  added the comment:
>
> Proposed rewrite:

Hi,
thanks for the quick reply. If we were to rewrite the whole entry, some 
more changes could be done:

I think it would be useful to mention explicitly that Python simply uses 
the native floating-point implementation in hardware and thus behaves 
very similarly to other languages which do this, for instance C or Java. 
This should clear up a lot of the behaviour for people who know other 
programming languages. "how the underlying platform handles 
floating-point" says something very similar, but the reader needs to 
understand what the "underlying platform" exactly is.

It is easy to count, that exactly 17 digits are accurate.

I have to admit, that I'm completely lost here --- why would a vastly 
inaccurate number (with more than half of digits wrong) be ever stored?
If "1.2" is converted to a float (a C double in current implementation), 
it has 15.96 decimal digits of precision.

"Similarly, the result of a floating-point operation must be rounded to 
fit into the fixed precision, often resulting in another tiny error." ?

----------

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

From report at bugs.python.org  Sat Mar 10 15:17:02 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 10 Mar 2012 14:17:02 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <4F5B609F.9050407@in.waw.pl>
Message-ID: <4F5B6257.9050003@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

[part mangled by the tracker]

">     1.1999999999999999555910790149937383830547332763671875
">
"> which is accurate to around 16 decimal digits.)

It is easy to count, that exactly 17 digits are accurate.

I have to admit, that I'm completely lost here --- why would a vastly
inaccurate number (with more than half of digits wrong) be ever stored?
If "1.2" is converted to a float (a C double in current implementation),
it has 15.96 decimal digits of precision.

" > Similarly, the result of any
" > floating-point operation must often be rounded to fit into the
" > internal format, resulting in another tiny error.
"Similarly, the result of a floating-point operation must be rounded to 
fit into the fixed precision, often resulting in another tiny error." ?

----------

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

From report at bugs.python.org  Sat Mar 10 15:37:35 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Mar 2012 14:37:35 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za>
Message-ID: <1331390255.21.0.339765760796.issue14245@psf.upfronthosting.co.za>


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

> I think it would be useful to mention explicitly that Python simply uses 
> the native floating-point implementation in hardware and thus behaves 
> very similarly to other languages which do this, for instance C or Java. 

Agreed that it's useful to say something here to make it obvious that Python's behaving just like most other mainstream programming languages.  Perhaps most straightforward would be to state that CPython just uses C doubles.  (That sidesteps nitpicking about software floating-point :-).

> It is easy to count, that exactly 17 digits are accurate.

Hmm;  that depends a bit on your definitions.  The relative error here is around 3.7e-17, so in this particular case you're getting something between 16 and 17 decimal digits of accuracy.  Other cases would produce different relative errors, with a max relative error for normal cases of 2**-53, or approximately 1.1e-16.

> I have to admit, that I'm completely lost here --- why would a vastly 
> inaccurate number (with more than half of digits wrong) be ever stored?

Because that number is the unique closest representable IEEE 754 double to the target number (1.2).  You can go through all the steps here:

 - convert 1.2 to binary, to get:

    1.001100110011001100110011.....  repeated ad infinitum

 - round to the nearest 53-bit number:

    1.0011001100110011001100110011001100110011001100110011

 - convert back to decimal to get the number that I gave.

But this sort of detail is already there in the tutorial, and doesn't seem appropriate for the FAQ entry.  For the FAQ, maybe it would be less confusing to give only about a 20-digit approximation.

> "Similarly, the result of any
> floating-point operation must often be rounded to fit into the 
> internal format,
> resulting in another tiny error." ?

The aim here was to make the point that it's not just conversion from decimal to binary that introduces errors;  it's also true that any arithmetic operation has the potential to introduce errors.  For example, 10**16 and 1 are both exactly representable as floats, but the sum of 10**16 + 1 is not;  the result has to be rounded to fit into a float.  Suggestions for rewording to make this clearer are welcome!

----------

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

From report at bugs.python.org  Sat Mar 10 15:51:00 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 10 Mar 2012 14:51:00 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <4F5B609F.9050407@in.waw.pl>
Message-ID: <4F5B6A50.3080506@v.loewis.de>


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

> I think it would be useful to mention explicitly that Python simply uses
> the native floating-point implementation in hardware and thus behaves
> very similarly to other languages which do this, for instance C or Java.
> This should clear up a lot of the behaviour for people who know other
> programming languages. "how the underlying platform handles
> floating-point" says something very similar, but the reader needs to
> understand what the "underlying platform" exactly is.

Well, people may just be as confused about the term "native 
implementation" as they are seemingly confused about "underlying
platform".

 >
> I have to admit, that I'm completely lost here --- why would a vastly
> inaccurate number (with more than half of digits wrong) be ever stored?
> If "1.2" is converted to a float (a C double in current implementation),
> it has 15.96 decimal digits of precision.

Since it has this number of decimal digits of precision, the text says
"about 16", rather than "exactly 17", which would mislead people into
thinking that they get 17 digits of precision.

I don't understand your confusion. The numbers are stored in binary,
and it's *not* the case that half of the digits are wrong. In binary,
all 53 bits of mantissa are correct. When displaying this number in
decimal (which is not the way in which it is stored), then you many more
decimal digits to make the decimal representation correct.

----------

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

From report at bugs.python.org  Sat Mar 10 19:21:26 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 10 Mar 2012 18:21:26 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za>
Message-ID: <1331403686.47.0.300772606512.issue14245@psf.upfronthosting.co.za>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Proposed rewrite (building on Mark's version):
- mention C doubles
- explain ``1.2`` example a bit more

"""
Why are floating-point calculations inaccurate?
-----------------------------------------------

Users are often surprised by results like this::

   >>> 1.2 - 1.0
   0.199999999999999996

and think it is a bug in Python.  It's not.  This has little to do with Python,
and much more to do with how the underlying platform handles floating-point
numbers.

The float type in CPython simply uses C ``double`` for storage. The number is stored in binary floating-point with a fixed precision (typically 53 bits) and Python uses C operations, which in turn rely on the hardware implementation in the processor, to perform floating-point operations. This means that as far as floating-point operations are concerned, Python behaves like many popular languages including C and Java.

Many numbers that can be written easily in decimal notation (``1.2``, for example), cannot be expressed exactly in the binary format.  After::

   >>> x = 1.2

the value stored for ``x`` is a (very good) approximation of the value ``1.2``, but
is not exactly equal to it.  On a typical machine, the actual stored value
is::

   1.0011001100110011001100110011001100110011001100110011 (binary)

which is approximately::

   1.19999999999999995559 (decimal)

53 binary digits are equivalent to about 16 decimal digits and in this case the first 17 digits are correct after the conversion back to decimal.

Similarly, the result of any floating-point operation must be rounded to 
fit into the fixed precision, often resulting in another tiny error.

For a more detailed explanation of what's involved, please see the chapter on
:ref:`floating point arithmetic <tut-fp-issues>` in the Python tutorial.
"""

----------

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

From report at bugs.python.org  Sat Mar 10 19:52:18 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 10 Mar 2012 18:52:18 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <1331403686.47.0.300772606512.issue14245@psf.upfronthosting.co.za>
Message-ID: <4F5BA2E0.80900@v.loewis.de>


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

> - explain ``1.2`` example a bit more

+1 for giving the binary representation; -1 for rounding
the decimal version of it.

----------

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

From report at bugs.python.org  Sat Mar 10 20:43:19 2012
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 10 Mar 2012 19:43:19 +0000
Subject: [docs] =?utf-8?q?=5Bissue14248=5D_Typo_in_=22What=E2=80=99s_New_I?=
 =?utf-8?q?n_Python_3=2E3=22=3A_=22comparaison=22?=
Message-ID: <1331408599.07.0.132199218541.issue14248@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

Typo in Doc/whatsnew/3.3.rst: "comparaison" -> "comparison".

----------
assignee: docs at python
components: Documentation
messages: 155347
nosy: docs at python, jwilk
priority: normal
severity: normal
status: open
title: Typo in "What?s New In Python 3.3": "comparaison"
versions: Python 3.3

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

From report at bugs.python.org  Sat Mar 10 20:52:23 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Mar 2012 19:52:23 +0000
Subject: [docs] =?utf-8?q?=5Bissue14248=5D_Typo_in_=22What=E2=80=99s_New_I?=
 =?utf-8?q?n_Python_3=2E3=22=3A_=22comparaison=22?=
In-Reply-To: <1331408599.07.0.132199218541.issue14248@psf.upfronthosting.co.za>
Message-ID: <E1S6SKz-0003Ap-Mr@dinsdale.python.org>


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

New changeset 9afbb3af1693 by Georg Brandl in branch 'default':
Close #14248: fix typo.
http://hg.python.org/cpython/rev/9afbb3af1693

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

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

From report at bugs.python.org  Sat Mar 10 21:10:12 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 10 Mar 2012 20:10:12 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <4F5BA2E0.80900@v.loewis.de>
Message-ID: <4F5BB51B.6050602@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

On 03/10/2012 07:52 PM, Martin v. L?wis wrote:
>> - explain ``1.2`` example a bit more
>
> +1 for giving the binary representation; -1 for rounding
> the decimal version of it.

Oh, 1.1999999999999999555910790149937383830547332763671875
is exactly equal to 
1.0011001100110011001100110011001100110011001100110011. In this case 
yes, rounding it is not beneficial.

So one more version (without this rounding):

"""
Why are floating-point calculations inaccurate?
-----------------------------------------------

Users are often surprised by results like this::

    >>> 1.2 - 1.0
    0.199999999999999996

and think it is a bug in Python.  It's not.  This has little to do with 
Python, and much more to do with how the underlying platform handles 
floating-point numbers.

The float type in CPython simply uses C ``double`` for storage. The 
number is stored in binary floating-point with a fixed precision 
(typically 53 bits) and Python uses C operations, which in turn rely on 
the hardware implementation in the processor, to perform floating-point 
operations. This means that as far as floating-point operations are 
concerned, Python behaves like many popular languages including C and Java.

Many numbers that can be written easily in decimal notation (``1.2``, 
for example), cannot be expressed exactly in the binary format.  After::

    >>> x = 1.2

the value stored for ``x`` is a (very good) approximation of the value 
``1.2``, but is not exactly equal to it.  On a typical machine, the 
actual stored value is::

    1.0011001100110011001100110011001100110011001100110011 (binary)

which is exactly::

    1.1999999999999999555910790149937383830547332763671875 (decimal)

53 binary digits are equivalent to about 16 decimal digits and in this 
case the first 17 digits are correct after the conversion back to decimal.

Similarly, the result of any floating-point operation must be rounded to 
fit into the fixed precision, often resulting in another tiny error.

For a more detailed explanation of what's involved, please see the 
chapter on :ref:`floating point arithmetic <tut-fp-issues>` in the 
Python tutorial.
"""

----------

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

From johnroth1 at gmail.com  Sat Mar 10 22:00:38 2012
From: johnroth1 at gmail.com (John Roth)
Date: Sat, 10 Mar 2012 14:00:38 -0700
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <mailman.4303.1331410212.3036.docs@python.org>
References: <mailman.4303.1331410212.3036.docs@python.org>
Message-ID: <4F5BC0F6.30107@gmail.com>

I keep looking at this issue. What rattles around in my head is the 
satori I had when I first heard "integers are for things that are 
counted, floats are for things that are measured." Possibly something to 
the effect that "the industry standard for floating point is intended 
for measurements, which are never absolutely precise. Thus floating 
point, by its nature, will not usually represent factions as precisely 
as one would like."

From report at bugs.python.org  Sun Mar 11 01:46:32 2012
From: report at bugs.python.org (py.user)
Date: Sun, 11 Mar 2012 00:46:32 +0000
Subject: [docs] [issue14250] regex.flags is never equal to 0
Message-ID: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

http://docs.python.org/py3k/library/re.html#re.regex.flags
"or 0 if no flags were provided"

>>> import re
>>> p = re.compile(r'', 0)
>>> p.flags
32
>>>

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 155362
nosy: docs at python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: regex.flags is never equal to 0
versions: Python 3.2

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

From report at bugs.python.org  Sun Mar 11 03:01:13 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 11 Mar 2012 02:01:13 +0000
Subject: [docs] [issue14250] regex.flags is never equal to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331431272.76.0.0531426956919.issue14250@psf.upfronthosting.co.za>


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

32 is re.U, which is always ored with the passed in flags, unless re.A is set in the passed in flags.  The flag docs should certinaly be updated to reflect this.

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

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

From report at bugs.python.org  Sun Mar 11 03:15:54 2012
From: report at bugs.python.org (Ejaj Hassan)
Date: Sun, 11 Mar 2012 02:15:54 +0000
Subject: [docs] [issue14190] Minor C API documentation bugs
In-Reply-To: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za>
Message-ID: <1331432154.07.0.550793955707.issue14190@psf.upfronthosting.co.za>


Ejaj Hassan <starhunter7 at gmail.com> added the comment:

The patch removes the function *PyCodec_KnownEncoding
form document codec.rst
found in cpython/doc/c-api

----------
keywords: +patch
nosy: +ejjy
Added file: http://bugs.python.org/file24779/issues14190.diff

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

From report at bugs.python.org  Sun Mar 11 04:08:00 2012
From: report at bugs.python.org (Ejaj Hassan)
Date: Sun, 11 Mar 2012 03:08:00 +0000
Subject: [docs] [issue14190] Minor C API documentation bugs
In-Reply-To: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za>
Message-ID: <1331435280.38.0.687916672496.issue14190@psf.upfronthosting.co.za>


Ejaj Hassan <starhunter7 at gmail.com> added the comment:

The diff file is the second submission containing the fixes to the following bugs:
* PyCode_GetNumFree accepts a PyCodeObject* not PyObject*
* PyOS_strnicmp returns int, not char*
* PyUnicode_RichCompare returns PyObject*, not int
* PyType_IS_GC needs a PyTypeObject*, not PyObject*
* PyType_HasFeature needs a PyTypeObject*, not PyObject*
 
Well, if the problems given are specified with each's version, then it would make it easier. Some of the reported bugs are not associated with version 2.7

----------
Added file: http://bugs.python.org/file24781/issues14190-2.diff

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

From eliben at gmail.com  Sun Mar 11 04:28:14 2012
From: eliben at gmail.com (Eli Bendersky)
Date: Sun, 11 Mar 2012 05:28:14 +0200
Subject: [docs] str.lstrip(char) takes too many characters
In-Reply-To: <4F5A7960.7020404@aps.anl.gov>
References: <4F5A7960.7020404@aps.anl.gov>
Message-ID: <CAF-Rda_U7B4Z=CcQnGaN5qbix1Pjz94Se7QQT3q4n=KZEqVPXw@mail.gmail.com>

> I have a string ? ? trans_11.79_1.78_133392642.sdds
>
> if I execute
>
> >> ?test = trans_11.79_1.78_133392642.sdds
> >> test.lstrip("trans" + ?"_" ?+ 11.79 + "_" + 1.78 + "_").rstrip(".sdds")
>
> I get the result
> 33392642
>
>
> a friend verified this problem.


Byron, here's the documentation of lstrip:

----
str.lstrip([chars])

Return a copy of the string with leading characters removed. The chars
argument is a string specifying the set of characters to be removed.
If omitted or None, the chars argument defaults to removing
whitespace. The chars argument is not a prefix; rather, all
combinations of its values are stripped:
----

Read the last sentence, especially, and note that "1" appears as one
of the chars that should be removed.

Eli

From report at bugs.python.org  Sun Mar 11 11:21:09 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Mar 2012 10:21:09 +0000
Subject: [docs] [issue14250] regex.flags is never equal to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331461269.45.0.49972118383.issue14250@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 11 14:48:08 2012
From: report at bugs.python.org (Johannes Kolb)
Date: Sun, 11 Mar 2012 13:48:08 +0000
Subject: [docs] [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1331473688.21.0.868440735968.issue13498@psf.upfronthosting.co.za>


Johannes Kolb <johannes.kolb at gmx.net> added the comment:

I want to mention a situation in which the current behaviour of os.makedirs is
confusing. At the first glance I would expect that if
>>> os.makedirs(path)
succeeds, then a following call to
>>> os.makedirs(path, exist_ok=True)
will succeed too.

This is not always the case. Consider this (assuming Linux as OS and the umask
set to 0o022):
>>> os.makedirs('/tmp/mytest')
>>> os.chmod('/tmp/mytest', 0o2755)
>>> path='/tmp/mytest/dir1'
>>> os.makedirs(path)
>>> os.makedirs(path, exist_ok=True)
OSError: [Errno 17] File exists: '/tmp/mytest/dir1'

The directory '/tmp/mytest' here has the SETGID flag set, which is inherited
automatically. Therefore the flags of '/tmp/mytest/dir1' are not 0o755 as expected by os.makedirs, but 0o2755.

The same problem occurs if the user can changes the umask between the calls to
os.makedirs.

I wonder in what situation the current behaviour of os.makedirs is really
helpful and not introducing subtle bugs. Consider using os.makedirs to ensure
that the output directory of your script exists. Now the user decides to make
this output directory world writeable. For most cases this is no problem, but
os.makedirs will complain.

----------
nosy: +jokoala

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

From report at bugs.python.org  Sun Mar 11 22:58:50 2012
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 11 Mar 2012 21:58:50 +0000
Subject: [docs] [issue14187] add "annotation" entry to Glossary
In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>
Message-ID: <1331503130.7.0.427739940182.issue14187@psf.upfronthosting.co.za>


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

Well, I thought the Glossary was a somewhat useful document in and of itself ("What's conceptual term 'X' mean? Hmm... I'll check the Glossary!") and so should include all terms which aren't module-specific.

But I won't push hard if no one else sees value in adding this entry.

----------

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

From report at bugs.python.org  Sun Mar 11 23:16:20 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Mar 2012 22:16:20 +0000
Subject: [docs] [issue14187] add "annotation" entry to Glossary
In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>
Message-ID: <1331504180.75.0.254074001271.issue14187@psf.upfronthosting.co.za>


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

FWIW searching for "annotations" in the Sphinx quick search doesn't yield anything interesting, and the first result that actually contains a paragraph about annotations is the 11th (compound statements).

----------

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

From report at bugs.python.org  Sun Mar 11 23:30:40 2012
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 11 Mar 2012 22:30:40 +0000
Subject: [docs] [issue14187] add "annotation" entry to Glossary
In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>
Message-ID: <1331505040.75.0.429059762954.issue14187@psf.upfronthosting.co.za>


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

Also, it would be a nice place to point out for those coming from Java or similar that the Java-esque concept of annotations has little to do with Python's function annotations, and that in Python their uses are typically served using decorators instead.

----------

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

From report at bugs.python.org  Mon Mar 12 00:13:19 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Mar 2012 23:13:19 +0000
Subject: [docs] [issue14187] add "annotation" entry to Glossary
In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>
Message-ID: <1331507599.48.0.684604630808.issue14187@psf.upfronthosting.co.za>


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

Propose some brief text for an entry so we have something to evaluate for its utility.

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

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

From report at bugs.python.org  Mon Mar 12 01:14:32 2012
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 12 Mar 2012 00:14:32 +0000
Subject: [docs] [issue14187] add "annotation" entry to Glossary
In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>
Message-ID: <1331511272.21.0.909972779247.issue14187@psf.upfronthosting.co.za>


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

Strawman entry wording:

An annotation is an arbitrary metadata value associated with a function parameter or return value. The syntax for function annotations is explained in [Function definitions][http://docs.python.org/dev/reference/compound_stmts.html#function-definitions]. Annotations may be accessed via the [__annotations__][http://docs.python.org/dev/reference/datamodel.html#the-standard-type-hierarchy : Callable types -> User-defined functions -> Special attributes] special attribute of a function object.

Python itself does not assign any particular meaning to function annotations; they are intended to be interpreted by third-party libraries or tools. Annotations were added to Python by [PEP 3107 "Function Annotations"][http://www.python.org/dev/peps/pep-3107/], which describes some of their possible uses.

Some other languages (e.g. Java, C#) also have a concept of "annotations", but it is distinct from the Python concept; the purpose of these "annotations" is served in Python using [decorators]["decorator" entry in Glossary] instead.

----------

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

From report at bugs.python.org  Mon Mar 12 01:32:26 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 12 Mar 2012 00:32:26 +0000
Subject: [docs] [issue14250] regex.flags is never equal to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331512346.91.0.456845139769.issue14250@psf.upfronthosting.co.za>


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


----------
keywords: +easy

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

From report at bugs.python.org  Mon Mar 12 02:27:06 2012
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 12 Mar 2012 01:27:06 +0000
Subject: [docs] [issue14257] minor error in glossary wording regarding
	__hash__
Message-ID: <1331515626.11.0.049158499672.issue14257@psf.upfronthosting.co.za>


New submission from Chris Rebert <pybugs at rebertia.com>:

The entry for "dictionary" reads in part:
    [...] The keys can be any object with __hash__() function and __eq__() methods. [...]

__hash__() is a method, not a function (well, it's a "hash function" in the computer science sense, but it's still confusing even if that reading is what was intended; I think delegating the hashing part of the explanation to __hash__()'s docs is fine). Remove the word "function" from said sentence.

----------
assignee: docs at python
components: Documentation
messages: 155427
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: minor error in glossary wording regarding __hash__
versions: Python 3.3

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

From senthil at uthcode.com  Mon Mar 12 04:09:11 2012
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 11 Mar 2012 20:09:11 -0700
Subject: [docs] copy&waste problem
In-Reply-To: <1331302342.87978.YahooMailClassic@web171201.mail.ir2.yahoo.com>
References: <CAPOVWOTBWAD3UNg8gcjUchqXZuXj2T=Q1ze31Pu3cajg7REyhw@mail.gmail.com>
	<1331302342.87978.YahooMailClassic@web171201.mail.ir2.yahoo.com>
Message-ID: <CAPOVWOQs0O8Dx-iGfsUE4U7YQcws5OpqPtkuVjbp5FJffusiUQ@mail.gmail.com>

Hello Hauke,

I guess, you are mistaken with the meaning of re.LOCALE flag for space.  It
is not intersection but Union of the locale's space characters with the
ascii space characters.

For \S, with `LOCALE flag set, it will match [^ \t\n\r\f\v] plus any
non-whitespace characters defined by that locale.



+   In case both ``re.LOCALE`` and ``re.UNICODE`` are specified alongside,
+   these character classes will behave as if the union was given.

Where did you find this logic? I see that, locale flag is matched first and
then unicode.

In Modules\_sre.c

if (pattern->flags & SRE_FLAG_LOCALE)
        state->lower = sre_lower_locale;
    else if (pattern->flags & SRE_FLAG_UNICODE)


I am going ahead with the changes as I suggested previously and also
opening a bug report. Further discussions and changes can be tracked there.
Yeah, sometimes doc changes go for discussions and iterations too. :(

-- 
Senthil



On Fri, Mar 9, 2012 at 6:12 AM, Hauke Rehr <homo_laber at yahoo.de> wrote:

> Hello again,
>
> I can?t agree with your rewrite either, sorry - my suggestion based on
> yours:
>
>
> +   When the :const:`LOCALE` and :const:`UNICODE` flags are not specified,
> +   matches any non-whitespace character; this is equivalent to the set
> ``[^
> +   \t\n\r\f\v]`` With :const:`LOCALE`, it will match those elements of
> the above set
> +   not defined as space in the current locale. If :const:`UNICODE` is
> set, those elements
> +   of ``[^ \t\n\r\f\v]`` not marked as space in the Unicode character
> properties database
> +   will be matched.
>
> If I don?t get the meaning of \S (that is: anything but \s) wrong, this
> should be correct.
> The same applies to \W:
>
> +   this will match anything other than ``[0-9_]`` not classified as
> +   alphanumeric in the Unicode character properties database.
>
>
> For the additional sentence, I?d prefer:
>
> +   In case both ``re.LOCALE`` and ``re.UNICODE`` are specified alongside,
> +   these character classes will behave as if the union was given.
>
> for that?s the logic behind.
>
> Hauke
>
> --- Senthil Kumaran *<senthil at uthcode.com>* schrieb am *Fr, 9.3.2012:
> *
>
> *
> Von: Senthil Kumaran <senthil at uthcode.com>
> Betreff: Re: [docs] copy&waste problem
> An: "Hauke Rehr" <homo_laber at yahoo.de>
> CC: docs at python.org
> Datum: Freitag, 9. M?rz, 2012 09:18 Uhr
>
> *
> *Hello Hauke,
>
> Yeah, it was pretty confusing. Thanks for catching this. How does this
> change sound?
>
> -   When the :const:`LOCALE` and :const:`UNICODE` flags are not
> specified, matches
> -   any non-whitespace character; this is equivalent to the set ``[^
> \t\n\r\f\v]``
> -   With :const:`LOCALE`, it will match any character not in this set, and
> not
> -   defined as space in the current locale. If :const:`UNICODE` is
> set, this will
> -   match anything other than ``[ \t\n\r\f\v]`` and characters marked
> as space in
> -   the Unicode character properties database.
> +   When the :const:`LOCALE` and :const:`UNICODE` flags are not specified,
> +   matches any non-whitespace character; this is equivalent to the set
> ``[^
> +   \t\n\r\f\v]`` With :const:`LOCALE`, it will match the above set and any
> +   non-space character in the current locale. If :const:`UNICODE` is set,
> the
> +   above set ``[^ \t\n\r\f\v]`` and characters not marked as space in the
> +   Unicode character properties database.
>
> ``\w``
>     When the :const:`LOCALE` and :const:`UNICODE` flags are not
> specified, matches
> @@ -381,8 +381,8 @@
>     any non-alphanumeric character; this is equivalent to the set
> ``[^a-zA-Z0-9_]``.
>     With :const:`LOCALE`, it will match any character not in the set
> ``[0-9_]``, and
>     not defined as alphanumeric for the current locale. If
> :const:`UNICODE` is set,
> -   this will match anything other than ``[0-9_]`` and characters marked as
> -   alphanumeric in the Unicode character properties database.
> +   this will match anything other than ``[0-9_]`` plus characters
> classied as
> +   not alphanumeric in the Unicode character properties database.
>
>
> Hope the rewrite is less confusing.
>
> We can also include this sentence somewhere.
>
> Both re.LOCALE and re.UNICODE is specified together,in that case
> re.LOCALE would be matched first and the re.UNICODE.
>
>
> --
> Senthil
>
> *
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120311/1d4a519a/attachment.html>

From senthil at uthcode.com  Mon Mar 12 04:39:05 2012
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 11 Mar 2012 20:39:05 -0700
Subject: [docs] copy&waste problem
In-Reply-To: <CAPOVWOQs0O8Dx-iGfsUE4U7YQcws5OpqPtkuVjbp5FJffusiUQ@mail.gmail.com>
References: <CAPOVWOTBWAD3UNg8gcjUchqXZuXj2T=Q1ze31Pu3cajg7REyhw@mail.gmail.com>
	<1331302342.87978.YahooMailClassic@web171201.mail.ir2.yahoo.com>
	<CAPOVWOQs0O8Dx-iGfsUE4U7YQcws5OpqPtkuVjbp5FJffusiUQ@mail.gmail.com>
Message-ID: <20120312033905.GF1986@mathmagic>


The tracker issue I created for this discussion is here:
http://bugs.python.org/issue14258

I have made the changes too. Thanks for spotting the mistake.

-- 
Senthil

On Sun, Mar 11, 2012 at 08:09:11PM -0700, Senthil Kumaran wrote:
> Hello Hauke,
> 
> I guess, you are mistaken with the meaning of re.LOCALE flag for space. ?It is
> not intersection but Union of the locale's space characters with the ascii
> space characters.
> 
> For \S,?with `LOCALE flag set, it will match?[^ \t\n\r\f\v]?plus any
> non-whitespace characters defined by that locale.?
> 
> 
> 
> +?? In case both ``re.LOCALE`` and ``re.UNICODE`` are specified alongside,
> +?? these character classes will behave as if the union was given.
> 
> Where did you find this logic? I see that, locale flag is matched first and
> then unicode.
> 
> In Modules\_sre.c? ??
> 
> if (pattern->flags & SRE_FLAG_LOCALE)
> ? ? ? ? state->lower = sre_lower_locale;
> ? ? else if (pattern->flags & SRE_FLAG_UNICODE)
> 
> 
> I am going ahead with the changes as I suggested previously and also opening a
> bug report. Further discussions and changes can be tracked there. Yeah,
> sometimes doc changes go for discussions and iterations too. :(?
> 
> --?
> Senthil
> 
> 
> 
> On Fri, Mar 9, 2012 at 6:12 AM, Hauke Rehr <homo_laber at yahoo.de> wrote:
> 
>     Hello again,
> 
>     I can?t agree with your rewrite either, sorry - my suggestion based on
>     yours:
> 
> 
>     +???When the :const:`LOCALE` and :const:`UNICODE` flags are not specified,
>     +???matches any non-whitespace character; this is equivalent to the set
>     ``[^
>     +???\t\n\r\f\v]`` With :const:`LOCALE`, it will match those elements of the
>     above set
>     +?? not defined as space in the current locale. If :const:`UNICODE` is set,
>     those elements
>     +?? of ``[^ \t\n\r\f\v]`` not marked as space in the Unicode character
>     properties database
>     +?? will be matched.
> 
>     If I don?t get the meaning of \S (that is: anything but \s) wrong, this
>     should be correct.
>     The same applies to \W:
> 
>     +???this will match anything other than ``[0-9_]`` not classified as
>     +?? alphanumeric in the Unicode character properties database.
> 
> 
>     For the additional sentence, I?d prefer:
> 
>     +?? In case both ``re.LOCALE`` and ``re.UNICODE`` are specified alongside,
>     +?? these character classes will behave as if the union was given.
> 
>     for that?s the logic behind.
> 
>     Hauke
> 
>     --- Senthil Kumaran <senthil at uthcode.com> schrieb am Fr, 9.3.2012:
> 
> 
>         Von: Senthil Kumaran <senthil at uthcode.com>
>         Betreff: Re: [docs] copy&waste problem
>         An: "Hauke Rehr" <homo_laber at yahoo.de>
>         CC: docs at python.org
>         Datum: Freitag, 9. M?rz, 2012 09:18 Uhr
> 
>         Hello Hauke,
> 
>         Yeah, it was pretty confusing. Thanks for catching this. How does this
>         change sound?
> 
>         -???When the :const:`LOCALE` and :const:`UNICODE` flags are not
>         specified, matches
>         -???any non-whitespace character; this is equivalent to the set ``[^
>         \t\n\r\f\v]``
>         -???With :const:`LOCALE`, it will match any character not in this set,
>         and not
>         -???defined as space in the current locale. If :const:`UNICODE` is
>         set, this will
>         -???match anything other than ``[ \t\n\r\f\v]`` and characters marked
>         as space in
>         -???the Unicode character properties database.
>         +???When the :const:`LOCALE` and :const:`UNICODE` flags are not
>         specified,
>         +???matches any non-whitespace character; this is equivalent to the set
>         ``[^
>         +???\t\n\r\f\v]`` With :const:`LOCALE`, it will match the above set and
>         any
>         +???non-space character in the current locale. If :const:`UNICODE` is
>         set, the
>         +???above set ``[^ \t\n\r\f\v]`` and characters not marked as space in
>         the
>         +???Unicode character properties database.
> 
>         ``\w``
>         ? ? When the :const:`LOCALE` and :const:`UNICODE` flags are not
>         specified, matches
>         @@ -381,8 +381,8 @@
>         ? ? any non-alphanumeric character; this is equivalent to the set
>         ``[^a-zA-Z0-9_]``.
>         ? ? With :const:`LOCALE`, it will match any character not in the set
>         ``[0-9_]``, and
>         ? ? not defined as alphanumeric for the current locale. If
>         :const:`UNICODE` is set,
>         -???this will match anything other than ``[0-9_]`` and characters
>         marked as
>         -???alphanumeric in the Unicode character properties database.
>         +???this will match anything other than ``[0-9_]`` plus characters
>         classied as
>         +???not alphanumeric in the Unicode character properties database.
> 
> 
>         Hope the rewrite is less confusing.
> 
>         We can also include this sentence somewhere.
> 
>         Both re.LOCALE and re.UNICODE is specified together,in that case
>         re.LOCALE would be matched first and the re.UNICODE.
> 
> 
>         --
>         Senthil
> 
> 
> 
> 

From report at bugs.python.org  Mon Mar 12 05:06:15 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Mar 2012 04:06:15 +0000
Subject: [docs] [issue14257] minor error in glossary wording regarding
	__hash__
In-Reply-To: <1331515626.11.0.049158499672.issue14257@psf.upfronthosting.co.za>
Message-ID: <E1S6wWU-0007h1-Ce@dinsdale.python.org>


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

New changeset f0a5f39615c8 by Senthil Kumaran in branch '2.7':
closes issue14257 minor error in glossary wording regarding __hash__
http://hg.python.org/cpython/rev/f0a5f39615c8

New changeset 3f15c069454d by Senthil Kumaran in branch '3.2':
closes issue14257 - 3.2 minor error in glossary wording regarding __hash__
http://hg.python.org/cpython/rev/3f15c069454d

New changeset 2b7c39db2150 by Senthil Kumaran in branch 'default':
closes issue14257 - cpython - minor error in glossary wording regarding __hash__
http://hg.python.org/cpython/rev/2b7c39db2150

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

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

From report at bugs.python.org  Mon Mar 12 10:16:31 2012
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 12 Mar 2012 09:16:31 +0000
Subject: [docs] [issue14257] minor error in glossary wording regarding
	__hash__
In-Reply-To: <1331515626.11.0.049158499672.issue14257@psf.upfronthosting.co.za>
Message-ID: <1331543790.78.0.0177793307274.issue14257@psf.upfronthosting.co.za>


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

I regret to inform you that those changes made the sentence in question ungrammatical. Removing the word "method" will make it grammatical again (as originally suggested).

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

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

From report at bugs.python.org  Tue Mar 13 03:17:02 2012
From: report at bugs.python.org (py.user)
Date: Tue, 13 Mar 2012 02:17:02 +0000
Subject: [docs] [issue14250] for string patterns regex.flags is never equal
	to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331605022.03.0.45101634433.issue14250@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

>>> import re
>>> p = re.compile(br'')
>>> p.flags
0
>>>

----------
title: regex.flags is never equal to 0 -> for string patterns regex.flags is never equal to 0

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

From report at bugs.python.org  Tue Mar 13 03:20:37 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Mar 2012 02:20:37 +0000
Subject: [docs] [issue14250] for string patterns regex.flags is never equal
	to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331605237.09.0.843095687115.issue14250@psf.upfronthosting.co.za>


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

Heh.  Good point.

Documenting this is a clear way may be non-trivial.

----------

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

From report at bugs.python.org  Tue Mar 13 03:55:45 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 13 Mar 2012 02:55:45 +0000
Subject: [docs] [issue14250] for string patterns regex.flags is never equal
	to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331607345.06.0.505319754778.issue14250@psf.upfronthosting.co.za>


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

Issue #13358 may be related

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

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

From report at bugs.python.org  Tue Mar 13 04:03:21 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Mar 2012 03:03:21 +0000
Subject: [docs] [issue14250] for string patterns regex.flags is never equal
	to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331607801.3.0.880147405573.issue14250@psf.upfronthosting.co.za>


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

It doesn't look like it.  Is that the right issue number?

----------

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

From report at bugs.python.org  Tue Mar 13 04:18:41 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 13 Mar 2012 03:18:41 +0000
Subject: [docs] [issue14250] for string patterns regex.flags is never equal
	to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331608721.65.0.94981583055.issue14250@psf.upfronthosting.co.za>


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

Oh, sorry I meant http://bugs.python.org/issue13385

----------

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

From report at bugs.python.org  Tue Mar 13 06:06:49 2012
From: report at bugs.python.org (py.user)
Date: Tue, 13 Mar 2012 05:06:49 +0000
Subject: [docs] [issue14283] match.pos describes that match object has
	methods	search() and match()
Message-ID: <1331615209.27.0.948367520003.issue14283@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

http://docs.python.org/py3k/library/re.html#re.match.pos
http://docs.python.org/py3k/library/re.html#re.match.endpos
"which was passed to the search() or match() method of a match object."

http://docs.python.org/py3k/library/re.html#re.match.re

match object -> regular expression object

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 155571
nosy: docs at python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: match.pos describes that match object has methods search() and match()
versions: Python 3.2

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

From report at bugs.python.org  Tue Mar 13 08:17:23 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Mar 2012 07:17:23 +0000
Subject: [docs] [issue14257] minor error in glossary wording regarding
	__hash__
In-Reply-To: <1331515626.11.0.049158499672.issue14257@psf.upfronthosting.co.za>
Message-ID: <E1S7Lz0-0001zd-3c@dinsdale.python.org>


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

New changeset 0f146020d8e9 by Senthil Kumaran in branch '3.2':
closes issue14257 - Grammatical fix
http://hg.python.org/cpython/rev/0f146020d8e9

New changeset c5833f277258 by Senthil Kumaran in branch 'default':
closes issue14257 - Grammatical fix
http://hg.python.org/cpython/rev/c5833f277258

New changeset f3c8bdbe2cf3 by Senthil Kumaran in branch '2.7':
closes issue14257 - Grammatical fix
http://hg.python.org/cpython/rev/f3c8bdbe2cf3

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

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

From report at bugs.python.org  Tue Mar 13 13:23:19 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 13 Mar 2012 12:23:19 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331641399.66.0.123588273996.issue14202@psf.upfronthosting.co.za>


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

I reviewed the patch in http://bugs.python.org/review/14202/show

----------

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

From report at bugs.python.org  Tue Mar 13 15:03:33 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Mar 2012 14:03:33 +0000
Subject: [docs] [issue14217] text output pretends to be code
In-Reply-To: <1331108351.7.0.269278733631.issue14217@psf.upfronthosting.co.za>
Message-ID: <1331647413.38.0.421405891634.issue14217@psf.upfronthosting.co.za>


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

This issue does not apply to 2.7 docs because they lack the local/nonlocal assignment example; do you agree it would be good to backport that?

Tshepang, if you find more instances of the same problem, please report them.  Thanks!

----------

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

From senthil at uthcode.com  Tue Mar 13 17:16:53 2012
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 13 Mar 2012 09:16:53 -0700
Subject: [docs] copy&waste problem
In-Reply-To: <1331641057.87298.YahooMailClassic@web171202.mail.ir2.yahoo.com>
References: <CAPOVWOQs0O8Dx-iGfsUE4U7YQcws5OpqPtkuVjbp5FJffusiUQ@mail.gmail.com>
	<1331641057.87298.YahooMailClassic@web171202.mail.ir2.yahoo.com>
Message-ID: <20120313161653.GB2880@mathmagic>

I understand  your points. My reasoning was based on - 

man 5 locale which stated the following for locale.

space  followed by a list of characters defined as white-space
characters.  Characters also  specified  as  upper,  lower,
alpha,  digit, graph, or xdigit are not allowed.  The
characters <space>, <form-feed>, <newline>, <carriage-return>,
<tab>, and <vertical-tab> are automatically included.

If the intersection logic were to be followed then, it would
completely remove those "<space>, <form-feed>, <newline>,
<carriage-return>, <tab>, and <vertical-tab>" from the match as they
are included as space characters in the locale definition too.
Isn't it?

Here is bug report - 

http://bugs.python.org/issue14258

Thanks,
Senthil


On Tue, Mar 13, 2012 at 12:17:37PM +0000, Hauke Rehr wrote:
> Hello again,
> 
> I?d rather use the ticket you started, but I couldn?t find where to post an
> answer/where the discussion is tracked.
> 
> So once again, to clarify what I had in mind:
> 
> As for the positive (lowercase) classes: Yes, that?s union (first one is
> matched, if there?s no success, the other one is tried). For the negative
> (uppercase) classes it?s deMorgan:
> complement(union(A, B)) = intersection(complement(A), complement(B))
> So we have
> \<uppercase> = complement(\<lowercase>)
> = complement(union(\<lowercase_locale>, \<lowercase_unicode>))
> = intersection(complement(\<lowercase_locale>), complement(\
> <lowercase_unicode>))
> = intersection(\<uppercase_locale>, \<uppercase_unicode>).
> 
> At least, that?s how it should be and what the code means you quoted
> (it doesn?t matter which one you try first: union is symmetric)
> for a match of an uppercase class means nothing but
> a char that doesn?t match the corresponding lowercase class
> 
> So I still believe my corrections to be - well, correct; and your suggestion to
> be erroneous.
> 
> Hauke
> 
> 
> --- Senthil Kumaran <senthil at uthcode.com> schrieb am Mo, 12.3.2012:
> 
> 
>     Von: Senthil Kumaran <senthil at uthcode.com>
>     Betreff: Re: [docs] copy&waste problem
>     An: "Hauke Rehr" <homo_laber at yahoo.de>
>     CC: docs at python.org
>     Datum: Montag, 12. M?rz, 2012 04:09 Uhr
> 
>     Hello Hauke,
> 
>     I guess, you are mistaken with the meaning of re.LOCALE flag for space.  It
>     is not intersection but Union of the locale's space characters with the
>     ascii space characters.
> 
>     For \S, with `LOCALE flag set, it will match [^ \t\n\r\f\v] plus any
>     non-whitespace characters defined by that locale. 
> 
> 
> 
>     +   In case both ``re.LOCALE`` and ``re.UNICODE`` are specified alongside,
>     +   these character classes will behave as if the union was given.
> 
>     Where did you find this logic? I see that, locale flag is matched first and
>     then unicode.
> 
>     In Modules\_sre.c    
> 
>     if (pattern->flags & SRE_FLAG_LOCALE)
>             state->lower = sre_lower_locale;
>         else if (pattern->flags & SRE_FLAG_UNICODE)
> 
> 
>     I am going ahead with the changes as I suggested previously and also
>     opening a bug report. Further discussions and changes can be tracked there.
>     Yeah, sometimes doc changes go for discussions and iterations too. :( 
> 
>     -- 
>     Senthil
> 
> 
> 
>     On Fri, Mar 9, 2012 at 6:12 AM, Hauke Rehr <homo_laber at yahoo.de> wrote:
> 
>         Hello again,
> 
>         I can?t agree with your rewrite either, sorry - my suggestion based on
>         yours:
> 
> 
>         +   When the :const:`LOCALE` and :const:`UNICODE` flags are not
>         specified,
>         +   matches any non-whitespace character; this is equivalent to the set
>         ``[^
>         +   \t\n\r\f\v]`` With :const:`LOCALE`, it will match those elements of
>         the above set
>         +   not defined as space in the current locale. If :const:`UNICODE` is
>         set, those elements
>         +   of ``[^ \t\n\r\f\v]`` not marked as space in the Unicode character
>         properties database
>         +   will be matched.
> 
>         If I don?t get the meaning of \S (that is: anything but \s) wrong, this
>         should be correct.
>         The same applies to \W:
> 
>         +   this will match anything other than ``[0-9_]`` not classified as
>         +   alphanumeric in the Unicode character properties database.
> 
> 
>         For the additional sentence, I?d prefer:
> 
>         +   In case both ``re.LOCALE`` and ``re.UNICODE`` are specified
>         alongside,
>         +   these character classes will behave as if the union was given.
> 
>         for that?s the logic behind.
> 
>         Hauke
> 
> 
> 

From report at bugs.python.org  Tue Mar 13 20:39:38 2012
From: report at bugs.python.org (Nam Nguyen)
Date: Tue, 13 Mar 2012 19:39:38 +0000
Subject: [docs] [issue14289] Prebuilt CHM file on Docs download page
Message-ID: <1331667578.7.0.0463792055808.issue14289@psf.upfronthosting.co.za>


New submission from Nam Nguyen <bitsink at gmail.com>:

Before 2.7, one can easily find .CHM files in the Documentation download page. When 2.7 come out, the only way to get CHM files is downloading the Windows installers (EXE or MSI), installing it on Windows, and grabbing the CHM files. This is unwieldy.

I am on a Mac at work, have a desktop running Linux and Windows at home. In all cases, I usually rely on the CHM file. It is self-packaged, indexable, and easily searchable. There are CHM readers out there that work across different OSes such as the cross platform xCHM.

Therefore, I'd like to request for a prebuilt .CHM file for download, in addition to what there already are.

----------
assignee: docs at python
components: Documentation
messages: 155650
nosy: Nam.Nguyen, docs at python
priority: normal
severity: normal
status: open
title: Prebuilt CHM file on Docs download page

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

From report at bugs.python.org  Tue Mar 13 20:50:27 2012
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 13 Mar 2012 19:50:27 +0000
Subject: [docs] [issue14289] Prebuilt CHM file on Docs download page
In-Reply-To: <1331667578.7.0.0463792055808.issue14289@psf.upfronthosting.co.za>
Message-ID: <1331668227.04.0.125069506414.issue14289@psf.upfronthosting.co.za>


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

The CHMs are already on the Python download page, along with the .msi installers.

We can add a note to the docs download page that they are to be found there.

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

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

From senthil at uthcode.com  Wed Mar 14 01:39:16 2012
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 13 Mar 2012 17:39:16 -0700
Subject: [docs] copy&waste problem
In-Reply-To: <1331641057.87298.YahooMailClassic@web171202.mail.ir2.yahoo.com>
References: <CAPOVWOQs0O8Dx-iGfsUE4U7YQcws5OpqPtkuVjbp5FJffusiUQ@mail.gmail.com>
	<1331641057.87298.YahooMailClassic@web171202.mail.ir2.yahoo.com>
Message-ID: <20120314003916.GA2822@mathmagic>

Hello Hauke,

The deMorgan's completion logic does not seem to apply here. I tried
it by doing an exercise of of intersecting \S between two languages.
It is clear to see that output did not include space from the 2nd
language.

Here is the tracker # http://bugs.python.org/issue14258

Thanks,
Senthil

On Tue, Mar 13, 2012 at 12:17:37PM +0000, Hauke Rehr wrote:
> Hello again,
> 
> I?d rather use the ticket you started, but I couldn?t find where to post an
> answer/where the discussion is tracked.
> 
> So once again, to clarify what I had in mind:
> 
> As for the positive (lowercase) classes: Yes, that?s union (first one is
> matched, if there?s no success, the other one is tried). For the negative
> (uppercase) classes it?s deMorgan:
> complement(union(A, B)) = intersection(complement(A), complement(B))
> So we have
> \<uppercase> = complement(\<lowercase>)
> = complement(union(\<lowercase_locale>, \<lowercase_unicode>))
> = intersection(complement(\<lowercase_locale>), complement(\
> <lowercase_unicode>))
> = intersection(\<uppercase_locale>, \<uppercase_unicode>).
> 
> At least, that?s how it should be and what the code means you quoted
> (it doesn?t matter which one you try first: union is symmetric)
> for a match of an uppercase class means nothing but
> a char that doesn?t match the corresponding lowercase class
> 
> So I still believe my corrections to be - well, correct; and your suggestion to
> be erroneous.
> 
> Hauke
> 
> 
> --- Senthil Kumaran <senthil at uthcode.com> schrieb am Mo, 12.3.2012:
> 
> 
>     Von: Senthil Kumaran <senthil at uthcode.com>
>     Betreff: Re: [docs] copy&waste problem
>     An: "Hauke Rehr" <homo_laber at yahoo.de>
>     CC: docs at python.org
>     Datum: Montag, 12. M?rz, 2012 04:09 Uhr
> 
>     Hello Hauke,
> 
>     I guess, you are mistaken with the meaning of re.LOCALE flag for space.  It
>     is not intersection but Union of the locale's space characters with the
>     ascii space characters.
> 
>     For \S, with `LOCALE flag set, it will match [^ \t\n\r\f\v] plus any
>     non-whitespace characters defined by that locale. 
> 
> 
> 
>     +   In case both ``re.LOCALE`` and ``re.UNICODE`` are specified alongside,
>     +   these character classes will behave as if the union was given.
> 
>     Where did you find this logic? I see that, locale flag is matched first and
>     then unicode.
> 
>     In Modules\_sre.c    
> 
>     if (pattern->flags & SRE_FLAG_LOCALE)
>             state->lower = sre_lower_locale;
>         else if (pattern->flags & SRE_FLAG_UNICODE)
> 
> 
>     I am going ahead with the changes as I suggested previously and also
>     opening a bug report. Further discussions and changes can be tracked there.
>     Yeah, sometimes doc changes go for discussions and iterations too. :( 
> 
>     -- 
>     Senthil
> 
> 
> 
>     On Fri, Mar 9, 2012 at 6:12 AM, Hauke Rehr <homo_laber at yahoo.de> wrote:
> 
>         Hello again,
> 
>         I can?t agree with your rewrite either, sorry - my suggestion based on
>         yours:
> 
> 
>         +   When the :const:`LOCALE` and :const:`UNICODE` flags are not
>         specified,
>         +   matches any non-whitespace character; this is equivalent to the set
>         ``[^
>         +   \t\n\r\f\v]`` With :const:`LOCALE`, it will match those elements of
>         the above set
>         +   not defined as space in the current locale. If :const:`UNICODE` is
>         set, those elements
>         +   of ``[^ \t\n\r\f\v]`` not marked as space in the Unicode character
>         properties database
>         +   will be matched.
> 
>         If I don?t get the meaning of \S (that is: anything but \s) wrong, this
>         should be correct.
>         The same applies to \W:
> 
>         +   this will match anything other than ``[0-9_]`` not classified as
>         +   alphanumeric in the Unicode character properties database.
> 
> 
>         For the additional sentence, I?d prefer:
> 
>         +   In case both ``re.LOCALE`` and ``re.UNICODE`` are specified
>         alongside,
>         +   these character classes will behave as if the union was given.
> 
>         for that?s the logic behind.
> 
>         Hauke
> 
> 
> 

From report at bugs.python.org  Wed Mar 14 03:51:17 2012
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 14 Mar 2012 02:51:17 +0000
Subject: [docs] [issue14298] account for dict randomization in Design &
	History FAQ
Message-ID: <1331693477.45.0.106920867641.issue14298@psf.upfronthosting.co.za>


New submission from Chris Rebert <pybugs at rebertia.com>:

The randomization introduced by the fix for issue 13703 means that the example string hash values given in http://docs.python.org/dev/faq/design.html#how-are-dictionaries-implemented are liable to become more difficult to reproduce (in fact, the example already currently implicitly assumes a 32-bit build). Either the phrasing should be changed to emphasize that these are *possible* values the strings *might* hash to, or no concrete hash values should be given at all.

----------
assignee: docs at python
components: Documentation
messages: 155714
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: account for dict randomization in Design & History FAQ
versions: Python 3.4

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

From report at bugs.python.org  Wed Mar 14 07:50:23 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Mar 2012 06:50:23 +0000
Subject: [docs] [issue14298] account for dict randomization in Design &
	History FAQ
In-Reply-To: <1331693477.45.0.106920867641.issue14298@psf.upfronthosting.co.za>
Message-ID: <E1S7i2P-0000cn-Rc@dinsdale.python.org>


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

New changeset 305cf9be1cd3 by Georg Brandl in branch 'default':
Closes #14298: update section about dict implementation.
http://hg.python.org/cpython/rev/305cf9be1cd3

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

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

From report at bugs.python.org  Wed Mar 14 07:58:20 2012
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Mar 2012 06:58:20 +0000
Subject: [docs] [issue14250] for string patterns regex.flags is never equal
	to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331708300.5.0.151583761233.issue14250@psf.upfronthosting.co.za>


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

There is even more wrongness here: if you give flags inline in the pattern, they also show up in .flags (since they are global, at least in the current implementation).  Suggested patch attached.

----------
keywords: +patch
nosy: +georg.brandl
Added file: http://bugs.python.org/file24840/regexflags.patch

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

From jeffwilson456 at gmail.com  Mon Mar 12 20:34:53 2012
From: jeffwilson456 at gmail.com (Jeff Wilson)
Date: Mon, 12 Mar 2012 19:34:53 +0000
Subject: [docs] Generators
Message-ID: <CAC17bYNzqxtTwEj08dm+p3Fo1mgJG2UJoR=81A3prS5yAcjx9A@mail.gmail.com>

Good Day,

I am Jeff Wilson and i  will like to know if you do carry Generators in
stock . If you do get back to me with the unit prices of the types you
carry.


 I await your response.

Thank You
Jeff Wilson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120312/e666f716/attachment-0001.html>

From homo_laber at yahoo.de  Tue Mar 13 13:17:37 2012
From: homo_laber at yahoo.de (Hauke Rehr)
Date: Tue, 13 Mar 2012 12:17:37 +0000 (GMT)
Subject: [docs] copy&waste problem
In-Reply-To: <CAPOVWOQs0O8Dx-iGfsUE4U7YQcws5OpqPtkuVjbp5FJffusiUQ@mail.gmail.com>
Message-ID: <1331641057.87298.YahooMailClassic@web171202.mail.ir2.yahoo.com>

Hello again,

I?d rather use the ticket you started, but I couldn?t find where to post an answer/where the discussion is tracked.

So once again, to clarify what I had in mind:

As for the positive (lowercase) classes: Yes, that?s union (first one is matched, if there?s no success, the other one is tried). For the negative (uppercase) classes it?s deMorgan:
complement(union(A, B)) = intersection(complement(A), complement(B))
So we have
\<uppercase> = complement(\<lowercase>)
= complement(union(\<lowercase_locale>, \<lowercase_unicode>))
= intersection(complement(\<lowercase_locale>), complement(\<lowercase_unicode>))
= intersection(\<uppercase_locale>, \<uppercase_unicode>).

At least, that?s how it should be and what the code means you quoted
(it doesn?t matter which one you try first: union is symmetric)
for a match of an uppercase class means nothing but
a char that doesn?t match the corresponding lowercase class

So I still believe my corrections to be - well, correct; and your suggestion to be erroneous.

Hauke


--- Senthil Kumaran <senthil at uthcode.com> schrieb am Mo, 12.3.2012:

Von: Senthil Kumaran <senthil at uthcode.com>
Betreff: Re: [docs] copy&waste problem
An: "Hauke Rehr" <homo_laber at yahoo.de>
CC: docs at python.org
Datum: Montag, 12. M?rz, 2012 04:09 Uhr

Hello Hauke,
I guess, you are mistaken with the meaning of re.LOCALE flag for space. ?It is not intersection but Union of the locale's space characters with the ascii space characters.

For \S,?with `LOCALE flag set, it will match?[^ \t\n\r\f\v]?plus any non-whitespace characters defined by that locale.?



+?? In case both ``re.LOCALE`` and ``re.UNICODE`` are specified alongside,
+?? these character classes will behave as if the union was given.


Where did you find this logic? I see that, locale flag is matched first and then unicode.
In Modules\_sre.c? ??

if (pattern->flags & SRE_FLAG_LOCALE)? ? ? ? state->lower = sre_lower_locale;? ? else if (pattern->flags & SRE_FLAG_UNICODE)


I am going ahead with the changes as I suggested previously and also opening a bug report. Further discussions and changes can be tracked there. Yeah, sometimes doc changes go for discussions and iterations too. :(?

--?Senthil


On Fri, Mar 9, 2012 at 6:12 AM, Hauke Rehr <homo_laber at yahoo.de> wrote:


Hello again,

I can?t agree with your rewrite either, sorry - my suggestion based on yours:

 +???When the :const:`LOCALE` and :const:`UNICODE` flags are not specified,
+???matches any non-whitespace character; this is equivalent to the set ``[^

+???\t\n\r\f\v]`` With :const:`LOCALE`, it will match those elements of the above set
+?? not defined as space in the current locale. If :const:`UNICODE` is set, those elements
+?? of ``[^ \t\n\r\f\v]`` not marked as space in the Unicode character properties database

+?? will be matched.

If I don?t get the meaning of \S (that is: anything but \s) wrong, this should be correct.
The same applies to \W:

+???this will match anything other than ``[0-9_]`` not classified as

+??
 alphanumeric in the Unicode character properties database.


For the additional sentence, I?d prefer:

+?? In case both ``re.LOCALE`` and ``re.UNICODE`` are specified alongside,
+?? these character classes will behave as if the union was given.


for that?s the logic behind.

Hauke

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

From bitsink at gmail.com  Tue Mar 13 20:40:01 2012
From: bitsink at gmail.com (Nam Nguyen)
Date: Tue, 13 Mar 2012 12:40:01 -0700
Subject: [docs] Request for pre-built .CHM on Doc Download page
Message-ID: <CANG+ZTO9UafA2rbv_Gmm2zB6=qmYEVitcWND105mwqwHXSy-dw@mail.gmail.com>

Hi,

Before 2.7, one can easily find .CHM files in the Documentation
download page. When 2.7 come out, the only way to get CHM files is
downloading the Windows installers (EXE or MSI), installing it on
Windows, and grabbing the CHM files. This is unwieldy.

I am on a Mac at work, have a desktop running Linux and Windows at
home. In all cases, I usually rely on the CHM file. It is
self-packaged, indexable, and easily searchable. There are CHM readers
out there that work across different OSes such as the cross platform
xCHM.

Therefore, I'd like to request for a prebuilt .CHM file for download,
in addition to what there already are.

Thanks,
Nam
PS: Same content on http://bugs.python.org/issue14289

From report at bugs.python.org  Wed Mar 14 08:07:45 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Mar 2012 07:07:45 +0000
Subject: [docs] [issue14283] match.pos describes that match object has
	methods	search() and match()
In-Reply-To: <1331615209.27.0.948367520003.issue14283@psf.upfronthosting.co.za>
Message-ID: <E1S7iJE-0001tO-CD@dinsdale.python.org>


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

New changeset 544ed2cfb097 by Georg Brandl in branch '3.2':
Closes #14283: match() and search() are regex methods, not match methods.
http://hg.python.org/cpython/rev/544ed2cfb097

New changeset 3ffa1b88e9f6 by Georg Brandl in branch 'default':
#14283: merge with 3.2
http://hg.python.org/cpython/rev/3ffa1b88e9f6

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

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

From report at bugs.python.org  Wed Mar 14 08:19:21 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Mar 2012 07:19:21 +0000
Subject: [docs] [issue14289] Prebuilt CHM file on Docs download page
In-Reply-To: <1331667578.7.0.0463792055808.issue14289@psf.upfronthosting.co.za>
Message-ID: <E1S7iUR-0002vO-T3@dinsdale.python.org>


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

New changeset 2800530b00d3 by Georg Brandl in branch '3.2':
Closes #14289: put a link to the CHM download page on the docs download page.
http://hg.python.org/cpython/rev/2800530b00d3

New changeset b4d1e51d91f8 by Georg Brandl in branch 'default':
#14289: merge with 3.2
http://hg.python.org/cpython/rev/b4d1e51d91f8

New changeset 3e62379008c2 by Georg Brandl in branch '2.7':
Closes #14289: put a link to the CHM download page on the docs download page.
http://hg.python.org/cpython/rev/3e62379008c2

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

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

From senthil at uthcode.com  Wed Mar 14 08:33:12 2012
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 14 Mar 2012 00:33:12 -0700
Subject: [docs] Generators
In-Reply-To: <CAC17bYNzqxtTwEj08dm+p3Fo1mgJG2UJoR=81A3prS5yAcjx9A@mail.gmail.com>
References: <CAC17bYNzqxtTwEj08dm+p3Fo1mgJG2UJoR=81A3prS5yAcjx9A@mail.gmail.com>
Message-ID: <20120314073312.GB2703@mathmagic>

Hello Jeff,

Those are inbuilt in the language what we use! You can decorate your
generator too if you wish.

-- 
Senthil

On Mon, Mar 12, 2012 at 07:34:53PM +0000, Jeff Wilson wrote:
> Good Day,
> 
> I am Jeff Wilson and i  will like to know if you do carry Generators in stock .
> If you do get back to me with the unit prices of the types you carry.
>  
>  
>  I await your response.
> 
> Thank You
> Jeff Wilson

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


From report at bugs.python.org  Wed Mar 14 16:16:08 2012
From: report at bugs.python.org (Nam Nguyen)
Date: Wed, 14 Mar 2012 15:16:08 +0000
Subject: [docs] [issue14289] Prebuilt CHM file on Docs download page
In-Reply-To: <1331667578.7.0.0463792055808.issue14289@psf.upfronthosting.co.za>
Message-ID: <1331738168.34.0.0351206312296.issue14289@psf.upfronthosting.co.za>


Nam Nguyen <bitsink at gmail.com> added the comment:

I can't find any CHM for download.

For example, this is everything there is to Python 3.2.2:

http://www.python.org/ftp/python/3.2.2/

Yet there's no sight of CHM in it.

----------

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

From report at bugs.python.org  Wed Mar 14 17:58:18 2012
From: report at bugs.python.org (Shane Hansen)
Date: Wed, 14 Mar 2012 16:58:18 +0000
Subject: [docs] [issue14303] Incorrect documentation for socket.py on linux
Message-ID: <1331744298.15.0.025379356395.issue14303@psf.upfronthosting.co.za>


New submission from Shane Hansen <shanemhansen at gmail.com>:

The python docs state that for socket.makefile "The file object references a dup()ped version of the socket file descriptor, so the file object and socket object may be closed or garbage-collected independently."

In fact for socket.py dup() is never called, and no additional files are opened. Instead an object is returned which uses the original socket and does buffering.

For me, this is the desired behaviour, but just thought I'd mention the docs were off.

----------
assignee: docs at python
components: Documentation, IO
files: test.py
messages: 155768
nosy: Shane.Hansen, docs at python, georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: Incorrect documentation for socket.py on linux
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file24843/test.py

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

From report at bugs.python.org  Wed Mar 14 22:35:03 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 14 Mar 2012 21:35:03 +0000
Subject: [docs] [issue14305] fix typos
Message-ID: <1331760903.5.0.178759784454.issue14305@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Mar 14 22:41:19 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 14 Mar 2012 21:41:19 +0000
Subject: [docs] [issue14306] try/except block is both efficient and
	expensive?
Message-ID: <1331761279.09.0.327606618026.issue14306@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

In Doc/faq/design.rst, we got this text:

"A try/except block is extremely efficient. Actually catching an exception is expensive."

The 2 sentences appear contradictory.

----------
assignee: docs at python
components: Documentation
messages: 155798
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: try/except block is both efficient and expensive?

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

From report at bugs.python.org  Wed Mar 14 22:42:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Mar 2012 21:42:56 +0000
Subject: [docs] [issue14305] fix typos
Message-ID: <E1S7vyA-0001lr-L9@dinsdale.python.org>


New submission from Roundup Robot <devnull at psf.upfronthosting.co.za>:

New changeset 0092ab03fdd5 by Georg Brandl in branch '3.2':
Closes #14305: fix typo.
http://hg.python.org/cpython/rev/0092ab03fdd5

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

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

From report at bugs.python.org  Wed Mar 14 22:44:21 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Mar 2012 21:44:21 +0000
Subject: [docs] [issue14306] try/except block is both efficient and
	expensive?
In-Reply-To: <1331761279.09.0.327606618026.issue14306@psf.upfronthosting.co.za>
Message-ID: <1331761461.79.0.456177129312.issue14306@psf.upfronthosting.co.za>


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

What it's trying to say is that in case the operation in the "try" block succeeds there's almost no overhead, so it's very efficient.  On the other hand, raising and then catching the error is expensive.

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

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

From report at bugs.python.org  Wed Mar 14 22:45:13 2012
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Mar 2012 21:45:13 +0000
Subject: [docs] [issue14306] try/except block is both efficient and
	expensive?
In-Reply-To: <1331761279.09.0.327606618026.issue14306@psf.upfronthosting.co.za>
Message-ID: <1331761513.22.0.672582930389.issue14306@psf.upfronthosting.co.za>


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

It could be reworded, yes.

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

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

From report at bugs.python.org  Wed Mar 14 23:04:35 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 14 Mar 2012 22:04:35 +0000
Subject: [docs] [issue14217] text output pretends to be code
In-Reply-To: <1331108351.7.0.269278733631.issue14217@psf.upfronthosting.co.za>
Message-ID: <1331762675.23.0.65265673107.issue14217@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

?ric  - not really. nonlocal is from python3.x onwards only.

----------

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

From report at bugs.python.org  Wed Mar 14 23:10:48 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 14 Mar 2012 22:10:48 +0000
Subject: [docs] [issue14305] fix typos
In-Reply-To: <E1S7vyA-0001lr-L9@dinsdale.python.org>
Message-ID: <1331763048.35.0.690300189326.issue14305@psf.upfronthosting.co.za>


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


----------
hgrepos:  -116

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

From report at bugs.python.org  Thu Mar 15 01:14:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Mar 2012 00:14:47 +0000
Subject: [docs] [issue14217] text output pretends to be code
In-Reply-To: <1331108351.7.0.269278733631.issue14217@psf.upfronthosting.co.za>
Message-ID: <1331770487.52.0.687281809032.issue14217@psf.upfronthosting.co.za>


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

I thought nonlocal had been backported to 2.7 but you?re right, it was not.

----------
stage: patch review -> committed/rejected

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

From report at bugs.python.org  Thu Mar 15 02:11:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Mar 2012 01:11:56 +0000
Subject: [docs] [issue11261] urlopen breaks when data parameter is used.
In-Reply-To: <1298239651.85.0.222287222979.issue11261@psf.upfronthosting.co.za>
Message-ID: <E1S7zEQ-0005nK-GC@dinsdale.python.org>


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

New changeset fddbe9a59d26 by Senthil Kumaran in branch '3.2':
Fix the wrong urllib exampls which use str for POST data. Closes Issue11261
http://hg.python.org/cpython/rev/fddbe9a59d26

New changeset 0345dc184e9a by Senthil Kumaran in branch 'default':
cpython:Fix the wrong urllib exampls which use str for POST data. Closes Issue11261
http://hg.python.org/cpython/rev/0345dc184e9a

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

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

From report at bugs.python.org  Thu Mar 15 04:08:44 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Mar 2012 03:08:44 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <1331780923.37.0.309121485704.issue14163@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

What the status of 'hello demo'?

If there are no objections I can update the docs.

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

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

From report at bugs.python.org  Thu Mar 15 04:30:32 2012
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 15 Mar 2012 03:30:32 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <1331782232.76.0.938082790558.issue14163@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

The current tk_hello.py file works under Ubuntu 11.04 with the latest python build from the repository. It looks good to me.

----------

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

From report at bugs.python.org  Thu Mar 15 05:07:56 2012
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Mar 2012 04:07:56 +0000
Subject: [docs] [issue14312] Convert PEP 7 to reStructuredText for
	readability	purposes
Message-ID: <1331784476.68.0.20108574461.issue14312@psf.upfronthosting.co.za>


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


----------
assignee: docs at python
components: Documentation
files: pep-0007_v1.diff
keywords: patch
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Convert PEP 7 to reStructuredText for readability purposes
type: enhancement
Added file: http://bugs.python.org/file24856/pep-0007_v1.diff

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

From report at bugs.python.org  Thu Mar 15 05:41:37 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Mar 2012 04:41:37 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <E1S82VM-0008Ae-8P@dinsdale.python.org>


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

New changeset d8ba959a547b by Andrew Svetlov in branch 'default':
Closes issue #14163 - tkinter: problems with hello doc example
http://hg.python.org/cpython/rev/d8ba959a547b

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

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

From report at bugs.python.org  Thu Mar 15 05:43:23 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Mar 2012 04:43:23 +0000
Subject: [docs] [issue14163] tkinter: problems with hello doc example
In-Reply-To: <1330560048.21.0.5556738264.issue14163@psf.upfronthosting.co.za>
Message-ID: <1331786603.85.0.0814202991723.issue14163@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Pushed into master. Thanks.

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

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

From report at bugs.python.org  Thu Mar 15 06:47:01 2012
From: report at bugs.python.org (Dylan Sarber)
Date: Thu, 15 Mar 2012 05:47:01 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1331790421.08.0.528527006623.issue12758@psf.upfronthosting.co.za>


Dylan Sarber <dwsarber at gmail.com> added the comment:

I patched this one up quickly. One has been changed using belopolsky's recommendation, which already reads well.

----------
keywords: +patch
nosy: +dwsarber
Added file: http://bugs.python.org/file24858/time_doc_fix.patch

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

From report at bugs.python.org  Thu Mar 15 08:10:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Mar 2012 07:10:58 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <E1S84pt-0002tY-45@dinsdale.python.org>


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

New changeset 1559a82a3529 by R David Murray in branch '2.7':
#12758: removing confusing mention of UTC from time.time description
http://hg.python.org/cpython/rev/1559a82a3529

New changeset 5615d6b91b53 by R David Murray in branch '3.2':
#12758: removing confusing mention of UTC from time.time description
http://hg.python.org/cpython/rev/5615d6b91b53

New changeset f18767bb66ba by R David Murray in branch 'default':
Merge #12758: removing confusing mention of UTC from time.time description
http://hg.python.org/cpython/rev/f18767bb66ba

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

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

From report at bugs.python.org  Thu Mar 15 08:12:08 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Mar 2012 07:12:08 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1331795528.69.0.176281316554.issue12758@psf.upfronthosting.co.za>


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

Thanks, Dylan.

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

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

From report at bugs.python.org  Thu Mar 15 08:19:25 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 15 Mar 2012 07:19:25 +0000
Subject: [docs] [issue14312] Convert PEP 7 to reStructuredText for
	readability	purposes
Message-ID: <1331795964.87.0.67514867127.issue14312@psf.upfronthosting.co.za>


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

Yes, who not.  Applied in 5d6ae5e01df6.

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

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

From report at bugs.python.org  Thu Mar 15 08:20:30 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 15 Mar 2012 07:20:30 +0000
Subject: [docs] [issue14312] Convert PEP 7 to reStructuredText for
	readability	purposes
In-Reply-To: <1331795964.87.0.67514867127.issue14312@psf.upfronthosting.co.za>
Message-ID: <1331796030.18.0.654773119686.issue14312@psf.upfronthosting.co.za>


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

Yes, why not. Applied in c1fd4a5af1c5.

----------

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

From report at bugs.python.org  Thu Mar 15 08:20:35 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 15 Mar 2012 07:20:35 +0000
Subject: [docs] [issue14312] Convert PEP 7 to reStructuredText for
	readability	purposes
In-Reply-To: <1331796030.18.0.654773119686.issue14312@psf.upfronthosting.co.za>
Message-ID: <1331796035.57.0.519175265022.issue14312@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

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

From report at bugs.python.org  Thu Mar 15 16:38:21 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 15 Mar 2012 15:38:21 +0000
Subject: [docs] [issue14318]
	clarify	http://docs.python.org/dev/library/time.html#time.steady
Message-ID: <1331825901.66.0.135412437524.issue14318@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
status: open
title: clarify http://docs.python.org/dev/library/time.html#time.steady
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar 15 17:41:08 2012
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 15 Mar 2012 16:41:08 +0000
Subject: [docs] [issue14318] clarify "may not" in time.steady docs
Message-ID: <1331829668.71.0.947018206764.issue14318@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

http://docs.python.org/dev/library/time.html#time.steady

Current:
"""Return the current time as a floating point number expressed in seconds. This clock advances at a steady rate relative to real time and it may not be adjusted. The reference point of the returned value is undefined so only the difference of consecutive calls is valid.

If available, a monotonic clock is used. By default, if strict is False, the function falls back to another clock if the monotonic clock failed or is not available. If strict is True, raise an OSError on error or NotImplementedError if no monotonic clock is available."""

Does "may not" mean that the user isn't allowed to adjust it, or that they system won't always have adjusted it?  Assuming that this really means it won't jump around for daylight savings time or manual time resets, it could be reworded as:



"""Return elapsed seconds as a floating point number.  The start time is undefined, so only differences between calls are meaningful.  steady() is the best clock for profiling response time, as opposed to CPU usage.

This function prefers to rely upon a high-precision counter that is not affected by resetting the system time.  If no such monotonic clock is available, steady() will substitute another clock, but steady(strict=true) will raise either NotImplementedError or OSError.  """

----------
title: clarify http://docs.python.org/dev/library/time.html#time.steady -> clarify "may not" in time.steady docs

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

From report at bugs.python.org  Thu Mar 15 23:16:42 2012
From: report at bugs.python.org (Florian Mladitsch)
Date: Thu, 15 Mar 2012 22:16:42 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331849802.53.0.00400151378899.issue14202@psf.upfronthosting.co.za>


Changes by Florian Mladitsch <florian.mladitsch at googlemail.com>:


Added file: http://bugs.python.org/file24879/xml.dom.pulldom.rst

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

From report at bugs.python.org  Thu Mar 15 23:50:27 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Mar 2012 22:50:27 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331851827.42.0.3965247984.issue14202@psf.upfronthosting.co.za>


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

Could you provide a diff?  (instructions in the devguide)

----------

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

From report at bugs.python.org  Thu Mar 15 23:58:48 2012
From: report at bugs.python.org (Florian Mladitsch)
Date: Thu, 15 Mar 2012 22:58:48 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331852328.27.0.120746431016.issue14202@psf.upfronthosting.co.za>


Florian Mladitsch <florian.mladitsch at googlemail.com> added the comment:

It is a diff-file, or am I missing something? I generated the file with 'hg diff > xml.dom.pulldom.rst'
Probably should have given it a '*.patch' file-ending =/

----------

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

From report at bugs.python.org  Fri Mar 16 03:30:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 16 Mar 2012 02:30:24 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331865024.54.0.10755784619.issue14202@psf.upfronthosting.co.za>


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

Ah, right, I just assumed that your .rst file was the full file (like in your first upload), but it is indeed a diff.  Our tools don?t care about the file extension, but they sometimes are useful conventions for humans :)

----------

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

From report at bugs.python.org  Fri Mar 16 04:41:38 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 16 Mar 2012 03:41:38 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331869298.8.0.296244978304.issue14202@psf.upfronthosting.co.za>


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

Looks good, pending fixing of ?ric's comments. Florian, could you do that? We can then proceed to commit (to 3.3) and consider backports.

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

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

From report at bugs.python.org  Fri Mar 16 07:28:01 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 16 Mar 2012 06:28:01 +0000
Subject: [docs] [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>
Message-ID: <1331879281.68.0.679823030443.issue14009@psf.upfronthosting.co.za>


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

?ric, what stops us from closing this issue?

Given Ezio and Fred's feedback, I don't object to indexing cET in 3.3 - I guess it can't hurt.

----------

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

From report at bugs.python.org  Fri Mar 16 08:19:29 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Mar 2012 07:19:29 +0000
Subject: [docs] [issue13709] Capitalization mistakes in the documentation
	for ctypes
In-Reply-To: <1325645203.91.0.562347938508.issue13709@psf.upfronthosting.co.za>
Message-ID: <E1S8RRf-00072K-J6@dinsdale.python.org>


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

New changeset d2460ff173ff by Eli Bendersky in branch 'default':
Issue #13709: some fixes to the ctypes documentation. In addition to fixing
http://hg.python.org/cpython/rev/d2460ff173ff

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

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

From report at bugs.python.org  Fri Mar 16 08:20:04 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 16 Mar 2012 07:20:04 +0000
Subject: [docs] [issue13709] Capitalization mistakes in the documentation
	for ctypes
In-Reply-To: <1325645203.91.0.562347938508.issue13709@psf.upfronthosting.co.za>
Message-ID: <1331882404.15.0.934839211337.issue13709@psf.upfronthosting.co.za>


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

Fixed in 3.3

I don't think this is important enough to spend time on backporting.

----------
resolution:  -> fixed
stage: needs patch -> commit review
status: open -> closed
versions: +Python 3.3

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

From report at bugs.python.org  Fri Mar 16 11:02:23 2012
From: report at bugs.python.org (Florian Mladitsch)
Date: Fri, 16 Mar 2012 10:02:23 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331892143.43.0.888420669469.issue14202@psf.upfronthosting.co.za>


Changes by Florian Mladitsch <florian.mladitsch at googlemail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file24885/xml.dom.pulldom.rst.patch

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

From report at bugs.python.org  Fri Mar 16 13:42:03 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Mar 2012 12:42:03 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <E1S8WTp-0000UT-Lc@dinsdale.python.org>


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

New changeset 172630a3e6d8 by Eli Bendersky in branch '3.2':
Issue #14202: Greatly enhance the documentation of xml.dom.pulldom.
http://hg.python.org/cpython/rev/172630a3e6d8

New changeset 5d118a154ba3 by Eli Bendersky in branch 'default':
Issue #14202: Greatly enhance the documentation of xml.dom.pulldom.
http://hg.python.org/cpython/rev/5d118a154ba3

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

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

From report at bugs.python.org  Fri Mar 16 13:44:38 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 16 Mar 2012 12:44:38 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331901878.25.0.277152059525.issue14202@psf.upfronthosting.co.za>


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

I committed the patch after some minor modifications, to 3.2 and 3.3

Florian, thanks for the contribution!

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

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

From report at bugs.python.org  Fri Mar 16 13:57:18 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 16 Mar 2012 12:57:18 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1331902638.02.0.267716492542.issue11379@psf.upfronthosting.co.za>


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

?ric, what else would you like to do here?

----------

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

From report at bugs.python.org  Fri Mar 16 14:49:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 16 Mar 2012 13:49:07 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1331905747.72.0.93080867506.issue11379@psf.upfronthosting.co.za>


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

I?ll soon have a revised version of my patch to address your feedback.

----------

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

From report at bugs.python.org  Fri Mar 16 15:05:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 16 Mar 2012 14:05:18 +0000
Subject: [docs] [issue14009] Clearer documentation for cElementTree
In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za>
Message-ID: <1331906718.66.0.783576761558.issue14009@psf.upfronthosting.co.za>


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

I will commit the patch, keeping the indexing in 3.3 as agreed.  I just moved to a new city, so today is paperwork day but in the evening or tomorrow I?ll do Python work :)

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

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

From report at bugs.python.org  Fri Mar 16 15:31:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 16 Mar 2012 14:31:46 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331908306.56.0.580669043727.issue14202@psf.upfronthosting.co.za>


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

Thanks to you both, the new docs are greatly better!

Eli, why not backporting to 2.7 too?  It has the same rules and should get the same attention as 3.2.

BTW, when you nest class/method directives, you needn?t repeat the class name in the method directives:

  .. class:: DOVEventStream(stream, etc)

     .. method:: getEvent(blah)

A few nits you may want to avoid in future patches:
- The constants in the methods doc don?t use data markup
- s/ie./i.e./
- I?d say ?Unicode string?, not ?unicode string? (referring to the concept/standard, not the old class)

----------

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

From report at bugs.python.org  Fri Mar 16 15:40:39 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 16 Mar 2012 14:40:39 +0000
Subject: [docs] [issue14318] clarify "may not" in time.steady docs
In-Reply-To: <1331829668.71.0.947018206764.issue14318@psf.upfronthosting.co.za>
Message-ID: <1331908839.89.0.544100383012.issue14318@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 16 15:52:49 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Mar 2012 14:52:49 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <E1S8YWN-0004m4-L3@dinsdale.python.org>


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

New changeset 1a740ea4f2a1 by Eli Bendersky in branch '3.2':
Issue #14202: some additional doc fixes
http://hg.python.org/cpython/rev/1a740ea4f2a1

New changeset b2e27f21760e by Eli Bendersky in branch 'default':
Issue #14202: some additional doc fixes
http://hg.python.org/cpython/rev/b2e27f21760e

----------

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

From report at bugs.python.org  Fri Mar 16 15:57:34 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 16 Mar 2012 14:57:34 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331909854.86.0.476305017813.issue14202@psf.upfronthosting.co.za>


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

?ric, thanks for the comments - all fixed.

As for 2.7, it's just laziness really. Committing to both 3.2 and 3.3 is trivial since it's a simple merge. For 2.7 it's more complicated since it's an unrelated branch, and the code samples have to be fixed as well (the current ones use Python 3.x syntax).

So I wouldn't object for someone to backport it to 2.7, but I don't deem it very important. If it was a bug fix, I would bother, but for documentation... not really :-)

----------

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

From report at bugs.python.org  Fri Mar 16 16:35:29 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 16 Mar 2012 15:35:29 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1331912129.4.0.082455495118.issue14202@psf.upfronthosting.co.za>


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

I understand :)  I?ll do it.  I value doc as much as code, it?s also delivered faster to the users, and there are a lot of Python 2 users out there, so porting doc fixes to 2.7 is really worth it.

----------
assignee: docs at python -> eric.araujo
status: closed -> open
versions: +Python 2.7

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

From report at bugs.python.org  Fri Mar 16 19:01:25 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Mar 2012 18:01:25 +0000
Subject: [docs] [issue14332] Better explain "junk" concept in difflib doc
In-Reply-To: <1331877125.66.0.103153393744.issue14332@psf.upfronthosting.co.za>
Message-ID: <1331920885.34.0.290502995381.issue14332@psf.upfronthosting.co.za>


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

I reproduced the observed behavior in 3.3.0a.
However, I am rather sure it is not a bug.
In any case, linejunk is not ignored. Passing 'lambda x: 1/0' causes ZeroDivisionError, proving that it gets called.

The body of ndiff(linejunk,charjunk,a,b) is
    return Differ(linejunk, charjunk).compare(a, b)
Differ only uses the linejunk parameter here
        cruncher = SequenceMatcher(self.linejunk, a, b)

SequenceMatcher uses the first parameter, isjunk, in the internal .__chain_b method to segregate (not remove) items expected to be common in order to speed up the .find_longest_match method. Read the docstring for that method (and possibly the code) to see how it affects matching. The main intent of the *junk parameters is to speed up matching to find differences, not to mask differences. It does, however, affect output of the .*ratio methods.

The doc string for ndiff says "The default is None, and is recommended; as of Python 2.3, an adaptive notion of "noise" lines is used that does a good job on its own." That is a good idea.

That said, I think the doc (and docstrings) should explain the notion of "junk" elements and what 'ignoring' them means. In particular, I think a couple of sentences should be added after "The idea is to find the longest contiguous matching subsequence that contains no ?junk? elements (the Ratcliff and Obershelp algorithm doesn?t address junk)." The quotes around "junk" indicate that it is being used with a non-standard, module specific meaning. What is it? And what does 'ignore' (used several times later in the doc) mean?

Tim, I think we may need your help here since 'junk' is your label for your concept and I am not sure I understand well enough to articulate it. (For one thing, given that the "common" heuristic was apparently meant to replace at least the linejunk version version of junk, I do not understand why .get_longest_match treats 'junk' and 'common' items differently, other than that the two concepts are apparently not the same.)

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, eli.bendersky
stage:  -> needs patch
title: difflib.ndiff appears to ignore linejunk argument -> Better explain "junk" concept in difflib doc
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Mar 16 19:15:01 2012
From: report at bugs.python.org (Weronika Patena)
Date: Fri, 16 Mar 2012 18:15:01 +0000
Subject: [docs] [issue14332] Better explain "junk" concept in difflib doc
In-Reply-To: <1331877125.66.0.103153393744.issue14332@psf.upfronthosting.co.za>
Message-ID: <1331921701.06.0.454694922219.issue14332@psf.upfronthosting.co.za>


Weronika Patena <patena at gmail.com> added the comment:

Ah, I see. True, the ndiff docstring doesn't actually explain what junk IS - I was just engaging in wishful thinking and assuming it did the thing I wanted.  A better explanation would help.

----------

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

From report at bugs.python.org  Fri Mar 16 19:57:38 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Mar 2012 18:57:38 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za>
Message-ID: <1331924258.05.0.952408711229.issue14245@psf.upfronthosting.co.za>


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

The last version in the message above looks good to me. Ready to markup and apply?

----------
keywords: +patch
nosy: +terry.reedy
stage:  -> patch review

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

From report at bugs.python.org  Fri Mar 16 20:03:57 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Mar 2012 19:03:57 +0000
Subject: [docs] [issue14250] for string patterns regex.flags is never equal
	to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331924637.36.0.948127825959.issue14250@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 16 21:08:33 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Mar 2012 20:08:33 +0000
Subject: [docs] [issue14306] try/except block is both efficient and
	expensive?
In-Reply-To: <1331761279.09.0.327606618026.issue14306@psf.upfronthosting.co.za>
Message-ID: <1331928513.38.0.276806379325.issue14306@psf.upfronthosting.co.za>


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

I think it would be sufficient to add ' if no exceptions are raised' to the first sentence. The example that follows in the entry clarifies the implications of "cheap to try, expensive to catch".

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

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

From report at bugs.python.org  Fri Mar 16 21:25:01 2012
From: report at bugs.python.org (beeNuts)
Date: Fri, 16 Mar 2012 20:25:01 +0000
Subject: [docs] [issue14338] urllib2 HowTo for overriding post/3xx behavior.
Message-ID: <1331929501.86.0.889924099512.issue14338@psf.upfronthosting.co.za>


New submission from beeNuts <jeff.adams at linux.com>:

Issue #14144, with the title "urllib2 HTTPRedirectHandler not forwarding POST data in redirect" was recently closed with these comments: 

"This could be cookbook recipe style example, if it's utility
value is high. I am closing this issue as I feel that the requirement may not be addressed by a change. If there is patch for HowTo, we can tackle that in another issue. Thank you for contribution."

The decision that documents on this issue were preferable to a patch seems like a fair compromise, especially considering that the RFC is decidedly ambiguous.I was wondering if the HowTo would be forthcoming? 
It seems to me that the value/utility would certainly be high. I'd submit it myself but I'm so new to Python that I don't trust my ability to do it correctly. It's something I would find highly useful, though.

----------
assignee: docs at python
components: Documentation
messages: 156080
nosy: beerNuts, docs at python
priority: normal
severity: normal
status: open
title: urllib2 HowTo for overriding post/3xx behavior.
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar 16 21:25:18 2012
From: report at bugs.python.org (beeNuts)
Date: Fri, 16 Mar 2012 20:25:18 +0000
Subject: [docs] [issue14338] urllib2 HowTo for overriding post/3xx behavior.
In-Reply-To: <1331929501.86.0.889924099512.issue14338@psf.upfronthosting.co.za>
Message-ID: <1331929518.02.0.0861889501432.issue14338@psf.upfronthosting.co.za>


Changes by beeNuts <jeff.adams at linux.com>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Fri Mar 16 21:37:24 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Mar 2012 20:37:24 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <1331372112.92.0.532785259032.issue14245@psf.upfronthosting.co.za>
Message-ID: <1331930244.2.0.236102179825.issue14245@psf.upfronthosting.co.za>


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

Fine by me.

Language nitpick:  "approximation to" sounds a bit better to my ears than "approximation of"

----------

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

From report at bugs.python.org  Sat Mar 17 00:33:27 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 16 Mar 2012 23:33:27 +0000
Subject: [docs] [issue14338] Document how to forward POST data on redirects
In-Reply-To: <1331929501.86.0.889924099512.issue14338@psf.upfronthosting.co.za>
Message-ID: <1331940807.3.0.227791892393.issue14338@psf.upfronthosting.co.za>


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

The idea is to add a short example in Doc/howto/urllib2.rst.  Senthil explained how to do things on #14144 (?obtain the redirected URL and then POST to [it]?), and the example should be introduced by a clear warning about security/misbehavior risks (this is why I?m not adding the ?easy? keyword to this report).

If you would like to propose a patch, you can find instructions on how to get and edit the source for the docs in the devguide.  You can also write to the beginner-friendly core-mentorship mailing list (link in the devguide or on mail.python.org) to request help or guidance.

----------
nosy: +crustymonkey, eric.araujo, orsenthil
stage:  -> needs patch
title: urllib2 HowTo for overriding post/3xx behavior. -> Document how to forward POST data on redirects
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Mar 17 01:48:28 2012
From: report at bugs.python.org (py.user)
Date: Sat, 17 Mar 2012 00:48:28 +0000
Subject: [docs] [issue14342] In re's examples the example with recursion
	doesn't work
Message-ID: <1331945308.4.0.250244486328.issue14342@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

http://docs.python.org/py3k/library/re.html#avoiding-recursion

>>> import sys
>>> sys.getrecursionlimit()
1000
>>> import re
>>> s = 'Begin ' + 1000*'a very long string ' + 'end'
>>> re.match('Begin (\w| )*? end', s).end()
19009
>>>

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 156112
nosy: docs at python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: In re's examples the example with recursion doesn't work
versions: Python 3.2

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

From report at bugs.python.org  Sat Mar 17 01:50:34 2012
From: report at bugs.python.org (py.user)
Date: Sat, 17 Mar 2012 00:50:34 +0000
Subject: [docs] [issue14343] In re's examples the example with re.split()
	overlaps	builtin input()
Message-ID: <1331945434.37.0.313316190883.issue14343@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

http://docs.python.org/py3k/library/re.html#making-a-phonebook

input -> text

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 156114
nosy: docs at python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: In re's examples the example with re.split() overlaps builtin input()
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Sat Mar 17 03:41:20 2012
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 17 Mar 2012 02:41:20 +0000
Subject: [docs] [issue14342] In re's examples the example with recursion
	doesn't work
In-Reply-To: <1331945308.4.0.250244486328.issue14342@psf.upfronthosting.co.za>
Message-ID: <1331952079.98.0.715898103596.issue14342@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

As far as I can tell, back in 2003, changes were made to replace the recursive scheme which used stack allocation with a non-recursive scheme which used heap allocation in order to the improve the behaviour.

To me it looks like an oversight and that the example should have been removed at the time, but unfortunately was retained and just updated in subsequent releases to refer to the Python version ("python3.2" in this case).

----------

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

From report at bugs.python.org  Sat Mar 17 03:44:52 2012
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 17 Mar 2012 02:44:52 +0000
Subject: [docs] [issue14343] In re's examples the example with re.split()
	shadows	builtin input()
In-Reply-To: <1331945434.37.0.313316190883.issue14343@psf.upfronthosting.co.za>
Message-ID: <1331952292.73.0.0885714499664.issue14343@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


----------
title: In re's examples the example with re.split() overlaps builtin input() -> In re's examples the example with re.split() shadows builtin input()

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

From report at bugs.python.org  Sat Mar 17 05:39:18 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 17 Mar 2012 04:39:18 +0000
Subject: [docs] [issue14250] for string patterns regex.flags is never equal
	to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <1331959158.87.0.555280505839.issue14250@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/issue14250>
_______________________________________

From report at bugs.python.org  Sat Mar 17 06:43:02 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 17 Mar 2012 05:43:02 +0000
Subject: [docs] [issue14345] Document socket.SOL_SOCKET
Message-ID: <1331962982.1.0.381278454339.issue14345@psf.upfronthosting.co.za>


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

socket.get/setsockopt() docs can be improved by providing description for SOL_SOCKET constant, and link to source code for other level constants and socket level options.

----------
assignee: docs at python
components: Documentation
messages: 156140
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Document socket.SOL_SOCKET

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

From report at bugs.python.org  Sat Mar 17 15:26:23 2012
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 17 Mar 2012 14:26:23 +0000
Subject: [docs] [issue14245] float rounding examples in FAQ are outdated
In-Reply-To: <1331930244.2.0.236102179825.issue14245@psf.upfronthosting.co.za>
Message-ID: <4F649F08.6090603@in.waw.pl>


Zbyszek Szmek <zbyszek at in.waw.pl> added the comment:

Both appear to be commonly used. Both sound OK to me.

----------

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

From report at bugs.python.org  Sat Mar 17 16:08:06 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 17 Mar 2012 15:08:06 +0000
Subject: [docs] [issue14349] The documentation of 'dis' doesn't
	describe	MAKE_FUNCTION correctly
Message-ID: <1331996886.47.0.46755295506.issue14349@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The documentation of the MAKE_FUNCTION opcode in 'dis' says:

"Pushes a new function object on the stack. TOS is the code associated with the function. "

Which doesn't appear to be true. In Python/ceval.c:

[...]
        TARGET_WITH_IMPL(MAKE_CLOSURE, _make_function)
        TARGET(MAKE_FUNCTION)
        _make_function:
        {
            int posdefaults = oparg & 0xff;
            int kwdefaults = (oparg>>8) & 0xff;
            int num_annotations = (oparg >> 16) & 0x7fff;

            w = POP(); /* qualname */
            v = POP(); /* code object */
            x = PyFunction_NewWithQualName(v, f->f_globals, w);
[...]

----------
assignee: docs at python
components: Documentation
messages: 156161
nosy: docs at python, eli.bendersky, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: The documentation of 'dis' doesn't describe MAKE_FUNCTION correctly
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Mar 17 16:58:17 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Mar 2012 15:58:17 +0000
Subject: [docs] [issue14306] try/except block is both efficient and
	expensive?
In-Reply-To: <1331761279.09.0.327606618026.issue14306@psf.upfronthosting.co.za>
Message-ID: <E1S8w1H-0000aF-NY@dinsdale.python.org>


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

New changeset 9a7dcfbcf726 by Georg Brandl in branch '3.2':
Closes #14306: clarify expensiveness of try-except and update code snippet
http://hg.python.org/cpython/rev/9a7dcfbcf726

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

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

From report at bugs.python.org  Sat Mar 17 16:58:55 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Mar 2012 15:58:55 +0000
Subject: [docs] [issue14306] try/except block is both efficient and
	expensive?
In-Reply-To: <1331761279.09.0.327606618026.issue14306@psf.upfronthosting.co.za>
Message-ID: <E1S8w1u-0000c7-Gc@dinsdale.python.org>


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

New changeset 7a93f6ee2ebc by Georg Brandl in branch '2.7':
Closes #14306: clarify expensiveness of try-except and update code snippet
http://hg.python.org/cpython/rev/7a93f6ee2ebc

----------

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

From report at bugs.python.org  Sat Mar 17 16:59:37 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 17 Mar 2012 15:59:37 +0000
Subject: [docs] [issue14349] The documentation of 'dis' doesn't
	describe	MAKE_FUNCTION correctly
In-Reply-To: <1331996886.47.0.46755295506.issue14349@psf.upfronthosting.co.za>
Message-ID: <1331999977.95.0.387752216986.issue14349@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

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

From report at bugs.python.org  Sat Mar 17 17:26:40 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Mar 2012 16:26:40 +0000
Subject: [docs] [issue14343] In re's examples the example with re.split()
	shadows	builtin input()
In-Reply-To: <1331945434.37.0.313316190883.issue14343@psf.upfronthosting.co.za>
Message-ID: <E1S8wSl-0002mh-9C@dinsdale.python.org>


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

New changeset 6cf5f963e0c4 by Georg Brandl in branch '3.2':
Closes #14343: avoid shadowing builtin input() in example code.
http://hg.python.org/cpython/rev/6cf5f963e0c4

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

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

From report at bugs.python.org  Sat Mar 17 17:26:41 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Mar 2012 16:26:41 +0000
Subject: [docs] [issue14342] In re's examples the example with recursion
	doesn't work
In-Reply-To: <1331945308.4.0.250244486328.issue14342@psf.upfronthosting.co.za>
Message-ID: <E1S8wSl-0002mh-9P@dinsdale.python.org>


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

New changeset 8172d7dce0ed by Georg Brandl in branch '3.2':
Closes #14342: remove out-of-date section about avoiding recursion errors.
http://hg.python.org/cpython/rev/8172d7dce0ed

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

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

From report at bugs.python.org  Sat Mar 17 17:27:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Mar 2012 16:27:48 +0000
Subject: [docs] [issue14343] In re's examples the example with re.split()
	shadows	builtin input()
In-Reply-To: <1331945434.37.0.313316190883.issue14343@psf.upfronthosting.co.za>
Message-ID: <E1S8wTq-0002tH-St@dinsdale.python.org>


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

New changeset 483319c711d4 by Georg Brandl in branch '2.7':
Closes #14343: avoid shadowing builtin input() in example code.
http://hg.python.org/cpython/rev/483319c711d4

----------

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

From report at bugs.python.org  Sat Mar 17 17:27:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Mar 2012 16:27:48 +0000
Subject: [docs] [issue14342] In re's examples the example with recursion
	doesn't work
In-Reply-To: <1331945308.4.0.250244486328.issue14342@psf.upfronthosting.co.za>
Message-ID: <E1S8wTq-0002tH-TL@dinsdale.python.org>


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

New changeset 276f79e4b215 by Georg Brandl in branch '2.7':
Closes #14342: remove out-of-date section about avoiding recursion errors.
http://hg.python.org/cpython/rev/276f79e4b215

----------

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

From report at bugs.python.org  Sat Mar 17 17:29:45 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Mar 2012 16:29:45 +0000
Subject: [docs] [issue14250] for string patterns regex.flags is never equal
	to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <E1S8wVj-00031d-Mz@dinsdale.python.org>


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

New changeset b3b3a4a7d7b2 by Georg Brandl in branch '3.2':
Closes #14250: regex.flags has not only explicit flags but also implicit flags and those from the pattern
http://hg.python.org/cpython/rev/b3b3a4a7d7b2

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

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

From report at bugs.python.org  Sat Mar 17 17:31:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Mar 2012 16:31:32 +0000
Subject: [docs] [issue14250] for string patterns regex.flags is never equal
	to 0
In-Reply-To: <1331426792.04.0.0924775979082.issue14250@psf.upfronthosting.co.za>
Message-ID: <E1S8wXT-0003Cr-Kp@dinsdale.python.org>


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

New changeset ac00531a63aa by Georg Brandl in branch '2.7':
Closes #14250: regex.flags has not only explicit flags but also those from the pattern
http://hg.python.org/cpython/rev/ac00531a63aa

----------

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

From report at bugs.python.org  Sat Mar 17 20:51:32 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Mar 2012 19:51:32 +0000
Subject: [docs] [issue14351] Script error in 3.2.3rc1 Windows doc
Message-ID: <1332013892.73.0.333055094928.issue14351@psf.upfronthosting.co.za>


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

3.2.3rc1: When I click the Python manuals Start Menu icon, the Windows help version of the docs comes up, but with a Script Error box. 

Contents of the box:
<warning sign> A error has occurred in the script on this page
Line  : 1
Char  : 1
Error : The value of the property '$' is null or undefined, not a Function object
Code  : 0
URL   : mk:@MSITStore:C:\<...>\pthon323rc1.chm:/_static/copybuttom.js
Do you want to continue running script on this page?
[yes] [no]

Whether I click yes or no, clicking on anything, for instance, Language Reference, brings up the the error box again. After clicking away the error box, I get what I intended, but having to do that with every click makes that nice form of the doc, which I use daily, unusable. So I think this should be a release blocker.

I did not notice before because I have been using and testing 3.3.0a1.
The chm manual for that works fine, as normal.
I have not loaded 2.7.3rc1. I am on Win7, 64bit.

----------
assignee: docs at python
components: Documentation, Windows
messages: 156195
nosy: docs at python, georg.brandl, loewis, terry.reedy
priority: normal
severity: normal
status: open
title: Script error in 3.2.3rc1 Windows doc
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Mar 17 21:07:23 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Mar 2012 20:07:23 +0000
Subject: [docs] [issue14351] Script error in 3.2.3rc1 Windows doc
In-Reply-To: <1332013892.73.0.333055094928.issue14351@psf.upfronthosting.co.za>
Message-ID: <1332014843.25.0.48147873541.issue14351@psf.upfronthosting.co.za>


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

I believe this was already found by someone (Georg, Martin?) and fixed by Ezio.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti, r.david.murray

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

From report at bugs.python.org  Sat Mar 17 21:58:49 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 17 Mar 2012 20:58:49 +0000
Subject: [docs] [issue14355] imp module should omit references to init_frozen
Message-ID: <1332017929.34.0.162160469146.issue14355@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The imp.init_frozen() function was removed from the documentation prior to 3.2 (changeset 2cf7bb2bbfb8).  One reference to the function was left behind.  I've attached a very intricate patch.  <wink>

----------
assignee: docs at python
components: Documentation
files: imp_doc.rst
messages: 156206
nosy: docs at python, eric.snow
priority: normal
severity: normal
status: open
title: imp module should omit references to init_frozen
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24920/imp_doc.rst

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

From report at bugs.python.org  Sat Mar 17 22:29:30 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Mar 2012 21:29:30 +0000
Subject: [docs] [issue14351] Script error in 3.2.3rc1 Windows doc
In-Reply-To: <1332013892.73.0.333055094928.issue14351@psf.upfronthosting.co.za>
Message-ID: <1332019770.59.0.41648327829.issue14351@psf.upfronthosting.co.za>


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

I hope you are right. The module docs server is also not working for me. Has that also been found and fixed (I don't see any issues) or should I file a separate report?

----------

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

From report at bugs.python.org  Sat Mar 17 23:01:38 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 17 Mar 2012 22:01:38 +0000
Subject: [docs] [issue14351] Script error in 3.2.3rc1 Windows doc
In-Reply-To: <1332013892.73.0.333055094928.issue14351@psf.upfronthosting.co.za>
Message-ID: <1332021698.1.0.188903183556.issue14351@psf.upfronthosting.co.za>


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

Yes, it should be fixed in rc2. The "module docs server" (I'm not familiar with that) is probably another issue.

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

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

From report at bugs.python.org  Sat Mar 17 23:04:40 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 17 Mar 2012 22:04:40 +0000
Subject: [docs] [issue14351] Script error in 3.2.3rc1 Windows doc
In-Reply-To: <1332013892.73.0.333055094928.issue14351@psf.upfronthosting.co.za>
Message-ID: <1332021880.3.0.479175572006.issue14351@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution: fixed -> duplicate
superseder:  -> 2.7.3rc1 chm gives JS error

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

From report at bugs.python.org  Sun Mar 18 09:13:46 2012
From: report at bugs.python.org (Eric Snow)
Date: Sun, 18 Mar 2012 08:13:46 +0000
Subject: [docs] [issue14355] imp module docs should omit references to
	init_frozen
In-Reply-To: <1332017929.34.0.162160469146.issue14355@psf.upfronthosting.co.za>
Message-ID: <1332058426.41.0.581049084588.issue14355@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
title: imp module should omit references to init_frozen -> imp module docs should omit references to init_frozen

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

From report at bugs.python.org  Sun Mar 18 12:18:24 2012
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 18 Mar 2012 11:18:24 +0000
Subject: [docs] [issue14362] No mention of collections.ChainMap in What's
	New for 3.3
Message-ID: <1332069504.3.0.514334264343.issue14362@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

The 3.3 What's New doesn't mention collections.ChainMap

----------
assignee: docs at python
components: Documentation
messages: 156244
nosy: docs at python, stevenjd
priority: normal
severity: normal
status: open
title: No mention of collections.ChainMap in What's New for 3.3
versions: Python 3.3

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

From report at bugs.python.org  Sun Mar 18 22:31:42 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 18 Mar 2012 21:31:42 +0000
Subject: [docs] [issue10423] s/args/options in arpgarse "Upgrading optparse
	code"
In-Reply-To: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>
Message-ID: <1332106302.7.0.943035368305.issue10423@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 18 22:35:25 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 18 Mar 2012 21:35:25 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1332106525.5.0.941974588024.issue11176@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 18 22:56:51 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 18 Mar 2012 21:56:51 +0000
Subject: [docs] [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>
Message-ID: <1332107811.95.0.551915210281.issue13850@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 18 22:58:16 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 18 Mar 2012 21:58:16 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1332107896.46.0.715779421338.issue13540@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 18 23:06:36 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 18 Mar 2012 22:06:36 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1332108395.94.0.15444219318.issue14034@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

friendly ping

----------

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

From report at bugs.python.org  Sun Mar 18 23:07:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 18 Mar 2012 22:07:47 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1332108467.71.0.449225433478.issue14034@psf.upfronthosting.co.za>


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

I?m going to Rietveld to review the patch.

----------

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

From report at bugs.python.org  Sun Mar 18 23:37:57 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 18 Mar 2012 22:37:57 +0000
Subject: [docs] [issue14362] No mention of collections.ChainMap in What's
	New for 3.3
In-Reply-To: <1332069504.3.0.514334264343.issue14362@psf.upfronthosting.co.za>
Message-ID: <1332110277.21.0.0956566773504.issue14362@psf.upfronthosting.co.za>


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

Raymond is the author of What?s New In Python 3.3 and of the collections changes (adding ChainMap and moving ABCs to collections.abc from the top of my head).  Maybe he?s waiting for later in the release cycle to review all changes and expand whatsnew.  Raymond, is that the case or would you like me to add a stub entry for collections changes?

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

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

From report at bugs.python.org  Sun Mar 18 23:49:29 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 18 Mar 2012 22:49:29 +0000
Subject: [docs] [issue9694] argparse: Default Help Message Lists Required
	Args As	Optional
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1332110969.5.0.245731651451.issue9694@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar 19 01:50:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Mar 2012 00:50:56 +0000
Subject: [docs] [issue14355] imp module docs should omit references to
	init_frozen
In-Reply-To: <1332017929.34.0.162160469146.issue14355@psf.upfronthosting.co.za>
Message-ID: <E1S9QoJ-00035p-Hv@dinsdale.python.org>


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

New changeset 66e2dab98041 by R David Murray in branch '3.2':
#14355: remove obsolete doc reference to previously removed init_frozen.
http://hg.python.org/cpython/rev/66e2dab98041

New changeset 1e827a176306 by R David Murray in branch 'default':
Merge #14355: remove obsolete doc reference to previously removed init_frozen.
http://hg.python.org/cpython/rev/1e827a176306

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

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

From report at bugs.python.org  Mon Mar 19 01:51:34 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Mar 2012 00:51:34 +0000
Subject: [docs] [issue14355] imp module docs should omit references to
	init_frozen
In-Reply-To: <1332017929.34.0.162160469146.issue14355@psf.upfronthosting.co.za>
Message-ID: <1332118294.77.0.453036459473.issue14355@psf.upfronthosting.co.za>


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

Thanks, Eric.

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

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

From report at bugs.python.org  Mon Mar 19 04:30:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Mar 2012 03:30:47 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1332127847.57.0.545480154984.issue14034@psf.upfronthosting.co.za>


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

Sorry, a burger party fell on me.  I?ll make time this week.

Nick, I just read on python-dev that you had suggestions for argparse docs; could you post the bug numbers / message IDs here or the list of suggestions?

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

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

From report at bugs.python.org  Mon Mar 19 04:57:35 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 19 Mar 2012 03:57:35 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1332129454.9.0.449814458686.issue14034@psf.upfronthosting.co.za>


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

13850 (already mentioned above) is my relevant argparse docs proposal - it turns out the other argparse issues I remembered posting were actual feature requests rather than docs suggestions (FWIW, those are 14037 and 14039)

----------

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

From report at bugs.python.org  Mon Mar 19 05:17:43 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 19 Mar 2012 04:17:43 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1332130663.43.0.872734730459.issue14034@psf.upfronthosting.co.za>


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

A couple of thoughts on the draft HOWTO:

I like the "verbosity" example, but I'd also like to see it continue on into introducing the "action='count'" alternative that allows "-vv" to set the verbosity level to 2, etc.

I also find the idea of having higher verbosity levels that aren't supersets of lower verbosity levels to be an anti-pattern, so I'd prefer not to see it in an official HOWTO. To my mind, verbosity levels should be checked with ">=", never "==".

----------

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

From report at bugs.python.org  Mon Mar 19 08:55:54 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Mar 2012 07:55:54 +0000
Subject: [docs] [issue14362] No mention of collections.ChainMap in What's
	New for 3.3
In-Reply-To: <1332069504.3.0.514334264343.issue14362@psf.upfronthosting.co.za>
Message-ID: <1332143754.3.0.583521318184.issue14362@psf.upfronthosting.co.za>


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

?ric, please go ahead and add a stub entry or a draft entry.  I haven't had a chance to start my whatsnew edits yet.

----------

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

From report at bugs.python.org  Mon Mar 19 09:34:42 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 19 Mar 2012 08:34:42 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1332130663.43.0.872734730459.issue14034@psf.upfronthosting.co.za>
Message-ID: <CAA77j2Di0WCnOTihiq=mVCkDt4EO1KV5tGZkLfAN-rYONSixQg@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> A couple of thoughts on the draft HOWTO:
>
> I like the "verbosity" example, but I'd also like to see it continue on into introducing the "action='count'" alternative that allows "-vv" to set the verbosity level to 2, etc.

I wonder if this usage is common enough to get an entry in this
introductory text.

> I also find the idea of having higher verbosity levels that aren't supersets of lower verbosity levels to be an anti-pattern, so I'd prefer not to see it in an official HOWTO. To my mind, verbosity levels should be checked with ">=", never "==".

I don't really understand this paragraph. Do you have an example to
compare with any of the examples in the attached patch?

----------

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

From report at bugs.python.org  Mon Mar 19 09:49:03 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 19 Mar 2012 08:49:03 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <CAA77j2Di0WCnOTihiq=mVCkDt4EO1KV5tGZkLfAN-rYONSixQg@mail.gmail.com>
Message-ID: <CAA77j2CPKe4F4CVOce5U21KvyTWhiFtDytRNTY2NjqHZXFnhDw@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

On Mon, Mar 19, 2012 at 10:34, Tshepang Lekhonkhobe <tshepang at gmail.com> wrote:
>> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>>
>> A couple of thoughts on the draft HOWTO:
>>
>> I like the "verbosity" example, but I'd also like to see it continue on into introducing the "action='count'" alternative that allows "-vv" to set the verbosity level to 2, etc.
>
> I wonder if this usage is common enough to get an entry in this
> introductory text.
>
>> I also find the idea of having higher verbosity levels that aren't supersets of lower verbosity levels to be an anti-pattern, so I'd prefer not to see it in an official HOWTO. To my mind, verbosity levels should be checked with ">=", never "==".
>
> I don't really understand this paragraph. Do you have an example to
> compare with any of the examples in the attached patch?

After playing a bit more with this and thinking about it a bit, I do
get your point. It makes a lot of sense. I will attach a patch soon,
which will also include the count keyword. Thanks for the review.

----------

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

From report at bugs.python.org  Mon Mar 19 11:51:00 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 19 Mar 2012 10:51:00 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <CAA77j2CPKe4F4CVOce5U21KvyTWhiFtDytRNTY2NjqHZXFnhDw@mail.gmail.com>
Message-ID: <CAA77j2AhPzLi=caR3ccQ47NeNZRgGAZ2iGhJpSPCug6VE9hL7w@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

> After playing a bit more with this and thinking about it a bit, I do
> get your point. It makes a lot of sense. I will attach a patch soon,
> which will also include the count keyword. Thanks for the review.

Find attached. Note that I kept some of those anti-pattern examples
you mentioned, and then later on introduced your preferred way of
doing things (using action="count" and ">=" checks instead of "=="
ones).

----------
Added file: http://bugs.python.org/file24937/argparse_howto2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________
-------------- next part --------------
diff --git a/Doc/howto/argparse.rst b/Doc/howto/argparse.rst
new file mode 100644
--- /dev/null
+++ b/Doc/howto/argparse.rst
@@ -0,0 +1,720 @@
+*****************************
+Command Line Interface HOWTO
+*****************************
+
+:author: Tshepang Lekhonkhobe <tshepang at gmail.com>
+
+.. _argparse-howto:
+
+This is intended to be a gentle introduction to command line parsing
+using :mod:`argparse` module, the recommended module for such a purpose
+in Python. Please pay careful attention to the code and its output. All of
+it was carefully selected for its instructive value.
+
+.. note::
+
+   There's two other modules that fulfill the same task, namely
+   :mod:`getopt` (an equivalent for :c:func:`getopt` from the C
+   language) and the deprecated :mod:`optparse`.
+
+
+Concepts
+========
+
+Let's show the sort of functionality that we are going to explore in this
+introductory tutorial by making use of the :command:`ls` command::
+
+
+    $ ls
+    cpython  devguide  prog.py  pypy  rm-unused-function.patch
+    $ ls pypy
+    ctypes_configure  demo  dotviewer  include  lib_pypy  lib-python ...
+    $ ls -l
+    total 20
+    drwxr-xr-x 19 wena wena 4096 Feb 18 18:51 cpython
+    drwxr-xr-x  4 wena wena 4096 Feb  8 12:04 devguide
+    -rwxr-xr-x  1 wena wena  535 Feb 19 00:05 prog.py
+    drwxr-xr-x 14 wena wena 4096 Feb  7 00:59 pypy
+    -rw-r--r--  1 wena wena  741 Feb 18 01:01 rm-unused-function.patch
+    $ ls --help
+    Usage: ls [OPTION]... [FILE]...
+    List information about the FILEs (the current directory by default).
+    Sort entries alphabetically if none of -cftuvSUX nor --sort is specified.
+    ...
+
+A few concepts we can learn from the four commands:
+
+#. The :command:`ls` command is useful when run without any options at all. It defaults
+   to displaying the contents of the current directory.
+
+#. If we want beyond what it provides by default, we tell it a bit more. In
+   this case, we want it to display a different directory, ``pypy``.
+   What we did is specify what is known as a positional argument. It's named so
+   because the program should know what to do with the value, solely based on
+   where it appears on the command line. This concept is more relevant
+   to a command like :command:`cp`, whose most basic usage is ``cp SRC DEST``.
+   The first position is *what you want copied,* and the second
+   position is *where you want it copied to*.
+
+#. Now, say we want to change behaviour of the program. In our example,
+   we display more info for each file instead of just showing the file names.
+   The ``-l`` in that case is known as an optional argument.
+
+#. That's a snippet of the help text. It's very useful in that you can
+   come across a program you have never used before, and can figure out
+   how it works simply by reading it's help text.
+
+
+The basics
+==========
+
+Let us start with a very simple example which does (almost) nothing::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.parse_args()
+
+Following is a result of running the code::
+
+    $ python3 prog.py 
+    $ python3 prog.py --help
+    usage: prog.py [-h]
+
+    optional arguments:
+      -h, --help  show this help message and exit
+    $ python3 prog.py --verbose
+    usage: prog.py [-h]
+    prog.py: error: unrecognized arguments: --verbose
+    $ python3 prog.py foo
+    usage: prog.py [-h]
+    prog.py: error: unrecognized arguments: foo
+
+Here is what is happening:
+
+* Running the script without any options results in nothing displayed to
+  stdout. Not so useful.
+
+* The second one starts to display the usefulness of the :mod:`argparse`
+  module. We have done almost nothing, but already we get a nice help message.
+
+* The ``--help`` option, which can also be shortened to ``-h``, is the only
+  option we get for free (i.e. no need to specify it). Specifying anything
+  else results in an error. But even then, we do get a useful usage message,
+  also for free.
+
+
+Introducing Positional arguments
+================================
+
+An example::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("echo")
+    args = parser.parse_args()
+    print(args.echo)
+
+And running the code::
+
+    $ python3 prog.py
+    usage: prog.py [-h] echo
+    prog.py: error: the following arguments are required: echo
+    $ python3 prog.py --help
+    usage: prog.py [-h] echo
+
+    positional arguments:
+      echo
+
+    optional arguments:
+      -h, --help  show this help message and exit
+    $ python3 prog.py foo
+    foo
+
+Here is what's happening:
+
+#. We've added :meth:`add_argument` method, which is what we use to specify
+   which command line options the program is willing to accept. In this case,
+   I've named it ``echo`` so that it's in line with its function.
+
+#. Calling our program now requires us to specify an option.
+
+#. Also, the :meth:`parse_args` method actually returns some data from the
+   options specified, in this case, ``echo``. Note that the variable is some
+   form of 'magic' that :mod:`argparse` performs for free (i.e. no need to
+   specify which variable that value is stored in). Note also that it's
+   name matches the string argument given to the method, ``echo``.
+
+Note however that, although the help display looks nice and all, it currently
+is not as helpful as it can be. For example we see that we got ``echo`` as a
+positional argument, but we don't know what it does, other than by guessing or
+by reading the source code. So, let's make it a bit more useful::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("echo", help="echo the string you use here")
+    args = parser.parse_args()
+    print(args.echo)
+
+And we get::
+
+    $ python3 prog.py -h
+    usage: prog.py [-h] echo
+
+    positional arguments:
+      echo        echo the string you use here
+
+    optional arguments:
+      -h, --help  show this help message and exit
+
+Now, how about doing something even more useful::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", help="display a square of a given number")
+    args = parser.parse_args()
+    print(pow(args.square, 2))
+
+Following is a result of running the code::
+
+    $ python3 prog.py 4
+    Traceback (most recent call last):
+      File "prog.py", line 5, in <module>
+        print(pow(args.square, 2))
+    TypeError: unsupported operand type(s) for ** or pow(): 'str' and 'int'
+
+That didn't go so well. That's because :mod:`argparse` treats the options we
+give it as strings, unless we tell it otherwise and the :func:`pow` function
+doesn't accept strings as arguments. So, let's tell
+:mod:`argparse` to treat that input as an integer::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", help="display a square of a given number",
+                        type=int)
+    args = parser.parse_args()
+    print(pow(args.square, 2))
+
+Following is a result of running the code::
+
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py four
+    usage: prog.py [-h] square
+    prog.py: error: argument square: invalid int value: 'four'
+
+That went well. The program now even helpfully quits on bad illegal input
+before proceeding.
+
+
+Introducing Optional arguments
+==============================
+
+So far we, have been playing with positional arguments. Let us
+have a look on how to add optional ones::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("--verbosity", help="increase output verbosity")
+    args = parser.parse_args()
+    if args.verbosity:
+        print("verbosity turned on")
+
+And the output::
+
+    $ python3 prog.py --verbosity 1
+    verbosity turned on
+    $ python3 prog.py
+    $ python3 prog.py --help
+    usage: prog.py [-h] [--verbosity VERBOSITY]
+
+    optional arguments:
+      -h, --help            show this help message and exit
+      --verbosity VERBOSITY
+                            increase output verbosity
+    $ python3 prog.py --verbosity 
+    usage: prog.py [-h] [--verbosity VERBOSITY]
+    prog.py: error: argument --verbosity: expected one argument
+
+Here is what is happening:
+
+#. The program is written so as to display something when ``--verbosity`` is
+   specified and display nothing when not.
+
+#. To show that the option is actually optional, there is no error when running
+   the program without it. Note that by default, if an optional argument isn't
+   used, the relevant variable, in this case :data:`args.verbosity`, is
+   given ``None`` as a value, which is the reason it fails the truth
+   test of the :keyword:`if` statement.
+
+#. The help message is a bit different.
+
+#. When using the ``--verbosity`` option, one must also specify some value, any
+   value.
+
+The above example accepts arbitrary integer values for ``--verbosity``, but for
+our simple program, only two values are actually useful, ``True`` or ``False``.
+Let's modify the code accordingly::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("--verbose", help="increase output verbosity",
+                        action="store_true")
+    args = parser.parse_args()
+    if args.verbose:
+        print("verbosity turned on")
+
+And the output::
+
+    $ python3 prog.py --verbose
+    verbosity turned on
+    $  python3 prog.py --verbose 1
+    usage: prog.py [-h] [--verbose]
+    prog.py: error: unrecognized arguments: 1
+    $ python3 prog.py --help
+    usage: prog.py [-h] [--verbose]
+
+    optional arguments:
+      -h, --help  show this help message and exit
+      --verbose   increase output verbosity
+
+Here is what is happening:
+
+#. The option is now more of a flag than something that requires a value.
+   We even changed the name of the option to match that idea.
+   Note that we now specify a new keyword, ``action``, and give it the value
+   "store_true". This means that, if the option is specified, assign the value
+   ``True`` to :data:`args.verbose` ``True``. Not specifying it implies
+   ``False``.
+
+#. It complains when you specify a value, in true spirit of what flags
+   actually are.
+
+#. Notice the different help text.
+
+If you are familiar with command line usage, you will notice that I haven't yet
+touched on the topic of short versions of the options. It's quite simple::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("-v", "--verbose", help="increase output verbosity",
+                        action="store_true")
+    args = parser.parse_args()
+    if args.verbose:
+        print("verbosity turned on")
+
+And here goes::
+
+    $ python3 prog.py -v
+    verbosity turned on
+    $ python3 prog.py --help
+    usage: prog.py [-h] [-v]
+
+    optional arguments:
+      -h, --help     show this help message and exit
+      -v, --verbose  increase output verbosity
+
+Note that the new ability is also reflected in the help text.
+
+
+Combining Positional and Optional arguments
+===========================================
+
+Our program keeps growing in complexity::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbose", action="store_true",
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbose:
+        print("the square of {} equals {}".format(args.square, answer))
+    else:
+        print(answer)
+
+And now the output::
+
+    $ python3 prog.py
+    usage: prog.py [-h] [-v] square
+    prog.py: error: the following arguments are required: square
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py 4 --verbose
+    the square of 4 equals 16
+    $ python3 prog.py --verbose 4
+    the square of 4 equals 16
+
+* We've brought back a positional argument, hence the complaint.
+
+* As for the fourth output, note that the order does not matter.
+
+How about we give this program of ours back the ability to have
+multiple verbosity values, and actually get to use them::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", type=int,
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity == 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity == 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+    
+And the output::
+
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py 4 -v
+    usage: prog.py [-h] [-v VERBOSITY] square
+    prog.py: error: argument -v/--verbosity: expected one argument
+    $ python3 prog.py 4 -v 1
+    pow(4, 2) == 16
+    $ python3 prog.py 4 -v 2
+    the square of 4 equals 16
+    $ python3 prog.py 4 -v 3
+    16
+
+These all look good except the last one, which exposes a bug in our program.
+Let's fix it by restricting the values the ``--verbosity`` option can accept::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", type=int, choices=[0, 1, 2],
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity == 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity == 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+And the output::
+
+    $ python3 prog.py 4 -v 3
+    usage: prog.py [-h] [-v {0,1,2}] square
+    prog.py: error: argument -v/--verbosity: invalid choice: 3 (choose from 0, 1, 2)
+    $ python3 prog.py 4 -h
+    usage: prog.py [-h] [-v {0,1,2}] square
+
+    positional arguments:
+      square                display a square of a given number
+
+    optional arguments:
+      -h, --help            show this help message and exit
+      -v {0,1,2}, --verbosity {0,1,2}
+                            increase output verbosity
+
+Note that the change also reflects both in the error message as well as the
+help string.
+
+Now, let's use a different approach of playing with verbosity, which is pretty
+common (and is recommended by at least one core CPython developer)::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", action="count",
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity == 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity == 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+We have introduced another action, "count". What it does is keep a count of
+optional arguments::
+
+    $ python3 prog.py 4 -v 1
+    usage: prog.py [-h] [-v] square
+    prog.py: error: unrecognized arguments: 1
+    $ python3 prog.py 4 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 -vv
+    the square of 4 equals 16
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py 4 --verbosity --verbosity
+    the square of 4 equals 16
+    $ python3 prog.py 4 -h
+    usage: prog.py [-h] [-v] square
+
+    positional arguments:
+      square           display a square of a given number
+
+    optional arguments:
+      -h, --help       show this help message and exit
+      -v, --verbosity  increase output verbosity
+    $ python3 prog.py 4 -vvv
+    16
+
+* Yes, it's now more of a flag (similar tp `action="store_true"`) in the
+  previous version of our script. That should explain the complaint.
+* See what I mean that it behaves similar to "store_true" action?
+* Now here's a demonstration of what the "count" action gives. You've probably
+  seen this sort of usage before.
+* And, just like the "store_true" action, if you don't specify the `-v` flag,
+  that flag is considered to have ``None`` value.
+* As should be expected, specifying the long form of the flag, we should get
+  the same output.
+* Sadly, our help output isn't very informative on the new ability our script
+  has acquired, but that can always be fixed by improving the documentation for
+  out script (e.g. via the `help` keyword argument).
+* That's a bug in our program. Let's fix::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", action="count",
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity >= 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity >= 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+And this is what it gives::
+
+    $ python3 prog.py 4 -vvv
+    the square of 4 equals 16
+    $ python3 prog.py 4 -vvvv
+    the square of 4 equals 16
+    $ python3 prog.py 4
+    Traceback (most recent call last):
+      File "prog.py", line 11, in <module>
+        if args.verbosity >= 2:
+    TypeError: unorderable types: NoneType() >= int()
+
+* First output went as well, and fixes the bug we had before. That is, to avoid
+  such problems, do `>=` checks in future, not `==`.
+* Third output not so good, so let's fix that bug::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", action="count",
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if not args.verbosity:
+        print(answer)
+    elif args.verbosity >= 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity >= 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+
+And::
+
+    $ python3 prog.py 4
+    16
+
+All's well.
+
+Powerful isn't it. We have only scratched the surface. The :mod:`argparse`
+module is excessively powerful, and we'll explore a bit more of it before we
+end this tutorial.
+
+
+Getting a little more advanced
+==============================
+
+What if we wanted to expand our tiny program to perform other powers, not
+just 2::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("power", type=int, nargs=2)
+    parser.add_argument("-v", "--verbosity", action="count")
+    args = parser.parse_args()
+    answer = pow(args.power[0], args.power[1])
+    if not args.verbosity:
+        print(answer)
+    elif args.verbosity >= 2:
+        print("{} to the power {} equals {}".format(args.power[0], args.power[1], answer))
+    elif args.verbosity >= 1:
+        print("pow({}, {}) == {}".format(args.power[0], args.power[1], answer))
+
+Output::
+
+    $ python3 prog.py
+    usage: prog.py [-h] [-v] power power
+    prog.py: error: the following arguments are required: power
+    $ python3 prog.py -h
+    usage: prog.py [-h] [-v] power power
+
+    positional arguments:
+      power
+
+    optional arguments:
+      -h, --help       show this help message and exit
+      -v, --verbosity
+    $ python3 prog.py 4 2
+    16
+    $ python3 prog.py 4 2 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -vv
+    4 to the power 2 equals 16
+    $ python3 prog.py 4 2 -vvv
+    4 to the power 2 equals 16
+
+We introduced another keyword argument, ``nargs``. It helps us specify
+how many arguments are expected for a given command line option, which is
+2 in this case.
+
+As you can see, the help text could be a little better than what it is
+(``usage: prog.py [-h] [-v {0,1,2}] power power``). Let's fix it::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    parser.add_argument("-v", "--verbosity", action="count")
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+    if not args.verbosity:
+        print(answer)
+    elif args.verbosity >= 2:
+        print("{} to the power {} equals {}".format(args.x, args.y, answer))
+    elif args.verbosity >= 1:
+        print("pow({}, {}) == {}".format(args.x, args.y, answer))
+
+Output::
+
+    $ python3 prog.py
+    usage: prog.py [-h] [-v] x y
+    prog.py: error: the following arguments are required: x, y
+    $ python3 prog.py -h
+    usage: prog.py [-h] [-v] x y
+
+    positional arguments:
+      x                the 'x' in x^y
+      y                the 'y' in x^y
+
+    optional arguments:
+      -h, --help       show this help message and exit
+      -v, --verbosity
+    $ python3 prog.py 4 2 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -v 1
+    usage: prog.py [-h] [-v] x y
+    prog.py: error: unrecognized arguments: 1
+
+That looks much better, and the last example serves as a reminder that this
+is pretty much a flag, removing the need to provide values.
+
+So far, we have been working with two methods of an
+:class:`argparse.ArgumentParser` instance. Let's introduce a third one,
+``add_mutually_exclusive_group``. It allows for us to specify options that
+conflict with each other. Let's also change the rest of the program make the
+new functionality makes more sense::
+
+    import argparse
+
+    parser = argparse.ArgumentParser()
+    group = parser.add_mutually_exclusive_group()
+    group.add_argument("-v", "--verbose", action="store_true")
+    group.add_argument("-q", "--quiet", action="store_true")
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+
+    if args.quiet:
+        print(answer)
+    elif args.verbose:
+        print("{} to the power {} equals {}".format(args.x, args.y, answer))
+    else:
+        print("pow({}, {}) == {}".format(args.x, args.y, answer))
+
+Our program is now simpler, and we've lost some functionality for the sake of
+demonstration. Anyways, here's the output::
+
+    $ python3 prog.py 4 2
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -q
+    16
+    $ python3 prog.py 4 2 -v
+    4 to the power 2 equals 16
+    $ python3 prog.py 4 2 -vq
+    usage: prog.py [-h] [-v | -q] x y
+    prog.py: error: argument -q/--quiet: not allowed with argument -v/--verbose
+    $ python3 prog.py 4 2 -v --quiet
+    usage: prog.py [-h] [-v | -q] x y
+    prog.py: error: argument -q/--quiet: not allowed with argument -v/--verbose
+
+That should be easy to follow. I've added that last output so you can see the
+sort of flexibility you get, i.e. mixing long form options with short form
+ones. That's nice.
+
+Before we conclude, you probably want to tell your users the main purpose of
+your program, just in case they don't know::
+
+    import argparse
+
+    parser = argparse.ArgumentParser(description="calculate X to the power of Y")
+    group = parser.add_mutually_exclusive_group()
+    group.add_argument("-v", "--verbose", action="store_true")
+    group.add_argument("-q", "--quiet", action="store_true")
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+
+    if args.quiet:
+        print(answer)
+    elif args.verbose:
+        print("{} to the power {} equals {}".format(args.x, args.y, answer))
+    else:
+        print("pow({}, {}) == {}".format(args.x, args.y, answer))
+
+Which outputs::
+
+    $ python3 prog.py --help
+    usage: prog.py [-h] [-v | -q] x y
+
+    calculate X to the power of Y
+
+    positional arguments:
+      x              the 'x' in x^y
+      y              the 'y' in x^y
+
+    optional arguments:
+      -h, --help     show this help message and exit
+      -v, --verbose
+      -q, --quiet
+
+Note that slight difference in the usage text. Note the `[-v | -q]`, which
+tells us that we can either use `-v` or `-q`, but not both at the same time.
+
+Conclusion
+==========
+
+There's lots more to the module of course, things like customising
+the help message, or simply disabling its getting generated.
+You can also force optional arguments to be required, or even change the
+character used to denote them (e.g. ``+v`` instead of ``-v``).
+
+Have a look at the API docs.
+They are quite detailed and thorough, and full of examples. I hope that
+having gone through this tutorial, you will easily digest them
+without feeling overwhelmed.
diff --git a/Doc/howto/index.rst b/Doc/howto/index.rst
--- a/Doc/howto/index.rst
+++ b/Doc/howto/index.rst
@@ -27,4 +27,5 @@
    unicode.rst
    urllib2.rst
    webservers.rst
+   argparse.rst
 
diff --git a/Doc/library/argparse.rst b/Doc/library/argparse.rst
--- a/Doc/library/argparse.rst
+++ b/Doc/library/argparse.rst
@@ -10,6 +10,12 @@
 
 **Source code:** :source:`Lib/argparse.py`
 
+.. sidebar:: Tutorial
+
+   This page contains the API reference information. For a more gentle
+   introduction to Python command line parsing, have a look at the
+   :ref:`Basic Tutorial <argparse-howto>`.
+
 --------------
 
 The :mod:`argparse` module makes it easy to write user-friendly command-line

From report at bugs.python.org  Mon Mar 19 12:02:10 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 19 Mar 2012 11:02:10 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <CAA77j2AhPzLi=caR3ccQ47NeNZRgGAZ2iGhJpSPCug6VE9hL7w@mail.gmail.com>
Message-ID: <CAA77j2Dxwf=_3joe9mG63XiXfoovgHN3mb3GgVho94L7RM9y4Q@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

> Find attached. Note that I kept some of those anti-pattern examples
> you mentioned, and then later on introduced your preferred way of
> doing things (using action="count" and ">=" checks instead of "=="
> ones).

Reason I kept those is to easily lead the reader into the "more
correct" way of doing things, by first doing them in a more obvious
but less ideal way.

For example, when the goal of one is to teach one to remove duplicates
from list, it's nice if you first do the process manually, and then
later on introduce the set() type, just so the user can appreciate
them more. Same applies to doing "for item in range(len(iterable))"
vs. "for item in iterable".

----------

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

From report at bugs.python.org  Mon Mar 19 12:11:04 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 19 Mar 2012 11:11:04 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1332155463.51.0.429576311793.issue14034@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

Okay, there was some bad markup on my version 2. Lemme fix.

----------
Added file: http://bugs.python.org/file24938/argparse_howto2.patch

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

From report at bugs.python.org  Mon Mar 19 13:20:54 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 19 Mar 2012 12:20:54 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1332159654.24.0.237132075093.issue14034@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file24937/argparse_howto2.patch

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

From report at bugs.python.org  Mon Mar 19 13:21:53 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Mar 2012 12:21:53 +0000
Subject: [docs] [issue14318] clarify "may not" in time.steady docs
In-Reply-To: <1331829668.71.0.947018206764.issue14318@psf.upfronthosting.co.za>
Message-ID: <1332159713.49.0.838978482208.issue14318@psf.upfronthosting.co.za>


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

> Does "may not" mean that the user isn't allowed to adjust it,
> or that they system won't always have adjusted it?

It depends on which clock is used.

 - clock_gettime(CLOCK_MONOTONIC_RAW) cannot be adjusted
 - clock_gettime(CLOCK_MONOTONIC) can be adjusted by NTP (only its speed, no forward or backward jump)
 - I don't think that QueryPerformanceCounter() can be adjusted
 - gettimeofday(), ftime() and time() are the system clock and can be changed manually by the system administrator or automatically by NTP (maybe with a jump, forward or backward)
 - clock() is used on Windows if QueryPerformanceFrequency failed. I donk't know if it can be ajdusted

It is important to mention that time.steady() may be adjusted in some cases.

----------

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

From report at bugs.python.org  Mon Mar 19 13:48:36 2012
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Mar 2012 12:48:36 +0000
Subject: [docs] [issue14318] clarify "may not" in time.steady docs
In-Reply-To: <1331829668.71.0.947018206764.issue14318@psf.upfronthosting.co.za>
Message-ID: <1332161315.97.0.298484019617.issue14318@psf.upfronthosting.co.za>


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

FYI "may not" comes from the C++ Timeout Specification:

"Objects of class steady_clock represent clocks for which values of time_point never decrease as physical time advances and for which values of time_point advance at a steady rate relative to real time. That is, the clock may not be adjusted."

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.htm

----------

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

From report at bugs.python.org  Mon Mar 19 14:05:43 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 19 Mar 2012 13:05:43 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1332162343.57.0.59473390537.issue14034@psf.upfronthosting.co.za>


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

Rather than "is recommended by at least one core CPython developer" I'd say "matches the way the CPython executable handles its own verbosity argument" (check the output of "python --help")

Also, a better fix for the non-orderable types problem is to use "default=0" when defining the verbosity arg rather than changing the test in the code.

Finally, the "not a superset" problem that I have with the way the running example uses its verbosity argument is that it uses it to *change* the message that gets displayed, instead of using it to *display more messages* at higher verbosity levels.

>From that point of view, more idiomatic usage might look something like:

    if verbosity >= 2:
        print("Running {!r}".format(self.__file__)
    if verbosity >= 1:
        print("Calculating {}^2".format(args.square)
    print(answer)

However, I'll grant that things like test runners do use their verbosity argument to switch from shorthand progress markers to printing out the test names and results, so I can live with the examples as they are.

----------

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

From report at bugs.python.org  Mon Mar 19 15:42:02 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 19 Mar 2012 14:42:02 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1332162343.57.0.59473390537.issue14034@psf.upfronthosting.co.za>
Message-ID: <CAA77j2B-RSMQQFJv95szwGgdot_oXp_ZoCPH3=J7x0=EPvO4hg@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> Rather than "is recommended by at least one core CPython developer" I'd say "matches the way the CPython executable handles its own verbosity argument" (check the output of "python --help")

Done.

> Also, a better fix for the non-orderable types problem is to use "default=0" when defining the verbosity arg rather than changing the test in the code.

Done.

> Finally, the "not a superset" problem that I have with the way the running example uses its verbosity argument is that it uses it to *change* the message that gets displayed, instead of using it to *display more messages* at higher verbosity levels.
>
> >From that point of view, more idiomatic usage might look something like:
>
> ? ?if verbosity >= 2:
> ? ? ? ?print("Running {!r}".format(self.__file__)
> ? ?if verbosity >= 1:
> ? ? ? ?print("Calculating {}^2".format(args.square)
> ? ?print(answer)

Yeah, I clearly didn't understand what you meant by 'superset'. I've
added one example similar to the above.

These were good suggestions. I've attached the patch.

----------
Added file: http://bugs.python.org/file24941/argparse_howto3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________
-------------- next part --------------
diff --git a/Doc/howto/argparse.rst b/Doc/howto/argparse.rst
new file mode 100644
--- /dev/null
+++ b/Doc/howto/argparse.rst
@@ -0,0 +1,755 @@
+*****************************
+Command Line Interface HOWTO
+*****************************
+
+:author: Tshepang Lekhonkhobe <tshepang at gmail.com>
+
+.. _argparse-howto:
+
+This is intended to be a gentle introduction to command line parsing
+using :mod:`argparse` module, the recommended module for such a purpose
+in Python. Please pay careful attention to the code and its output. All of
+it was carefully selected for its instructive value.
+
+.. note::
+
+   There's two other modules that fulfill the same task, namely
+   :mod:`getopt` (an equivalent for :c:func:`getopt` from the C
+   language) and the deprecated :mod:`optparse`.
+
+
+Concepts
+========
+
+Let's show the sort of functionality that we are going to explore in this
+introductory tutorial by making use of the :command:`ls` command::
+
+
+    $ ls
+    cpython  devguide  prog.py  pypy  rm-unused-function.patch
+    $ ls pypy
+    ctypes_configure  demo  dotviewer  include  lib_pypy  lib-python ...
+    $ ls -l
+    total 20
+    drwxr-xr-x 19 wena wena 4096 Feb 18 18:51 cpython
+    drwxr-xr-x  4 wena wena 4096 Feb  8 12:04 devguide
+    -rwxr-xr-x  1 wena wena  535 Feb 19 00:05 prog.py
+    drwxr-xr-x 14 wena wena 4096 Feb  7 00:59 pypy
+    -rw-r--r--  1 wena wena  741 Feb 18 01:01 rm-unused-function.patch
+    $ ls --help
+    Usage: ls [OPTION]... [FILE]...
+    List information about the FILEs (the current directory by default).
+    Sort entries alphabetically if none of -cftuvSUX nor --sort is specified.
+    ...
+
+A few concepts we can learn from the four commands:
+
+#. The :command:`ls` command is useful when run without any options at all. It defaults
+   to displaying the contents of the current directory.
+
+#. If we want beyond what it provides by default, we tell it a bit more. In
+   this case, we want it to display a different directory, ``pypy``.
+   What we did is specify what is known as a positional argument. It's named so
+   because the program should know what to do with the value, solely based on
+   where it appears on the command line. This concept is more relevant
+   to a command like :command:`cp`, whose most basic usage is ``cp SRC DEST``.
+   The first position is *what you want copied,* and the second
+   position is *where you want it copied to*.
+
+#. Now, say we want to change behaviour of the program. In our example,
+   we display more info for each file instead of just showing the file names.
+   The ``-l`` in that case is known as an optional argument.
+
+#. That's a snippet of the help text. It's very useful in that you can
+   come across a program you have never used before, and can figure out
+   how it works simply by reading it's help text.
+
+
+The basics
+==========
+
+Let us start with a very simple example which does (almost) nothing::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.parse_args()
+
+Following is a result of running the code::
+
+    $ python3 prog.py 
+    $ python3 prog.py --help
+    usage: prog.py [-h]
+
+    optional arguments:
+      -h, --help  show this help message and exit
+    $ python3 prog.py --verbose
+    usage: prog.py [-h]
+    prog.py: error: unrecognized arguments: --verbose
+    $ python3 prog.py foo
+    usage: prog.py [-h]
+    prog.py: error: unrecognized arguments: foo
+
+Here is what is happening:
+
+* Running the script without any options results in nothing displayed to
+  stdout. Not so useful.
+
+* The second one starts to display the usefulness of the :mod:`argparse`
+  module. We have done almost nothing, but already we get a nice help message.
+
+* The ``--help`` option, which can also be shortened to ``-h``, is the only
+  option we get for free (i.e. no need to specify it). Specifying anything
+  else results in an error. But even then, we do get a useful usage message,
+  also for free.
+
+
+Introducing Positional arguments
+================================
+
+An example::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("echo")
+    args = parser.parse_args()
+    print(args.echo)
+
+And running the code::
+
+    $ python3 prog.py
+    usage: prog.py [-h] echo
+    prog.py: error: the following arguments are required: echo
+    $ python3 prog.py --help
+    usage: prog.py [-h] echo
+
+    positional arguments:
+      echo
+
+    optional arguments:
+      -h, --help  show this help message and exit
+    $ python3 prog.py foo
+    foo
+
+Here is what's happening:
+
+#. We've added :meth:`add_argument` method, which is what we use to specify
+   which command line options the program is willing to accept. In this case,
+   I've named it ``echo`` so that it's in line with its function.
+
+#. Calling our program now requires us to specify an option.
+
+#. Also, the :meth:`parse_args` method actually returns some data from the
+   options specified, in this case, ``echo``. Note that the variable is some
+   form of 'magic' that :mod:`argparse` performs for free (i.e. no need to
+   specify which variable that value is stored in). Note also that it's
+   name matches the string argument given to the method, ``echo``.
+
+Note however that, although the help display looks nice and all, it currently
+is not as helpful as it can be. For example we see that we got ``echo`` as a
+positional argument, but we don't know what it does, other than by guessing or
+by reading the source code. So, let's make it a bit more useful::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("echo", help="echo the string you use here")
+    args = parser.parse_args()
+    print(args.echo)
+
+And we get::
+
+    $ python3 prog.py -h
+    usage: prog.py [-h] echo
+
+    positional arguments:
+      echo        echo the string you use here
+
+    optional arguments:
+      -h, --help  show this help message and exit
+
+Now, how about doing something even more useful::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", help="display a square of a given number")
+    args = parser.parse_args()
+    print(pow(args.square, 2))
+
+Following is a result of running the code::
+
+    $ python3 prog.py 4
+    Traceback (most recent call last):
+      File "prog.py", line 5, in <module>
+        print(pow(args.square, 2))
+    TypeError: unsupported operand type(s) for ** or pow(): 'str' and 'int'
+
+That didn't go so well. That's because :mod:`argparse` treats the options we
+give it as strings, unless we tell it otherwise and the :func:`pow` function
+doesn't accept strings as arguments. So, let's tell
+:mod:`argparse` to treat that input as an integer::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", help="display a square of a given number",
+                        type=int)
+    args = parser.parse_args()
+    print(pow(args.square, 2))
+
+Following is a result of running the code::
+
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py four
+    usage: prog.py [-h] square
+    prog.py: error: argument square: invalid int value: 'four'
+
+That went well. The program now even helpfully quits on bad illegal input
+before proceeding.
+
+
+Introducing Optional arguments
+==============================
+
+So far we, have been playing with positional arguments. Let us
+have a look on how to add optional ones::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("--verbosity", help="increase output verbosity")
+    args = parser.parse_args()
+    if args.verbosity:
+        print("verbosity turned on")
+
+And the output::
+
+    $ python3 prog.py --verbosity 1
+    verbosity turned on
+    $ python3 prog.py
+    $ python3 prog.py --help
+    usage: prog.py [-h] [--verbosity VERBOSITY]
+
+    optional arguments:
+      -h, --help            show this help message and exit
+      --verbosity VERBOSITY
+                            increase output verbosity
+    $ python3 prog.py --verbosity 
+    usage: prog.py [-h] [--verbosity VERBOSITY]
+    prog.py: error: argument --verbosity: expected one argument
+
+Here is what is happening:
+
+#. The program is written so as to display something when ``--verbosity`` is
+   specified and display nothing when not.
+
+#. To show that the option is actually optional, there is no error when running
+   the program without it. Note that by default, if an optional argument isn't
+   used, the relevant variable, in this case :data:`args.verbosity`, is
+   given ``None`` as a value, which is the reason it fails the truth
+   test of the :keyword:`if` statement.
+
+#. The help message is a bit different.
+
+#. When using the ``--verbosity`` option, one must also specify some value, any
+   value.
+
+The above example accepts arbitrary integer values for ``--verbosity``, but for
+our simple program, only two values are actually useful, ``True`` or ``False``.
+Let's modify the code accordingly::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("--verbose", help="increase output verbosity",
+                        action="store_true")
+    args = parser.parse_args()
+    if args.verbose:
+        print("verbosity turned on")
+
+And the output::
+
+    $ python3 prog.py --verbose
+    verbosity turned on
+    $  python3 prog.py --verbose 1
+    usage: prog.py [-h] [--verbose]
+    prog.py: error: unrecognized arguments: 1
+    $ python3 prog.py --help
+    usage: prog.py [-h] [--verbose]
+
+    optional arguments:
+      -h, --help  show this help message and exit
+      --verbose   increase output verbosity
+
+Here is what is happening:
+
+#. The option is now more of a flag than something that requires a value.
+   We even changed the name of the option to match that idea.
+   Note that we now specify a new keyword, ``action``, and give it the value
+   "store_true". This means that, if the option is specified, assign the value
+   ``True`` to :data:`args.verbose` ``True``. Not specifying it implies
+   ``False``.
+
+#. It complains when you specify a value, in true spirit of what flags
+   actually are.
+
+#. Notice the different help text.
+
+If you are familiar with command line usage, you will notice that I haven't yet
+touched on the topic of short versions of the options. It's quite simple::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("-v", "--verbose", help="increase output verbosity",
+                        action="store_true")
+    args = parser.parse_args()
+    if args.verbose:
+        print("verbosity turned on")
+
+And here goes::
+
+    $ python3 prog.py -v
+    verbosity turned on
+    $ python3 prog.py --help
+    usage: prog.py [-h] [-v]
+
+    optional arguments:
+      -h, --help     show this help message and exit
+      -v, --verbose  increase output verbosity
+
+Note that the new ability is also reflected in the help text.
+
+
+Combining Positional and Optional arguments
+===========================================
+
+Our program keeps growing in complexity::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbose", action="store_true",
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbose:
+        print("the square of {} equals {}".format(args.square, answer))
+    else:
+        print(answer)
+
+And now the output::
+
+    $ python3 prog.py
+    usage: prog.py [-h] [-v] square
+    prog.py: error: the following arguments are required: square
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py 4 --verbose
+    the square of 4 equals 16
+    $ python3 prog.py --verbose 4
+    the square of 4 equals 16
+
+* We've brought back a positional argument, hence the complaint.
+
+* As for the fourth output, note that the order does not matter.
+
+How about we give this program of ours back the ability to have
+multiple verbosity values, and actually get to use them::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", type=int,
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity == 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity == 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+    
+And the output::
+
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py 4 -v
+    usage: prog.py [-h] [-v VERBOSITY] square
+    prog.py: error: argument -v/--verbosity: expected one argument
+    $ python3 prog.py 4 -v 1
+    pow(4, 2) == 16
+    $ python3 prog.py 4 -v 2
+    the square of 4 equals 16
+    $ python3 prog.py 4 -v 3
+    16
+
+These all look good except the last one, which exposes a bug in our program.
+Let's fix it by restricting the values the ``--verbosity`` option can accept::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", type=int, choices=[0, 1, 2],
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity == 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity == 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+And the output::
+
+    $ python3 prog.py 4 -v 3
+    usage: prog.py [-h] [-v {0,1,2}] square
+    prog.py: error: argument -v/--verbosity: invalid choice: 3 (choose from 0, 1, 2)
+    $ python3 prog.py 4 -h
+    usage: prog.py [-h] [-v {0,1,2}] square
+
+    positional arguments:
+      square                display a square of a given number
+
+    optional arguments:
+      -h, --help            show this help message and exit
+      -v {0,1,2}, --verbosity {0,1,2}
+                            increase output verbosity
+
+Note that the change also reflects both in the error message as well as the
+help string.
+
+Now, let's use a different approach of playing with verbosity, which is pretty
+common. It also matches the way the CPython executable handles its own
+verbosity argument (check the output of `python --help`)::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", action="count",
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity == 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity == 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+We have introduced another action, "count". What it does is keep a count of
+optional arguments::
+
+    $ python3 prog.py 4 -v 1
+    usage: prog.py [-h] [-v] square
+    prog.py: error: unrecognized arguments: 1
+    $ python3 prog.py 4 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 -vv
+    the square of 4 equals 16
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py 4 --verbosity --verbosity
+    the square of 4 equals 16
+    $ python3 prog.py 4 -h
+    usage: prog.py [-h] [-v] square
+
+    positional arguments:
+      square           display a square of a given number
+
+    optional arguments:
+      -h, --help       show this help message and exit
+      -v, --verbosity  increase output verbosity
+    $ python3 prog.py 4 -vvv
+    16
+
+* Yes, it's now more of a flag (similar tp `action="store_true"`) in the
+  previous version of our script. That should explain the complaint.
+* See what I mean that it behaves similar to "store_true" action?
+* Now here's a demonstration of what the "count" action gives. You've probably
+  seen this sort of usage before.
+* And, just like the "store_true" action, if you don't specify the `-v` flag,
+  that flag is considered to have ``None`` value.
+* As should be expected, specifying the long form of the flag, we should get
+  the same output.
+* Sadly, our help output isn't very informative on the new ability our script
+  has acquired, but that can always be fixed by improving the documentation for
+  out script (e.g. via the `help` keyword argument).
+* That's a bug in our program.
+
+Let's fix::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", action="count",
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity >= 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity >= 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+And this is what it gives::
+
+    $ python3 prog.py 4 -vvv
+    the square of 4 equals 16
+    $ python3 prog.py 4 -vvvv
+    the square of 4 equals 16
+    $ python3 prog.py 4
+    Traceback (most recent call last):
+      File "prog.py", line 11, in <module>
+        if args.verbosity >= 2:
+    TypeError: unorderable types: NoneType() >= int()
+
+* First output went as well, and fixes the bug we had before. That is, to avoid
+  such problems, do `>=` checks in future, not `==`.
+* Third output not so good
+
+Let's fix that bug::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", action="count", default=0,
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity >= 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity >= 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+We've just introduced yet another keyword, `default`. We've set it to `0` in
+order to make it comparable to the other int values. Remember that by
+default, if an optional argument isn't specified, it gets the `None` value, and
+that cannot be compared to an int value (hence the :exc:`TypeError` exception).
+
+And::
+
+    $ python3 prog.py 4
+    16
+
+You can go quite far just with what we've learned so, and we have only
+scratched the surface. The :mod:`argparse` module is excessively powerful, and
+we'll explore a bit more of it before we end this tutorial.
+
+
+Getting a little more advanced
+==============================
+
+What if we wanted to expand our tiny program to perform other powers, not
+just 2::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("power", type=int, nargs=2)
+    parser.add_argument("-v", "--verbosity", action="count", default=0)
+    args = parser.parse_args()
+    answer = pow(args.power[0], args.power[1])
+    if args.verbosity >= 2:
+        print("{} to the power {} equals {}".format(args.power[0], args.power[1], answer))
+    elif args.verbosity >= 1:
+        print("pow({}, {}) == {}".format(args.power[0], args.power[1], answer))
+    else:
+        print(answer)
+
+Output::
+
+    $ python3 prog.py
+    usage: prog.py [-h] [-v] power power
+    prog.py: error: the following arguments are required: power
+    $ python3 prog.py -h
+    usage: prog.py [-h] [-v] power power
+
+    positional arguments:
+      power
+
+    optional arguments:
+      -h, --help       show this help message and exit
+      -v, --verbosity
+    $ python3 prog.py 4 2
+    16
+    $ python3 prog.py 4 2 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -vv
+    4 to the power 2 equals 16
+    $ python3 prog.py 4 2 -vvv
+    4 to the power 2 equals 16
+
+We introduced yet another keyword argument, ``nargs``. It helps us specify
+how many arguments are expected for a given command line option, which is
+2 in this case.
+
+As you can see, the help text could be a little better than what it is
+(``usage: prog.py [-h] [-v {0,1,2}] power power``). Let's fix it::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    parser.add_argument("-v", "--verbosity", action="count", default=0)
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+    if args.verbosity >= 2:
+        print("{} to the power {} equals {}".format(args.x, args.y, answer))
+    elif args.verbosity >= 1:
+        print("pow({}, {}) == {}".format(args.x, args.y, answer))
+    else:
+        print(answer)
+
+Output::
+
+    $ python3 prog.py
+    usage: prog.py [-h] [-v] x y
+    prog.py: error: the following arguments are required: x, y
+    $ python3 prog.py -h
+    usage: prog.py [-h] [-v] x y
+
+    positional arguments:
+      x                the 'x' in x^y
+      y                the 'y' in x^y
+
+    optional arguments:
+      -h, --help       show this help message and exit
+      -v, --verbosity
+    $ python3 prog.py 4 2 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -v 1
+    usage: prog.py [-h] [-v] x y
+    prog.py: error: argument -v/--verbosity: ignored explicit argument '1'
+
+That looks much better, and the last example serves as a reminder that this
+is pretty much a flag, removing the need to provide values.
+
+Notice that so far we've been using verbosity level to *change* the text
+that gets displayed. The following example instead uses verbosity level
+to display *more* text instead::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    parser.add_argument("-v", "--verbosity", action="count", default=0)
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+    if args.verbosity >= 2:
+        print("Running '{}'".format(__file__))
+    if args.verbosity >= 1:
+        print("pow({}, {}) == ".format(args.x, args.y), end="")
+    print(answer)
+
+Output:
+
+    $ python3 prog.py 4 2
+    16
+    $ python3 prog.py 4 2 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -vv
+    Running 'prog.py'
+    pow(4, 2) == 16
+
+So far, we have been working with two methods of an
+:class:`argparse.ArgumentParser` instance. Let's introduce a third one,
+``add_mutually_exclusive_group``. It allows for us to specify options that
+conflict with each other. Let's also change the rest of the program make the
+new functionality makes more sense::
+
+    import argparse
+
+    parser = argparse.ArgumentParser()
+    group = parser.add_mutually_exclusive_group()
+    group.add_argument("-v", "--verbose", action="store_true")
+    group.add_argument("-q", "--quiet", action="store_true")
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+
+    if args.quiet:
+        print(answer)
+    elif args.verbose:
+        print("{} to the power {} equals {}".format(args.x, args.y, answer))
+    else:
+        print("pow({}, {}) == {}".format(args.x, args.y, answer))
+
+Our program is now simpler, and we've lost some functionality for the sake of
+demonstration. Anyways, here's the output::
+
+    $ python3 prog.py 4 2
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -q
+    16
+    $ python3 prog.py 4 2 -v
+    4 to the power 2 equals 16
+    $ python3 prog.py 4 2 -vq
+    usage: prog.py [-h] [-v | -q] x y
+    prog.py: error: argument -q/--quiet: not allowed with argument -v/--verbose
+    $ python3 prog.py 4 2 -v --quiet
+    usage: prog.py [-h] [-v | -q] x y
+    prog.py: error: argument -q/--quiet: not allowed with argument -v/--verbose
+
+That should be easy to follow. I've added that last output so you can see the
+sort of flexibility you get, i.e. mixing long form options with short form
+ones.
+
+Before we conclude, you probably want to tell your users the main purpose of
+your program, just in case they don't know::
+
+    import argparse
+
+    parser = argparse.ArgumentParser(description="calculate X to the power of Y")
+    group = parser.add_mutually_exclusive_group()
+    group.add_argument("-v", "--verbose", action="store_true")
+    group.add_argument("-q", "--quiet", action="store_true")
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+
+    if args.quiet:
+        print(answer)
+    elif args.verbose:
+        print("{} to the power {} equals {}".format(args.x, args.y, answer))
+    else:
+        print("pow({}, {}) == {}".format(args.x, args.y, answer))
+
+Which outputs::
+
+    $ python3 prog.py --help
+    usage: prog.py [-h] [-v | -q] x y
+
+    calculate X to the power of Y
+
+    positional arguments:
+      x              the 'x' in x^y
+      y              the 'y' in x^y
+
+    optional arguments:
+      -h, --help     show this help message and exit
+      -v, --verbose
+      -q, --quiet
+
+Note that slight difference in the usage text. Note the `[-v | -q]`, which
+tells us that we can either use `-v` or `-q`, but not both at the same time.
+
+Conclusion
+==========
+
+There's lots more to the module of course, things like customising
+the help message, or simply disabling its getting generated.
+You can also force optional arguments to be required, or even change the
+character used to denote them (e.g. ``+v`` instead of ``-v``).
+
+Have a look at the API docs.
+They are quite detailed and thorough, and full of examples. I hope that
+having gone through this tutorial, you will easily digest them
+without feeling overwhelmed.
diff --git a/Doc/howto/index.rst b/Doc/howto/index.rst
--- a/Doc/howto/index.rst
+++ b/Doc/howto/index.rst
@@ -27,4 +27,5 @@
    unicode.rst
    urllib2.rst
    webservers.rst
+   argparse.rst
 
diff --git a/Doc/library/argparse.rst b/Doc/library/argparse.rst
--- a/Doc/library/argparse.rst
+++ b/Doc/library/argparse.rst
@@ -10,6 +10,12 @@
 
 **Source code:** :source:`Lib/argparse.py`
 
+.. sidebar:: Tutorial
+
+   This page contains the API reference information. For a more gentle
+   introduction to Python command line parsing, have a look at the
+   :ref:`Basic Tutorial <argparse-howto>`.
+
 --------------
 
 The :mod:`argparse` module makes it easy to write user-friendly command-line

From report at bugs.python.org  Mon Mar 19 15:48:35 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 19 Mar 2012 14:48:35 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <CAA77j2B-RSMQQFJv95szwGgdot_oXp_ZoCPH3=J7x0=EPvO4hg@mail.gmail.com>
Message-ID: <CAA77j2Auy7tdRDTkXRRhhGHiRRCiQDA1Q4kRifwj9JUHQ=OWSg@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

Fixing a markup error. Sorry for the noise.

----------
Added file: http://bugs.python.org/file24942/argparse_howto3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14034>
_______________________________________
-------------- next part --------------
diff --git a/Doc/howto/argparse.rst b/Doc/howto/argparse.rst
new file mode 100644
--- /dev/null
+++ b/Doc/howto/argparse.rst
@@ -0,0 +1,755 @@
+*****************************
+Command Line Interface HOWTO
+*****************************
+
+:author: Tshepang Lekhonkhobe <tshepang at gmail.com>
+
+.. _argparse-howto:
+
+This is intended to be a gentle introduction to command line parsing
+using :mod:`argparse` module, the recommended module for such a purpose
+in Python. Please pay careful attention to the code and its output. All of
+it was carefully selected for its instructive value.
+
+.. note::
+
+   There's two other modules that fulfill the same task, namely
+   :mod:`getopt` (an equivalent for :c:func:`getopt` from the C
+   language) and the deprecated :mod:`optparse`.
+
+
+Concepts
+========
+
+Let's show the sort of functionality that we are going to explore in this
+introductory tutorial by making use of the :command:`ls` command::
+
+
+    $ ls
+    cpython  devguide  prog.py  pypy  rm-unused-function.patch
+    $ ls pypy
+    ctypes_configure  demo  dotviewer  include  lib_pypy  lib-python ...
+    $ ls -l
+    total 20
+    drwxr-xr-x 19 wena wena 4096 Feb 18 18:51 cpython
+    drwxr-xr-x  4 wena wena 4096 Feb  8 12:04 devguide
+    -rwxr-xr-x  1 wena wena  535 Feb 19 00:05 prog.py
+    drwxr-xr-x 14 wena wena 4096 Feb  7 00:59 pypy
+    -rw-r--r--  1 wena wena  741 Feb 18 01:01 rm-unused-function.patch
+    $ ls --help
+    Usage: ls [OPTION]... [FILE]...
+    List information about the FILEs (the current directory by default).
+    Sort entries alphabetically if none of -cftuvSUX nor --sort is specified.
+    ...
+
+A few concepts we can learn from the four commands:
+
+#. The :command:`ls` command is useful when run without any options at all. It defaults
+   to displaying the contents of the current directory.
+
+#. If we want beyond what it provides by default, we tell it a bit more. In
+   this case, we want it to display a different directory, ``pypy``.
+   What we did is specify what is known as a positional argument. It's named so
+   because the program should know what to do with the value, solely based on
+   where it appears on the command line. This concept is more relevant
+   to a command like :command:`cp`, whose most basic usage is ``cp SRC DEST``.
+   The first position is *what you want copied,* and the second
+   position is *where you want it copied to*.
+
+#. Now, say we want to change behaviour of the program. In our example,
+   we display more info for each file instead of just showing the file names.
+   The ``-l`` in that case is known as an optional argument.
+
+#. That's a snippet of the help text. It's very useful in that you can
+   come across a program you have never used before, and can figure out
+   how it works simply by reading it's help text.
+
+
+The basics
+==========
+
+Let us start with a very simple example which does (almost) nothing::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.parse_args()
+
+Following is a result of running the code::
+
+    $ python3 prog.py 
+    $ python3 prog.py --help
+    usage: prog.py [-h]
+
+    optional arguments:
+      -h, --help  show this help message and exit
+    $ python3 prog.py --verbose
+    usage: prog.py [-h]
+    prog.py: error: unrecognized arguments: --verbose
+    $ python3 prog.py foo
+    usage: prog.py [-h]
+    prog.py: error: unrecognized arguments: foo
+
+Here is what is happening:
+
+* Running the script without any options results in nothing displayed to
+  stdout. Not so useful.
+
+* The second one starts to display the usefulness of the :mod:`argparse`
+  module. We have done almost nothing, but already we get a nice help message.
+
+* The ``--help`` option, which can also be shortened to ``-h``, is the only
+  option we get for free (i.e. no need to specify it). Specifying anything
+  else results in an error. But even then, we do get a useful usage message,
+  also for free.
+
+
+Introducing Positional arguments
+================================
+
+An example::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("echo")
+    args = parser.parse_args()
+    print(args.echo)
+
+And running the code::
+
+    $ python3 prog.py
+    usage: prog.py [-h] echo
+    prog.py: error: the following arguments are required: echo
+    $ python3 prog.py --help
+    usage: prog.py [-h] echo
+
+    positional arguments:
+      echo
+
+    optional arguments:
+      -h, --help  show this help message and exit
+    $ python3 prog.py foo
+    foo
+
+Here is what's happening:
+
+#. We've added :meth:`add_argument` method, which is what we use to specify
+   which command line options the program is willing to accept. In this case,
+   I've named it ``echo`` so that it's in line with its function.
+
+#. Calling our program now requires us to specify an option.
+
+#. Also, the :meth:`parse_args` method actually returns some data from the
+   options specified, in this case, ``echo``. Note that the variable is some
+   form of 'magic' that :mod:`argparse` performs for free (i.e. no need to
+   specify which variable that value is stored in). Note also that it's
+   name matches the string argument given to the method, ``echo``.
+
+Note however that, although the help display looks nice and all, it currently
+is not as helpful as it can be. For example we see that we got ``echo`` as a
+positional argument, but we don't know what it does, other than by guessing or
+by reading the source code. So, let's make it a bit more useful::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("echo", help="echo the string you use here")
+    args = parser.parse_args()
+    print(args.echo)
+
+And we get::
+
+    $ python3 prog.py -h
+    usage: prog.py [-h] echo
+
+    positional arguments:
+      echo        echo the string you use here
+
+    optional arguments:
+      -h, --help  show this help message and exit
+
+Now, how about doing something even more useful::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", help="display a square of a given number")
+    args = parser.parse_args()
+    print(pow(args.square, 2))
+
+Following is a result of running the code::
+
+    $ python3 prog.py 4
+    Traceback (most recent call last):
+      File "prog.py", line 5, in <module>
+        print(pow(args.square, 2))
+    TypeError: unsupported operand type(s) for ** or pow(): 'str' and 'int'
+
+That didn't go so well. That's because :mod:`argparse` treats the options we
+give it as strings, unless we tell it otherwise and the :func:`pow` function
+doesn't accept strings as arguments. So, let's tell
+:mod:`argparse` to treat that input as an integer::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", help="display a square of a given number",
+                        type=int)
+    args = parser.parse_args()
+    print(pow(args.square, 2))
+
+Following is a result of running the code::
+
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py four
+    usage: prog.py [-h] square
+    prog.py: error: argument square: invalid int value: 'four'
+
+That went well. The program now even helpfully quits on bad illegal input
+before proceeding.
+
+
+Introducing Optional arguments
+==============================
+
+So far we, have been playing with positional arguments. Let us
+have a look on how to add optional ones::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("--verbosity", help="increase output verbosity")
+    args = parser.parse_args()
+    if args.verbosity:
+        print("verbosity turned on")
+
+And the output::
+
+    $ python3 prog.py --verbosity 1
+    verbosity turned on
+    $ python3 prog.py
+    $ python3 prog.py --help
+    usage: prog.py [-h] [--verbosity VERBOSITY]
+
+    optional arguments:
+      -h, --help            show this help message and exit
+      --verbosity VERBOSITY
+                            increase output verbosity
+    $ python3 prog.py --verbosity 
+    usage: prog.py [-h] [--verbosity VERBOSITY]
+    prog.py: error: argument --verbosity: expected one argument
+
+Here is what is happening:
+
+#. The program is written so as to display something when ``--verbosity`` is
+   specified and display nothing when not.
+
+#. To show that the option is actually optional, there is no error when running
+   the program without it. Note that by default, if an optional argument isn't
+   used, the relevant variable, in this case :data:`args.verbosity`, is
+   given ``None`` as a value, which is the reason it fails the truth
+   test of the :keyword:`if` statement.
+
+#. The help message is a bit different.
+
+#. When using the ``--verbosity`` option, one must also specify some value, any
+   value.
+
+The above example accepts arbitrary integer values for ``--verbosity``, but for
+our simple program, only two values are actually useful, ``True`` or ``False``.
+Let's modify the code accordingly::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("--verbose", help="increase output verbosity",
+                        action="store_true")
+    args = parser.parse_args()
+    if args.verbose:
+        print("verbosity turned on")
+
+And the output::
+
+    $ python3 prog.py --verbose
+    verbosity turned on
+    $  python3 prog.py --verbose 1
+    usage: prog.py [-h] [--verbose]
+    prog.py: error: unrecognized arguments: 1
+    $ python3 prog.py --help
+    usage: prog.py [-h] [--verbose]
+
+    optional arguments:
+      -h, --help  show this help message and exit
+      --verbose   increase output verbosity
+
+Here is what is happening:
+
+#. The option is now more of a flag than something that requires a value.
+   We even changed the name of the option to match that idea.
+   Note that we now specify a new keyword, ``action``, and give it the value
+   "store_true". This means that, if the option is specified, assign the value
+   ``True`` to :data:`args.verbose` ``True``. Not specifying it implies
+   ``False``.
+
+#. It complains when you specify a value, in true spirit of what flags
+   actually are.
+
+#. Notice the different help text.
+
+If you are familiar with command line usage, you will notice that I haven't yet
+touched on the topic of short versions of the options. It's quite simple::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("-v", "--verbose", help="increase output verbosity",
+                        action="store_true")
+    args = parser.parse_args()
+    if args.verbose:
+        print("verbosity turned on")
+
+And here goes::
+
+    $ python3 prog.py -v
+    verbosity turned on
+    $ python3 prog.py --help
+    usage: prog.py [-h] [-v]
+
+    optional arguments:
+      -h, --help     show this help message and exit
+      -v, --verbose  increase output verbosity
+
+Note that the new ability is also reflected in the help text.
+
+
+Combining Positional and Optional arguments
+===========================================
+
+Our program keeps growing in complexity::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbose", action="store_true",
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbose:
+        print("the square of {} equals {}".format(args.square, answer))
+    else:
+        print(answer)
+
+And now the output::
+
+    $ python3 prog.py
+    usage: prog.py [-h] [-v] square
+    prog.py: error: the following arguments are required: square
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py 4 --verbose
+    the square of 4 equals 16
+    $ python3 prog.py --verbose 4
+    the square of 4 equals 16
+
+* We've brought back a positional argument, hence the complaint.
+
+* As for the fourth output, note that the order does not matter.
+
+How about we give this program of ours back the ability to have
+multiple verbosity values, and actually get to use them::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", type=int,
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity == 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity == 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+    
+And the output::
+
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py 4 -v
+    usage: prog.py [-h] [-v VERBOSITY] square
+    prog.py: error: argument -v/--verbosity: expected one argument
+    $ python3 prog.py 4 -v 1
+    pow(4, 2) == 16
+    $ python3 prog.py 4 -v 2
+    the square of 4 equals 16
+    $ python3 prog.py 4 -v 3
+    16
+
+These all look good except the last one, which exposes a bug in our program.
+Let's fix it by restricting the values the ``--verbosity`` option can accept::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", type=int, choices=[0, 1, 2],
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity == 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity == 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+And the output::
+
+    $ python3 prog.py 4 -v 3
+    usage: prog.py [-h] [-v {0,1,2}] square
+    prog.py: error: argument -v/--verbosity: invalid choice: 3 (choose from 0, 1, 2)
+    $ python3 prog.py 4 -h
+    usage: prog.py [-h] [-v {0,1,2}] square
+
+    positional arguments:
+      square                display a square of a given number
+
+    optional arguments:
+      -h, --help            show this help message and exit
+      -v {0,1,2}, --verbosity {0,1,2}
+                            increase output verbosity
+
+Note that the change also reflects both in the error message as well as the
+help string.
+
+Now, let's use a different approach of playing with verbosity, which is pretty
+common. It also matches the way the CPython executable handles its own
+verbosity argument (check the output of `python --help`)::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", action="count",
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity == 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity == 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+We have introduced another action, "count". What it does is keep a count of
+optional arguments::
+
+    $ python3 prog.py 4 -v 1
+    usage: prog.py [-h] [-v] square
+    prog.py: error: unrecognized arguments: 1
+    $ python3 prog.py 4 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 -vv
+    the square of 4 equals 16
+    $ python3 prog.py 4
+    16
+    $ python3 prog.py 4 --verbosity --verbosity
+    the square of 4 equals 16
+    $ python3 prog.py 4 -h
+    usage: prog.py [-h] [-v] square
+
+    positional arguments:
+      square           display a square of a given number
+
+    optional arguments:
+      -h, --help       show this help message and exit
+      -v, --verbosity  increase output verbosity
+    $ python3 prog.py 4 -vvv
+    16
+
+* Yes, it's now more of a flag (similar tp `action="store_true"`) in the
+  previous version of our script. That should explain the complaint.
+* See what I mean that it behaves similar to "store_true" action?
+* Now here's a demonstration of what the "count" action gives. You've probably
+  seen this sort of usage before.
+* And, just like the "store_true" action, if you don't specify the `-v` flag,
+  that flag is considered to have ``None`` value.
+* As should be expected, specifying the long form of the flag, we should get
+  the same output.
+* Sadly, our help output isn't very informative on the new ability our script
+  has acquired, but that can always be fixed by improving the documentation for
+  out script (e.g. via the `help` keyword argument).
+* That's a bug in our program.
+
+Let's fix::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", action="count",
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity >= 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity >= 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+And this is what it gives::
+
+    $ python3 prog.py 4 -vvv
+    the square of 4 equals 16
+    $ python3 prog.py 4 -vvvv
+    the square of 4 equals 16
+    $ python3 prog.py 4
+    Traceback (most recent call last):
+      File "prog.py", line 11, in <module>
+        if args.verbosity >= 2:
+    TypeError: unorderable types: NoneType() >= int()
+
+* First output went as well, and fixes the bug we had before. That is, to avoid
+  such problems, do `>=` checks in future, not `==`.
+* Third output not so good
+
+Let's fix that bug::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("square", type=int,
+                        help="display a square of a given number")
+    parser.add_argument("-v", "--verbosity", action="count", default=0,
+                        help="increase output verbosity")
+    args = parser.parse_args()
+    answer = pow(args.square, 2)
+    if args.verbosity >= 2:
+        print("the square of {} equals {}".format(args.square, answer))
+    elif args.verbosity >= 1:
+        print("pow({}, 2) == {}".format(args.square, answer))
+    else:
+        print(answer)
+
+We've just introduced yet another keyword, `default`. We've set it to `0` in
+order to make it comparable to the other int values. Remember that by
+default, if an optional argument isn't specified, it gets the `None` value, and
+that cannot be compared to an int value (hence the :exc:`TypeError` exception).
+
+And::
+
+    $ python3 prog.py 4
+    16
+
+You can go quite far just with what we've learned so, and we have only
+scratched the surface. The :mod:`argparse` module is excessively powerful, and
+we'll explore a bit more of it before we end this tutorial.
+
+
+Getting a little more advanced
+==============================
+
+What if we wanted to expand our tiny program to perform other powers, not
+just 2::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("power", type=int, nargs=2)
+    parser.add_argument("-v", "--verbosity", action="count", default=0)
+    args = parser.parse_args()
+    answer = pow(args.power[0], args.power[1])
+    if args.verbosity >= 2:
+        print("{} to the power {} equals {}".format(args.power[0], args.power[1], answer))
+    elif args.verbosity >= 1:
+        print("pow({}, {}) == {}".format(args.power[0], args.power[1], answer))
+    else:
+        print(answer)
+
+Output::
+
+    $ python3 prog.py
+    usage: prog.py [-h] [-v] power power
+    prog.py: error: the following arguments are required: power
+    $ python3 prog.py -h
+    usage: prog.py [-h] [-v] power power
+
+    positional arguments:
+      power
+
+    optional arguments:
+      -h, --help       show this help message and exit
+      -v, --verbosity
+    $ python3 prog.py 4 2
+    16
+    $ python3 prog.py 4 2 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -vv
+    4 to the power 2 equals 16
+    $ python3 prog.py 4 2 -vvv
+    4 to the power 2 equals 16
+
+We introduced yet another keyword argument, ``nargs``. It helps us specify
+how many arguments are expected for a given command line option, which is
+2 in this case.
+
+As you can see, the help text could be a little better than what it is
+(``usage: prog.py [-h] [-v {0,1,2}] power power``). Let's fix it::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    parser.add_argument("-v", "--verbosity", action="count", default=0)
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+    if args.verbosity >= 2:
+        print("{} to the power {} equals {}".format(args.x, args.y, answer))
+    elif args.verbosity >= 1:
+        print("pow({}, {}) == {}".format(args.x, args.y, answer))
+    else:
+        print(answer)
+
+Output::
+
+    $ python3 prog.py
+    usage: prog.py [-h] [-v] x y
+    prog.py: error: the following arguments are required: x, y
+    $ python3 prog.py -h
+    usage: prog.py [-h] [-v] x y
+
+    positional arguments:
+      x                the 'x' in x^y
+      y                the 'y' in x^y
+
+    optional arguments:
+      -h, --help       show this help message and exit
+      -v, --verbosity
+    $ python3 prog.py 4 2 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -v 1
+    usage: prog.py [-h] [-v] x y
+    prog.py: error: argument -v/--verbosity: ignored explicit argument '1'
+
+That looks much better, and the last example serves as a reminder that this
+is pretty much a flag, removing the need to provide values.
+
+Notice that so far we've been using verbosity level to *change* the text
+that gets displayed. The following example instead uses verbosity level
+to display *more* text instead::
+
+    import argparse
+    parser = argparse.ArgumentParser()
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    parser.add_argument("-v", "--verbosity", action="count", default=0)
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+    if args.verbosity >= 2:
+        print("Running '{}'".format(__file__))
+    if args.verbosity >= 1:
+        print("pow({}, {}) == ".format(args.x, args.y), end="")
+    print(answer)
+
+Output::
+
+    $ python3 prog.py 4 2
+    16
+    $ python3 prog.py 4 2 -v
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -vv
+    Running 'prog.py'
+    pow(4, 2) == 16
+
+So far, we have been working with two methods of an
+:class:`argparse.ArgumentParser` instance. Let's introduce a third one,
+``add_mutually_exclusive_group``. It allows for us to specify options that
+conflict with each other. Let's also change the rest of the program make the
+new functionality makes more sense::
+
+    import argparse
+
+    parser = argparse.ArgumentParser()
+    group = parser.add_mutually_exclusive_group()
+    group.add_argument("-v", "--verbose", action="store_true")
+    group.add_argument("-q", "--quiet", action="store_true")
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+
+    if args.quiet:
+        print(answer)
+    elif args.verbose:
+        print("{} to the power {} equals {}".format(args.x, args.y, answer))
+    else:
+        print("pow({}, {}) == {}".format(args.x, args.y, answer))
+
+Our program is now simpler, and we've lost some functionality for the sake of
+demonstration. Anyways, here's the output::
+
+    $ python3 prog.py 4 2
+    pow(4, 2) == 16
+    $ python3 prog.py 4 2 -q
+    16
+    $ python3 prog.py 4 2 -v
+    4 to the power 2 equals 16
+    $ python3 prog.py 4 2 -vq
+    usage: prog.py [-h] [-v | -q] x y
+    prog.py: error: argument -q/--quiet: not allowed with argument -v/--verbose
+    $ python3 prog.py 4 2 -v --quiet
+    usage: prog.py [-h] [-v | -q] x y
+    prog.py: error: argument -q/--quiet: not allowed with argument -v/--verbose
+
+That should be easy to follow. I've added that last output so you can see the
+sort of flexibility you get, i.e. mixing long form options with short form
+ones.
+
+Before we conclude, you probably want to tell your users the main purpose of
+your program, just in case they don't know::
+
+    import argparse
+
+    parser = argparse.ArgumentParser(description="calculate X to the power of Y")
+    group = parser.add_mutually_exclusive_group()
+    group.add_argument("-v", "--verbose", action="store_true")
+    group.add_argument("-q", "--quiet", action="store_true")
+    parser.add_argument("x", type=int, help="the 'x' in x^y")
+    parser.add_argument("y", type=int, help="the 'y' in x^y")
+    args = parser.parse_args()
+    answer = pow(args.x, args.y)
+
+    if args.quiet:
+        print(answer)
+    elif args.verbose:
+        print("{} to the power {} equals {}".format(args.x, args.y, answer))
+    else:
+        print("pow({}, {}) == {}".format(args.x, args.y, answer))
+
+Which outputs::
+
+    $ python3 prog.py --help
+    usage: prog.py [-h] [-v | -q] x y
+
+    calculate X to the power of Y
+
+    positional arguments:
+      x              the 'x' in x^y
+      y              the 'y' in x^y
+
+    optional arguments:
+      -h, --help     show this help message and exit
+      -v, --verbose
+      -q, --quiet
+
+Note that slight difference in the usage text. Note the `[-v | -q]`, which
+tells us that we can either use `-v` or `-q`, but not both at the same time.
+
+Conclusion
+==========
+
+There's lots more to the module of course, things like customising
+the help message, or simply disabling its getting generated.
+You can also force optional arguments to be required, or even change the
+character used to denote them (e.g. ``+v`` instead of ``-v``).
+
+Have a look at the API docs.
+They are quite detailed and thorough, and full of examples. I hope that
+having gone through this tutorial, you will easily digest them
+without feeling overwhelmed.
diff --git a/Doc/howto/index.rst b/Doc/howto/index.rst
--- a/Doc/howto/index.rst
+++ b/Doc/howto/index.rst
@@ -27,4 +27,5 @@
    unicode.rst
    urllib2.rst
    webservers.rst
+   argparse.rst
 
diff --git a/Doc/library/argparse.rst b/Doc/library/argparse.rst
--- a/Doc/library/argparse.rst
+++ b/Doc/library/argparse.rst
@@ -10,6 +10,12 @@
 
 **Source code:** :source:`Lib/argparse.py`
 
+.. sidebar:: Tutorial
+
+   This page contains the API reference information. For a more gentle
+   introduction to Python command line parsing, have a look at the
+   :ref:`Basic Tutorial <argparse-howto>`.
+
 --------------
 
 The :mod:`argparse` module makes it easy to write user-friendly command-line

From report at bugs.python.org  Mon Mar 19 15:49:07 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 19 Mar 2012 14:49:07 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1332168547.13.0.614792684601.issue14034@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file24941/argparse_howto3.patch

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

From report at bugs.python.org  Mon Mar 19 16:31:44 2012
From: report at bugs.python.org (Jay Deiman)
Date: Mon, 19 Mar 2012 15:31:44 +0000
Subject: [docs] [issue14338] Document how to forward POST data on redirects
In-Reply-To: <1331929501.86.0.889924099512.issue14338@psf.upfronthosting.co.za>
Message-ID: <1332171104.34.0.947824621796.issue14338@psf.upfronthosting.co.za>


Jay Deiman <admin at splitstreams.com> added the comment:

I actually just worked around this issue in my library to do specifically what I needed it to do, which was an automatic redirect POST with data.  As far as general recipes are concerned, anyone could just follow what I did in my library at:

https://github.com/crustymonkey/py-sonic or
http://pypi.python.org/pypi/py-sonic

All I did was just subclass HTTPRedirectHandler and essentially add my patch.

----------

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

From report at bugs.python.org  Wed Mar 21 12:06:47 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 21 Mar 2012 11:06:47 +0000
Subject: [docs] [issue14379] Several traceback docs improvements
Message-ID: <1332328007.08.0.704590425302.issue14379@psf.upfronthosting.co.za>


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

Some notes about current `traceback` documentation:
http://docs.python.org/library/traceback.html

1. It needs a mentioning that traceback module works with traceback objects and frame objects

2. Functions that work with frames should probably be grouped together

3. Docs for frame function should include info about where to get frames (e.g. 
http://docs.python.org/library/inspect.html#the-interpreter-stack)

4. There is no traceback object description, which should be at http://docs.python.org/library/sys.html#sys.exc_info

----------
assignee: docs at python
components: Documentation
messages: 156486
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Several traceback docs improvements

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

From report at bugs.python.org  Wed Mar 21 12:56:40 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 21 Mar 2012 11:56:40 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1332331000.39.0.0545296777394.issue5066@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar 21 18:11:14 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 21 Mar 2012 17:11:14 +0000
Subject: [docs] [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1332349874.4.0.00531363480784.issue7057@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From report at bugs.python.org  Fri Mar 23 10:01:35 2012
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 23 Mar 2012 09:01:35 +0000
Subject: [docs] [issue14393] Incorporate Guide to Magic Methods?
Message-ID: <1332493295.71.0.816804721304.issue14393@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

Should we perhaps ask if we can include https://github.com/RafeKettler/magicmethods in the official docs? It seems nice (and now ranks higher on Google than the official docs...).

----------
assignee: docs at python
components: Documentation
messages: 156639
nosy: djc, docs at python
priority: normal
severity: normal
status: open
title: Incorporate Guide to Magic Methods?

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

From report at bugs.python.org  Fri Mar 23 10:51:11 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 23 Mar 2012 09:51:11 +0000
Subject: [docs] [issue14394] missing links on performance claims of cdecimal
Message-ID: <1332496271.62.0.623566153633.issue14394@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

Looking at "What's New" section for cdecimal [1], I see this claim:

"Performance gains range from 12x for database applications to 80x for numerically intensive applications..."

But there's no link on the benchmark code.

[1] http://hg.python.org/cpython/file/9ceac471bd8c/Doc/whatsnew/3.3.rst#l599

----------
assignee: docs at python
components: Documentation
messages: 156640
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: missing links on performance claims of cdecimal
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar 23 10:54:33 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 23 Mar 2012 09:54:33 +0000
Subject: [docs] [issue14394] missing links on performance claims of cdecimal
In-Reply-To: <1332496271.62.0.623566153633.issue14394@psf.upfronthosting.co.za>
Message-ID: <1332496473.19.0.187572678229.issue14394@psf.upfronthosting.co.za>


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

It would be nice to have access to the benchmarks, yes, but I hope our users have enough trust in Python to believe this "claim" as it is.

----------
nosy: +georg.brandl
priority: normal -> low
type:  -> enhancement

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

From report at bugs.python.org  Fri Mar 23 10:59:21 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 23 Mar 2012 09:59:21 +0000
Subject: [docs] [issue14394] missing links on performance claims of cdecimal
In-Reply-To: <1332496473.19.0.187572678229.issue14394@psf.upfronthosting.co.za>
Message-ID: <CAA77j2B2ZbXv7QnPqVPGSTRW+cJcST8S9+CNG+Rdhj4DQK5vvg@mail.gmail.com>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

> Georg Brandl <georg at python.org> added the comment:
>
> It would be nice to have access to the benchmarks, yes, but I hope our users have enough trust in Python to believe this "claim" as it is.

Well, there's also curiosity. For example to find out what is "pi" and
"telco", and having to go through that massive issue 7652 to find out
is a bit much.

----------

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

From report at bugs.python.org  Fri Mar 23 13:14:51 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 23 Mar 2012 12:14:51 +0000
Subject: [docs] [issue14349] The documentation of 'dis' doesn't
	describe	MAKE_FUNCTION correctly
In-Reply-To: <1331996886.47.0.46755295506.issue14349@psf.upfronthosting.co.za>
Message-ID: <1332504891.06.0.00859601507922.issue14349@psf.upfronthosting.co.za>


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

Patch attached.

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

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

From report at bugs.python.org  Fri Mar 23 15:54:50 2012
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 23 Mar 2012 14:54:50 +0000
Subject: [docs] [issue14393] Incorporate Guide to Magic Methods?
In-Reply-To: <1332493295.71.0.816804721304.issue14393@psf.upfronthosting.co.za>
Message-ID: <1332514490.56.0.290358130867.issue14393@psf.upfronthosting.co.za>


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

Someone would have to 1) determine if this a good idea 2) ask the author 3) actually perform the integration (that is determine how this would replace/complement things in reference/*).

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

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

From report at bugs.python.org  Fri Mar 23 20:16:34 2012
From: report at bugs.python.org (David Manowitz)
Date: Fri, 23 Mar 2012 19:16:34 +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: <1332530194.28.0.545044730007.issue6634@psf.upfronthosting.co.za>


David Manowitz <david.manowitz at gmail.com> added the comment:

I don't see why this should be considered acceptable behavior.  Why don't threads have their own ThreadExit exception, rather than overloading the use, and therefore, the meaning, of the SystemExit exception?  As indicated by their names, sys.exit and the SystemExit exception should *only* be used to exit the entire system, not just a thread!

----------
components: +Library (Lib)
nosy: +David.Manowitz

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

From report at bugs.python.org  Fri Mar 23 20:48:17 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 23 Mar 2012 19:48:17 +0000
Subject: [docs] [issue14394] missing links on performance claims of cdecimal
In-Reply-To: <1332496271.62.0.623566153633.issue14394@psf.upfronthosting.co.za>
Message-ID: <1332532097.33.0.820119695029.issue14394@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> But there's no link on the benchmark code.

I don't know if external links are appropriate in whatsnew, but this
is it:


http://www.bytereef.org/mpdecimal/quickstart.html

----------
nosy: +skrah

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

From report at bugs.python.org  Fri Mar 23 23:38:18 2012
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 23 Mar 2012 22:38:18 +0000
Subject: [docs] [issue14318] clarify "may not" in time.steady docs
In-Reply-To: <1331829668.71.0.947018206764.issue14318@psf.upfronthosting.co.za>
Message-ID: <1332542298.52.0.507304960878.issue14318@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

(1)  How does the user control (or even find out) which clock is used by time.steady()?

If the answer is time.steady(clock=QueryPerformanceCounter) then there is no need for strict=?, but then I'm not sure what the point of time.steady itself is.

I had been assuming that time.steady() relied on the best clock it could find, which shouldn't normally change on a specific machine, let alone within a single process.  In that case, exposing the actual clock (or its name) as an attribute seems better than a boolean "complain_if_my_machine_is_not_good_enough" parameter.


(2)  That fragment from the C++ standard suggests that "MAY NOT" ought to have been replaced by the unambiguous "MUST NOT".  I do not think that python should repeat the editorial error.

(3)  Even leaving aside the question of which clock is actually provided, I still prefer a change in wording.  My trailing paragraph might change with the API, but the rationale for:

"""Return elapsed seconds as a floating point number.  

The start time is undefined, so only differences between calls are meaningful.  steady() is the best clock for profiling response time, as opposed to CPU usage.
"""

includes:

"elapsed" ==> time since something, as opposed to absolute time.  

If practicality and efficiency weren't important, I would even suggest that the function return an opaque object that supported only ordering and subtraction (returning a timedelta).

There are enough time-related modules/classes/functions/etc that people *will* get confused; the name "steady" isn't obvious enough. Including the intended use case in the docstring gives people a fighting chance.

----------

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

From report at bugs.python.org  Sat Mar 24 00:40:31 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Mar 2012 23:40:31 +0000
Subject: [docs] [issue14318] clarify "may not" in time.steady docs
In-Reply-To: <1331829668.71.0.947018206764.issue14318@psf.upfronthosting.co.za>
Message-ID: <1332546031.69.0.263446826662.issue14318@psf.upfronthosting.co.za>


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

> (2)  That fragment from the C++ standard suggests that "MAY NOT" ought to have been replaced by the unambiguous "MUST NOT".

No. A program cannot deny the modification of system clock and time.steady() may use the system date.

----------

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

From report at bugs.python.org  Sat Mar 24 00:55:06 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 23 Mar 2012 23:55:06 +0000
Subject: [docs] [issue14394] missing links on performance claims of cdecimal
In-Reply-To: <1332496271.62.0.623566153633.issue14394@psf.upfronthosting.co.za>
Message-ID: <1332546906.24.0.051036340459.issue14394@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Instead of what's new, I think, linking the benchmarks in the docs could be helpful so that library users can find it they want to. I think, we have similar performance benchmark links at other places too.

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

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

From report at bugs.python.org  Sat Mar 24 11:47:52 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Mar 2012 10:47:52 +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: <1332586072.39.0.983087451163.issue6634@psf.upfronthosting.co.za>


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

> I don't see why this should be considered acceptable behavior.  Why
> don't threads have their own ThreadExit exception, rather than
> overloading the use, and therefore, the meaning, of the SystemExit
> exception?  As indicated by their names, sys.exit and the SystemExit
> exception should *only* be used to exit the entire system, not just a
> thread!

I agree the situation isn't optimal. However, fixing this would also break compatibility with any application that uses sys.exit() in a thread and expects it to exit the thread, not the whole process. So we're kind of stuck with it.

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

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

From report at bugs.python.org  Sat Mar 24 13:18:30 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Mar 2012 12:18:30 +0000
Subject: [docs] [issue14349] The documentation of 'dis' doesn't
	describe	MAKE_FUNCTION correctly
In-Reply-To: <1331996886.47.0.46755295506.issue14349@psf.upfronthosting.co.za>
Message-ID: <1332591510.77.0.844557423091.issue14349@psf.upfronthosting.co.za>


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

Looks good to me.

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

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

From report at bugs.python.org  Sat Mar 24 17:27:48 2012
From: report at bugs.python.org (Dionysios Kalofonos)
Date: Sat, 24 Mar 2012 16:27:48 +0000
Subject: [docs] [issue14400] Typo in cporting.rst
Message-ID: <1332606468.59.0.165889017465.issue14400@psf.upfronthosting.co.za>


New submission from Dionysios Kalofonos <peitemou at gmail.com>:

A typo (see attached file).

----------
assignee: docs at python
components: Documentation
files: typo.diff
keywords: patch
messages: 156700
nosy: dk, docs at python
priority: normal
severity: normal
status: open
title: Typo in cporting.rst
versions: Python 2.7
Added file: http://bugs.python.org/file25012/typo.diff

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

From report at bugs.python.org  Sat Mar 24 17:31:51 2012
From: report at bugs.python.org (Dionysios Kalofonos)
Date: Sat, 24 Mar 2012 16:31:51 +0000
Subject: [docs] [issue14400] Typo in cporting.rst
In-Reply-To: <1332606468.59.0.165889017465.issue14400@psf.upfronthosting.co.za>
Message-ID: <1332606711.03.0.294144821278.issue14400@psf.upfronthosting.co.za>


Changes by Dionysios Kalofonos <peitemou at gmail.com>:


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

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

From report at bugs.python.org  Sat Mar 24 17:38:37 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Mar 2012 16:38:37 +0000
Subject: [docs] [issue14400] Typo in cporting.rst
In-Reply-To: <1332606468.59.0.165889017465.issue14400@psf.upfronthosting.co.za>
Message-ID: <E1SBTz9-00054D-IG@dinsdale.python.org>


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

New changeset e0e28695f11b by Martin v. L?wis in branch '2.7':
Issue #14400: Fix typo.
http://hg.python.org/cpython/rev/e0e28695f11b

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

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

From report at bugs.python.org  Sat Mar 24 17:40:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Mar 2012 16:40:58 +0000
Subject: [docs] [issue14400] Typo in cporting.rst
In-Reply-To: <1332606468.59.0.165889017465.issue14400@psf.upfronthosting.co.za>
Message-ID: <E1SBU1R-0005SJ-5m@dinsdale.python.org>


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

New changeset ff679f22682b by Martin v. L?wis in branch '3.2':
Issue #14400: Fix typo.
http://hg.python.org/cpython/rev/ff679f22682b

----------

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

From report at bugs.python.org  Sat Mar 24 17:41:19 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 24 Mar 2012 16:41:19 +0000
Subject: [docs] [issue14400] Typo in cporting.rst
In-Reply-To: <1332606468.59.0.165889017465.issue14400@psf.upfronthosting.co.za>
Message-ID: <1332607279.76.0.704835077561.issue14400@psf.upfronthosting.co.za>


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

Thanks for the patch.

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

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

From report at bugs.python.org  Sat Mar 24 17:53:24 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Mar 2012 16:53:24 +0000
Subject: [docs] [issue14349] The documentation of 'dis' doesn't
	describe	MAKE_FUNCTION correctly
In-Reply-To: <1331996886.47.0.46755295506.issue14349@psf.upfronthosting.co.za>
Message-ID: <E1SBUDS-0006Y5-OY@dinsdale.python.org>


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

New changeset 242d3f8e8c50 by Eli Bendersky in branch 'default':
Issue #14349: Fix the doc of the MAKE_FUNCTION opcode in Doc/library/dis.rst to
http://hg.python.org/cpython/rev/242d3f8e8c50

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

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

From report at bugs.python.org  Sat Mar 24 17:54:09 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 24 Mar 2012 16:54:09 +0000
Subject: [docs] [issue14349] The documentation of 'dis' doesn't
	describe	MAKE_FUNCTION correctly
In-Reply-To: <1331996886.47.0.46755295506.issue14349@psf.upfronthosting.co.za>
Message-ID: <1332608049.31.0.952825162204.issue14349@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Mar 24 18:32:13 2012
From: report at bugs.python.org (Dionysios Kalofonos)
Date: Sat, 24 Mar 2012 17:32:13 +0000
Subject: [docs] [issue14401] Typos in curses.rst
Message-ID: <1332610333.54.0.189521557338.issue14401@psf.upfronthosting.co.za>


New submission from Dionysios Kalofonos <peitemou at gmail.com>:

Typos (see attached file).

----------
assignee: docs at python
components: Documentation
files: curses.diff
keywords: patch
messages: 156708
nosy: dk, docs at python
priority: normal
severity: normal
status: open
title: Typos in curses.rst
versions: Python 2.7, Python 3.1, Python 3.3
Added file: http://bugs.python.org/file25014/curses.diff

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

From report at bugs.python.org  Sun Mar 25 01:53:21 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 25 Mar 2012 00:53:21 +0000
Subject: [docs] [issue14391] misc TYPO in argparse.Action docstring
In-Reply-To: <1332483933.58.0.148840583117.issue14391@psf.upfronthosting.co.za>
Message-ID: <1332636801.55.0.725153572079.issue14391@psf.upfronthosting.co.za>


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

The patch, to an unspecified version of 2.7, changes 'str' to 'string', so I presume that is what you meant. The current repository code already says 'string' for 2.7, 3.2, and 3.3. This is what you should see in the current release candidates, including 2.7.3rc2

----------
assignee:  -> docs at python
components: +Documentation
nosy: +bethard, docs at python, terry.reedy
resolution:  -> out of date
stage:  -> patch review
status: open -> closed

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

From report at bugs.python.org  Sun Mar 25 03:24:13 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 25 Mar 2012 01:24:13 +0000
Subject: [docs] [issue14393] Incorporate Guide to Magic Methods?
In-Reply-To: <1332493295.71.0.816804721304.issue14393@psf.upfronthosting.co.za>
Message-ID: <1332638653.84.0.981881405053.issue14393@psf.upfronthosting.co.za>


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

If one searches for the informal name 'Python magic methods', RafeKettler's doc and 3. Data model ? Python v2.7.2 documentation come in 1,2. Given that the latter does not even contain the word 'magic', that means that is actually ranks higher in some real sense.

Suggestion: we should do a bit of SEO and add the informal name to that page (and 3.4). Then either might come in first for such inquiries.

If one searches for the official name 'Python special methods', then our Chapter 3 comes in first and RafeK's doc 9th. The 2.5.2 version of 3.4 Special method names comes in second. This points to a second problem with google rank: we have several versions of the docs indexed, so links to our docs are scattered among them, and none rank as high as they really should. 

I glanced at the git doc and it seems to largely duplicate the info in the docs already. So it should not be just 'incorporated'.

Dirkjan: if you have any specific suggestions for doc improvement, regardless of inspiration, please give them. If not, I think this issue should be closed.

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

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

From report at bugs.python.org  Sun Mar 25 08:43:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Mar 2012 06:43:48 +0000
Subject: [docs] [issue14401] Typos in curses.rst
In-Reply-To: <1332610333.54.0.189521557338.issue14401@psf.upfronthosting.co.za>
Message-ID: <E1SBhB5-00079Y-9f@dinsdale.python.org>


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

New changeset 87539f66156b by Georg Brandl in branch '2.7':
Closes #14401: fix typos in curses howto.
http://hg.python.org/cpython/rev/87539f66156b

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

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

From report at bugs.python.org  Sun Mar 25 08:43:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Mar 2012 06:43:58 +0000
Subject: [docs] [issue14401] Typos in curses.rst
In-Reply-To: <1332610333.54.0.189521557338.issue14401@psf.upfronthosting.co.za>
Message-ID: <E1SBhBF-00079u-1F@dinsdale.python.org>


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

New changeset a9129cf78cf0 by Georg Brandl in branch '3.2':
Closes #14401: fix typos in curses howto.
http://hg.python.org/cpython/rev/a9129cf78cf0

----------

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

From report at bugs.python.org  Sun Mar 25 09:30:09 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 25 Mar 2012 07:30:09 +0000
Subject: [docs] [issue11310] Document byte[s|array]() and
	byte[s|array](count) in	docstrings
In-Reply-To: <1298572139.69.0.327669775377.issue11310@psf.upfronthosting.co.za>
Message-ID: <1332660609.38.0.63748747385.issue11310@psf.upfronthosting.co.za>


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

I think you could just go ahead and commit your patch.  I don?t remember if the reST docs were changed recently-ish or if it?s still an open bug, so you may want to check that the new docstrings matches the doc.

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

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

From report at bugs.python.org  Sun Mar 25 19:21:52 2012
From: report at bugs.python.org (Xavier Morel)
Date: Sun, 25 Mar 2012 17:21:52 +0000
Subject: [docs] [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>
Message-ID: <1332696112.29.0.261773416585.issue13850@psf.upfronthosting.co.za>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

Had some time to play with this today, here's a draft matrix of actions and add_argument parameters which is pretty readable, but:

* It's incredibly not helpful for people who don't know argparse
* I tried adding effects descriptions in the cells instead of mere tick marks, the table becomes completely unreadable. I added a note directive below the table but it only lists a few really important/weird things, and it really won't scale beyond the current 3 items (which might already be too much)
* I completely removed the ``help`` action from the table as it's unlikely anyone will want to override it (and its row was completely blank)
* Hyperlinking and cross-linking (to the params, the actions, footnotes) would probably be a good idea, although it would definitely make the "raw text" (in-rst) 

I also tried my hand at formatting ``nargs``, but I don't see it as much clearer than http://docs.python.org/library/argparse.html#nargs without the examples, it's still just a mapping from a value to a behavior. I think the result would be just as good if the current ``nargs`` description was made into a definition list (in effect, it already is one emulated through an unordered list) and the examples were moved or removed.

----------
Added file: http://bugs.python.org/file25018/argparse-actions-matrix

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

From report at bugs.python.org  Sun Mar 25 19:23:30 2012
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 25 Mar 2012 17:23:30 +0000
Subject: [docs] [issue14405] Some "Other Resources" in the sidebar are
	hopelessly out	of date
Message-ID: <1332696210.48.0.175266420412.issue14405@psf.upfronthosting.co.za>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

The "Other Resources" section lists these resources:


Guido's Essays: out of date, the first is about 2.2, by the fifth, we're into Python 1.5.

New-style Classes: this means "new" as of 2.2, and the linked page begins, "Unfortunately, new-style classes have not yet been integrated into Python's standard documention."

These two links should be removed from the doc sidebar, they don't add much over the documentation itself.

----------
assignee: docs at python
components: Documentation
messages: 156761
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: Some "Other Resources" in the sidebar are hopelessly out of date

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

From report at bugs.python.org  Sun Mar 25 19:23:41 2012
From: report at bugs.python.org (Xavier Morel)
Date: Sun, 25 Mar 2012 17:23:41 +0000
Subject: [docs] [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>
Message-ID: <1332696221.67.0.751947492038.issue13850@psf.upfronthosting.co.za>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

completion for list item 4:

> although it would definitely make the "raw text" (in-rst) much harder to read compared to the current table (which can be used from the rst source without compiling)

----------

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

From report at bugs.python.org  Mon Mar 26 09:44:02 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 26 Mar 2012 07:44:02 +0000
Subject: [docs] [issue14410] argparse typo
Message-ID: <1332747842.06.0.97639285353.issue14410@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

typo fix

----------
assignee: docs at python
components: Documentation
files: typo.patch
keywords: patch
messages: 156801
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: argparse typo
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file25024/typo.patch

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

From report at bugs.python.org  Mon Mar 26 09:56:52 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 26 Mar 2012 07:56:52 +0000
Subject: [docs] [issue14411] outdatedness on rlcompleter docstring
Message-ID: <1332748612.71.0.338162063198.issue14411@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe <tshepang at gmail.com>:

This text appeared in Lib/rlcompleter.py in 1997, so ought to be outdated:

"This requires the latest extension to the readline module..."

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 156802
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: outdatedness on rlcompleter docstring
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Mar 26 12:34:31 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Mar 2012 10:34:31 +0000
Subject: [docs] [issue14379] Several traceback docs improvements
In-Reply-To: <1332328007.08.0.704590425302.issue14379@psf.upfronthosting.co.za>
Message-ID: <1332758071.15.0.903446978488.issue14379@psf.upfronthosting.co.za>


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


----------
type:  -> enhancement

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

From report at bugs.python.org  Mon Mar 26 18:38:27 2012
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 26 Mar 2012 16:38:27 +0000
Subject: [docs] [issue14410] argparse typo
In-Reply-To: <1332747842.06.0.97639285353.issue14410@psf.upfronthosting.co.za>
Message-ID: <1332779907.67.0.701545853941.issue14410@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Patch is doc-only, and looks good to me.

----------
nosy: +Jim.Jewett

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

From report at bugs.python.org  Mon Mar 26 19:40:33 2012
From: report at bugs.python.org (David Manowitz)
Date: Mon, 26 Mar 2012 17:40:33 +0000
Subject: [docs] [issue6634] sys.exit() called from threads other than the
	main one:	undocumented behaviour
In-Reply-To: <1332586072.39.0.983087451163.issue6634@psf.upfronthosting.co.za>
Message-ID: <CABr2X-as931QKF21zu7i7rFNFkRThKxbfHiUWL7tNh78KHA6Mg@mail.gmail.com>


David Manowitz <david.manowitz at gmail.com> added the comment:

I have a couple of issues with that argument:

1.) Until fairly recently, the fact that sys.exit() when called from a
non-primary thread only causes the thread to die, was not clearly
documented (and still isn't in the python2.6 docs).  Admittedly,
thread.exit() does say that it raises the SystemExit exception, but as most
people are encouraged to use the *threading* module, rather than the
*thread* module directly, this is still fairly obscure.

2.) A ThreadExit exception could be derived from the SystemExit exception,
so existing code that works by catching a SystemExit exception would still
work.

--David

On Sat, Mar 24, 2012 at 6:47 AM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> > I don't see why this should be considered acceptable behavior.  Why
> > don't threads have their own ThreadExit exception, rather than
> > overloading the use, and therefore, the meaning, of the SystemExit
> > exception?  As indicated by their names, sys.exit and the SystemExit
> > exception should *only* be used to exit the entire system, not just a
> > thread!
>
> I agree the situation isn't optimal. However, fixing this would also break
> compatibility with any application that uses sys.exit() in a thread and
> expects it to exit the thread, not the whole process. So we're kind of
> stuck with it.
>
> ----------
> nosy: +pitrou
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6634>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Mar 26 19:43:19 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Mar 2012 17:43:19 +0000
Subject: [docs] [issue7635] 19.6 xml.dom.pulldom doc: stub?
In-Reply-To: <1262651647.28.0.891885115157.issue7635@psf.upfronthosting.co.za>
Message-ID: <1332783799.21.0.115224137361.issue7635@psf.upfronthosting.co.za>


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

Looks like someone else noticed the problem, but did not notice that there was an existing issue with a patch :(.

Sorry about that, Mark.  Thanks very much for working on this, and I'm very sorry it got lost.  Hopefully Eli will review your patch and see if there is anything to adopt from it to add to the stuff he already checked in on issue 14202.

----------
nosy: +eli.bendersky, r.david.murray
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> The docs of xml.dom.pulldom are almost nonexistent

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

From report at bugs.python.org  Mon Mar 26 19:46:15 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Mar 2012 17:46:15 +0000
Subject: [docs] [issue14410] argparse typo
In-Reply-To: <1332747842.06.0.97639285353.issue14410@psf.upfronthosting.co.za>
Message-ID: <E1SCDzg-0004Eg-FV@dinsdale.python.org>


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

New changeset 03771ea22ead by Sandro Tosi in branch '2.7':
Issue #14410: fix typo in argparse doc; patch by Tshepang Lekhonkhobe
http://hg.python.org/cpython/rev/03771ea22ead

New changeset 3e18af617266 by Sandro Tosi in branch '3.2':
Issue #14410: fix typo in argparse doc; patch by Tshepang Lekhonkhobe
http://hg.python.org/cpython/rev/3e18af617266

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

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

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

From report at bugs.python.org  Mon Mar 26 19:46:43 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 26 Mar 2012 17:46:43 +0000
Subject: [docs] [issue14410] argparse typo
In-Reply-To: <1332747842.06.0.97639285353.issue14410@psf.upfronthosting.co.za>
Message-ID: <1332784003.88.0.267415770115.issue14410@psf.upfronthosting.co.za>


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

Thanks for your patch: committed!

----------
nosy: +sandro.tosi
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Mar 26 20:44:26 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Mar 2012 18:44:26 +0000
Subject: [docs] [issue14006] Improve the documentation of
	xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <E1SCEu1-0001CR-7Q@dinsdale.python.org>


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

New changeset e38f4cf482c7 by Eli Bendersky in branch 'default':
Issue #6488: Explain the XPath support of xml.etree.ElementTree, with code
http://hg.python.org/cpython/rev/e38f4cf482c7

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

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

From report at bugs.python.org  Mon Mar 26 20:45:45 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 26 Mar 2012 18:45:45 +0000
Subject: [docs] [issue14006] Improve the documentation of
	xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1332787545.41.0.922745002627.issue14006@psf.upfronthosting.co.za>


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

First step in the right direction - e38f4cf482c7

----------

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

From report at bugs.python.org  Mon Mar 26 20:53:13 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 26 Mar 2012 18:53:13 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1332787993.46.0.958280153291.issue14202@psf.upfronthosting.co.za>


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

There was a patch for the docs (+ other stuff) in issue #7635 as well. It can be integrated, if relevant.

----------

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

From report at bugs.python.org  Mon Mar 26 20:54:05 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 26 Mar 2012 18:54:05 +0000
Subject: [docs] [issue7635] 19.6 xml.dom.pulldom doc: stub?
In-Reply-To: <1262651647.28.0.891885115157.issue7635@psf.upfronthosting.co.za>
Message-ID: <1332788045.61.0.787752329508.issue7635@psf.upfronthosting.co.za>


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

Yes, sorry for missing this. I've placed a note in issue #14202 to review this. Mark, it would be great if you could prepare a fresh patch vs. 3.3 default with your additions. Let's continue discussion in #14202 - it's still open.

----------

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

From report at bugs.python.org  Mon Mar 26 22:53:45 2012
From: report at bugs.python.org (Geoffrey Bache)
Date: Mon, 26 Mar 2012 20:53:45 +0000
Subject: [docs] [issue14418] Document differences in SocketServer between
	Python 2.6	and 2.7
Message-ID: <1332795225.64.0.202093290254.issue14418@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

Here I'm referring to the section about RequestHandler objects under the SocketServer page.  

http://docs.python.org/release/2.7.2/library/socketserver.html#requesthandler-objects
 
This appears to be the same in Python 2.6 and Python 2.7. But the objects don't behave the same, in two respects:

1) For finish() "If setup() or handle() raise an exception, this function will not be called." This is true in Python 2.6. It appears to no longer be true in Python 2.7, where finish() is called in a "finally" clause.

2) For handle(). "The default implementation does nothing". This is true up to a point, but using the default implementation has different effects. Specifically, if I try to read from a socket when the server has not written anything, I get an exception in Python 2.6 and an empty string in Python 2.7. Consider this code:

## server.py

from SocketServer import TCPServer, StreamRequestHandler
import sys, socket
        
server = TCPServer((socket.gethostname(), 0), StreamRequestHandler)
host, port = server.socket.getsockname()
address = host + ":" + str(port)
print "Started server at", address
sys.stdout.flush()

server.serve_forever()

## client.py

import sys, socket

servAddr = sys.argv[1]
host, port = servAddr.split(":")
serverAddress = (host, int(port))
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(serverAddress)
sock.sendall("Some Message")
sock.shutdown(1)
response = sock.makefile().read()
print "Got reply:", response
sock.close()

and compare the following:

$ python2.7 server.py &
Started server at  127.0.1.1:42759
$ python2.7 client.py 127.0.1.1:42759
Got reply:
$ python2.6 server.py &
Started server at  127.0.1.1:42758
$ python client.py 127.0.1.1:42758
Traceback (most recent call last):
  File "client.py", line 12, in <module>
    response = sock.makefile().read()
  File "/usr/lib/python2.7/socket.py", line 351, in read
    data = self._sock.recv(rbufsize)
socket.error: [Errno 104] Connection reset by peer

(doesn't matter which Python runs the client in the last case)

I am unsure whether this is a bug in Python 2.6, or really what the reasoning behind the behaviour difference is, but I think this change in behaviour is worth a small note in the documentation (how it will behave if you try to read when nothing has been written)

----------
assignee: docs at python
components: Documentation
messages: 156869
nosy: docs at python, gjb1002
priority: normal
severity: normal
status: open
title: Document differences in SocketServer between Python 2.6 and 2.7
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Mar 27 03:03:36 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 27 Mar 2012 01:03:36 +0000
Subject: [docs] [issue14405] Some "Other Resources" in the sidebar are
	hopelessly out	of date
In-Reply-To: <1332696210.48.0.175266420412.issue14405@psf.upfronthosting.co.za>
Message-ID: <1332810216.49.0.251681460448.issue14405@psf.upfronthosting.co.za>


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

+0 as long as the linked pages don't go anywhere.  They've been great resources, containing some information that is not located elsewhere.

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

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

From report at bugs.python.org  Tue Mar 27 06:06:24 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 27 Mar 2012 04:06:24 +0000
Subject: [docs] [issue14006] Improve the documentation of
	xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <1332821184.23.0.551077583177.issue14006@psf.upfronthosting.co.za>


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

There are two parallel discussions going on here:

1. The external ReST documentation
2. The internal docstring documentation

I opened the issue with (1) in focus, since it's more important IMHO. Not only for the usual reasons (most users don't go into the source to find docstrings), but also because ElementTree.py is just a "reference implementation" in 3.3, since the _elementtree extension is imported by default and is expected to be used on the vast majority of platforms.

Therefore, it's important to have external documentation serving essentially as an API spec implemented once in Python and once in C.

Not that I would object to docstring patches. But it doesn't appear Leon's work is progressing. In any case, I'll be focusing on the ReST docs.

----------

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

From report at bugs.python.org  Tue Mar 27 07:47:19 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Mar 2012 05:47:19 +0000
Subject: [docs] [issue14411] outdatedness on rlcompleter docstring
In-Reply-To: <1332748612.71.0.338162063198.issue14411@psf.upfronthosting.co.za>
Message-ID: <E1SCPFV-0008DW-1Z@dinsdale.python.org>


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

New changeset 37751d1cb4a8 by Georg Brandl in branch '3.2':
Closes #14411: remove outdated comment in rlcompleter docstring.
http://hg.python.org/cpython/rev/37751d1cb4a8

New changeset 39d1c2c7bcf7 by Georg Brandl in branch '2.7':
Closes #14411: remove outdated comment in rlcompleter docstring.
http://hg.python.org/cpython/rev/39d1c2c7bcf7

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

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

From jcm1981 at gmail.com  Thu Mar 15 08:09:20 2012
From: jcm1981 at gmail.com (Chang Min Jeon)
Date: Thu, 15 Mar 2012 16:09:20 +0900
Subject: [docs] unittest document bug report
Message-ID: <CAMAomqb_f9m0T3ALYxN9zkz02Ovuke1q3bAYxURM4VOXEtq_yA@mail.gmail.com>

url :
http://docs.python.org/library/unittest.html#skipping-tests-and-expected-failures

before
Classes can be skipped just like methods:

@skip("showing class skipping")

after
Classes can be skipped just like methods:

@unittest.skip("showing class skipping")-

Spread Great Software to the world.
my dream
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120315/2c4a157a/attachment-0001.html>

From homo_laber at yahoo.de  Thu Mar 15 10:11:44 2012
From: homo_laber at yahoo.de (Hauke Rehr)
Date: Thu, 15 Mar 2012 09:11:44 +0000 (GMT)
Subject: [docs] copy&waste problem
In-Reply-To: <20120315030940.GB24138@mathmagic>
Message-ID: <1331802704.15142.YahooMailClassic@web171206.mail.ir2.yahoo.com>

Hello Senthil

Sorry, but your program doesn?t prove anything but the correct behaviour of sets in python.
Maybe there was a misunderstanding. I?d have expected this very behaviour your code showed. As I said earlier, for the positive (lowercase) classes, it?s union, for the negative (uppercase) ones, it?s intersection. And that?s exactly what your program showed. I don?t see where you got me wrong.
But your code doesn?t deal with the UNICODE or LOCALE flag at all. I wanted to see, if they behave the same (as correct) as the builtin set data structure you used in your code. You?d have to first set the UNICODE and LOCALE definitions of space characters to check whether they show correct results - that is, in my opinion:
s(uni, loc) = union(s(uni), s(loc)) and S(uni, loc) = intersection(S(uni), S(loc))
analogous to the example in your code. I?d still expect them to work like this.

regards,
Hauke

--- Senthil Kumaran <senthil at uthcode.com> schrieb am Do, 15.3.2012:

Von: Senthil Kumaran <senthil at uthcode.com>
Betreff: Re: [docs] copy&waste problem
An: "Hauke Rehr" <homo_laber at yahoo.de>
Datum: Donnerstag, 15. M?rz, 2012 04:09 Uhr

Hi Hauke,

Thanks for persisting. I see the logic and I stand correct. Here is
simple program which I tried for testing the theory. In my first
version, I tried it incorrectly.


ascii_allchars = set(['a','b','c','\t','\n'])
kling_allchars = set([1,2,3,'\t','\n','s']) # 's' is space in kling
universe = ascii_allchars.union(kling_allchars)
ascii_s = set(['\t','\n'])
kling_s = set(['\t','\n','s'])
ascii_S = universe.difference(ascii_s)
kling_S = universe.difference(kling_s)

# my claim is, with locale kling with ascii
s = ascii_s.union( kling_s)
S = ascii_S.union(kling_S)? # this is wrong.

print "\s matches"
print s

print "\S matches"
print S

# for intersection - it is correct
print ascii_S.intersection(kling_S)


# INCORRECT way of doing this which I was trying.

ascii_allchars = ['a','b','c','\t','\n']
kling_allchars=[1,2,3,'\t','\n','s']#'s'isspaceinkling
ascii_s=['\t','\n']
kling_s=['\t','\n','s']
ascii_S=['a','b','c']
kling_S=[1,2,3]

s=ascii_s+kling_s
S=ascii_S+kling_S

print"\smatches"
prints

print"\Smatches"
printS

#Theotherclaimisforintersectionitshouldbe
print set(ascii_S).intersection(set(kling_S))


Having concluded on this, we have another problem. namely the behavior
of Python 2.7. Looking at the code, I find that re.L is completely
ignored for space or non-white space and for re.U, the logic is if
char is less than 128, the ascii non-white space characters are
checked and if its greater than 128, the unicode non-white space
characters are checked.? I think, documentation should be updated with
the behavior rather than supposed logic.

Thank you,
Senthil

On Wed, Mar 14, 2012 at 04:38:41PM +0000, Hauke Rehr wrote:
> Hello,
> 
> you wrote:
> If the intersection logic were to be followed then, it would
> completely remove those "<space>, <form-feed>, <newline>,
> <carriage-return>, <tab>, and <vertical-tab>" from the match as they
> are included as space characters in the locale definition too.
> 
> I don?t see where you get this from: the negative (uppercase) classes - to
> which I still think the intersection logic should apply - don?t have those
> space characters for they?re the exact complement: everything but those space
> chars.
> 
> I say, to build the set \S you either build the union of the positive
> (lowercase) classes and complement the result, or equivalently intersect the
> complements \S(unicode) and \S(locale) which don?t contain any spaces (and so
> does the result which is what we want when specifying \S).
> 
> To cut it short, I thought if characters a, b are in \s(unicode) and a, c are
> in \s(locale), then \S(unicode, locale) should contain any character not in any
> of unicode or locale. Therefore, it should in particular not match a nor any of
> b, c.
> Did your example script show a different behaviour? Please send it for me to
> see if I?m wrong about that.
> 
> I guess, you?ll argee, that \s(uni, loc) is the union of \s(uni) and \s(loc).
> \S(uni, loc) is meant to be the exact complement, so it?s complement of union,
> that is, intersection of the complements \S(uni) and \S(loc).
> 
> Union would not make sense to me:
> if I want a non-space, I don?t want it to be considered space by any of uni or
> loc, so I want it to be in both complements and thus in their (the
> complements?) intersection.
> 
> I hope your script will either show I got this wrong or prove my understanding
> to be correct.
> 
> --- Senthil Kumaran <senthil at uthcode.com> schrieb am Di, 13.3.2012:
> 
> 
>? ???Von: Senthil Kumaran <senthil at uthcode.com>
>? ???Betreff: Re: [docs] copy&waste problem
>? ???An: "Hauke Rehr" <homo_laber at yahoo.de>
>? ???CC: docs at python.org
>? ???Datum: Dienstag, 13. M?rz, 2012 17:16 Uhr
> 
>? ???I understand? your points. My reasoning was based on -
> 
>? ???man 5 locale which stated the following for locale.
> 
>? ???space? followed by a list of characters defined as white-space
>? ???characters.? Characters also? specified? as? upper,? lower,
>? ???alpha,? digit, graph, or xdigit are not allowed.? The
>? ???characters <space>, <form-feed>, <newline>, <carriage-return>,
>? ???<tab>, and <vertical-tab> are automatically included.
> 
>? ???If the intersection logic were to be followed then, it would
>? ???completely remove those "<space>, <form-feed>, <newline>,
>? ???<carriage-return>, <tab>, and <vertical-tab>" from the match as they
>? ???are included as space characters in the locale definition too.
>? ???Isn't it?
> 
>? ???Here is bug report -
> 
>? ???http://bugs.python.org/issue14258
> 
>? ???Thanks,
>? ???Senthil
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120315/36eb8f82/attachment-0001.html>

From szepesva at ualberta.ca  Fri Mar 16 03:07:01 2012
From: szepesva at ualberta.ca (Csaba Szepesvari)
Date: Thu, 15 Mar 2012 20:07:01 -0600
Subject: [docs] Turtle graphics, what is the function done doing?
In-Reply-To: <CAPdtAj0n5SOEhv3g0ZGYcOuRZc7nOzLw+pWsNXtL64sm4mx1Gw@mail.gmail.com>
References: <4E9D9316.60008@sztaki.hu>
	<CAPdtAj0n5SOEhv3g0ZGYcOuRZc7nOzLw+pWsNXtL64sm4mx1Gw@mail.gmail.com>
Message-ID: <4F62A045.20708@ualberta.ca>

Hi Sandro,

I have found another minor issue.
In Section 23.1.4.3, Using Screen Events,
it is (implicitly) suggested that the functions
turtle.onclick(fun, btn=1, add=None)
turtle.onscreenclick(fun, btn=1, add=None)
will behave identically.
However, what happens is that turtle.onclick will call onclick on the 
default turtle and is not identical to an Screen().onclick()
(the example assumes you used import turtle at the beginning).
I would suggest this to be clarified in the documentation (looking at 
the source, this is because turtle.onclick is bound twice when the 
module is imported; first to the default screen's method, and then to 
the default turtle's corresponding method).
Cheers,
   Csaba

On 11-10-31 3:17 AM, Sandro Tosi wrote:
> Hello Csaba,
>
> On Tue, Oct 18, 2011 at 16:54, Csaba Szepesvari<szepesva at ualberta.ca>  wrote:
>> Hi,
>>
>> Look at the example code at:
>> http://docs.python.org/py3k/library/turtle.html#turtle.towards
>>
>> from turtle import *
>> color('red', 'yellow')
>> begin_fill()
>> while True:
>>      forward(200)
>>      left(170)
>>      if abs(pos())<  1:
>>          break
>> end_fill()
>> done()
>>
>> It calls the done() function at the end. However, this function is not
>> documented.
>> My experimentation shows that this is really coming from the turtle module,
>> so it should be documented here.. (or at least pls give some pointer to its
>> documentation).
>
> This has now been fixed with these commits:
>
>      http://hg.python.org/cpython/rev/1588b678d634
>      http://hg.python.org/cpython/rev/e23baae539f7
>      http://hg.python.org/cpython/rev/c7963dff98fa
>
> Regards,

From chamilton at dyercpa.com  Mon Mar 19 15:10:52 2012
From: chamilton at dyercpa.com (Charles Hamilton)
Date: Mon, 19 Mar 2012 10:10:52 -0400
Subject: [docs] typo in shutil.move documentation?
Message-ID: <4F673E6C.6000800@dyercpa.com>

Hi! I believe I've found a typo in the documentation; specifically, 
shutil.move:

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

_According to the docs:_

shutil.move(/src/,/dst/)
    Recursively move a file or directory (/src/) to another location
    (/dst/).
    If the destination is a directory or a symlink to a directory,
    then/src/is moved inside that directory.
    *The destination directory must not already exist.* If the
    destination already exists but is not a directory, it may be
    overwritten depending onos.rename()
    <http://docs.python.org/library/os.html#os.rename>semantics.
    If the destination is on the current filesystem, thenos.rename()
    <http://docs.python.org/library/os.html#os.rename>is used.
    Otherwise,/src/is copied (usingshutil.copy2()
    <http://docs.python.org/library/shutil.html#shutil.copy2>)
    to/dst/and then removed.
    New in version 2.3.


###

But that's not correct; if a directory doesn't exist before trying to 
move a file into it, shutil.move raises an IOError (as you'd expect). 
Please let me know if I'm not correct on this. Thanks!

-- 
------------------------------------------------------------------------
Charles Hamilton
I.T. Department
Dyer & Associates, P.C.
10415 Armory Ave
Kensington, MD 20895

chamilton at dyercpa.com
301.654.6200 (office)
301.814.6664 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120319/a567f577/attachment-0001.html>

From jonathan.eunice at gmail.com  Mon Mar 19 18:10:19 2012
From: jonathan.eunice at gmail.com (Jonathan Eunice)
Date: Mon, 19 Mar 2012 13:10:19 -0400
Subject: [docs] Omission in webbrowser documentation
Message-ID: <CA+aeMmsu1C=mCFsXTKbafQMsMgox8hJkECNVnSQQbZ_T6u9EPA@mail.gmail.com>

http://docs.python.org/library/webbrowser.html (currently for 2.7.2)
contains a table giving supported browser names. On Mac OS X
at least,  the string "safari" does indeed work, e.g.:

webbrowser.get("safari").open("http://cnn.com")

Yet "safari" does not appear in the table.

Interestingly, Google Chrome does not appear to be readily nameable/
explicitly launchable from this module. But that's a bug for another
team....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120319/08db3476/attachment-0001.html>

From kanepyork at gmail.com  Mon Mar 19 20:30:40 2012
From: kanepyork at gmail.com (Kane York)
Date: Mon, 19 Mar 2012 12:30:40 -0700
Subject: [docs] Py3k doc suggestion: Circular imports
Message-ID: <CABeNrKV-u+Oaxe46JU5m+=u7yZU5PRF3XJ0V96Gt4dhT4DcDaw@mail.gmail.com>

I'd like you to, somewhere in the docs, talk about circular imports.

Specifically, why importing the modules circularly works while from imports
do not (the class isn't defined yet with the from imports).
It can get quite annoying to try to figure this out on your own :S

~Kane
Sent from gmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120319/cb590e3b/attachment-0001.html>

From aaronjencks at aol.com  Mon Mar 19 23:41:33 2012
From: aaronjencks at aol.com (Aaron Jencks)
Date: Mon, 19 Mar 2012 18:41:33 -0400 (EDT)
Subject: [docs] bug
Message-ID: <8CED43891E01D77-1C44-13DFA@Webmail-m117.sysops.aol.com>


Dear Python Volunteers,
I have attached a program that once worked on my computer, then I changed one line of code, reset it(put the line back exactly the way it was before), and tried to run it.  I keep getting an error message that's preventing me to get any work done on this school project.  Why does it keep giving me an internal runcode() error? Errno 10035.
Sincerely,
Aaron Jencks


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120319/378f518d/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Flute_Key
URL: <http://mail.python.org/pipermail/docs/attachments/20120319/378f518d/attachment-0001.ksh>

From rabcor1 at hotmail.com  Tue Mar 20 02:44:39 2012
From: rabcor1 at hotmail.com (Daniel Oskarsson)
Date: Tue, 20 Mar 2012 01:44:39 +0000
Subject: [docs] Your tutorial isn't working
Message-ID: <BAY160-W23962D7E0F5BABA5A91093F1430@phx.gbl>


So i read through your first introduction page, ok no problem sounds cool, etc, etc... ok then i go to page 2... and none of the suggested commands are working. not even a little bit. only thing that works when i type it into the python command line thingy is "import sys" which doesn't help me very much when i'm only halfway to understanding how to use it. and then i got to this part.
>>> the_world_is_flat = 1
>>> if the_world_is_flat:
...     print "Be careful not to fall off!"
...
Be careful not to fall off!This is what happens in GUI (something similar happens in command line):>>> the_world_is_flat = 1
>>> if the_world_is_flat:
	print "Be careful not to fall off!"
	
SyntaxError: invalid syntaxSo whats the deal?  the c++ tutorials, and the javascript tutorials at least fucking work. every tutorial or instruction or whatever i've got for anything (and i mean anything) related to unix except for the mac os (which is the crap among crap) be it linux or freebsd or whatever. only like 1/10 of every tutorial seem to work, now what i'm not getting is how can you put a tutorial that doesn't work on your homepage? isn't that like a fail among fails? after making so much effort to make it sound like its easy... on one page, the very next page doesn't even make sense, so what is it that i am doing wrong? 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120320/b205ebe0/attachment-0001.html>

From jannesvantoever at gmail.com  Tue Mar 20 18:40:18 2012
From: jannesvantoever at gmail.com (Jannes van 't Oever)
Date: Tue, 20 Mar 2012 10:40:18 -0700
Subject: [docs] str.replace
	(http://docs.python.org/library/stdtypes.html#str.replace)
Message-ID: <CAELQnp2k-O8wwQsdS5GLL7cRsXhrhr4dS10j9VqQBuZ54oB6Bw@mail.gmail.com>

In section: http://docs.python.org/library/stdtypes.html#str.replace
the string to parse is missing in the parameters.

-- str.replace(old, new[, count])

This should read:

-- str.replace(str, old, new[, count])

Kind regards,
Jannes van 't Oever


-- 
*******************************
 www.vikingsinspace.com
*******************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120320/46f673de/attachment.html>

From kogelnik at gmail.com  Wed Mar 21 19:25:01 2012
From: kogelnik at gmail.com (Chris Kogelnik)
Date: Wed, 21 Mar 2012 11:25:01 -0700
Subject: [docs] string reverse
Message-ID: <4F6A1CFD.3010101@gmail.com>

Hi,

There is no string reverse method in Python, but there is an easy way to 
do it using negative stepping in the extended slice syntax, ie. 
some_string[::-1].  Since this is somewhat non-intuitive, I think adding 
a note to the String Methods section under Built-in Types will spare a 
lot of people the time of implementing such a method.

From nik at nikolaskallis.com  Fri Mar 23 01:02:31 2012
From: nik at nikolaskallis.com (Nikolas Kallis)
Date: Fri, 23 Mar 2012 11:02:31 +1100
Subject: [docs] Bug in Sock Programming HOWTO
Message-ID: <4F6BBD97.5010508@nikolaskallis.com>

Hello,



I believe there is a bug in the Socket Programming HOWTO, in which the 
inclusion of the socket module is missing in the example code.

http://docs.python.org/howto/sockets.html



Regards,

Nikolas Kallis


P.O box 9435
South Yarra, 3141
Melbourne, Victoria, Australia

+61 0431 564 815

From spmcinerney at hotmail.com  Mon Mar 26 22:25:40 2012
From: spmcinerney at hotmail.com (Stephen McInerney)
Date: Mon, 26 Mar 2012 13:25:40 -0700
Subject: [docs] subprocess Frequently Used Arguments: state explicitly that
 you must use shell=True if your command has wildcards/globbing
Message-ID: <BAY155-W18D44509FB665612562424A0450@phx.gbl>



Dear esteemed doc folks, 
Re the documentation of subprocess Frequently Used Arguments (line in red below):It's way too vague and misleading ('can be useful'?!).What is not clear is if you have a command with any wildcards in it, it will break in a non-obvious wayPlease change this to explicitly state (on a separate line):
You must use shell=True if the command contains wildcards/globbing (or else call glob/fnmatch manually).
Thanks!Stephen
http://docs.python.org/library/subprocess.html?highlight=subprocess#frequently-used-arguments17.1.1.1. Frequently Used ArgumentsTo support a wide variety of use cases, the Popen constructor (and the convenience functions) accept a large number of optional arguments. For most typical use cases, many of these arguments can be safely left at their default values. The arguments that are most commonly needed are:...If shell is True, the specified command will be executed through the shell. This can be useful if you are using Python primarily for the enhanced control flow it offers over most system shells and still want access to other shell features such as filename wildcards, shell pipes and environment variable expansion. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120326/63227e49/attachment.html>

From georg at python.org  Tue Mar 27 08:04:42 2012
From: georg at python.org (Georg Brandl)
Date: Tue, 27 Mar 2012 08:04:42 +0200
Subject: [docs] Your tutorial isn't working
In-Reply-To: <BAY160-W23962D7E0F5BABA5A91093F1430@phx.gbl>
References: <BAY160-W23962D7E0F5BABA5A91093F1430@phx.gbl>
Message-ID: <4F71587A.4060107@python.org>

On 20.03.2012 02:44, Daniel Oskarsson wrote:
> So i read through your first introduction page, ok no problem sounds cool, etc,
> etc... ok then i go to page 2... and none of the suggested commands are working.
> not even a little bit. only thing that works when i type it into the python
> command line thingy is "import sys" which doesn't help me very much when i'm
> only halfway to understanding how to use it. and then i got to this part.
> 
>>>> the_world_is_flat = 1
>>>> if the_world_is_flat:
> ...     print "Be careful not to fall off!"
> ...
> Be careful not to fall off!
> 
> This is what happens in GUI (something similar happens in command line):
> 
>>>> the_world_is_flat = 1
>>>> if the_world_is_flat:
> 	print "Be careful not to fall off!"
> 	
> SyntaxError: invalid syntax
> 
> So whats the deal?  the c++ tutorials, and the javascript tutorials at least fucking work.
[...]

Hi Daniel,

relax.  Please use the version of the docs or tutorial that belongs to your
version of Python.  In this case, it looks like you have Python 3 and are
looking at the Python 2 tutorial.

The Python 3 docs are at docs.python.org/py3k

cheers,
Georg


From georg at python.org  Tue Mar 27 08:05:54 2012
From: georg at python.org (Georg Brandl)
Date: Tue, 27 Mar 2012 08:05:54 +0200
Subject: [docs] str.replace
	(http://docs.python.org/library/stdtypes.html#str.replace)
In-Reply-To: <CAELQnp2k-O8wwQsdS5GLL7cRsXhrhr4dS10j9VqQBuZ54oB6Bw@mail.gmail.com>
References: <CAELQnp2k-O8wwQsdS5GLL7cRsXhrhr4dS10j9VqQBuZ54oB6Bw@mail.gmail.com>
Message-ID: <4F7158C2.3070605@python.org>

On 20.03.2012 18:40, Jannes van 't Oever wrote:
> In section: http://docs.python.org/library/stdtypes.html#str.replace
> the string to parse is missing in the parameters.
> 
> -- str.replace(old, new[, count])
> 
> This should read:
> 
> -- str.replace(str, old, new[, count])
> 
> Kind regards,
> Jannes van 't Oever

Hi Jannes,

while you are right that the unbound method "str.replace" gets a self
argument, we never list that in the docs as it's always implied for
methods.

cheers,
Georg

From report at bugs.python.org  Tue Mar 27 14:33:31 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 27 Mar 2012 12:33:31 +0000
Subject: [docs] [issue14424] document PyType_GenericAlloc
Message-ID: <1332851611.13.0.643004221435.issue14424@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

PyType_GenericAlloc is not documented in http://docs.python.org/dev/c-api/type.html

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 156917
nosy: docs at python, eli.bendersky
priority: low
severity: normal
status: open
title: document PyType_GenericAlloc
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Mar 27 16:32:35 2012
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 27 Mar 2012 14:32:35 +0000
Subject: [docs] [issue5824] SocketServer.DatagramRequestHandler Broken under
	Linux
In-Reply-To: <1240525238.53.0.858571250541.issue5824@psf.upfronthosting.co.za>
Message-ID: <1332858755.08.0.716928986899.issue5824@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/issue5824>
_______________________________________

From report at bugs.python.org  Tue Mar 27 21:10:24 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Mar 2012 19:10:24 +0000
Subject: [docs] [issue14427] urllib.request.Request get_header and
	header_items not	documented
Message-ID: <1332875424.01.0.0659150950753.issue14427@psf.upfronthosting.co.za>


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

These appear from the source to be public methods (and I certainly want to be able to use get_header), but they aren't documented.

----------
assignee: docs at python
components: Documentation
messages: 156953
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: urllib.request.Request get_header and header_items not documented
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Mar 27 21:49:51 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 27 Mar 2012 19:49:51 +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: <1332877791.79.0.503983385292.issue6634@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Mar 28 06:55:29 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 28 Mar 2012 04:55:29 +0000
Subject: [docs] [issue14418] Document differences in SocketServer between
	Python 2.6	and 2.7
In-Reply-To: <1332795225.64.0.202093290254.issue14418@psf.upfronthosting.co.za>
Message-ID: <1332910529.36.0.14208527139.issue14418@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
versions:  -Python 2.6

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

From dmugtasimov at gmail.com  Tue Mar 27 10:42:52 2012
From: dmugtasimov at gmail.com (Dmitry Mugtasimov)
Date: Tue, 27 Mar 2012 12:42:52 +0400
Subject: [docs] Bug in description of namespaces and scopes
Message-ID: <CAJ0n+L2j8WnfxmP5C-P7zuxV-Dp6W-mmQSxAQ7YcxMiuNjMqhA@mail.gmail.com>

Hello,

I found it hard for me to understand the relation between namespaces and
scopes, so I tried find out why it is hard do it. I found that description
of namespaces and scopes it contradictive and brakes plain logic. I would
like to ask to refactor description somehow, so it would be logically
structured. Here is my analysis:

*http://docs.python.org/tutorial/classes.html:*
*

"A namespace is a mapping from names to objects."

> namespace is a mapping from names to objects
*

*

A scope is a textual region of a Python program where a namespace is
directly accessible. "Directly accessible" here means that an unqualified
reference to a name attempts to find the name in the namespace.

> scope is textual region

Although scopes are determined statically, they are used dynamically. At
any time during execution, there are at least three nested scopes whose
namespaces are directly accessible:

> scope owns namespaces

   -

   the innermost scope, which is searched first, contains the local names

> scope contains names

   -

   the scopes of any enclosing functions, which are searched starting with
   the nearest enclosing scope, contains non-local, but also non-global
   names

> scope contains names

   -

   the next-to-last scope contains the current module's global names

> scope contains names

   -

   the outermost scope (searched last) is the namespace containing built-in
   names

> scope is the namespace
--------------------
> namespace is a mapping from names to objects
> scope is textual region
> scope owns namespaces
> scope contains names
> scope is the namespace
--------------------
scope is textual region which owns namespaces and scope contains names
scope is a mapping from names to objects
textual region == a mapping from names to objects ?*

Please, take it seriously. Absence of strict description does not allow
full understanding of the language and its advanced usage.

-- 
Regards,
Dmitry Mugtasimov
dmugtasimov at gmail.com
+7 903 756 37 26

? ?????????,
??????? ??????????
dmugtasimov at gmail.com
+7 903 756 37 26

--
????????? ????????? ?????????: govoritter.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120327/b2ca7952/attachment.html>

From sixt-hil at dsv.su.se  Wed Mar 28 15:49:29 2012
From: sixt-hil at dsv.su.se (Sixten Hilborn)
Date: Wed, 28 Mar 2012 15:49:29 +0200
Subject: [docs] =?utf-8?q?Documentation_bug_for_PyEval=5FSetTrace=3F?=
Message-ID: <75a97b7ad2757ee40ccd962898885770@dsv.su.se>

Hi!

I'm using the Python interpreter (2.6.6, but I've found the same 
problem in 2.7.3) to log function calls when running a couple of Python 
programs. However, I'm not sure about the 
PyEval_SetProfile/PyEval_SetTrace functions, since the output I get from 
the interpreter contains more differences than line number 
registrations.
According to the Python/C API documentation: "PyEval_SetTrace: Set the 
tracing function to func. This is similar to PyEval_SetProfile(), except 
the tracing function does receive line-number events."
After looking in the CPython source code (the macro C_TRACE, found in 
Python/ceval.c), it seems like PyEval_SetProfile also reports C function 
calls (and exceptions and return values, but I haven't tried them), 
while PyEval_SetTrace doesn't, is this a bug in the interpreter or in 
the documentation?

Regards,
Sixten Hilborn

From report at bugs.python.org  Thu Mar 29 07:54:06 2012
From: report at bugs.python.org (Bill Winslow)
Date: Thu, 29 Mar 2012 05:54:06 +0000
Subject: [docs] [issue14434] Tutorial link in "help()" in 3.2.2
Message-ID: <1333000446.19.0.515069891496.issue14434@psf.upfronthosting.co.za>


New submission from Bill Winslow <bunslow at gmail.com>:

I installed "python3" to get into a good scripting language.

I ran "python3" and it said type "help". I did and it said type "help()" for interactive help, or "help(object)" for specific help. Just looking to get started, I did the former, where the message displayed says "Welcome to Python 3.2!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/."

The link, unfortunately, leads to the Python 2.7 documentation, which is rather useless considering I'm trying to learn 3.2. The proper link should be http://docs.python.org/py3k/tutorial/.

Yes, this is really minor, but it would help with the "completeness" or "professional" appearance.

----------
assignee: docs at python
components: Documentation
messages: 157011
nosy: Dubslow, docs at python
priority: normal
severity: normal
status: open
title: Tutorial link in "help()" in 3.2.2
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Mar 29 12:06:38 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Mar 2012 10:06:38 +0000
Subject: [docs] [issue14434] Tutorial link in "help()" in Python3 points to
	Python2	tutorial
In-Reply-To: <1333000446.19.0.515069891496.issue14434@psf.upfronthosting.co.za>
Message-ID: <1333015597.97.0.0525904748041.issue14434@psf.upfronthosting.co.za>


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

It should be easy enough to patch this to use

   http://docs.python.org/<major>.<minor>/tutorial

I think that is probably a good idea, but the doc folks should sign off on it.

----------
keywords: +easy
nosy: +r.david.murray
title: Tutorial link in "help()" in 3.2.2 -> Tutorial link in "help()" in Python3 points to Python2 tutorial
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Mar 29 15:43:12 2012
From: report at bugs.python.org (Joseph Chadwick)
Date: Thu, 29 Mar 2012 13:43:12 +0000
Subject: [docs] [issue13744] raw byte strings are described in a confusing
	way
In-Reply-To: <1326116062.09.0.84789277908.issue13744@psf.upfronthosting.co.za>
Message-ID: <1333028592.74.0.882838957728.issue13744@psf.upfronthosting.co.za>


Joseph Chadwick <josephholyheart at gmail.com> added the comment:

The attached replaces the text for the documentation in 2.4.1 between the lexical definitions table and the escape sequence table. The only change is the following addition to the paragraph on string and byte literals prefixed by 'r' or 'R':

When a byte literal is prefixed with both 'r' or 'R' and 'b' or 'B', the b must precede the r, as in: 'Br', 'bR', or 'BR' and not 'Rb', 'rB', or 'RB'.

----------
nosy: +j.chadwick
type:  -> enhancement
Added file: http://bugs.python.org/file25064/stringByteLiteralBR.docx

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

From report at bugs.python.org  Thu Mar 29 15:52:29 2012
From: report at bugs.python.org (Joseph Chadwick)
Date: Thu, 29 Mar 2012 13:52:29 +0000
Subject: [docs] [issue13744] raw byte strings are described in a confusing
	way
In-Reply-To: <1326116062.09.0.84789277908.issue13744@psf.upfronthosting.co.za>
Message-ID: <1333029149.01.0.109002094832.issue13744@psf.upfronthosting.co.za>


Joseph Chadwick <josephholyheart at gmail.com> added the comment:

I uploaded before making the final save, so the first document is incomplete.

(that's embarrassing)

----------
Added file: http://bugs.python.org/file25065/stringByteLiteralBR.docx

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

From report at bugs.python.org  Thu Mar 29 16:19:53 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 29 Mar 2012 14:19:53 +0000
Subject: [docs] [issue13744] raw byte strings are described in a confusing
	way
In-Reply-To: <1326116062.09.0.84789277908.issue13744@psf.upfronthosting.co.za>
Message-ID: <1333030793.86.0.238964038511.issue13744@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Removed file: http://bugs.python.org/file25064/stringByteLiteralBR.docx

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

From report at bugs.python.org  Thu Mar 29 23:21:05 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 29 Mar 2012 21:21:05 +0000
Subject: [docs] [issue14448] Metnion pytz in datetime's docs
Message-ID: <1333056065.25.0.804124513061.issue14448@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Python Standard Library itself has not timezone objects.
There are well-maintained project named pytz.

Let's mention pytz in datetime docs.

I have attached a patch, please review it.

----------
assignee: docs at python
components: Documentation
files: pytz.diff
keywords: easy, patch
messages: 157104
nosy: asvetlov, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Metnion pytz in datetime's docs
type: enhancement
Added file: http://bugs.python.org/file25069/pytz.diff

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

From report at bugs.python.org  Fri Mar 30 01:05:15 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 29 Mar 2012 23:05:15 +0000
Subject: [docs] [issue14448] Mention pytz in datetime's docs
In-Reply-To: <1333056065.25.0.804124513061.issue14448@psf.upfronthosting.co.za>
Message-ID: <1333062315.84.0.662135846839.issue14448@psf.upfronthosting.co.za>


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

Good idea.  The patch has a few English and markup errors; I?ll update it when I get home.  To catch such errors in the future, you can re-run ?make html?.

----------
nosy: +eric.araujo
title: Metnion pytz in datetime's docs -> Mention pytz in datetime's docs
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Mar 30 04:52:30 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Mar 2012 02:52:30 +0000
Subject: [docs] [issue13744] raw byte strings are described in a confusing
	way
In-Reply-To: <1326116062.09.0.84789277908.issue13744@psf.upfronthosting.co.za>
Message-ID: <1333075950.79.0.899517305957.issue13744@psf.upfronthosting.co.za>


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

Thanks for the contribution.  Could you post your suggested wording as a plain text file?

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

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

From report at bugs.python.org  Fri Mar 30 04:53:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Mar 2012 02:53:18 +0000
Subject: [docs] [issue13744] raw byte strings are described in a confusing
	way
In-Reply-To: <1326116062.09.0.84789277908.issue13744@psf.upfronthosting.co.za>
Message-ID: <1333075998.39.0.262066638132.issue13744@psf.upfronthosting.co.za>


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

Actually it?s fine, we already have the text in your message :)

----------

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

From report at bugs.python.org  Fri Mar 30 10:45:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Mar 2012 08:45:32 +0000
Subject: [docs] [issue14006] Improve the documentation of
	xml.etree.ElementTree
In-Reply-To: <1329190125.69.0.69162565954.issue14006@psf.upfronthosting.co.za>
Message-ID: <E1SDXSd-0007G7-1k@dinsdale.python.org>


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

New changeset 78038b6e0a85 by Eli Bendersky in branch 'default':
Issue #14006: improve the documentation of xml.etree.ElementTree
http://hg.python.org/cpython/rev/78038b6e0a85

----------

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

From maj.smerkol at gmail.com  Thu Mar 29 21:44:51 2012
From: maj.smerkol at gmail.com (Maj Smerkol)
Date: Thu, 29 Mar 2012 21:44:51 +0200
Subject: [docs] Python 3.2 curses module bug
Message-ID: <CAML08yUqSThjWK-KVxVhQJAiOUnBQCXwekkfeUprKUST37HsjA@mail.gmail.com>

Hello,

I may have found a bug (or a not yet implemented feature) in the curses
module, class Textbox.

It cannot be created with a pad as a window. If so is done, it returns
_curses.error: refresh() for a pad requires 6 arguments
.
Problem is located in .../python3.2/curses/textpad.py, line 174, in edit.
I hope this is actually a bug and that I am not only clogging your efforts
with this report.

Sincerely,
Maj

-- 
http://www.youtube.com/watch?v=nAD82J6QMPU&feature=colike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120329/2ba4f557/attachment.html>

From report at bugs.python.org  Fri Mar 30 23:45:08 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Mar 2012 21:45:08 +0000
Subject: [docs] [issue11310] Document byte[s|array]() and
	byte[s|array](count) in	docstrings
In-Reply-To: <1298572139.69.0.327669775377.issue11310@psf.upfronthosting.co.za>
Message-ID: <1333143908.12.0.654122539764.issue11310@psf.upfronthosting.co.za>


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

Duplicate of issue 11231.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> bytes() constructor is not correctly documented

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

From report at bugs.python.org  Sat Mar 31 00:09:41 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Mar 2012 22:09:41 +0000
Subject: [docs] [issue10423] s/args/options in arpgarse "Upgrading optparse
	code"
In-Reply-To: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>
Message-ID: <E1SDk0p-00077I-JT@dinsdale.python.org>


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

New changeset dee1597b3ce3 by R David Murray in branch '3.2':
#10423: clarify options vs args in argparse discussion of optparse
http://hg.python.org/cpython/rev/dee1597b3ce3

New changeset 7ad1728691b2 by R David Murray in branch 'default':
Merge #10423: clarify options vs args in argparse discussion of optparse
http://hg.python.org/cpython/rev/7ad1728691b2

New changeset cb5214e6c287 by R David Murray in branch '2.7':
#10423: clarify options vs args in argparse discussion of optparse
http://hg.python.org/cpython/rev/cb5214e6c287

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

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

From report at bugs.python.org  Sat Mar 31 00:10:13 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Mar 2012 22:10:13 +0000
Subject: [docs] [issue10423] s/args/options in arpgarse "Upgrading optparse
	code"
In-Reply-To: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>
Message-ID: <1333145413.43.0.193139614357.issue10423@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Mar 31 01:12:58 2012
From: report at bugs.python.org (Sven Marnach)
Date: Fri, 30 Mar 2012 23:12:58 +0000
Subject: [docs] [issue14456] Relation between threads and signals unclear
Message-ID: <1333149178.59.0.333821086904.issue14456@psf.upfronthosting.co.za>


New submission from Sven Marnach <sven at marnach.net>:

The documentation of the 'signal' module states on the one hand

    [T]he main thread will be the only one to receive signals (this is
    enforced by the Python signal module, even if the underlying thread
    implementation supports sending signals to individual threads).

On the other hand, it provides the function 'pthread_kill()':

    Send the signal signum to the thread thread_id, another thread in
    the same process as the caller. The signal is asynchronously
    directed to thread.

These two passages are in contradiction to each other.  The documentation also states that only the main thread can set signal handlers -- if this is true, it is utterly unclear how sending signals to other threads is useful.

Probably the documentation wasn't fully updated when the above function was introduced.

----------
assignee: docs at python
components: Documentation
messages: 157156
nosy: docs at python, smarnach
priority: normal
severity: normal
status: open
title: Relation between threads and signals unclear
versions: Python 3.3

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

From report at bugs.python.org  Sat Mar 31 01:27:05 2012
From: report at bugs.python.org (Sven Marnach)
Date: Fri, 30 Mar 2012 23:27:05 +0000
Subject: [docs] [issue14456] Relation between threads and signals unclear
In-Reply-To: <1333149178.59.0.333821086904.issue14456@psf.upfronthosting.co.za>
Message-ID: <1333150025.09.0.194422757284.issue14456@psf.upfronthosting.co.za>


Sven Marnach <sven at marnach.net> added the comment:

For reference: the functions 'pthread_kill()' etc. were intrduced in issue8407.

----------

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

From report at bugs.python.org  Sat Mar 31 01:41:20 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Mar 2012 23:41:20 +0000
Subject: [docs] [issue14456] Relation between threads and signals unclear
In-Reply-To: <1333149178.59.0.333821086904.issue14456@psf.upfronthosting.co.za>
Message-ID: <1333150880.38.0.0184594314582.issue14456@psf.upfronthosting.co.za>


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

> These two passages are in contradiction to each other.

By default, a thread signal can receive any signal and the signal handler implemented in C will be called in the context of the thread.

CPython ensures that a signal handler implemented in Python and installed by signal.signal() will be called in the main thread. It uses a signal handler implemented in C which only store the notification and will be the Python signal handler later (as early as possible).

pthread_sigmask() can be used to mask some signals (or all signals) on a specific thread.

----------
nosy: +haypo, neologix

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

From report at bugs.python.org  Sat Mar 31 03:30:51 2012
From: report at bugs.python.org (Andy Harrington)
Date: Sat, 31 Mar 2012 01:30:51 +0000
Subject: [docs] [issue14454] argparse metavar list parameter with nargs=k
In-Reply-To: <1333139530.69.0.0400880123602.issue14454@psf.upfronthosting.co.za>
Message-ID: <1333157451.4.0.532362262124.issue14454@psf.upfronthosting.co.za>


Andy Harrington <aharrin at luc.edu> added the comment:

Withdrawn.  My error.  I missed the part of the documentation that says a *tuple*, not the list that I tried, does just what I wanted.

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

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

From report at bugs.python.org  Sat Mar 31 13:12:12 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Mar 2012 11:12:12 +0000
Subject: [docs] [issue14434] Tutorial link in "help()" in Python3 points to
	Python2	tutorial
In-Reply-To: <1333000446.19.0.515069891496.issue14434@psf.upfronthosting.co.za>
Message-ID: <1333192332.7.0.712811137747.issue14434@psf.upfronthosting.co.za>


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

Sounds like good fix to me.

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

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

From report at bugs.python.org  Sat Mar 31 13:43:24 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 31 Mar 2012 11:43:24 +0000
Subject: [docs] [issue14034] Add argparse howto
In-Reply-To: <1329417262.26.0.419020263055.issue14034@psf.upfronthosting.co.za>
Message-ID: <1333194204.25.0.534033884619.issue14034@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe <tshepang at gmail.com> added the comment:

Would be nice to get another review.

----------

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

From sandro.tosi at gmail.com  Sat Mar 31 14:18:40 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Mar 2012 14:18:40 +0200
Subject: [docs] Python 3.2 curses module bug
In-Reply-To: <CAML08yUqSThjWK-KVxVhQJAiOUnBQCXwekkfeUprKUST37HsjA@mail.gmail.com>
References: <CAML08yUqSThjWK-KVxVhQJAiOUnBQCXwekkfeUprKUST37HsjA@mail.gmail.com>
Message-ID: <CAB4XWXy9ZmVSVHYuz04WfDmxiOHh6gh2UEu+SmOkuzEbEpaOMw@mail.gmail.com>

Hello Maj,

On Thu, Mar 29, 2012 at 21:44, Maj Smerkol <maj.smerkol at gmail.com> wrote:
> Hello,
>
> I may have found a bug (or a not yet implemented feature) in the curses
> module, class Textbox.
>
> It cannot be created with a pad as a window. If so is done, it returns
> _curses.error: refresh() for a pad requires 6 arguments
> .
> Problem is located in .../python3.2/curses/textpad.py, line 174, in edit.

This mailing list is about bugs/enhancements to Python documentation,
so it doesn't fit with your question; I'd suggest to contact
mail.python.org/mailman/listinfo/python-list for guidance.

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

From sandro.tosi at gmail.com  Sat Mar 31 16:13:07 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Mar 2012 16:13:07 +0200
Subject: [docs] Bug in description of namespaces and scopes
In-Reply-To: <CAJ0n+L2j8WnfxmP5C-P7zuxV-Dp6W-mmQSxAQ7YcxMiuNjMqhA@mail.gmail.com>
References: <CAJ0n+L2j8WnfxmP5C-P7zuxV-Dp6W-mmQSxAQ7YcxMiuNjMqhA@mail.gmail.com>
Message-ID: <CAB4XWXwYY9imjKNnr-AgGHPotmon83pfFp+CvvA_q39sBiirLg@mail.gmail.com>

Hello Dmitry,

On Tue, Mar 27, 2012 at 10:42, Dmitry Mugtasimov <dmugtasimov at gmail.com> wrote:
> --------------------
>> namespace is a mapping from names to objects
>> scope is textual region
>> scope owns namespaces
>> scope contains names
>> scope is the namespace
> --------------------
> scope is textual region which owns namespaces and scope contains names
> scope is a mapping from names to objects
> textual region == a mapping from names to objects ?

It's hard to follow your reasoning, since you're assuming some
conclusions which are not exactly true.

A namespace is a way to associate a piece of code to a name when you
write your program. As mentioned in the tutorial, asb() is a built-in
name which is associated to python code (object) that gets invoked
when the interpreter find the name abs in your program.

a scope is a part of your code, that defines some rules about how
namespaces are looked up to return an object upon invocation. What
happens if you're defining a new abs() function in your program and
then call it? is it the one used or the built-in one? and what if you
do that in a module ? and in a class (so abs becomes a method of that
class)?

try to experiment a bit with those definition: this will probably
clarify your doubts a bit. Maybe it is worth to contact
mail.python.org/mailman/listinfo/python-list for further guidance too.

> Please, take it seriously. Absence of strict description does not allow full
> understanding of the language and its advanced usage.

why shouldn't we be taking this seriously? We try to do our best, but
we're definitely open to suggestions and improvements (but in this
case, it's probably better if you propose an explicit alternate text
to be used)

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

From sandro.tosi at gmail.com  Sat Mar 31 16:39:05 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Mar 2012 16:39:05 +0200
Subject: [docs] Bug in Sock Programming HOWTO
In-Reply-To: <4F6BBD97.5010508@nikolaskallis.com>
References: <4F6BBD97.5010508@nikolaskallis.com>
Message-ID: <CAB4XWXybJRwwpN2=MdEar29PzMJmOLxz5z-Q_Zr8QwLOJa2CJg@mail.gmail.com>

Hello Nikolas,

On Fri, Mar 23, 2012 at 01:02, Nikolas Kallis <nik at nikolaskallis.com> wrote:
> I believe there is a bug in the Socket Programming HOWTO, in which the
> inclusion of the socket module is missing in the example code.
>
> http://docs.python.org/howto/sockets.html

I's often customary to not write "import <module>" explicitly when
talking only about that module (like its documentation or an howto),
but on the other hand, the other howtos sometime have the "import ..."
written down. I don't have a strong opinion about adding "import
socket" or not, so I'd like to hear what others think.

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

From sandro.tosi at gmail.com  Sat Mar 31 16:44:50 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Mar 2012 16:44:50 +0200
Subject: [docs] bug
In-Reply-To: <8CED43891E01D77-1C44-13DFA@Webmail-m117.sysops.aol.com>
References: <8CED43891E01D77-1C44-13DFA@Webmail-m117.sysops.aol.com>
Message-ID: <CAB4XWXwKSnEdBEwUObMRV_aG74r4OyoYr=QGs0dppmGmMhJ28w@mail.gmail.com>

Hello Aaron,
this mailing list is about bugs/enhancement to python documentation,
but your messages is not about them. I'd suggest to contact
mail.python.org/mailman/listinfo/python-list for further guidance.

Regards,
Sandro

On Mon, Mar 19, 2012 at 23:41, Aaron Jencks <aaronjencks at aol.com> wrote:
> Dear Python Volunteers,
> I have attached a program that once worked on my computer, then I changed
> one line of code, reset it(put the line back exactly the way it was before),
> and tried to run it.? I keep getting an error message that's preventing me
> to get any work done on this school project.? Why does it keep giving me an
> internal runcode() error? Errno 10035.
> Sincerely,
> Aaron Jencks
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



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

From sandro.tosi at gmail.com  Sat Mar 31 17:50:18 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Mar 2012 17:50:18 +0200
Subject: [docs] Omission in webbrowser documentation
In-Reply-To: <CA+aeMmsu1C=mCFsXTKbafQMsMgox8hJkECNVnSQQbZ_T6u9EPA@mail.gmail.com>
References: <CA+aeMmsu1C=mCFsXTKbafQMsMgox8hJkECNVnSQQbZ_T6u9EPA@mail.gmail.com>
Message-ID: <CAB4XWXx_UjjLXapz7OFr-pinWayp+fK8vEEYneLzOHjsD4e63g@mail.gmail.com>

Hello Jonathan,
thanks for your email

On Mon, Mar 19, 2012 at 18:10, Jonathan Eunice
<jonathan.eunice at gmail.com> wrote:
> http://docs.python.org/library/webbrowser.html (currently for 2.7.2)
> contains a table giving supported browser names. On Mac OS X
> at least, ?the string "safari"?does indeed work, e.g.:
>
> webbrowser.get("safari").open("http://cnn.com")
>
> Yet "safari" does not appear in the table.

Indeed, that has been fixed with:

http://hg.python.org/cpython/rev/9411b7268cf5
http://hg.python.org/cpython/rev/722ce1be9eeb
http://hg.python.org/cpython/rev/a51764ed57a2

> Interestingly, Google Chrome does not appear to be readily nameable/
> explicitly launchable?from this module. But that's a bug for another
> team....

This was already addressed in python 3.3:
http://docs.python.org/dev/library/webbrowser.html

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

From report at bugs.python.org  Sat Mar 31 18:11:17 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Mar 2012 16:11:17 +0000
Subject: [docs] [issue14434] Tutorial link in "help()" in Python3 points to
	Python2	tutorial
In-Reply-To: <1333000446.19.0.515069891496.issue14434@psf.upfronthosting.co.za>
Message-ID: <E1SE0tX-0000S0-LE@dinsdale.python.org>


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

New changeset d478c0a68bcb by R David Murray in branch '3.2':
#14434: make tutorial link in 'help' banner version-specific
http://hg.python.org/cpython/rev/d478c0a68bcb

New changeset ee9b6574b497 by R David Murray in branch 'default':
Merge #14434: make tutorial link in 'help' banner version-specific
http://hg.python.org/cpython/rev/ee9b6574b497

New changeset b3a7b27953e0 by R David Murray in branch '2.7':
#14434: make tutorial link in 'help' banner version-specific
http://hg.python.org/cpython/rev/b3a7b27953e0

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

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

From report at bugs.python.org  Sat Mar 31 18:11:57 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Mar 2012 16:11:57 +0000
Subject: [docs] [issue14434] Tutorial link in "help()" in Python3 points to
	Python2	tutorial
In-Reply-To: <1333000446.19.0.515069891496.issue14434@psf.upfronthosting.co.za>
Message-ID: <1333210317.71.0.190513139662.issue14434@psf.upfronthosting.co.za>


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

Fixed.  Thanks for the report, Bill.

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

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

From sandro.tosi at gmail.com  Sat Mar 31 18:22:56 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Mar 2012 18:22:56 +0200
Subject: [docs] typo in shutil.move documentation?
In-Reply-To: <4F673E6C.6000800@dyercpa.com>
References: <4F673E6C.6000800@dyercpa.com>
Message-ID: <CAB4XWXwOLz+b=e7PsrD42uLYLrC7x0dn6_EqSpB6djaTB0GMKg@mail.gmail.com>

Hello Charles,

On Mon, Mar 19, 2012 at 15:10, Charles Hamilton <chamilton at dyercpa.com> wrote:
> The destination directory must not already exist. If the destination already
...
> But that's not correct; if a directory doesn't exist before trying to move a
> file into it, shutil.move raises an IOError (as you'd expect). Please let me
> know if I'm not correct on this. Thanks!

What is tries to say is that: if you want to move directory A into
directory B but B/A already exists (so B contains already a
subdirectory named A), then you'll get an error.

On the other hand, if you want to move file f into directory B but B/f
already exists (so B already contains a file name f) then it might get
overwritten.

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

From sandro.tosi at gmail.com  Sat Mar 31 18:50:50 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Mar 2012 18:50:50 +0200
Subject: [docs] unittest document bug report
In-Reply-To: <CAMAomqb_f9m0T3ALYxN9zkz02Ovuke1q3bAYxURM4VOXEtq_yA@mail.gmail.com>
References: <CAMAomqb_f9m0T3ALYxN9zkz02Ovuke1q3bAYxURM4VOXEtq_yA@mail.gmail.com>
Message-ID: <CAB4XWXxPWRsWaAgOWd-EHZLVHeCW+zAFBtqVEi9hmag-hEe7Zw@mail.gmail.com>

Hello Chang,

On Thu, Mar 15, 2012 at 08:09, Chang Min Jeon <jcm1981 at gmail.com> wrote:
> url
> :?http://docs.python.org/library/unittest.html#skipping-tests-and-expected-failures
>
> before
> Classes can be skipped just like methods:
>
> @skip("showing class skipping")
>
> after
> Classes can be skipped just like methods:
>
> @unittest.skip("showing class skipping")-

Thanks for your email, this has been fixed with:

http://hg.python.org/cpython/rev/3ca81a951c31
http://hg.python.org/cpython/rev/6774a2285579
http://hg.python.org/cpython/rev/b926a8c386ad

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

From report at bugs.python.org  Sat Mar 31 19:16:13 2012
From: report at bugs.python.org (Chris Rebert)
Date: Sat, 31 Mar 2012 17:16:13 +0000
Subject: [docs] [issue13997] Clearly explain the bare minimum Python 3 users
	should	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1333214172.97.0.477098426203.issue13997@psf.upfronthosting.co.za>


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

Links to the "rambling Unicode thread"s for posterity and convenience:

Gets into several issues, among them, Unicode:
http://mail.python.org/pipermail/python-ideas/2012-February/013665.html

Unicode-specific offshoot of the above:
http://mail.python.org/pipermail/python-ideas/2012-February/013825.html

----------

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

From report at bugs.python.org  Sat Mar 31 21:15:00 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Mar 2012 19:15:00 +0000
Subject: [docs] [issue14456] Relation between threads and signals unclear
In-Reply-To: <1333149178.59.0.333821086904.issue14456@psf.upfronthosting.co.za>
Message-ID: <E1SE3lK-0004JM-S6@dinsdale.python.org>


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

New changeset 52e32f3b933d by Antoine Pitrou in branch '3.2':
Issue #14456: improve documentation of the signal module w.r.t. threads.
http://hg.python.org/cpython/rev/52e32f3b933d

New changeset 44d13f371811 by Antoine Pitrou in branch 'default':
Issue #14456: improve documentation of the signal module w.r.t. threads.
http://hg.python.org/cpython/rev/44d13f371811

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

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

From report at bugs.python.org  Sat Mar 31 21:15:46 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Mar 2012 19:15:46 +0000
Subject: [docs] [issue14456] Relation between threads and signals unclear
In-Reply-To: <1333149178.59.0.333821086904.issue14456@psf.upfronthosting.co.za>
Message-ID: <1333221346.3.0.848165629556.issue14456@psf.upfronthosting.co.za>


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

Should be fixed now.

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

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

From sandro.tosi at gmail.com  Sat Mar 31 21:32:14 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Mar 2012 21:32:14 +0200
Subject: [docs] subprocess Frequently Used Arguments: state explicitly
 that you must use shell=True if your command has wildcards/globbing
In-Reply-To: <BAY155-W18D44509FB665612562424A0450@phx.gbl>
References: <BAY155-W18D44509FB665612562424A0450@phx.gbl>
Message-ID: <CAB4XWXz-dQrdJy73b-SgwEkPTBqeo1EwXgtYU10oVctdQ+Rrkg@mail.gmail.com>

Hello Stephen,

On Mon, Mar 26, 2012 at 22:25, Stephen McInerney
<spmcinerney at hotmail.com> wrote:
> You must use shell=True if the command contains wildcards/globbing (or else
> call glob/fnmatch manually).

vs

> If?shell?is?True, the specified command will be executed through the shell.
> This can be useful if you are using Python primarily for the enhanced
> control flow it offers over most system shells and still want access to
> other shell features such as filename wildcards, shell pipes and environment
> variable expansion.

is a much reduced note about shell=True removing some important
information. you want shell=True if you want the commands and
arguments specified to subprocess to be executed like if you writing
in a shell, so with all it's powerful features (some of them enlisted
in the current note).

I don't think we need to change that note, for sure not with the
proposed version.

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

From sandro.tosi at gmail.com  Sat Mar 31 22:21:37 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Mar 2012 22:21:37 +0200
Subject: [docs] Py3k doc suggestion: Circular imports
In-Reply-To: <CABeNrKV-u+Oaxe46JU5m+=u7yZU5PRF3XJ0V96Gt4dhT4DcDaw@mail.gmail.com>
References: <CABeNrKV-u+Oaxe46JU5m+=u7yZU5PRF3XJ0V96Gt4dhT4DcDaw@mail.gmail.com>
Message-ID: <CAB4XWXw0ZyCWcmC-ErGm+7d9BWFFjMGHSzUdSgsd8mWFyRKYwg@mail.gmail.com>

Hello Kane,

On Mon, Mar 19, 2012 at 20:30, Kane York <kanepyork at gmail.com> wrote:
> I'd like you to, somewhere in the docs, talk about circular imports.
>
> Specifically, why importing the modules circularly works while from imports
> do not (the class isn't defined yet with the from imports).
> It can get quite annoying to try to figure this out on your own :S

I think you're probably searching:
http://docs.python.org/faq/programming.html#what-are-the-best-practices-for-using-import-in-a-module

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

From sandro.tosi at gmail.com  Sat Mar 31 22:31:34 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Mar 2012 22:31:34 +0200
Subject: [docs] string reverse
In-Reply-To: <4F6A1CFD.3010101@gmail.com>
References: <4F6A1CFD.3010101@gmail.com>
Message-ID: <CAB4XWXxGJf-R0uDtK9V0Cmn3m+pG9XQZFzHzd+4Yh3q1Knk+dg@mail.gmail.com>

Hello Chris,

On Wed, Mar 21, 2012 at 19:25, Chris Kogelnik <kogelnik at gmail.com> wrote:
> Hi,
>
> There is no string reverse method in Python, but there is an easy way to do
> it using negative stepping in the extended slice syntax, ie.
> some_string[::-1]. ?Since this is somewhat non-intuitive, I think adding a
> note to the String Methods section under Built-in Types will spare a lot of
> people the time of implementing such a method.

It is already mentioned at:
http://docs.python.org/faq/programming.html#how-do-i-iterate-over-a-sequence-in-reverse-order

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