From report at bugs.python.org  Mon Apr  1 00:16:07 2013
From: report at bugs.python.org (Amit Saha)
Date: Sun, 31 Mar 2013 22:16:07 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364768167.44.0.930240463247.issue17583@psf.upfronthosting.co.za>


Amit Saha added the comment:

Adding the patch here. I am not sure about how to add the screenshots, so I haven't done them. 

Just attached the document as a patch (note that I have placed in doc/howto).

Thanks for the comments.

----------
hgrepos: +180
keywords: +patch
Added file: http://bugs.python.org/file29641/idle.patch

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

From ezio.melotti at gmail.com  Mon Apr  1 01:03:42 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sun, 31 Mar 2013 23:03:42 -0000
Subject: [docs] IDLE HOWTO (issue 17583)
Message-ID: <20130331230342.11947.23270@psf.upfronthosting.co.za>


http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst
File Doc/howto/idle.rst (right):

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode4
Doc/howto/idle.rst:4: In this guide, we take a look at the basic
features of `IDLE`
`...` should never be used, in this case the `` are not necessary, but
for code snippets you can use ``...``.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode13
Doc/howto/idle.rst:13: On Windows (Microsoft Windows 7), if you have
installed Python using the installer, IDLE
I think this is true for all versions, so I would remove the (MS Win 7).
 Also this line is too long.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode14
Doc/howto/idle.rst:14: should already be installed. Go to your start
menu and look for IDLE
You can start IDLE from :menuselection:`Start --> Programs --> Python
--> IDLE (Python GUI)`.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode23
Doc/howto/idle.rst:23: package manager. On Ubuntu (Ubuntu 12.04) , you
can use the software center to search
I would remove the Ubuntu version.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode26
Doc/howto/idle.rst:26: ``idle2`` and ``idle3`` on Ubuntu and
``python-tools`` and
I see ``idle`` and ``idle3``, but no ``idle2``.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode27
Doc/howto/idle.rst:27: ``python3-tools`` on Fedora (Fedora 18).
Ditto.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode39
Doc/howto/idle.rst:39: :alt: alternate text
Here (and later) you should add some meaningful alternate text.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode53
Doc/howto/idle.rst:53: To open the editor, click on ``File -> New
Window`` menu item.
Here (and later) you can use :menuselection: too.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode69
Doc/howto/idle.rst:69: Module`` menu item to execute it.
Wasn't there a shortcut like ``F5`` to do the same?
Maybe it can be mentioned here.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode78
Doc/howto/idle.rst:78: the previous `shell window` from where you
started the editor.
The `...` should be removed.  If there's a corresponding term in the
glossary for this you can use :term:`...`, otherwise you could just use
*shell window* to make it italic.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode119
Doc/howto/idle.rst:119: discuss at this point of time.
This section doesn't add much, so it should either removed or expanded
IMHO.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode159
Doc/howto/idle.rst:159: =========
You could use a .. seealso:: here.

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

From report at bugs.python.org  Mon Apr  1 01:04:19 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 31 Mar 2013 23:04:19 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364771059.11.0.411000227414.issue17583@psf.upfronthosting.co.za>


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


----------
hgrepos:  -180

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

From report at bugs.python.org  Mon Apr  1 01:08:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 31 Mar 2013 23:08:10 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364771290.94.0.591487538468.issue17583@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I left a few comments on rietveld.
I wonder if it's better to make two separate versions, one for py2 and one for py3, and avoid repeating things (like the name of the packages) twice.

You should also be able to include the images in the patch by using "hg add" locally.  This should include them when you do "hg diff > idle.patch" (if it doesn't work you might have to set "git = on" (see http://docs.python.org/devguide/committing.html#minimal-configuration)).

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

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

From report at bugs.python.org  Mon Apr  1 01:50:45 2013
From: report at bugs.python.org (Amit Saha)
Date: Sun, 31 Mar 2013 23:50:45 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364773845.79.0.867434432606.issue17583@psf.upfronthosting.co.za>


Amit Saha added the comment:

Hi Ezio, thanks for your review comments. 

I will make the changes to the document, and also add the images in a later patch.

I do agree that repeating package names for Python 2 and Python 3 is perhaps not an ideal way. I am also trying to think of other ways to justify having two separate documents: may be the code samples? print 'Hello world' versus print('Hello World') ?

Thanks.

----------

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

From report at bugs.python.org  Mon Apr  1 02:06:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Apr 2013 00:06:51 +0000
Subject: [docs] [issue17586] fix typo in contextlib.rst
Message-ID: <3ZfDPQ5jTxzPhP@mail.python.org>


New submission from Roundup Robot:

New changeset 18e699c4d8c0 by Ned Deily in branch 'default':
Issue #17586: fix typo in contextlib.rst
http://hg.python.org/cpython/rev/18e699c4d8c0

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

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

From report at bugs.python.org  Mon Apr  1 02:07:43 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Apr 2013 00:07:43 +0000
Subject: [docs] [issue17586] fix typo in contextlib.rst
In-Reply-To: <3ZfDPQ5jTxzPhP@mail.python.org>
Message-ID: <1364774863.94.0.53836210283.issue17586@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for catching this!

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From rovitotv at gmail.com  Mon Apr  1 04:17:46 2013
From: rovitotv at gmail.com (rovitotv at gmail.com)
Date: Mon, 01 Apr 2013 02:17:46 -0000
Subject: [docs] IDLE HOWTO (issue 17583)
Message-ID: <20130401021746.12879.84367@psf.upfronthosting.co.za>

Nice start!!!!


http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst
File Doc/howto/idle.rst (right):

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode4
Doc/howto/idle.rst:4: In this guide, we take a look at the basic
features of `IDLE`
I would replace the word "guide" with FAQ throughout the document
because you are adding a new FAQ after all right?

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode6
Doc/howto/idle.rst:6: are suitable for a new Python programmer. The
scope of this document
which is suitable for a beginner Python programmer.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode8
Doc/howto/idle.rst:8: write programs using the editor and running it.
The scope of this document is intentionally limited to demonstrate the
use of the IDLE editor to create Python programs then run those programs
in the IDLE shell.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode28
Doc/howto/idle.rst:28: 
I wonder if you should add a section for Mac?  The Mac is a little
tricky because every version of OS X has Python built in, but I don't
use that version because I am always running the latest and greatest to
help contribute.  The question is does the Python community support the
Apple version of Python or recommend that a official Python version be
installed?  I am not sure.  Here is more information to start your
research http://www.python.org/getit/mac/

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode43
Doc/howto/idle.rst:43: You can go back to previous commands using the
``UP`` arrow key and
At the moment the UP and DOWN arrow keys do not function the way you
describe.  Although we are talking about changing this behavior and I
hope we do soon :-).  Basically the up history is alt-p and the down
history is alt-n currently.  The arrow keys will move a user around then
they can select a previous line and press enter and that line will be
copied to the >>> prompt for execution or editing.  I am doing a
horrible job explaining it but that is the default behavior at the
moment.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode116
Doc/howto/idle.rst:116: accordingly.
I would add a few sentences about hi-lighting code sections then using
Indent Region (ctrl-]) and Dedent region (ctrl-[).  Also the comment
code section is handy for testing and debugging.  As Ezio explained you
have the room so go for it!

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

From report at bugs.python.org  Mon Apr  1 04:21:56 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 01 Apr 2013 02:21:56 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364782916.47.0.40245383198.issue17583@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Ezio,
   I left a few comments on rietveld.  This is a really nice start to a great FAQ.  Thanks for your contribution I think Python needs a nice FAQ on IDLE.  You might want to add some detail about the right click menu which allows a user to cut, copy, paste, and set breakpoints.  I think a section on the debugger would be excellent.

----------

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

From report at bugs.python.org  Mon Apr  1 04:23:46 2013
From: report at bugs.python.org (Amit Saha)
Date: Mon, 01 Apr 2013 02:23:46 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364783026.34.0.202135142792.issue17583@psf.upfronthosting.co.za>


Amit Saha added the comment:

Hi Todd, thanks for your comments. I wanted to clarify that I intend to make this a HOWTO, not a FAQ.

I hope that's fine?

-Amit.

----------

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

From report at bugs.python.org  Mon Apr  1 05:49:01 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Apr 2013 03:49:01 +0000
Subject: [docs] [issue17586] fix typo in contextlib.rst
In-Reply-To: <3ZfDPQ5jTxzPhP@mail.python.org>
Message-ID: <1364788141.51.0.811375880063.issue17586@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks.

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

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

From report at bugs.python.org  Mon Apr  1 06:25:40 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 01 Apr 2013 04:25:40 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1364790340.3.0.0982214130811.issue16893@psf.upfronthosting.co.za>


Todd Rovito added the comment:

I added roger.serwy to the nosy list.  Terry Reedy is already on the list.  I think this issue will help maintain the IDLE documentation now and in the future. Right now it has to manually be synced between help.txt and idle.rst. Only Python 3.4 is synced right now based on this issue:
http://bugs.python.org/issue5066
  
Zach has done a great job working the issue so I think it should be committed.

----------
nosy: +roger.serwy

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

From report at bugs.python.org  Mon Apr  1 06:55:13 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 01 Apr 2013 04:55:13 +0000
Subject: [docs] [issue17589] Make documentation about macros in C API
	explicit about	rvalue vs statement
In-Reply-To: <1364758755.79.0.998719447408.issue17589@psf.upfronthosting.co.za>
Message-ID: <1364792113.39.0.322309380276.issue17589@psf.upfronthosting.co.za>


Larry Hastings added the comment:

> Py_INCREF usable as an rvalue sounds more like an accident
> than a deliberate feature

I'd go with "misfeature", but in no way is it accidental.  The coding deliberately preserves the rvalue-ness of it, c.f. _Py_REF_DEBUG_COMMA.

----------

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

From report at bugs.python.org  Mon Apr  1 07:28:14 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 01 Apr 2013 05:28:14 +0000
Subject: [docs] [issue17586] fix typo in contextlib.rst
In-Reply-To: <1364788141.51.0.811375880063.issue17586@psf.upfronthosting.co.za>
Message-ID: <CAA77j2Aazoy-yJhCZmEfD3nwnJi+9Ku1MtPYRByfmD8CU4P4Fw@mail.gmail.com>


Tshepang Lekhonkhobe added the comment:

@hettinger You mentioning committing this in your wonderful keynote
talk, http://pyvideo.org/video/1669/keynote-3, and that's how I
checked it out.

----------

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

From report at bugs.python.org  Mon Apr  1 09:57:55 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Apr 2013 07:57:55 +0000
Subject: [docs] [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1364803075.02.0.0319743078252.issue7057@psf.upfronthosting.co.za>


Ned Deily added the comment:

I just noticed that the changes committed earlier for this issue added a reference to the Tcl/Tk 8.6 man pages.  Since there are known problems with using 8.6 with tkinter (for example, Issue16809) and we don't currently ship 8.6 with any of our binary installers, it would be better to reference the 8.5 man pages until the status of 8.6 support is resolved.

----------

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

From report at bugs.python.org  Mon Apr  1 12:40:56 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Apr 2013 10:40:56 +0000
Subject: [docs] [issue1944] Documentation for PyUnicode_AsString (et al.)
	missing.
In-Reply-To: <1364645377.35.0.326877424936.issue1944@psf.upfronthosting.co.za>
Message-ID: <51596435.2010506@egenix.com>


Marc-Andre Lemburg added the comment:

On 30.03.2013 13:09, Mark Lawrence wrote:
> 
> Is it worth applying the patch given the complete rewrite of unicode for 3.3 via PEP393?

PEP 393 only changed the way Unicode is internally stored.
The Unicode API is mostly unaffected by this change.

----------

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

From report at bugs.python.org  Mon Apr  1 12:50:36 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Apr 2013 10:50:36 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1364813436.33.0.197236566515.issue16893@psf.upfronthosting.co.za>


Ned Deily added the comment:

Zach, thanks for addressing most of the comments. The Makefile does now work as intended and more information is retained in the help.txt.

But I'm still troubled by the plaintext rendering, particularly of the inline code markup.  With the `` marks from the reStructuredText directives appearing in the help.txt, the help file as displayed is, IMO, more cluttered and, more importantly, more confusing.  Using `` to delimit displayed plaintext in lieu of more sophisticated text styling is unconventional at best.  I think changing the help file to include such marks would be a step backward.  But that's just one of the more obvious drawbacks of trying to use a plaintext format for help.

Ironically, the Tk text widget is perfectly capable of rendering richer text styles.  But, AFAIK, there hasn't been a use case up to now to support some sort of rich text format (be it rtf or html or rst directly) from a file in IDLE.  My initial thought was to suggest adding some sort of Tk-friendly Sphinx/Docutils builder.  That might be more generally useful but that will probably take a fair amount of work to define and implement.  Then it struck me that having an html-format help file would be able to represent all the existing Sphinx styles and, with the doc changes in the patch, we already have an html file that contains all the help text!  So rather than trying to sync the help file with the IDLE doc in the library, why not just display the library IDLE doc in a browser window?  IDLE already has a menu item and code to launch a web browser for the whole Python documentation set.  It would be easy to adapt that to change the IDLE help menu item to launch a web browser window with the IDLE page and get rid of help.txt.

There are a few issues that would need to be resolved.  The python.org binary installers and most Unix-y distributions can optionally install local copies of the Python doc set to eliminate the need for network access to docs.python.org.  There is platform-specific code in EditorWindow.__init__ to search locally for the doc files, falling back to http://doc.python.org if a local copy is not found.  The simplest approach would be to do the same for IDLE help, however that would have the drawback of there being no help available if the local copy had not been installed and there was no internet access.  Of course, that is the case today for the Python documentation.  If that is not acceptable for the help text, the docs build process could make a copy of a version of the library/idle.html into idlelib or, less desirable, the proposed plain text file could be the fallback.  Also, on Windows, AFAIK, the doc set is usually installed as a chm file which normally opens to the top-level index page in the help viewer.  A question is how to open directly to the IDLE page.  By inspection in the help viewer on Windows 7, it seems that a web browser.open call to a URL that appends '::/library/idle.html' to the existing pythonxxx.chm URL will open a browser window to the right page.  But there may be a better way to do that.

>From the user's perspective, ISTM that having the help in the rich format possible with the existing doc html would be a huge advantage over what can be provided with any plain text format.  Comments?

----------

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

From report at bugs.python.org  Mon Apr  1 13:44:22 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Apr 2013 11:44:22 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1364816662.46.0.0109012558721.issue16893@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Great idea. Using a browser to display help text has become pretty common. For many games, for instance, this has superseded .pdf manuals, which supercedes paper. Unless there is already a tk extension to display html this seems like a good idea. We could even put a link to a youtube video tutorial if there is one or if someone makes one. (There seems to be some creative types interested in helping with Idle. This would be a good way for someone to contribute.

----------

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

From report at bugs.python.org  Mon Apr  1 13:59:04 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 01 Apr 2013 11:59:04 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1364817544.21.0.995123615242.issue16893@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Ned,
   Using a web browser is a great idea!!!!  I like it because it removes code from IDLE making IDLE even simpler (and better).  Besides it would take us forever to duplicate some of the functionally that exists in today's modern web browser.  

Zach,
   What do you think?

Terry,
   What is this paper technology that you speak of?  A youtube video showing off IDLE would be fantastic.

----------

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

From report at bugs.python.org  Mon Apr  1 21:40:19 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 01 Apr 2013 19:40:19 +0000
Subject: [docs] [issue17566] Document that importlib.abc.Loader.module_repr
	is	abstract and thus needed by various other ABCs
In-Reply-To: <1364486422.93.0.992071692104.issue17566@psf.upfronthosting.co.za>
Message-ID: <1364845219.29.0.117747302284.issue17566@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Barry, Eric: can you clarify why you made module_repr an abstractmethod and thus require its overloading? It seems like its default is fine and you should only need to overload it when you can say something better than the default.

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

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

From report at bugs.python.org  Mon Apr  1 21:59:23 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 01 Apr 2013 19:59:23 +0000
Subject: [docs] [issue17566] Document that importlib.abc.Loader.module_repr
	is	abstract and thus needed by various other ABCs
In-Reply-To: <1364845219.29.0.117747302284.issue17566@psf.upfronthosting.co.za>
Message-ID: <20130401155918.59ccd480@anarchist>


Barry A. Warsaw added the comment:

On Apr 01, 2013, at 07:40 PM, Brett Cannon wrote:

>Barry, Eric: can you clarify why you made module_repr an abstractmethod and
>thus require its overloading?

Maybe Eric can, but I can't. ;) I honestly don't remember why we made it
abstract, except perhaps because we put it in the Loader class which already
had an abstract load_module() method.

>It seems like its default is fine and you should only need to overload it
>when you can say something better than the default.

Note that moduleobject.c can handle the case of a missing or uncallable
module_repr() attribute.  Then it implements the defaults specified in PEP
420.

----------

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

From report at bugs.python.org  Mon Apr  1 22:11:25 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Apr 2013 20:11:25 +0000
Subject: [docs] [issue17359] python modules.zip is not documented
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1364847085.48.0.629008432915.issue17359@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I don't think that's enough documentation for the feature. There's a whole PEP 338 just for the -m option due to the subtle issue associated with the "run a module" logic, so I'd expect somewhat more detail or an update of the PEP with the needed details.

This page would be the appropriate place for a section on the topic, I guess:

http://docs.python.org/3/library/runpy.html

A mention on this page would also be good:

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

Since the feature was added in Python 2.6, the documentation patch should also be backported to the Python 2.6 and 2.7.

PS: I wonder why the documentation search doesn't even return the page you mentioned.

----------

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

From report at bugs.python.org  Mon Apr  1 22:11:44 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Apr 2013 20:11:44 +0000
Subject: [docs] [issue17359] python modules.zip is not documented
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1364847104.41.0.85756244832.issue17359@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
versions: +Python 2.6

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

From report at bugs.python.org  Mon Apr  1 22:18:48 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Apr 2013 20:18:48 +0000
Subject: [docs] [issue17359] python modules.zip is not documented
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1364847528.76.0.153071659377.issue17359@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.6, Python 3.2

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

From report at bugs.python.org  Mon Apr  1 22:20:07 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Apr 2013 20:20:07 +0000
Subject: [docs] [issue17571] broken links on Lib/datetime.py docstring
In-Reply-To: <1364543666.79.0.123809819447.issue17571@psf.upfronthosting.co.za>
Message-ID: <1364847607.62.0.713807472481.issue17571@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Here's a patch.

----------
keywords: +patch
stage:  -> commit review
type:  -> enhancement
Added file: http://bugs.python.org/file29648/issue17571.diff

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

From ezio.melotti at gmail.com  Mon Apr  1 22:59:10 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 01 Apr 2013 20:59:10 -0000
Subject: [docs] IDLE HOWTO (issue 17583)
Message-ID: <20130401205910.18857.47154@psf.upfronthosting.co.za>


http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst
File Doc/howto/idle.rst (right):

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode4
Doc/howto/idle.rst:4: In this guide, we take a look at the basic
features of `IDLE`
On 2013/04/01 04:17:46, Todd.Rovito wrote:
> I would replace the word "guide" with FAQ throughout the document
because you
> are adding a new FAQ after all right?

This looks more like a guide/howto to me.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode6
Doc/howto/idle.rst:6: are suitable for a new Python programmer. The
scope of this document
On 2013/04/01 04:17:46, Todd.Rovito wrote:
> which is suitable for a beginner Python programmer.

which is suitable for beginner Python programmers.

http://bugs.python.org/review/17583/diff/7736/Doc/howto/idle.rst#newcode8
Doc/howto/idle.rst:8: write programs using the editor and running it.
On 2013/04/01 04:17:46, Todd.Rovito wrote:
> The scope of this document is intentionally limited to demonstrate the
use of
> the IDLE editor to create Python programs then run those programs in
the IDLE
> shell.

This sentence will get outdated as soon as new things will be added, so
it could either be removed, or replaced with something a little more
vague (e.g. "This document is only meant to provide a basic introduction
to IDLE features.").

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

From report at bugs.python.org  Mon Apr  1 23:00:42 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Apr 2013 21:00:42 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364850042.83.0.413850297393.issue17583@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I added a few more comments.

To clarify, when I said two documents, I meant that there will be only a single HOWTO, but on 2.7 it will be specific to Python 2, whereas on 3.x it will be specific to Python 3.

----------

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

From report at bugs.python.org  Mon Apr  1 23:04:35 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 01 Apr 2013 21:04:35 +0000
Subject: [docs] [issue17566] Document that importlib.abc.Loader.module_repr
	is	abstract and thus needed by various other ABCs
In-Reply-To: <1364486422.93.0.992071692104.issue17566@psf.upfronthosting.co.za>
Message-ID: <1364850275.51.0.701069525497.issue17566@psf.upfronthosting.co.za>


Brett Cannon added the comment:

If Eric doesn't have anything to add then I would like to change importlib.abc.Loader.module_repr() to no longer be abstract and the default to be defined as ``return repr(module)``. Else it should be entirely optional and not have a default implementation, but having it be required as abstract doesn't seem quite right to me.

----------

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

From report at bugs.python.org  Mon Apr  1 23:35:35 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 01 Apr 2013 21:35:35 +0000
Subject: [docs] [issue17566] Document that importlib.abc.Loader.module_repr
	is	abstract and thus needed by various other ABCs
In-Reply-To: <1364486422.93.0.992071692104.issue17566@psf.upfronthosting.co.za>
Message-ID: <1364852135.7.0.100514217221.issue17566@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I was going to blame Barry, but I see he beat me to it :)

It looks like an oversight, and it shouldn't be abstract.

----------

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

From report at bugs.python.org  Mon Apr  1 23:55:25 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 01 Apr 2013 21:55:25 +0000
Subject: [docs] [issue17566] Document that importlib.abc.Loader.module_repr
	is	abstract and thus needed by various other ABCs
In-Reply-To: <1364850275.51.0.701069525497.issue17566@psf.upfronthosting.co.za>
Message-ID: <20130401175523.703e6657@anarchist>


Barry A. Warsaw added the comment:

On Apr 01, 2013, at 09:04 PM, Brett Cannon wrote:

>If Eric doesn't have anything to add then I would like to change
>importlib.abc.Loader.module_repr() to no longer be abstract and the default
>to be defined as ``return repr(module)``. Else it should be entirely optional
>and not have a default implementation, but having it be required as abstract
>doesn't seem quite right to me.

I have no problem making it non-abstract, but I don't think you need to define
a default.  The built-in module object already does the right thing by
default.  Maybe that's why we (mistakenly?) made it abstract.  We might have
hoped to document the API but not provide a default implementation, since if
module_repr() is not both defined and callable, moduleobject.c already does
the right thing.

But at least there are unit tests so it should be hard for you to break
things. :)

----------

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

From report at bugs.python.org  Mon Apr  1 23:59:36 2013
From: report at bugs.python.org (Amit Saha)
Date: Mon, 01 Apr 2013 21:59:36 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364853576.32.0.395478386721.issue17583@psf.upfronthosting.co.za>


Amit Saha added the comment:

Thanks Ezio. I am almost done with incorporating the changes suggested and will submit a patch sometime in the next day or so.

----------

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

From report at bugs.python.org  Tue Apr  2 00:22:45 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 01 Apr 2013 22:22:45 +0000
Subject: [docs] [issue17566] Document that importlib.abc.Loader.module_repr
	is	abstract and thus needed by various other ABCs
In-Reply-To: <1364486422.93.0.992071692104.issue17566@psf.upfronthosting.co.za>
Message-ID: <1364854965.61.0.519341211669.issue17566@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Totally optional and no default argument it is.

----------
assignee: docs at python -> brett.cannon

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

From report at bugs.python.org  Tue Apr  2 00:38:36 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Apr 2013 22:38:36 +0000
Subject: [docs] [issue17359] Mention "__main__.py" explicit in command line
	docs
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1364855915.97.0.678953003039.issue17359@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The previous title was not accurate, as the directory and zipfile execution feature is documented at http://docs.python.org/2/using/cmdline.html#interface-options

It is also documented in http://docs.python.org/3/library/runpy#runpy.run_path

----------
title: python modules.zip is not documented -> Mention "__main__.py" explicit in command line docs

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

From report at bugs.python.org  Tue Apr  2 00:38:46 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Apr 2013 22:38:46 +0000
Subject: [docs] [issue17359] Mention "__main__.py" explicitly in command
	line docs
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1364855926.62.0.13090343283.issue17359@psf.upfronthosting.co.za>


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


----------
title: Mention "__main__.py" explicit in command line docs -> Mention "__main__.py" explicitly in command line docs

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

From report at bugs.python.org  Tue Apr  2 00:42:07 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Apr 2013 22:42:07 +0000
Subject: [docs] [issue17359] Mention "__main__.py" explicitly in command
	line docs
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1364856127.57.0.98710729645.issue17359@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

There's also a problem where the CLI docs claim __main__.py support was added in 2.5 - that's not accurate, it was only added in 2.6.

----------

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

From report at bugs.python.org  Tue Apr  2 01:07:11 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Apr 2013 23:07:11 +0000
Subject: [docs] [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1364857629.87.0.363497332116.issue14097@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Attached a new patch that should address all the points except the last example with Fibonacci.

----------
stage: needs patch -> patch review
versions:  -Python 3.2
Added file: http://bugs.python.org/file29649/issue14097-2.diff

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

From ezio.melotti at gmail.com  Tue Apr  2 01:19:18 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 01 Apr 2013 23:19:18 -0000
Subject: [docs] Improve the "introduction" page of the tutorial (issue
	14097)
Message-ID: <20130401231918.16620.42072@psf.upfronthosting.co.za>


http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst
File Doc/tutorial/introduction.rst (left):

http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst#oldcode294
Doc/tutorial/introduction.rst:294: >>> word[:2]    # The first two
characters
Most of these examples have been reorganized to introduce the concept
more gradually.

http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst#oldcode412
Doc/tutorial/introduction.rst:412: About Unicode
I think this can be postponed until bytes are introduced.  Maybe it
should be mentioned briefly that strings support Unicode though.

http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst#oldcode551
Doc/tutorial/introduction.rst:551: object!  We'll come back to *object
semantics* later.
This is a fundamental concept, and this lighthearted introduction only
serves to add more confusion IMHO.
I removed the example for now, but this should be covered at a later
point.

http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst
File Doc/tutorial/introduction.rst (right):

http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst#newcode203
Doc/tutorial/introduction.rst:203: 'unununium'
All the changes from this point onward are new in this patch, the
previous patch didn't include any of these.

http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst#newcode232
Doc/tutorial/introduction.rst:232: 
Double empty line.

http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst#newcode235
Doc/tutorial/introduction.rst:235: ::
This can be moved at the end of the previous sentence; also the previous
line is too long.

http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst#newcode280
Doc/tutorial/introduction.rst:280: One way to remember how slices work
is to think of the indices as pointing
While this is useful for slicing, it doesn't work too well for indexing,
where placing the index *below* (rather than *in between*) works better.
Should I show both the examples?

http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst#newcode286
Doc/tutorial/introduction.rst:286: | H | e | l | p | A |
The sample text should be changed.

http://bugs.python.org/review/14097/diff/7743/Doc/tutorial/introduction.rst#newcode514
Doc/tutorial/introduction.rst:514: >>> while b < 1000:
This still needs to be changed, but I'm not sure how yet.
I think it would be best to introduce "if" and "for" first, but this is
done in the next page IIRC, so it might be better to move this whole
example in the next page.

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

From report at bugs.python.org  Tue Apr  2 03:43:07 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 02 Apr 2013 01:43:07 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1364866987.3.0.62309093198.issue8913@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can issue8913-3.patch be committed or are any further tweaks needed?

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Tue Apr  2 03:46:13 2013
From: report at bugs.python.org (Todd Rovito)
Date: Tue, 02 Apr 2013 01:46:13 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364867173.4.0.230442357566.issue17583@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Sorry about using the wrong word, I should of used HowTo not FAQ.  I really meant to suggest replacing guide with the word HowTo.  A HowTo would be perfect!!!!  Sorry about the confusion.  Thanks again.

----------

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

From report at bugs.python.org  Tue Apr  2 04:12:46 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 02 Apr 2013 02:12:46 +0000
Subject: [docs] [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1364868766.78.0.552777678823.issue10379@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

msg120978 "The bug has been fixed upstream...".  Have I missed something as on Windows Vista...?

c:\Users\Mark\MyPython>python
Python 3.3.1rc1 (v3.3.1rc1:92c2cfb92405, Mar 25 2013, 22:39:19) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale; print(locale.format('%.0f KB', 100))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python33\lib\locale.py", line 193, in format
    "format specifier, %s not valid") % repr(percent))
ValueError: format() must be given exactly one %char format specifier, '%.0f KB' not valid

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Tue Apr  2 11:21:01 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Apr 2013 09:21:01 +0000
Subject: [docs] [issue17359] Mention "__main__.py" explicitly in command
	line docs
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1364894461.15.0.523629954009.issue17359@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I still don't think that the available documentation is detailed enough. It leaves too many unanswered question, e.g.

* What happens if you have both __init__.py and __main__.py in a directory or a ZIP file ?

* What does "the script name is added to the start of sys.path" mean when using a ZIP file ?

* What are the implications of "Directories and zipfiles containing a __main__.py file at the top level are now considered valid Python scripts." and where does this scope end ? The wording suggests that you can also import such directories or ZIP files.

* How are sys.path, __name__ and possibly __path__ setup when using this approach of running a dir/package/ZIP file ?

and probably a few more. The above can all be answered using trial-and-error, but it would be better to actually document the intended behavior.

Some quirks I found (dir is a directory with both __init__.py and __main__.py):

* "python2.6 dir" runs the __main__.py file, while "python2.6 -m dir" does not. Both work in the same way in Python 2.7.

* In Python 2.7, the two approaches differ in the way sys.path[0] is setup: "python2.7 dir" causes this to be set to "dir", while "python2.7 -m dir" results in "".

Background: The reason why I'm interested in this is that we are trying to mimic the Python command line interface with pyrun (http://www.egenix.com/products/python/PyRun/).

----------

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

From report at bugs.python.org  Tue Apr  2 12:23:53 2013
From: report at bugs.python.org (Amit Saha)
Date: Tue, 02 Apr 2013 10:23:53 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364898230.38.0.809312332946.issue17583@psf.upfronthosting.co.za>


Amit Saha added the comment:

I have tried to incorporate most of the suggestions and made some other changes as well. Hope it looks better now.

I haven't yet split it into two separate versions.

----------
Added file: http://bugs.python.org/file29654/idle.patch

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

From report at bugs.python.org  Tue Apr  2 13:32:54 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 02 Apr 2013 11:32:54 +0000
Subject: [docs] [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1364902374.8.0.228873822843.issue10379@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Barry meant that the upstream program that triggered this error has been changed to call format_string() instead of format(). The bug still exists in format().

My suggestion is to have format() be an alias for format_string(). Deprecating format() is an optional step, but may not be worth the hassle.

----------

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

From report at bugs.python.org  Tue Apr  2 15:35:48 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 02 Apr 2013 13:35:48 +0000
Subject: [docs] [issue10379] locale.format() input regression
In-Reply-To: <1364902374.8.0.228873822843.issue10379@psf.upfronthosting.co.za>
Message-ID: <20130402093543.76679230@anarchist>


Barry A. Warsaw added the comment:

On Apr 02, 2013, at 11:32 AM, Eric V. Smith wrote:

>My suggestion is to have format() be an alias for
>format_string(). Deprecating format() is an optional step, but may not be
>worth the hassle.

Agreed on both counts.

----------

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

From report at bugs.python.org  Tue Apr  2 17:04:58 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 02 Apr 2013 15:04:58 +0000
Subject: [docs] [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1364915098.27.0.347338387128.issue10379@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

So I guess the question is: would this be a bug fix and applied to 2.7 and 3.3, or just an enhancement for 3.4?

I think it would be a bug fix and thus should be backported. It's not like we'd be breaking any working code, unless it was expecting the exception.

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

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

From report at bugs.python.org  Tue Apr  2 17:38:06 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 02 Apr 2013 15:38:06 +0000
Subject: [docs] [issue10379] locale.format() input regression
In-Reply-To: <1364915098.27.0.347338387128.issue10379@psf.upfronthosting.co.za>
Message-ID: <20130402113803.77dde4cd@anarchist>


Barry A. Warsaw added the comment:

On Apr 02, 2013, at 03:04 PM, Eric V. Smith wrote:

>I think it would be a bug fix and thus should be backported. It's not like
>we'd be breaking any working code, unless it was expecting the exception.

That would be my preference.

----------

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

From report at bugs.python.org  Wed Apr  3 03:27:35 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 03 Apr 2013 01:27:35 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364952455.04.0.448047374987.issue17583@psf.upfronthosting.co.za>


?ric Araujo added the comment:

This is a great idea, thank you.

FYI You can share text and images with a diff file: if you call ?hg add path/to/images? and create the diff with the --git option, it will use an extended unified diff format which includes binary changes.  Our review system is not compatible with that format though, so you can simply attach the files here.

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

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

From report at bugs.python.org  Wed Apr  3 03:29:53 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 03 Apr 2013 01:29:53 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1364952593.1.0.506899600585.issue8913@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Ezio, you are the latest reviewer, do you have outstanding comments?

----------

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

From report at bugs.python.org  Wed Apr  3 03:35:52 2013
From: report at bugs.python.org (Amit Saha)
Date: Wed, 03 Apr 2013 01:35:52 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364952952.02.0.538386038842.issue17583@psf.upfronthosting.co.za>


Amit Saha added the comment:

Hello ?ric Araujo, thanks. Oh I thought it did support, and hence I created the diff in exactly the way you mention.

i also went ahead and tested it by 'hg import' -ing it into a cpython clone and i was all excited to see all my images there :-)

But, yeah I can certainly attach the images separately.

----------

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

From report at bugs.python.org  Wed Apr  3 06:47:46 2013
From: report at bugs.python.org (paul j3)
Date: Wed, 03 Apr 2013 04:47:46 +0000
Subject: [docs] [issue15427] Describe use of args parameter
	of	argparse.ArgumentParser.parse_args
In-Reply-To: <1342995154.12.0.902919829048.issue15427@psf.upfronthosting.co.za>
Message-ID: <1364964465.88.0.56695967004.issue15427@psf.upfronthosting.co.za>


paul j3 added the comment:

The 'args=' parameter is the same as the first positional parameter used in most of the examples.  That is normal Python behavior.

15.4.4.5. Beyond sys.argv
explains this alternative way of specifying argv.

Still 2 bullet points could be added to 15.4.4.

- args - A list of strings, default is sys.argv[1:] (link to 15.4.4.5.)
- namespace - A Namespace object, default is a new Namespace (link to 15.4.4.6.)

Maybe a 15.4.4.5. example using args=['1', '2', '3', '4'] would also be helpful.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Wed Apr  3 08:44:01 2013
From: report at bugs.python.org (paul j3)
Date: Wed, 03 Apr 2013 06:44:01 +0000
Subject: [docs] [issue15427] Describe use of args parameter
	of	argparse.ArgumentParser.parse_args
In-Reply-To: <1342995154.12.0.902919829048.issue15427@psf.upfronthosting.co.za>
Message-ID: <1364971441.05.0.274708389949.issue15427@psf.upfronthosting.co.za>


paul j3 added the comment:

This patch to argparse.rst adds the argument points to parse_args().  

It also adds two points to the 'Upgrading optparse code' section, one about using 'nargs=argparse.REMAINDER', and other about 'parse_known_args()'.

I'm not entirely happy with the format of the internal hyperlinks.

----------
keywords: +patch
Added file: http://bugs.python.org/file29661/remainder.patch

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

From report at bugs.python.org  Wed Apr  3 08:46:48 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 03 Apr 2013 06:46:48 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1364971608.85.0.344889157851.issue8913@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

My only suggestion would be that the datetime example would be better if it actually used a time portion, similar to the strftime example above it. Otherwise, it looks good.

----------

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

From report at bugs.python.org  Wed Apr  3 09:18:43 2013
From: report at bugs.python.org (paul j3)
Date: Wed, 03 Apr 2013 07:18:43 +0000
Subject: [docs] [issue15427] Describe use of args parameter
	of	argparse.ArgumentParser.parse_args
In-Reply-To: <1342995154.12.0.902919829048.issue15427@psf.upfronthosting.co.za>
Message-ID: <1364973523.72.0.0691205733897.issue15427@psf.upfronthosting.co.za>


paul j3 added the comment:

I changed the reference to the optparse allow_interspersed_args attribute to the disable_interspersed_args() method.

----------
Added file: http://bugs.python.org/file29662/remainder.patch

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

From report at bugs.python.org  Wed Apr  3 10:15:45 2013
From: report at bugs.python.org (Heikki Partanen)
Date: Wed, 03 Apr 2013 08:15:45 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1364976945.89.0.150409399816.issue8913@psf.upfronthosting.co.za>


Heikki Partanen added the comment:

Improved the datetime example to have time part

----------
Added file: http://bugs.python.org/file29663/issue8913-4.patch

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

From report at bugs.python.org  Wed Apr  3 11:22:47 2013
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 03 Apr 2013 09:22:47 +0000
Subject: [docs] [issue17623] Typo in Doc/whatsnew/3.3.rst
Message-ID: <1364980967.1.0.766058009466.issue17623@psf.upfronthosting.co.za>


New submission from Thomas Heller:

Typo:  trucate instead of truncate

----------
assignee: docs at python
components: Documentation
files: work.patch
keywords: patch
messages: 185901
nosy: docs at python, theller
priority: normal
severity: normal
status: open
title: Typo in Doc/whatsnew/3.3.rst
Added file: http://bugs.python.org/file29664/work.patch

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

From report at bugs.python.org  Wed Apr  3 12:18:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 03 Apr 2013 10:18:14 +0000
Subject: [docs] [issue17623] Typo in Doc/whatsnew/3.3.rst
In-Reply-To: <1364980967.1.0.766058009466.issue17623@psf.upfronthosting.co.za>
Message-ID: <3Zgjsx2yLHzQ1G@mail.python.org>


Roundup Robot added the comment:

New changeset 5dc976ce1b50 by R David Murray in branch '3.3':
#17623: fix whatsnew typo
http://hg.python.org/cpython/rev/5dc976ce1b50

New changeset 3c7a9c31001c by R David Murray in branch 'default':
Merge #17623: fix whatsnew typo
http://hg.python.org/cpython/rev/3c7a9c31001c

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

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

From report at bugs.python.org  Wed Apr  3 12:18:37 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Apr 2013 10:18:37 +0000
Subject: [docs] [issue17623] Typo in Doc/whatsnew/3.3.rst
In-Reply-To: <1364980967.1.0.766058009466.issue17623@psf.upfronthosting.co.za>
Message-ID: <1364984317.83.0.289364451491.issue17623@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Apr  3 12:47:03 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 03 Apr 2013 10:47:03 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1364986023.52.0.739689263491.issue8913@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

That looks great. Thanks!

----------

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

From report at bugs.python.org  Wed Apr  3 13:09:50 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Apr 2013 11:09:50 +0000
Subject: [docs] [issue17624] Confusing TypeError in urllib.urlopen
In-Reply-To: <1364985905.97.0.615690774313.issue17624@psf.upfronthosting.co.za>
Message-ID: <1364987390.27.0.436642177585.issue17624@psf.upfronthosting.co.za>


R. David Murray added the comment:

In Python3 the equivalent urllib.request.urlopen call produces:

  ValueError: unknown url type:

So this is effectively already fixed (although that error message should be doing a repr on the value, so I fixed that).  

We don't in general document every exception that might be raised by a function.  Here the TypeError is coming from treating the url as a local filename.  I don't think it is appropriate to document all the errors that can arise from treating the URL as a filename in the urllib docs, so I don't believe any changes should be made here.  I've added the 'doc' componennt, so if someone from the doc team disagrees with me they can reopen the issue.

As for your specific concern, the application has more problems (as in, security problems) than crashing because of a TypeError if it is composing the URL from user input such that the URL gets treated as a local filename.  (This is arguably a bug in urllib, that it appears has been fixed in Python3.)

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Apr  3 18:43:15 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 03 Apr 2013 16:43:15 +0000
Subject: [docs] [issue13249] argparse.ArgumentParser() lists arguments in
	the wrong	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1365007394.95.0.99982929489.issue13249@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can someone please review the latest patch and commit if appropriate.

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Wed Apr  3 18:50:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 03 Apr 2013 16:50:46 +0000
Subject: [docs] [issue15940] Time module: effect of locale
In-Reply-To: <1347559427.35.0.589419592153.issue15940@psf.upfronthosting.co.za>
Message-ID: <3ZgtZt0tl9zMWp@mail.python.org>


Roundup Robot added the comment:

New changeset ee5add45bf9d by Terry Jan Reedy in branch '3.3':
Issue #15940: Specify effect of locale on time functions.
http://hg.python.org/cpython/rev/ee5add45bf9d

New changeset 5ffb808683e1 by Terry Jan Reedy in branch '2.7':
Issue #15940: Specify effect of locale on time functions.
http://hg.python.org/cpython/rev/5ffb808683e1

New changeset a6d5fde72843 by Terry Jan Reedy in branch '3.3':
Issue #15940: Replace tab.
http://hg.python.org/cpython/rev/a6d5fde72843

New changeset b7d2cb2214d8 by Terry Jan Reedy in branch '2.7':
Issue #15940: Replace tab.
http://hg.python.org/cpython/rev/b7d2cb2214d8

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

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

From report at bugs.python.org  Wed Apr  3 19:25:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 03 Apr 2013 17:25:13 +0000
Subject: [docs] [issue15940] Time module: effect of locale
In-Reply-To: <1347559427.35.0.589419592153.issue15940@psf.upfronthosting.co.za>
Message-ID: <3ZgvLc6TF2zR0l@mail.python.org>


Roundup Robot added the comment:

New changeset 3daa20ce817e by Terry Jan Reedy in branch '3.3':
Issue #15940: NEWS entry
http://hg.python.org/cpython/rev/3daa20ce817e

New changeset be9273375b61 by Terry Jan Reedy in branch '2.7':
Issue #15940: NEWS entry
http://hg.python.org/cpython/rev/be9273375b61

----------

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

From report at bugs.python.org  Wed Apr  3 19:26:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 03 Apr 2013 17:26:15 +0000
Subject: [docs] [issue15940] Time module: effect of locale
In-Reply-To: <1347559427.35.0.589419592153.issue15940@psf.upfronthosting.co.za>
Message-ID: <1365009975.49.0.666134096776.issue15940@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Apr  4 01:25:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Apr 2013 23:25:57 +0000
Subject: [docs] [issue15331] Codecs docs should explain that the
	bytes-bytes	shorthand aliases are missing
In-Reply-To: <1342091074.63.0.386956250979.issue15331@psf.upfronthosting.co.za>
Message-ID: <1365031557.03.0.989864164041.issue15331@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Should they just be removed from the table then?

----------
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Thu Apr  4 01:43:43 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Apr 2013 23:43:43 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1365032623.74.0.216985375068.issue17221@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Serhiy, can you update and commit the patch?
A new IDLE section would be especially useful for #17506.

----------

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

From report at bugs.python.org  Thu Apr  4 02:27:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Apr 2013 00:27:39 +0000
Subject: [docs] [issue15964] SyntaxError in asdl when building 2.7 with
	system Python	3
In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za>
Message-ID: <1365035259.11.0.118705192816.issue15964@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Do you want to provide a patch and test that it works?

----------

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

From report at bugs.python.org  Thu Apr  4 02:36:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Apr 2013 00:36:15 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1365035775.22.0.342814296144.issue17221@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Has anyone checked that the last patch is basically correct?
Which is to say, does every entry removed get put back someplace?

I tried to import the last patch, NEWS-3.4_3.patch
73/74 chumks were applied, 1 rejected, which can be hand edited.
I am willing to do that if the sanity check has been done.
(I personally would have done this in multiple patches, like moving only IDLE issues for one patch, that would have been easier to check.)

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

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

From report at bugs.python.org  Thu Apr  4 02:47:10 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Apr 2013 00:47:10 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1365036430.15.0.350720049075.issue17221@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

That was easy. The .patch has a space at the end of this line:
- Issue #17028: Allowed Python arguments to be supplied to the Windows
which the file, of course, does not. That removed and it applies cleanly.

----------

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

From report at bugs.python.org  Thu Apr  4 02:53:13 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Apr 2013 00:53:13 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1365036792.65.0.784360016538.issue17221@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There is also this double entry before and after the patch. This is current patch with space and duplicate removed.

- Issue #15116: Remove references to appscript as it is no longer being
  supported.

- Issue #15116: Remove references to appscript as it is no longer being
  supported.

----------
Added file: http://bugs.python.org/file29676/NEWS-3.4_4.diff

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

From report at bugs.python.org  Thu Apr  4 03:04:12 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Apr 2013 01:04:12 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1365037452.49.0.327870405604.issue8913@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I left another review with a couple of suggestions.
The patch is OK, it's just that the examples look a bit meaningless to me.

----------
stage:  -> patch review
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Thu Apr  4 04:21:12 2013
From: report at bugs.python.org (paul j3)
Date: Thu, 04 Apr 2013 02:21:12 +0000
Subject: [docs] [issue16399] argparse: append action with default list adds
	to list	instead of overriding
In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>
Message-ID: <1365042072.82.0.103989209443.issue16399@psf.upfronthosting.co.za>


paul j3 added the comment:

The test file, test_argparse.py, has a test case for this:
'class TestOptionalsActionAppendWithDefault'

    argument_signatures = [Sig('--baz', action='append', default=['X'])]
    successes = [
        ('--baz a --baz b', NS(baz=['X', 'a', 'b'])),
    ]

----------
nosy: +paul.j3

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

From report at bugs.python.org  Thu Apr  4 04:32:42 2013
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 04 Apr 2013 02:32:42 +0000
Subject: [docs] [issue15964] SyntaxError in asdl when building 2.7 with
	system Python	3
In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za>
Message-ID: <1365042762.84.0.880353872672.issue15964@psf.upfronthosting.co.za>


Roger Serwy added the comment:

The attached patch allows the same parser code to run under Python 2 and Python 3. I'm not sure how to test it other than by running the test suite which passed.

----------
Added file: http://bugs.python.org/file29677/patch_2and3.py

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

From report at bugs.python.org  Thu Apr  4 07:05:36 2013
From: report at bugs.python.org (Heikki Partanen)
Date: Thu, 04 Apr 2013 05:05:36 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1365051936.79.0.378990516563.issue8913@psf.upfronthosting.co.za>


Heikki Partanen added the comment:

The examples in the previous patches were trying to show some "real-worldish" use cases, but I admit that they don't fit in that well to the existing examples shown in the docs.

The new examples Ezio suggested are more straightforward and better in line with existing docs, so uploaded a new patch with updated examples.

----------
Added file: http://bugs.python.org/file29678/issue8913-5.patch

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

From report at bugs.python.org  Thu Apr  4 08:18:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 04 Apr 2013 06:18:38 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <3ZhDW158HfzQyQ@mail.python.org>


Roundup Robot added the comment:

New changeset 40f582a73901 by Ezio Melotti in branch '3.3':
#8913: add examples and docs for date/time/datetime.__format__.  Patch by Heikki Partanen.
http://hg.python.org/cpython/rev/40f582a73901

New changeset 8dd7f7134700 by Ezio Melotti in branch 'default':
#8913: merge with 3.3.
http://hg.python.org/cpython/rev/8dd7f7134700

New changeset 0dac103a41bb by Ezio Melotti in branch '2.7':
#8913: add examples and docs for date/time/datetime.__format__.  Patch by Heikki Partanen.
http://hg.python.org/cpython/rev/0dac103a41bb

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

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

From report at bugs.python.org  Thu Apr  4 08:19:16 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Apr 2013 06:19:16 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1365056356.62.0.0900952365278.issue8913@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: behavior -> enhancement

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

From e.sergeev at student.unimelb.edu.au  Tue Apr  2 08:11:56 2013
From: e.sergeev at student.unimelb.edu.au (Evgeni Sergeev)
Date: Tue, 2 Apr 2013 17:11:56 +1100
Subject: [docs] Documentation improvement suggestion
Message-ID: <CAJWmTpuK3jftaOFB9YoQLMozRX7oKjmOmN-mv7QexZE=YwQrYQ@mail.gmail.com>

Proposed improvement for the page
http://docs.python.org/2/library/stdtypes.html#set

The elements of a set must be hashable.
The elements of a set must be :term:`hashable`.

From ksmith1 at telus.net  Tue Apr  2 22:08:49 2013
From: ksmith1 at telus.net (Kevin Smith)
Date: Tue, 02 Apr 2013 12:08:49 -0800
Subject: [docs] Documentation Bug frm ActivePython User Guide
Message-ID: <515B3AD1.1070100@telus.net>

             Hello,
    I tried the code from this section in the guide ...

4.4. break <../reference/simple_stmts.html#break> and continue 
<../reference/simple_stmts.html#continue> Statements, and else 
<../reference/compound_stmts.html#else> Clauses on Loops

The break <../reference/simple_stmts.html#break> statement, like in C, 
breaks out of the smallest enclosing for 
<../reference/compound_stmts.html#for> or while 
<../reference/compound_stmts.html#while> loop.

The continue <../reference/simple_stmts.html#continue> statement, also 
borrowed from C, continues with the next iteration of the loop.

Loop statements may have an else clause; it is executed when the loop 
terminates through exhaustion of the list (with for 
<../reference/compound_stmts.html#for>) or when the condition becomes 
false (with while <../reference/compound_stmts.html#while>), but not 
when the loop is terminated by a break 
<../reference/simple_stmts.html#break> statement. This is exemplified by 
the following loop, which searches for prime numbers:

Example code:

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...             print n, 'equals', x, '*', n/x
...             break
...     else:
...         # loop fell through without finding a factor
...         print n, 'is a prime number'
...

Output:

2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

Here is the output that I got:

3 is a prime number
4 equals 2 * 2
5 is a prime number
5 is a prime number
5 is a prime number
6 equals 2 * 3
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
8 equals 2 * 4
9 is a prime number
9 equals 3 * 3
 >>>

As you can see, the number two was skipped over. I have discovered that 
the 1st iteration of the second for loop counting for x when n is 2 
yields an empty range list [].
Typing range(2,2) ...  (which is what the 1st iteration of both loops 
would yield for the second range list) ... in the shell outputs "[]" and 
so the program doesn't execute the
if statement. It just jumps back to the first for line for n and n goes 
to 3.
Then it seems to work til it gets to 9 where we can see that it thinks 9 
is a prime
I haven't yet figured out where that fault lies.
When I add lines to print n and x thru each iteration of each for loop, 
x doesn't count properly.

With this code here you cane see how the loops are counting. ( I have 
reformatted the output so as to see it easier.)

for n in range(2,10):
    print "n = ",n
   
    for x in range(2,n):
        print "x = ",x

OUTPUT:
n =  2
n =  3 x =  2
n =  4 x =  2 x =  3
n =  5 x =  2 x =  3 x =  4
n =  6 x =  2 x =  3 x =  4 x =  5
n =  7 x =  2 x =  3 x =  4 x =  5 x =  6
n =  8 x =  2 x =  3 x =  4 x =  5 x =  6 x =  7
n =  9 x =  2 x =  3 x =  4 x =  5 x =  6 x =  7 x =  8

Notice on the first iteration  of n = 2, x is not counted nor printed.
Because when range(2,2) is run it yields an empty list.
x always lags behind by 1 which is I think why it screws up at 9. 
Actually now if I remember right ... from the debugging process x starts 
miscounting after 8 again.
Anyway, I spent hours trying to figure this out.
Maybe the break staement is the cause ?

Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130402/1cdfb0a1/attachment-0001.html>

From anthony at firebrandtech.com  Thu Apr  4 01:42:13 2013
From: anthony at firebrandtech.com (Anthony Dodd)
Date: Wed, 3 Apr 2013 18:42:13 -0500
Subject: [docs] Typo In Documentation
Message-ID: <CAJvDtcLspaEyBE1_-Pkv+zsqE_8EGv4biJPs1Xp+H8KxuOfE6Q@mail.gmail.com>

Greetings Python team.
I often find typographical errors in the python documentation, though it is
quite nice by and large. I will do my best to report them for now on. If
such is unwanted, please let me know via my personal email.

*TYPO:*
*Search           Replace            Location-Address*
There?s two      There are two
http://docs.python.org/3/howto/argparse.html#id1


-- 
*Anthony Josiah Dodd* | eBook Ninja
Anthony at FirebrandTech.com <anthony at firebrandtech.com> <work>
Dodd.AnthonyJosiah at gmail.com <personal>
512-417-1411

*FIREBRAND TECHNOLOGIES*
*eBook A**rchitects*
*
*
www.firebrandtech.com
www.ebookarchitects.com
www.ebookninjas.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130403/73a8e336/attachment-0001.html>

From ezio.melotti at gmail.com  Thu Apr  4 02:26:18 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Thu, 04 Apr 2013 00:26:18 -0000
Subject: [docs] Profile objects should be documented (issue 6696)
Message-ID: <20130404002618.18941.90850@psf.upfronthosting.co.za>


http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst
File Doc/library/profile.rst (left):

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#oldcode10
Doc/library/profile.rst:10: :synopsis: Python source profiler.
Why have you removed these?

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst
File Doc/library/profile.rst (right):

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode8
Doc/library/profile.rst:8: :source:`Modules/_lsprof.c` and
:source:`Lib/pstats.py`
:source:`Lib/cProfile.py` and :source:`Modules/_lsprof.c` shouldn't be
included IMHO.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode63
Doc/library/profile.rst:63: cProfile.run('foo(x)')
Why this change?
It seems easier to me to say that if you want to profile the function
foo you can call .run('foo()').

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode77
Doc/library/profile.rst:77: 43/3    0.533    0.012    0.749    0.250
pobject.py:99(evaluate)
I think it would be even better to use a real-world example that users
can run (maybe you can thing about something better than re.compile),
e.g.:
>>> import cProfile
>>> import re
>>> cProfile.run('re.compile("foo|bar")')
         197 function calls (192 primitive calls) in 0.002 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.001    0.001 <string>:1(<module>)
        1    0.000    0.000    0.001    0.001 re.py:212(compile)
        1    0.000    0.000    0.001    0.001 re.py:268(_compile)
        1    0.000    0.000    0.000    0.000
sre_compile.py:172(_compile_charset)
        1    0.000    0.000    0.000    0.000
sre_compile.py:201(_optimize_charset)
        4    0.000    0.000    0.000    0.000
sre_compile.py:25(_identityfunction)
      3/1    0.000    0.000    0.000    0.000
sre_compile.py:33(_compile)

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode104
Doc/library/profile.rst:104: provides the respective data of each
function
The end of lines are inconsistent.  You can remove the trailing commas
and full stop.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode280
Doc/library/profile.rst:280: Profile the cmd via :func:`exec` with the
specified global and local environment.
Line too long (there are a few others that are longer than 80 chars
too).

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode397
Doc/library/profile.rst:397: +------------------+----------------------+
Here you could use the simpler table syntax:
====== ======
header header
====== ======
row1   row1
row2   row2
...    ...
====== ======

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode418
Doc/library/profile.rst:418: .. For compatibility with the old profiler,
s/,/./

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode447
Doc/library/profile.rst:447: printed; as of Python 1.5b1, this uses the
Perl-style regular
This can probably be removed.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode618
Doc/library/profile.rst:618: interpreted differently:
This could point to the different times available in the time module,
and possibly provide some suggestion.

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

From ezio.melotti at gmail.com  Thu Apr  4 03:01:14 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Thu, 04 Apr 2013 01:01:14 -0000
Subject: [docs] Document that datetime.__format__ is datetime.strftime
	(issue 8913)
Message-ID: <20130404010114.28804.67310@psf.upfronthosting.co.za>

On 2012/11/04 20:02:50, Heikki Partanen wrote:
> http://bugs.python.org/review/8913/diff/6442/Doc/library/datetime.rst
> File Doc/library/datetime.rst (right):
> 
>
http://bugs.python.org/review/8913/diff/6442/Doc/library/datetime.rst#newcode616
> Doc/library/datetime.rst:616: 'John in 2002'
> The idea there is to emphasize the handiness of being able to format a
> date(time) within a single str.format() call. If there are no other
parameters
> in the example, this advantage may go unnoticed. 
> 

Showing that you can pass other parameters is OK, my objection was about
the fact that the resulting sentence seems meaningless to me (not sure
if I'm missing any reference here).

You could just use:
'The {} is {:%Y}'.format("year", d)

or something a bit more complicated like:
>>> 'The {1} is {0:%d}, the {2} is {0:%B}.'.format(d, 'day', 'month')
'The day is 11, the month is March.'



> It was actually suggested earlier by ?ric:
> http://bugs.python.org/review/8913/diff/6363/Doc/library/datetime.rst



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

From anthony at firebrandtech.com  Thu Apr  4 05:43:55 2013
From: anthony at firebrandtech.com (Anthony Dodd)
Date: Wed, 3 Apr 2013 22:43:55 -0500
Subject: [docs] Typographical Change
Message-ID: <D9BAC4EA-3F85-4EC8-B60B-F5F9C776234E@firebrandtech.com>

Correcting this typo should improve readability of this documentation. 

Location:
http://docs.python.org/3/howto/argparse.html#id1

Search:
Let?s also change the rest of the program make the new functionality makes more sense

Replace:
Let?s also change the rest of the program to make the new functionality make more sense

??
Anthony Josiah Dodd
Phone: 512-417-1411
Work: Anthony at FirebrandTech.com
Personal: Dodd.AnthonyJosiah at Gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130403/302e0e32/attachment.html>

From thomaspinckney3 at gmail.com  Thu Apr  4 15:51:02 2013
From: thomaspinckney3 at gmail.com (Tom Pinckney)
Date: Thu, 4 Apr 2013 09:51:02 -0400
Subject: [docs] Profile objects should be documented (issue 6696)
In-Reply-To: <20130404002618.18941.90850@psf.upfronthosting.co.za>
References: <20130404002618.18941.90850@psf.upfronthosting.co.za>
Message-ID: <2B33B11F-A1D0-4B90-B0C0-003EF52E2F84@gmail.com>

Thanks for the helpful feedback. I'll review and submit an updated patch this weekend.

On Apr 3, 2013, at 8:26 PM, ezio.melotti at gmail.com wrote:

> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst
> File Doc/library/profile.rst (left):
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#oldcode10
> Doc/library/profile.rst:10: :synopsis: Python source profiler.
> Why have you removed these?
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst
> File Doc/library/profile.rst (right):
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode8
> Doc/library/profile.rst:8: :source:`Modules/_lsprof.c` and
> :source:`Lib/pstats.py`
> :source:`Lib/cProfile.py` and :source:`Modules/_lsprof.c` shouldn't be
> included IMHO.
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode63
> Doc/library/profile.rst:63: cProfile.run('foo(x)')
> Why this change?
> It seems easier to me to say that if you want to profile the function
> foo you can call .run('foo()').
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode77
> Doc/library/profile.rst:77: 43/3    0.533    0.012    0.749    0.250
> pobject.py:99(evaluate)
> I think it would be even better to use a real-world example that users
> can run (maybe you can thing about something better than re.compile),
> e.g.:
>>>> import cProfile
>>>> import re
>>>> cProfile.run('re.compile("foo|bar")')
>         197 function calls (192 primitive calls) in 0.002 seconds
> 
>   Ordered by: standard name
> 
>   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>        1    0.000    0.000    0.001    0.001 <string>:1(<module>)
>        1    0.000    0.000    0.001    0.001 re.py:212(compile)
>        1    0.000    0.000    0.001    0.001 re.py:268(_compile)
>        1    0.000    0.000    0.000    0.000
> sre_compile.py:172(_compile_charset)
>        1    0.000    0.000    0.000    0.000
> sre_compile.py:201(_optimize_charset)
>        4    0.000    0.000    0.000    0.000
> sre_compile.py:25(_identityfunction)
>      3/1    0.000    0.000    0.000    0.000
> sre_compile.py:33(_compile)
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode104
> Doc/library/profile.rst:104: provides the respective data of each
> function
> The end of lines are inconsistent.  You can remove the trailing commas
> and full stop.
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode280
> Doc/library/profile.rst:280: Profile the cmd via :func:`exec` with the
> specified global and local environment.
> Line too long (there are a few others that are longer than 80 chars
> too).
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode397
> Doc/library/profile.rst:397: +------------------+----------------------+
> Here you could use the simpler table syntax:
> ====== ======
> header header
> ====== ======
> row1   row1
> row2   row2
> ...    ...
> ====== ======
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode418
> Doc/library/profile.rst:418: .. For compatibility with the old profiler,
> s/,/./
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode447
> Doc/library/profile.rst:447: printed; as of Python 1.5b1, this uses the
> Perl-style regular
> This can probably be removed.
> 
> http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode618
> Doc/library/profile.rst:618: interpreted differently:
> This could point to the different times available in the time module,
> and possibly provide some suggestion.
> 
> http://bugs.python.org/review/6696/


From report at bugs.python.org  Thu Apr  4 16:42:27 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 04 Apr 2013 14:42:27 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1365086547.5.0.660165601783.issue16893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Defaulting to opening a browser window sounds great to me.  In those cases where there is no network access, though, I think we should keep a fallback help.txt, and I think the Sphinx text rendering is about the simplest and easiest fallback we can get.  Shall we open another issue for using a browser for Help, and should this issue wait on that one, or can this go ahead in the meantime?

----------

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

From report at bugs.python.org  Thu Apr  4 16:49:57 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 04 Apr 2013 14:49:57 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1365086996.94.0.757529237525.issue17386@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Any comments?  Christian, I'd especially like to hear from you since it looks like you were the original author of Doc/make.bat (issue1472).

----------

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

From report at bugs.python.org  Thu Apr  4 17:58:37 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Apr 2013 15:58:37 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1365091117.74.0.553897504493.issue16893@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I just discovered that on Windows, the 3rd help option "Python Docs - F1" opens the local doc set whatever.chm in the Windows Help (HTML) Viewer. This is the same as the start menu choice. So on Windows, opening the same offline copy to the IDLE page, if possible, would be the thing to do. Perhaps the Windows code for opening the docs to the toc page can be reused to open them to the IDLE page.

----------

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

From report at bugs.python.org  Thu Apr  4 18:43:53 2013
From: report at bugs.python.org (Antony Lee)
Date: Thu, 04 Apr 2013 16:43:53 +0000
Subject: [docs] [issue17635] Doc of multiprocessing.connection
	mentions	answerChallenge instead of answer_challenge
Message-ID: <1365093833.89.0.404146948486.issue17635@psf.upfronthosting.co.za>


New submission from Antony Lee:

The documentation for multiprocessing.connection mentions the answerChallenge function, but it is actually called answer_challenge in 2.6, 2.7 and 3.3 -- I guess it's also the case in 3.1 and 3.2 but I didn't check.

----------
assignee: docs at python
components: Documentation
messages: 186043
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Doc of multiprocessing.connection mentions answerChallenge instead of answer_challenge
versions: Python 2.6, Python 2.7, Python 3.3

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

From andrew.svetlov at gmail.com  Fri Apr  5 09:15:22 2013
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Fri, 5 Apr 2013 10:15:22 +0300
Subject: [docs] Typo In Documentation
In-Reply-To: <CAJvDtcLspaEyBE1_-Pkv+zsqE_8EGv4biJPs1Xp+H8KxuOfE6Q@mail.gmail.com>
References: <CAJvDtcLspaEyBE1_-Pkv+zsqE_8EGv4biJPs1Xp+H8KxuOfE6Q@mail.gmail.com>
Message-ID: <CAL3CFcVFP-5RRhVpR1UJP1ZBtnkGamU2nYKkWqKFYy6XvuDcVA@mail.gmail.com>

Fixed. Thanks, Anthony.

On Thu, Apr 4, 2013 at 2:42 AM, Anthony Dodd <anthony at firebrandtech.com> wrote:
> Greetings Python team.
> I often find typographical errors in the python documentation, though it is
> quite nice by and large. I will do my best to report them for now on. If
> such is unwanted, please let me know via my personal email.
>
> TYPO:
> Search           Replace            Location-Address
> There?s two      There are two
> http://docs.python.org/3/howto/argparse.html#id1
>
>
> --
> Anthony Josiah Dodd | eBook Ninja
> Anthony at FirebrandTech.com <work>
> Dodd.AnthonyJosiah at gmail.com <personal>
> 512-417-1411
>
> FIREBRAND TECHNOLOGIES
> eBook Architects
>
> www.firebrandtech.com
> www.ebookarchitects.com
> www.ebookninjas.com
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



-- 
Thanks,
Andrew Svetlov

From andrew.svetlov at gmail.com  Fri Apr  5 10:41:02 2013
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Fri, 5 Apr 2013 11:41:02 +0300
Subject: [docs] Typographical Change
In-Reply-To: <D9BAC4EA-3F85-4EC8-B60B-F5F9C776234E@firebrandtech.com>
References: <D9BAC4EA-3F85-4EC8-B60B-F5F9C776234E@firebrandtech.com>
Message-ID: <CAL3CFcX_gdiNh6CQckki5zj1gmgn=RiFGJWTJdjQYNT_Cp2xuw@mail.gmail.com>

Fixed. Thanks again.

On Thu, Apr 4, 2013 at 6:43 AM, Anthony Dodd <anthony at firebrandtech.com> wrote:
> Correcting this typo should improve readability of this documentation.
>
> Location:
> http://docs.python.org/3/howto/argparse.html#id1
>
> Search:
> Let?s also change the rest of the program make the new functionality makes
> more sense
>
> Replace:
> Let?s also change the rest of the program to make the new functionality make
> more sense
>
> ??
> Anthony Josiah Dodd
> Phone: 512-417-1411
> Work: Anthony at FirebrandTech.com
> Personal: Dodd.AnthonyJosiah at Gmail.com
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



-- 
Thanks,
Andrew Svetlov

From andrew.svetlov at gmail.com  Fri Apr  5 15:23:08 2013
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Fri, 5 Apr 2013 16:23:08 +0300
Subject: [docs] Documentation improvement suggestion
In-Reply-To: <CAJWmTpuK3jftaOFB9YoQLMozRX7oKjmOmN-mv7QexZE=YwQrYQ@mail.gmail.com>
References: <CAJWmTpuK3jftaOFB9YoQLMozRX7oKjmOmN-mv7QexZE=YwQrYQ@mail.gmail.com>
Message-ID: <CAL3CFcWVwo6rqM63hxgPVGgs0J6Ez2fP8A5yWwcT6M5weCy4mQ@mail.gmail.com>

Fixed, thanks

On Tue, Apr 2, 2013 at 9:11 AM, Evgeni Sergeev
<e.sergeev at student.unimelb.edu.au> wrote:
> Proposed improvement for the page
> http://docs.python.org/2/library/stdtypes.html#set
>
> The elements of a set must be hashable.
> The elements of a set must be :term:`hashable`.
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs



-- 
Thanks,
Andrew Svetlov

From report at bugs.python.org  Fri Apr  5 18:18:09 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 05 Apr 2013 16:18:09 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
	(or	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1365178689.41.0.762367738381.issue17576@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +stoneleaf

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

From report at bugs.python.org  Fri Apr  5 19:54:41 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 05 Apr 2013 17:54:41 +0000
Subject: [docs] [issue17641] ssl module doc unification
Message-ID: <1365184481.29.0.784588958426.issue17641@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

I noticed 2.X version of ssl module doc does not mention different socket methods (sendall(), accept(), etc) whereas the 3.X version does.
Patch in attachment unifies the 2 docs.

----------
assignee: docs at python
components: Documentation
keywords: easy, needs review
messages: 186097
nosy: docs at python, ezio.melotti, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: ssl module doc unification
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr  5 21:03:08 2013
From: report at bugs.python.org (Tom Pinckney)
Date: Fri, 05 Apr 2013 19:03:08 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1365188587.6.0.248199776382.issue6696@psf.upfronthosting.co.za>


Tom Pinckney added the comment:

Updated based on Ezio's comments.

----------
Added file: http://bugs.python.org/file29683/patch3.diff

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

From report at bugs.python.org  Fri Apr  5 23:07:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Apr 2013 21:07:17 +0000
Subject: [docs] [issue17641] ssl module doc unification
In-Reply-To: <1365184481.29.0.784588958426.issue17641@psf.upfronthosting.co.za>
Message-ID: <1365196037.73.0.607239019324.issue17641@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The patch seems to be missing.

----------

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

From report at bugs.python.org  Fri Apr  5 23:11:01 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 05 Apr 2013 21:11:01 +0000
Subject: [docs] [issue17641] ssl module doc unification
In-Reply-To: <1365184481.29.0.784588958426.issue17641@psf.upfronthosting.co.za>
Message-ID: <1365196261.94.0.241289862751.issue17641@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Shame on me and my scatterbrained head! =)

----------
keywords: +patch
Added file: http://bugs.python.org/file29684/ssl-doc.patch

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

From report at bugs.python.org  Fri Apr  5 23:16:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Apr 2013 21:16:23 +0000
Subject: [docs] [issue17641] ssl module doc unification
In-Reply-To: <1365196261.94.0.241289862751.issue17641@psf.upfronthosting.co.za>
Message-ID: <1365196576.3370.0.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Giampaolo Rodola' added the comment:
> 
> Shame on me and my scatterbrained head! =)

Thanks, looks fine to me!

----------

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

From report at bugs.python.org  Sat Apr  6 02:24:45 2013
From: report at bugs.python.org (Andrew Gorcester)
Date: Sat, 06 Apr 2013 00:24:45 +0000
Subject: [docs] [issue16432] Template strings documentation in Python 3
	refers to %	substitution in present tense
In-Reply-To: <1352323704.72.0.0858754286751.issue16432@psf.upfronthosting.co.za>
Message-ID: <1365207885.34.0.0159766597525.issue16432@psf.upfronthosting.co.za>


Changes by Andrew Gorcester <andrew.gorcester at gmail.com>:


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

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

From report at bugs.python.org  Sat Apr  6 03:46:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 06 Apr 2013 01:46:57 +0000
Subject: [docs] [issue17641] ssl module doc unification
In-Reply-To: <1365184481.29.0.784588958426.issue17641@psf.upfronthosting.co.za>
Message-ID: <3ZjLNb6F5SzSgQ@mail.python.org>


Roundup Robot added the comment:

New changeset 03c65fc349c0 by Giampaolo Rodola' in branch '2.7':
#17641: 2.X / 3.X ssl doc unification
http://hg.python.org/cpython/rev/03c65fc349c0

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

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

From report at bugs.python.org  Sat Apr  6 03:47:23 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 06 Apr 2013 01:47:23 +0000
Subject: [docs] [issue17641] ssl module doc unification
In-Reply-To: <1365184481.29.0.784588958426.issue17641@psf.upfronthosting.co.za>
Message-ID: <1365212843.01.0.717817831078.issue17641@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Apr  6 16:43:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 06 Apr 2013 14:43:57 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <3Zjgd86jcwzT20@mail.python.org>


Roundup Robot added the comment:

New changeset f45902f8c7d7 by Christian Heimes in branch '3.2':
Issue 17538: Document XML vulnerabilties
http://hg.python.org/cpython/rev/f45902f8c7d7

----------

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

From report at bugs.python.org  Sat Apr  6 17:21:54 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Apr 2013 15:21:54 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1365261714.83.0.370857471872.issue17538@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Christian: there are people strongly disagreeing with the description of minidom as ?lightweight?, could you edit the libary/xml.rst file you added to say ?minimal? instead?  See c2ae1ed03853 and #11379 if you want more info.

----------

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

From report at bugs.python.org  Sat Apr  6 22:50:04 2013
From: report at bugs.python.org (Kristian)
Date: Sat, 06 Apr 2013 20:50:04 +0000
Subject: [docs] [issue17135] imp doc should direct to importlib
In-Reply-To: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>
Message-ID: <1365281404.7.0.016500165375.issue17135@psf.upfronthosting.co.za>


Kristian added the comment:

Here is the patch for this bug... Enjoy! I would be happy to work on this further if there are any problems or questions! Thanks!

----------
keywords: +patch
nosy: +ktran13
Added file: http://bugs.python.org/file29697/patch.diff

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

From report at bugs.python.org  Sun Apr  7 06:27:25 2013
From: report at bugs.python.org (Kyle Roberts)
Date: Sun, 07 Apr 2013 04:27:25 +0000
Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1365308845.08.0.832474852428.issue15984@psf.upfronthosting.co.za>


Kyle Roberts added the comment:

I made a change to the documentation to reflect PyUnicode_FromObject()'s change in implementation details. Let me know if the wording is off or more information is needed. Thanks!

----------
keywords: +patch
nosy: +kyle.roberts
Added file: http://bugs.python.org/file29702/from_object.patch

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

From report at bugs.python.org  Sun Apr  7 12:09:52 2013
From: report at bugs.python.org (Kostyantyn Leschenko)
Date: Sun, 07 Apr 2013 10:09:52 +0000
Subject: [docs] [issue13249] argparse.ArgumentParser() lists arguments in
	the wrong	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1365329391.98.0.831820676077.issue13249@psf.upfronthosting.co.za>


Kostyantyn Leschenko added the comment:

I've updated patch to work with current trunk.

----------
nosy: +Kostyantyn.Leschenko, asvetlov
versions: +Python 3.4 -Python 3.2
Added file: http://bugs.python.org/file29704/Issue13249-5.patch

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

From report at bugs.python.org  Sun Apr  7 13:49:25 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 07 Apr 2013 11:49:25 +0000
Subject: [docs] [issue13249] argparse.ArgumentParser() lists arguments in
	the wrong	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1365335365.67.0.0495187607416.issue13249@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed in 4712f9f8a90d, 5e5081cdc086, e4beda7cca2f.
Thanks.

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

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

From report at bugs.python.org  Sun Apr  7 14:31:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Apr 2013 12:31:10 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1365337869.29.0.836983806906.issue17221@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you, Terry. Here is a new version of a patch for 3.4. New entries move, IDLE section resorted in a chronological order, duplicates removed, some minor things fixed.

----------
Added file: http://bugs.python.org/file29711/NEWS-3.4_5.patch

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

From report at bugs.python.org  Sun Apr  7 14:32:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Apr 2013 12:32:31 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1365337950.7.0.41025525222.issue17221@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And here is a patch for 3.3.

----------
Added file: http://bugs.python.org/file29712/NEWS-3.3.patch

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

From report at bugs.python.org  Sun Apr  7 14:33:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 07 Apr 2013 12:33:46 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1365338026.8.0.862826304875.issue17221@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions: +Python 3.3

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

From report at bugs.python.org  Sun Apr  7 22:43:57 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 07 Apr 2013 20:43:57 +0000
Subject: [docs] [issue17653] fix typo in socketserver.rst
Message-ID: <1365367437.63.0.295899077701.issue17653@psf.upfronthosting.co.za>


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


----------
assignee: docs at python
components: Documentation
files: fix.diff
keywords: patch
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: fix typo in socketserver.rst
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29719/fix.diff

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

From report at bugs.python.org  Mon Apr  8 06:06:52 2013
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 08 Apr 2013 04:06:52 +0000
Subject: [docs] [issue16942] urllib still doesn't support persistent
	connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1365394012.81.0.0783565019617.issue16942@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Just noticed there was a typo in the link in my previous post. It should be directing to issue# 16901.

----------

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

From report at bugs.python.org  Mon Apr  8 14:32:38 2013
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 08 Apr 2013 12:32:38 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
Message-ID: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

The documentation of '%r' in http://docs.python.org/2/library/stdtypes.html#string-formatting-operations links to the wrong repr, the module (http://docs.python.org/2/library/repr.html#module-repr) instead of the builtin function (http://docs.python.org/2/library/functions.html#func-repr).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 186292
nosy: docs at python, twouters
priority: normal
severity: normal
status: open
title: documentation of '%r' links to the wrong repr
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  8 18:59:08 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Apr 2013 16:59:08 +0000
Subject: [docs] [issue17589] Make documentation about macros in C API
	explicit about	rvalue vs statement
In-Reply-To: <1364758755.79.0.998719447408.issue17589@psf.upfronthosting.co.za>
Message-ID: <1365440348.91.0.352715526148.issue17589@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

There are some extension modules (pytables) that do
  return Py_INREF(x), x;
and Py_RETURN_NONE is also defined with a comma expression.

Oh, and Cython:
#define __Pyx_PyBool_FromLong(b) ((b) ? (Py_INCREF(Py_True), Py_True) : (Py_INCREF(Py_False), Py_False))

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

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

From report at bugs.python.org  Mon Apr  8 19:10:52 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 08 Apr 2013 17:10:52 +0000
Subject: [docs] [issue17589] Make documentation about macros in C API
	explicit about	rvalue vs statement
In-Reply-To: <1364758755.79.0.998719447408.issue17589@psf.upfronthosting.co.za>
Message-ID: <1365441052.74.0.608678455983.issue17589@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


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

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

From report at bugs.python.org  Mon Apr  8 21:30:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Apr 2013 19:30:05 +0000
Subject: [docs] [issue17668] re.split loses characters matching ungrouped
	parts of a	pattern
In-Reply-To: <1365445138.49.0.018016443065.issue17668@psf.upfronthosting.co.za>
Message-ID: <1365449405.02.0.092198512202.issue17668@psf.upfronthosting.co.za>


R. David Murray added the comment:

>>> re.split('-', 'abc-def-jlk')
['abc', 'def', 'jlk']
>>> re.split('(-)', 'abc-def-jlk')
['abc', '-', 'def', '-', 'jlk']

Does that make it a bit clearer?  Maybe we need an actual example in the docs.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage: committed/rejected -> needs patch

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

From report at bugs.python.org  Mon Apr  8 21:52:20 2013
From: report at bugs.python.org (Tomasz J. Kotarba)
Date: Mon, 08 Apr 2013 19:52:20 +0000
Subject: [docs] [issue17668] re.split loses characters matching ungrouped
	parts of a	pattern
In-Reply-To: <1365445138.49.0.018016443065.issue17668@psf.upfronthosting.co.za>
Message-ID: <1365450740.12.0.256695691055.issue17668@psf.upfronthosting.co.za>


Tomasz J. Kotarba added the comment:

I agree that introducing an example like that plus making some slight changes in wording would be a welcome change to the docs to clearly explain the current behaviour.  Still, I maintain it would be useful to give users the option I described to allow them decide what output they get (i.e. also get texts matching the whole pattern and/or those matching the pattern and groups (e.g. pattern returned as kind of "group 0")).  As I said though, I realise that it is not for me to decide so I am just suggesting it to the powers that be.
Cheers,
T

----------
components:  -Documentation

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

From report at bugs.python.org  Mon Apr  8 22:05:43 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Apr 2013 20:05:43 +0000
Subject: [docs] [issue17668] re.split loses characters matching ungrouped
	parts of a	pattern
In-Reply-To: <1365445138.49.0.018016443065.issue17668@psf.upfronthosting.co.za>
Message-ID: <1365451543.92.0.249845024872.issue17668@psf.upfronthosting.co.za>


R. David Murray added the comment:

As you pointed out, you can already get that behavior by enclosing the entire split expression in a group.  I don't see that there is any functionality missing here.

----------

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

From report at bugs.python.org  Tue Apr  9 04:09:28 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 09 Apr 2013 02:09:28 +0000
Subject: [docs] [issue17589] Make documentation about macros in C API
	explicit about	rvalue vs statement
In-Reply-To: <1364758755.79.0.998719447408.issue17589@psf.upfronthosting.co.za>
Message-ID: <1365473368.19.0.268179976466.issue17589@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Amaury: I'd appreciate it if you'd bring those examples up on bug 17206.  If we're going to change the semantics of Py_INCREF I'd prefer we did it with our eyes wide open.

----------

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

From report at bugs.python.org  Tue Apr  9 04:15:15 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 09 Apr 2013 02:15:15 +0000
Subject: [docs] [issue17589] Make documentation about macros in C API
	explicit about	rvalue vs statement
In-Reply-To: <1364758755.79.0.998719447408.issue17589@psf.upfronthosting.co.za>
Message-ID: <1365473715.63.0.831379237333.issue17589@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Oh, and, yes, it's true that Py_RETURN_NONE currently takes advantage of Py_INCREF being an rvalue, and changing Py_INCREF to a statement would break the existing implementation.  But Py_RETURN_NONE itself is of necessity a statement.   We would simply change Py_RETURN_NONE's implementation to multiple statements, probably with the do { ... } while(0) trick, so it worked again.  I'd be shocked if that change broke any existing code.  So that's no big deal.

Having external code that depends on Py_INCREF being an rvalue is my concern, and what I hoped you'd bring up on bug #17206.

----------

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

From report at bugs.python.org  Tue Apr  9 06:59:52 2013
From: report at bugs.python.org (Tomasz J. Kotarba)
Date: Tue, 09 Apr 2013 04:59:52 +0000
Subject: [docs] [issue17668] re.split loses characters matching ungrouped
	parts of a	pattern
In-Reply-To: <1365445138.49.0.018016443065.issue17668@psf.upfronthosting.co.za>
Message-ID: <1365483592.59.0.797946847488.issue17668@psf.upfronthosting.co.za>


Tomasz J. Kotarba added the comment:

Hi,
I can still see one piece of functionality I have mentioned missing. Using my first example, even when one uses '^(>(.*))$' one cannot get ['', '>Homo sapiens catenin (cadherin-associated)', ''] as one will get a four-element list and need to deal with the third element of the returned list (i.e. the match for a group).  Having a parameter I have described before which allows for getting the output similar to what one gets for groups but for the whole pattern (and only that) would be very convenient for some scenarios (like when writing a procedure which processes texts using different (and unknown at the time of writing the procedure) regex patterns which uses a variable number of groups but also the pattern as a whole (also for performing the split operation)).
Of course it can be worked around using many different approaches but still, as I said at start, I believe it would be useful (and would not break compatibility).  Another possible solution (i.e. different than the one I suggested at start) would be to have a parameter to tell re.split to ignore the groups (or, going even further, to select which groups to ignore).  Anyway, I am not the developer of this module so if you feel it would be too much of a bother to add such a parameter just for the sake of convenience then, by all means, please feel free to disregard my comments and just close this report.
Cheers,
T
P.S.  It is very late so I can only hope I have been sane enough to properly / clearly express my thoughts.  Apologies if not.

----------

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

From report at bugs.python.org  Tue Apr  9 08:12:18 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 09 Apr 2013 06:12:18 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365487938.37.0.89116732179.issue17661@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks for catching this; Sphinx? lookup is confusing sometimes.  Using `.repr` or something similar will fix it.

----------
nosy: +eric.araujo, ezio.melotti

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

From report at bugs.python.org  Tue Apr  9 08:14:46 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 09 Apr 2013 06:14:46 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365488085.97.0.949993181955.issue17661@psf.upfronthosting.co.za>


Georg Brandl added the comment:

It just highlights the mistake we made calling a builtin module the same name as a builtin function :)

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

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

From report at bugs.python.org  Tue Apr  9 08:21:24 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Apr 2013 06:21:24 +0000
Subject: [docs] [issue17668] re.split loses characters matching ungrouped
	parts of a	pattern
In-Reply-To: <1365445138.49.0.018016443065.issue17668@psf.upfronthosting.co.za>
Message-ID: <1365488484.52.0.485966076314.issue17668@psf.upfronthosting.co.za>


R. David Murray added the comment:

Only group the stuff you want to see in the result:

>>> re.split(r'(^>.*$)', '>Homo sapiens catenin (cadherin-associated)')
['', '>Homo sapiens catenin (cadherin-associated)', '']

>>> re.split(r'^(>.*)$', '>Homo sapiens catenin (cadherin-associated)')
['', '>Homo sapiens catenin (cadherin-associated)', '']

If you are using grouping to get alternatives, you can use a non-capturing group:

>>> re.split(r'(ca(?:t|d))', '>Homo sapiens catenin (cadherin-associated)')
['>Homo sapiens ', 'cat', 'enin (', 'cad', 'herin-associated)']

(By the way, I'm a bit confused as to what exactly you are splitting in your original example, since you seem to be matching the whole string, and only if it is the whole string.  On the other hand, regular expressions regularly confuse me... :)

I indeed do not think it is worth complicating the interface to handle the unusual case of accepting and applying unknown regexes.  The one change I could see as a possibility would be to allow all of the groups matched by the split regex to appear as a single sublist.  But I'm not the maintainer of this module either :)

----------

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

From report at bugs.python.org  Tue Apr  9 15:25:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Apr 2013 13:25:24 +0000
Subject: [docs] [issue17674] All examples for concurrent.futures fail
	with	"BrokenProcessPool"
In-Reply-To: <1365512691.79.0.330331294917.issue17674@psf.upfronthosting.co.za>
Message-ID: <1365513924.58.0.303946082042.issue17674@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This is not the example code. The example code uses a main() function which is guarded by a "if" block:

if __name__ == '__main__':
    main()

See http://docs.python.org/2/library/multiprocessing.html#windows for explanations.

Also, perhaps the concurrent.futures docs could point to that paragraph.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib), Windows
nosy: +docs at python, pitrou
type: crash -> behavior
versions: +Python 3.4

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

From report at bugs.python.org  Tue Apr  9 15:52:18 2013
From: report at bugs.python.org (gjwebber)
Date: Tue, 09 Apr 2013 13:52:18 +0000
Subject: [docs] [issue17674] All examples for concurrent.futures fail
	with	"BrokenProcessPool"
In-Reply-To: <1365512691.79.0.330331294917.issue17674@psf.upfronthosting.co.za>
Message-ID: <1365515538.66.0.305303461736.issue17674@psf.upfronthosting.co.za>


gjwebber added the comment:

As mentioned in the previously linked post, I copy-pasted the example code shown here:
http://docs.python.org/dev/library/concurrent.futures.html#processpoolexecutor-example

Which resulted in exactly the same error as the 'more simple' example I provided.

There is no mention of anything Windows specific on the documentation page, or any hints as to why this may not be working.

----------

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

From report at bugs.python.org  Tue Apr  9 15:59:45 2013
From: report at bugs.python.org (gjwebber)
Date: Tue, 09 Apr 2013 13:59:45 +0000
Subject: [docs] [issue17674] All examples for concurrent.futures fail
	with	"BrokenProcessPool"
In-Reply-To: <1365512691.79.0.330331294917.issue17674@psf.upfronthosting.co.za>
Message-ID: <1365515985.35.0.134296368755.issue17674@psf.upfronthosting.co.za>


gjwebber added the comment:

Just ran the example code linked here again for my own sanity:
http://docs.python.org/dev/library/concurrent.futures.html#processpoolexecutor-example

Exactly the same thing happened. Here is the Traceback:
Traceback (most recent call last):
  File "<string>", line 420, in run_nodebug
  File "<module1>", line 28, in <module>
  File "<module1>", line 24, in main
  File "C:\Python33\lib\concurrent\futures\_base.py", line 546, in result_iterator
    yield future.result()
  File "C:\Python33\lib\concurrent\futures\_base.py", line 399, in result
    return self.__get_result()
  File "C:\Python33\lib\concurrent\futures\_base.py", line 351, in __get_result
    raise self._exception
concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.

----------

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

From report at bugs.python.org  Tue Apr  9 16:57:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Apr 2013 14:57:55 +0000
Subject: [docs] [issue17674] All examples for concurrent.futures fail
	with	"BrokenProcessPool"
In-Reply-To: <1365512691.79.0.330331294917.issue17674@psf.upfronthosting.co.za>
Message-ID: <1365519475.45.0.921350299926.issue17674@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, can someone else confirm the issue on Windows?

----------
nosy: +brian.curtin, sbt, tim.golden

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

From report at bugs.python.org  Tue Apr  9 17:01:09 2013
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Apr 2013 15:01:09 +0000
Subject: [docs] [issue17674] All examples for concurrent.futures fail
	with	"BrokenProcessPool"
In-Reply-To: <1365512691.79.0.330331294917.issue17674@psf.upfronthosting.co.za>
Message-ID: <1365519669.22.0.550866807171.issue17674@psf.upfronthosting.co.za>


Brian Curtin added the comment:

The example code works for me on 3.3.0 on Windows 8. I'd have to find a VM to try out XP like gjwebber - will look later.

----------

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

From report at bugs.python.org  Tue Apr  9 21:29:28 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Apr 2013 19:29:28 +0000
Subject: [docs] [issue17566] Make importlib.abc.Loader.module_repr optional
In-Reply-To: <1364486422.93.0.992071692104.issue17566@psf.upfronthosting.co.za>
Message-ID: <1365535768.05.0.324208263879.issue17566@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib) -Documentation
title: Document that importlib.abc.Loader.module_repr is abstract and thus needed by various other ABCs -> Make importlib.abc.Loader.module_repr optional
versions:  -Python 3.3

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

From report at bugs.python.org  Tue Apr  9 22:17:04 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 09 Apr 2013 20:17:04 +0000
Subject: [docs] [issue17674] All examples for concurrent.futures fail
	with	"BrokenProcessPool"
In-Reply-To: <1365512691.79.0.330331294917.issue17674@psf.upfronthosting.co.za>
Message-ID: <1365538624.06.0.122440946277.issue17674@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

@gjwebber: How exactly are you running the program to get that traceback?

The following lines make it look like you are doing something non-standard (as opposed to just saving the file and running it from the command line):

  File "<string>", line 420, in run_nodebug
  File "<module1>", line 28, in <module>
  File "<module1>", line 24, in main

----------

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

From report at bugs.python.org  Tue Apr  9 23:05:22 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Apr 2013 21:05:22 +0000
Subject: [docs] [issue17566] Make importlib.abc.Loader.module_repr optional
In-Reply-To: <1364486422.93.0.992071692104.issue17566@psf.upfronthosting.co.za>
Message-ID: <1365541522.56.0.955068471543.issue17566@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Fixed by http://hg.python.org/cpython/rev/8e733e30edf6 by raising NotImplementedError and relying on the fact that ModuleType.__repr__() swallows any exception.

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

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

From report at bugs.python.org  Tue Apr  9 23:05:53 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 09 Apr 2013 21:05:53 +0000
Subject: [docs] [issue17567] Clarify
	importlib.abc.PathEntryFinder.find_loader() docs
In-Reply-To: <1364486651.54.0.521676412907.issue17567@psf.upfronthosting.co.za>
Message-ID: <1365541553.68.0.170473131335.issue17567@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Covered by http://hg.python.org/cpython/rev/8e733e30edf6

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

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

From report at bugs.python.org  Wed Apr 10 00:01:18 2013
From: report at bugs.python.org (Tom Pinckney)
Date: Tue, 09 Apr 2013 22:01:18 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1365544877.2.0.80522114952.issue6696@psf.upfronthosting.co.za>


Tom Pinckney added the comment:

Another update based on comments. Removed links to cProfile.py and _lsof.c.

----------
Added file: http://bugs.python.org/file29756/patch4.diff

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

From report at bugs.python.org  Wed Apr 10 01:05:58 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Apr 2013 23:05:58 +0000
Subject: [docs] [issue17670] expandtabs() weirdness
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1365548758.09.0.828521068976.issue17670@psf.upfronthosting.co.za>


Ned Deily added the comment:

That's a good point.  Here's a patch for the documentation with a simplified example:

      >>> '01\t456\t89'.expandtabs(4)
      '01  456 89'

What do others think: is an example useful and, if so, this example?

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +patch
nosy: +docs at python
resolution: works for me -> 
stage: committed/rejected -> patch review
status: closed -> open
type: behavior -> 
versions: +Python 3.4
Added file: http://bugs.python.org/file29759/issue17670_doc.patch

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

From report at bugs.python.org  Wed Apr 10 05:21:34 2013
From: report at bugs.python.org (Kyle Roberts)
Date: Wed, 10 Apr 2013 03:21:34 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365564094.08.0.278906847393.issue17661@psf.upfronthosting.co.za>


Kyle Roberts added the comment:

Adding a '.' to the beginning (i.e. `.repr`) creates a link to repr.html#repr.repr. This made more sense after perusing Sphinx's documentation:

"If you prefix the name with a dot, this order is reversed. For example, in the documentation of Python?s codecs module, :py:func:`open` always refers to the built-in function, while :py:func:`.open` refers to codecs.open()."

I'm not sure what other options I can try after looking at the reST documentation. It seems like our best bet would be if we could define a priority for same-name functions when two definitions are discovered. I didn't see a way to do this in Sphinx/reST so I'm not sure how to move forward with this. I'm assuming we don't want to link directly to the correct url if it can be avoided.

Also, I noticed http://docs.python.org/2/library/repr.html#module-repr links to the wrong repr() a few times where it mentions the "built-in" function.

----------
nosy: +kyle.roberts

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

From report at bugs.python.org  Wed Apr 10 08:34:47 2013
From: report at bugs.python.org (gjwebber)
Date: Wed, 10 Apr 2013 06:34:47 +0000
Subject: [docs] [issue17674] All examples for concurrent.futures fail
	with	"BrokenProcessPool"
In-Reply-To: <1365512691.79.0.330331294917.issue17674@psf.upfronthosting.co.za>
Message-ID: <1365575687.18.0.95327784603.issue17674@psf.upfronthosting.co.za>


gjwebber added the comment:

Damn, this was my screw up. It was a combination of two things that threw me off:

1. I was running my (saved) code un-gaurded, but was getting the same error as with the example code. I thought the problem was elsewhere.

2. As it was just example code, I was copy-pasting it into my IDE and running it. This caused the slightly weird looking Traceback that Richard Oudkerk pointed out and the same error message.

After saving and running the standard example, everything worked as expected. After this, I added the 'main' guard to my code and that fixed the problem there.

Sorry about that, looks like there's no problem after all. Tested at home on Win 7 and on my works machine (XP Pro).

Regards,
Gareth

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

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

From report at bugs.python.org  Wed Apr 10 10:47:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Apr 2013 08:47:45 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365583665.58.0.551978234923.issue17661@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> It just highlights the mistake we made calling a builtin module the
> same name as a builtin function :)

But shouldn't the highlighting be handled by Pygments? 
;)

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

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

From report at bugs.python.org  Wed Apr 10 15:11:35 2013
From: report at bugs.python.org (Masato HASHIMOTO)
Date: Wed, 10 Apr 2013 13:11:35 +0000
Subject: [docs] [issue17686] Doc using/unix broken link
	(http://linuxmafia.com/)
Message-ID: <1365599495.88.0.846759502226.issue17686@psf.upfronthosting.co.za>


New submission from Masato HASHIMOTO:

In Doc/using/unix.rst, the following link is broken:

31:   http://linuxmafia.com/pub/linux/suse-linux-internals/chapter35.html

(See also for OpenSuse users)

----------
assignee: docs at python
components: Documentation
messages: 186491
nosy: docs at python, hashimo
priority: normal
severity: normal
status: open
title: Doc using/unix broken link (http://linuxmafia.com/)
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 10 16:59:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Apr 2013 14:59:35 +0000
Subject: [docs] [issue17635] Doc of multiprocessing.connection
	mentions	answerChallenge instead of answer_challenge
In-Reply-To: <1365093833.89.0.404146948486.issue17635@psf.upfronthosting.co.za>
Message-ID: <3Zm7nL1kVVzSfC@mail.python.org>


Roundup Robot added the comment:

New changeset 54532684dbed by Ezio Melotti in branch '2.7':
#17635: fix wrong function name in multiprocessing docs.
http://hg.python.org/cpython/rev/54532684dbed

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

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

From report at bugs.python.org  Wed Apr 10 17:01:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Apr 2013 15:01:34 +0000
Subject: [docs] [issue17635] Doc of multiprocessing.connection
	mentions	answerChallenge instead of answer_challenge
In-Reply-To: <1365093833.89.0.404146948486.issue17635@psf.upfronthosting.co.za>
Message-ID: <3Zm7qd32P0zSgx@mail.python.org>


Roundup Robot added the comment:

New changeset 5d39d459b90d by Ezio Melotti in branch '3.3':
#17635: fix wrong function name in multiprocessing docs.
http://hg.python.org/cpython/rev/5d39d459b90d

New changeset 1a935e932152 by Ezio Melotti in branch 'default':
#17635: merge with 3.3.
http://hg.python.org/cpython/rev/1a935e932152

----------

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

From report at bugs.python.org  Wed Apr 10 17:02:09 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 10 Apr 2013 15:02:09 +0000
Subject: [docs] [issue17635] Doc of multiprocessing.connection
	mentions	answerChallenge instead of answer_challenge
In-Reply-To: <1365093833.89.0.404146948486.issue17635@psf.upfronthosting.co.za>
Message-ID: <1365606129.46.0.404707036351.issue17635@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

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

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

From ezio.melotti at gmail.com  Wed Apr 10 17:23:21 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Wed, 10 Apr 2013 15:23:21 -0000
Subject: [docs] SyntaxError in asdl when building 2.7 with system Python 3
	(issue 15964)
Message-ID: <20130410152321.11326.35879@psf.upfronthosting.co.za>


http://bugs.python.org/review/15964/diff/7762/Parser/asdl.py
File Parser/asdl.py (right):

http://bugs.python.org/review/15964/diff/7762/Parser/asdl.py#newcode329
Parser/asdl.py:329: print("Error visiting %s" % repr(object))
print("Error visiting %r" % object)

http://bugs.python.org/review/15964/diff/7762/Parser/asdl.py#newcode429
Parser/asdl.py:429: print("%i %s" % (len(mod.dfns), "definitions"))
print("%d definitions" % len(mod.dfns))

http://bugs.python.org/review/15964/diff/7762/Parser/spark.py
File Parser/spark.py (right):

http://bugs.python.org/review/15964/diff/7762/Parser/spark.py#newcode174
Parser/spark.py:174: rules = doc.split() #string.split(doc)
This comment is probably unnecessary.

http://bugs.python.org/review/15964/diff/7762/Parser/spark.py#newcode833
Parser/spark.py:833: s = '\t\t' + str(lhs) + '::=' + ' '
s = '\t\t %s ::= ' % lhs

http://bugs.python.org/review/15964/diff/7762/Parser/spark.py#newcode834
Parser/spark.py:834: s += ' '.join(rhs[:pos]) + ' '
s += ' '.join(rhs[:pos])

http://bugs.python.org/review/15964/diff/7762/Parser/spark.py#newcode835
Parser/spark.py:835: s += '. ' + ' '.join(rhs[pos:])
s += ' . ' + ' '.join(rhs[pos:])

http://bugs.python.org/review/15964/diff/7762/Parser/spark.py#newcode839
Parser/spark.py:839: print('token %s' % str(tokens[i]))
The str() can be removed.

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

From report at bugs.python.org  Wed Apr 10 17:25:09 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 10 Apr 2013 15:25:09 +0000
Subject: [docs] [issue15964] SyntaxError in asdl when building 2.7 with
	system Python	3
In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za>
Message-ID: <1365607509.83.0.28181054599.issue15964@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I left a review.  To test it you could try to reproduce the steps described in the first message and see what happens.

----------

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

From report at bugs.python.org  Wed Apr 10 17:33:56 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 10 Apr 2013 15:33:56 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365608036.41.0.88895136543.issue17661@psf.upfronthosting.co.za>


?ric Araujo added the comment:

You can always use a ref role instead of func.  func tries to find a module, class or function in the global Sphinx index, but ref lets you link to one specific target (see the table at the top of library/functions.rst for an example).

----------

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

From ezio.melotti at gmail.com  Wed Apr 10 17:38:22 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Wed, 10 Apr 2013 15:38:22 -0000
Subject: [docs] Bring Doc/make.bat as close to Doc/Makefile as possible
	(issue 17386)
Message-ID: <20130410153822.6859.33069@psf.upfronthosting.co.za>


http://bugs.python.org/review/17386/diff/7596/Doc/README.txt
File Doc/README.txt (right):

http://bugs.python.org/review/17386/diff/7596/Doc/README.txt#newcode43
Doc/README.txt:43: make html "PYTHON=python"
Does "make html" work without specifying "PYTHON=python" (assuming that
"python" is a recognised command)?
If "python" is not a recognised command, I guess that 
`make html "PYTHON=C:\Python27\python.exe"` can be used instead.  Is the
syntax correct?  Maybe this could be added too here.

http://bugs.python.org/review/17386/diff/7596/Doc/README.txt#newcode90
Doc/README.txt:90: A "make update" cleans up all builds and updates the
Subversion checkouts of
Why this is not in the list?
Also on Linux there's "make htmlview", not sure if it's available on
Windows too though.

http://bugs.python.org/review/17386/diff/7596/Doc/README.txt#newcode117
Doc/README.txt:117: svn co
http://svn.python.org/projects/external/Pygments-1.5dev-20120930/pygments
tools/pygments
Any reason why a dev version is suggested?  Is this the version we are
currently using?

http://bugs.python.org/review/17386/diff/7596/Doc/make.bat
File Doc/make.bat (right):

http://bugs.python.org/review/17386/diff/7596/Doc/make.bat#newcode277
Doc/make.bat:277: echo positives, append that file to
tools\sphinxext\susp-ignored.csv.
On Linux if suspicious markup is found, the build gives an error and
this message is not printed (see http://bugs.python.org/issue15759). 
Does this work here? (You could add a few  ` or : in an rst file to make
the suspicious builder suspicious.)

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

From report at bugs.python.org  Wed Apr 10 17:40:01 2013
From: report at bugs.python.org (Tomasz J. Kotarba)
Date: Wed, 10 Apr 2013 15:40:01 +0000
Subject: [docs] [issue17668] re.split loses characters matching ungrouped
	parts of a	pattern
In-Reply-To: <1365445138.49.0.018016443065.issue17668@psf.upfronthosting.co.za>
Message-ID: <1365608401.6.0.750162601334.issue17668@psf.upfronthosting.co.za>


Tomasz J. Kotarba added the comment:

The example I gave was the simplest possible to illustrate my point but yes, you are correct, I often match the whole string as I do recursive matches.  I do use non-capturing groups but they would not solve the problem I talked about.  Anyway, I had solved my problem before I reported this issue so I would be all right with whatever the outcome of this discussion was but I am glad we have managed to contribute to improving the docs.  Thanks and nice talking to you :)!

----------

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

From report at bugs.python.org  Wed Apr 10 17:41:44 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 10 Apr 2013 15:41:44 +0000
Subject: [docs] [issue17641] ssl module doc unification
In-Reply-To: <1365184481.29.0.784588958426.issue17641@psf.upfronthosting.co.za>
Message-ID: <1365608504.23.0.286196967509.issue17641@psf.upfronthosting.co.za>


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


----------
stage:  -> committed/rejected
type:  -> enhancement

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

From report at bugs.python.org  Wed Apr 10 18:22:19 2013
From: report at bugs.python.org (=?utf-8?q?Daniel_M=C3=BCllner?=)
Date: Wed, 10 Apr 2013 16:22:19 +0000
Subject: [docs] [issue17688] Wrong signature for richcmpfunc in documentation
Message-ID: <1365610939.69.0.214227746512.issue17688@psf.upfronthosting.co.za>


New submission from Daniel M?llner:

The C API documentation has a code snippet with a sample implementation of a rich comparison function here:

http://docs.python.org/3.3/extending/newtypes.html#object-comparison

The function is declared as

static int
newdatatype_richcmp(PyObject *obj1, PyObject *obj2, int op)

but I believe that it should be

static PyObject *
newdatatype_richcmp(PyObject *obj1, PyObject *obj2, int op)

----------
assignee: docs at python
components: Documentation
messages: 186513
nosy: docs at python, muellner
priority: normal
severity: normal
status: open
title: Wrong signature for richcmpfunc in documentation
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 10 19:06:37 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 10 Apr 2013 17:06:37 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1365613597.55.0.486548536696.issue6696@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Last patch LGTM (except a couple of minor whitespace issues).
Tom, can you sign the contributor agreement (http://www.python.org/psf/contrib/contrib-form/)?

----------
stage: patch review -> commit review
versions:  -Python 3.2

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

From zachary.ware at gmail.com  Wed Apr 10 19:23:38 2013
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Wed, 10 Apr 2013 17:23:38 -0000
Subject: [docs] Bring Doc/make.bat as close to Doc/Makefile as possible
	(issue 17386)
Message-ID: <20130410172338.6860.13775@psf.upfronthosting.co.za>

Thanks for the comments, Ezio.


http://bugs.python.org/review/17386/diff/7596/Doc/README.txt
File Doc/README.txt (right):

http://bugs.python.org/review/17386/diff/7596/Doc/README.txt#newcode43
Doc/README.txt:43: make html "PYTHON=python"
On 2013/04/10 17:38:23, ezio.melotti wrote:
> Does "make html" work without specifying "PYTHON=python" (assuming
that "python"
> is a recognised command)?

Yes, that's a large part of the point of the patch to Doc/make.bat,
actually :)

> If "python" is not a recognised command, I guess that 
> `make html "PYTHON=C:\Python27\python.exe"` can be used instead.  Is
the syntax
> correct?  Maybe this could be added too here.

Exactly.  And yes, that syntax is correct, and that is a much better
example.  Next version of the patch will change to `make html
"PYTHON=C:\Python27\python.exe"`

http://bugs.python.org/review/17386/diff/7596/Doc/README.txt#newcode90
Doc/README.txt:90: A "make update" cleans up all builds and updates the
Subversion checkouts of
On 2013/04/10 17:38:23, ezio.melotti wrote:
> Why this is not in the list?

Just because it wasn't before.  I'm fine with adding it to the list.

> Also on Linux there's "make htmlview", not sure if it's available on
Windows too
> though.

Not yet :).  'htmlview' is undocumented even in the Makefile help
message, though (that's why it's not present in the make.bat patch yet);
next version of the patch will add 'htmlview' on Windows, document it in
Makefile, and add it and any other missing targets to README.txt
('clean', for example).

http://bugs.python.org/review/17386/diff/7596/Doc/README.txt#newcode117
Doc/README.txt:117: svn co
http://svn.python.org/projects/external/Pygments-1.5dev-20120930/pygments
tools/pygments
On 2013/04/10 17:38:23, ezio.melotti wrote:
> Any reason why a dev version is suggested?  Is this the version we are
currently
> using?

Yep, that's what's listed in Makefile and make.bat currently.

http://bugs.python.org/review/17386/diff/7596/Doc/make.bat
File Doc/make.bat (right):

http://bugs.python.org/review/17386/diff/7596/Doc/make.bat#newcode277
Doc/make.bat:277: echo positives, append that file to
tools\sphinxext\susp-ignored.csv.
On 2013/04/10 17:38:23, ezio.melotti wrote:
> On Linux if suspicious markup is found, the build gives an error and
this
> message is not printed (see http://bugs.python.org/issue15759).  Does
this work
> here? (You could add a few  ` or : in an rst file to make the
suspicious builder
> suspicious.)

Yes, this message always prints.  Actually, that's probably a bug; it
will print even if Sphinx never even ran, like say if PYTHON isn't a
valid command.  I can fix that either by adding an ERRORLEVEL check to
each completion method, or just make the completion messages more fuzzy
('should be' not 'is', etc).

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

From report at bugs.python.org  Wed Apr 10 19:56:22 2013
From: report at bugs.python.org (Kyle Roberts)
Date: Wed, 10 Apr 2013 17:56:22 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365616582.35.0.075905738169.issue17661@psf.upfronthosting.co.za>


Kyle Roberts added the comment:

Ah that's the type of thing I was looking for, thanks ?ric. I saw the underscored reference in functions.rst last night but figured it was just a local file link. I'll have a patch available later today. Thanks again.

----------

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

From report at bugs.python.org  Thu Apr 11 03:42:20 2013
From: report at bugs.python.org (Tom Pinckney)
Date: Thu, 11 Apr 2013 01:42:20 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1365613597.55.0.486548536696.issue6696@psf.upfronthosting.co.za>
Message-ID: <5C076541-CBC3-47C2-81CF-C54096242DDB@gmail.com>


Tom Pinckney added the comment:

Great!

Just signed the contributor agreement.

On Apr 10, 2013, at 1:06 PM, Ezio Melotti <report at bugs.python.org> wrote:

> 
> Ezio Melotti added the comment:
> 
> Last patch LGTM (except a couple of minor whitespace issues).
> Tom, can you sign the contributor agreement (http://www.python.org/psf/contrib/contrib-form/)?
> 
> ----------
> stage: patch review -> commit review
> versions:  -Python 3.2
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue6696>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Apr 11 05:35:07 2013
From: report at bugs.python.org (Kyle Roberts)
Date: Thu, 11 Apr 2013 03:35:07 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365651307.38.0.550515708411.issue17661@psf.upfronthosting.co.za>


Kyle Roberts added the comment:

So the :ref: keyword helps and creates a link, but it has the unfortunate side effect of adding different markup and style. I've attached two images to illustrate the differences. I couldn't find a way in the Sphinx or reST documentation to force it to style like a :func:, and my searches didn't come up with much either. Does anyone know of a way to style a :ref: just like a :func:?

The code I used to create the fixed link is:

:ref:`repr() <func-repr>`

----------
Added file: http://bugs.python.org/file29771/diff_style_example.PNG

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

From report at bugs.python.org  Thu Apr 11 05:35:20 2013
From: report at bugs.python.org (Kyle Roberts)
Date: Thu, 11 Apr 2013 03:35:20 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365651320.35.0.317403933036.issue17661@psf.upfronthosting.co.za>


Changes by Kyle Roberts <robertskyl at gmail.com>:


Added file: http://bugs.python.org/file29772/diff_style_markup.PNG

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

From report at bugs.python.org  Thu Apr 11 06:23:31 2013
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 11 Apr 2013 04:23:31 +0000
Subject: [docs] [issue15964] SyntaxError in asdl when building 2.7 with
	system Python	3
In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za>
Message-ID: <1365654211.22.0.805022885279.issue15964@psf.upfronthosting.co.za>


Roger Serwy added the comment:

Attached is the updated patch to include Ezio's review. Thanks Ezio!

----------
Added file: http://bugs.python.org/file29773/patch_2and3_rev1.py

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

From report at bugs.python.org  Thu Apr 11 06:26:00 2013
From: report at bugs.python.org (Roger Serwy)
Date: Thu, 11 Apr 2013 04:26:00 +0000
Subject: [docs] [issue17670] expandtabs() weirdness
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1365654360.82.0.0724367097585.issue17670@psf.upfronthosting.co.za>


Roger Serwy added the comment:

LGTM.

----------
nosy: +roger.serwy
stage: patch review -> commit review

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

From report at bugs.python.org  Thu Apr 11 14:53:35 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Apr 2013 12:53:35 +0000
Subject: [docs] [issue14971] (unittest) loadTestsFromName does not work on
	method	with a decorator
In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za>
Message-ID: <1365684815.47.0.64625721389.issue14971@psf.upfronthosting.co.za>


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


----------
nosy: +eckhardt

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

From report at bugs.python.org  Thu Apr 11 14:58:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 11 Apr 2013 12:58:38 +0000
Subject: [docs] [issue14971] (unittest) loadTestsFromName does not work on
	method	with a decorator
In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za>
Message-ID: <3Zmj3L1VNSzSH9@mail.python.org>


Roundup Robot added the comment:

New changeset b17bcfadd7f3 by R David Murray in branch '3.3':
#14971: Use class method name, not function.__name__, during unittest discovery.
http://hg.python.org/cpython/rev/b17bcfadd7f3

New changeset 659c89275be2 by R David Murray in branch 'default':
Merge #14971: Use class method name, not function.__name__, during unittest discovery.
http://hg.python.org/cpython/rev/659c89275be2

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

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

From report at bugs.python.org  Thu Apr 11 15:00:49 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Apr 2013 13:00:49 +0000
Subject: [docs] [issue14971] (unittest) loadTestsFromName does not work on
	method	with a decorator
In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za>
Message-ID: <1365685248.96.0.64080835828.issue14971@psf.upfronthosting.co.za>


R. David Murray added the comment:

Fixed in Python3.

The 2.7 unittest code is different enough that it is not immediately obvious how to make the equivalent fix (given that it has been a while since I looked at this logic).  If someone wants to work out the equivalent 2.7 patch, I will apply it.

----------
assignee: michael.foord -> 
stage:  -> needs patch
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Apr 12 00:34:50 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 11 Apr 2013 22:34:50 +0000
Subject: [docs] [issue17700] Update Curses HOWTO for 3.4
Message-ID: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za>


New submission from A.M. Kuchling:

Here's a patch updating the Curses HOWTO for 3.4 that can be applied to the default branch.  Changes:

* curses.wrapper.wrapper is now just curses.wrapper
* Mention window.encoding and its effect on Unicode.
* Describe getkey() as well as getch()
* Improve some examples.
* Use 4-space indentation.
* Add links to urwid, an alternate UI library.
* Various edits & rewording.

----------
assignee: docs at python
components: Documentation
files: update-curses-howto.txt
messages: 186599
nosy: akuchling, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Update Curses HOWTO for 3.4
type: enhancement
Added file: http://bugs.python.org/file29783/update-curses-howto.txt

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

From report at bugs.python.org  Fri Apr 12 02:06:03 2013
From: report at bugs.python.org (David Wolever)
Date: Fri, 12 Apr 2013 00:06:03 +0000
Subject: [docs] [issue17701] Improving strftime documentation
Message-ID: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>


New submission from David Wolever:

The current strftime documentation isn't very helpful. It doesn't have examples, and the ordering is unhelpful.

I've also moved some format-specific notes into the notes below the format-string-table, because the format string table is what 98%* of people care about.

TODO before this can be merged:
- Clean up note order
- Check that it works with the Python 3 docs

*: based on a sample size of 1

----------
assignee: docs at python
components: Documentation
files: strftime-docs.diff
keywords: needs review, patch
messages: 186601
nosy: docs at python, wolever
priority: normal
severity: normal
status: open
title: Improving strftime documentation
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file29784/strftime-docs.diff

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

From report at bugs.python.org  Fri Apr 12 02:08:09 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 12 Apr 2013 00:08:09 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365725289.84.0.975452207943.issue17701@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex

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

From report at bugs.python.org  Fri Apr 12 05:38:03 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Apr 2013 03:38:03 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365737883.03.0.0757957405403.issue17701@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks for the patch, looks good.  I?d put the versionadded block at the end of the note rather than the beginning, to match usual conventions.

----------
nosy: +eric.araujo
stage:  -> patch review
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Apr 12 05:45:18 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Apr 2013 03:45:18 +0000
Subject: [docs] [issue17700] Update Curses HOWTO for 3.4
In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za>
Message-ID: <1365738318.31.0.0246695491255.issue17700@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Do the changes (e.g. curses.wrapper new name) not apply to 3.3?

----------
nosy: +eric.araujo
versions: +Python 3.4

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

From report at bugs.python.org  Fri Apr 12 06:22:14 2013
From: report at bugs.python.org (David Wolever)
Date: Fri, 12 Apr 2013 04:22:14 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365740534.15.0.0130223708674.issue17701@psf.upfronthosting.co.za>


Changes by David Wolever <wolever at cs.toronto.edu>:


Added file: http://bugs.python.org/file29785/strftime-docs.diff

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

From report at bugs.python.org  Fri Apr 12 06:24:17 2013
From: report at bugs.python.org (David Wolever)
Date: Fri, 12 Apr 2013 04:24:17 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365740657.7.0.937677648658.issue17701@psf.upfronthosting.co.za>


David Wolever added the comment:

Ah, yes ? thanks ?ric. I've fiddled with the wording on the %f note a bit so it makes more sense along with the versionadded, and removed the versionadded text, which is basically identical to the note and description.

----------

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

From report at bugs.python.org  Fri Apr 12 15:09:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Apr 2013 13:09:31 +0000
Subject: [docs] [issue17688] Wrong signature for richcmpfunc in documentation
In-Reply-To: <1365610939.69.0.214227746512.issue17688@psf.upfronthosting.co.za>
Message-ID: <3ZnKFQ65gGzRMC@mail.python.org>


Roundup Robot added the comment:

New changeset a263d40d1724 by Andrew Svetlov in branch '3.3':
#17688: fix declaration for richcmp example in the docs.
http://hg.python.org/cpython/rev/a263d40d1724

New changeset 4c996682d086 by Andrew Svetlov in branch 'default':
#17688: fix declaration for richcmp example in the docs.
http://hg.python.org/cpython/rev/4c996682d086

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

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

From report at bugs.python.org  Fri Apr 12 15:10:01 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 12 Apr 2013 13:10:01 +0000
Subject: [docs] [issue17688] Wrong signature for richcmpfunc in documentation
In-Reply-To: <1365610939.69.0.214227746512.issue17688@psf.upfronthosting.co.za>
Message-ID: <1365772201.39.0.930084223775.issue17688@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed. Thanks.

----------
nosy: +asvetlov
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.4

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

From report at bugs.python.org  Fri Apr 12 15:25:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Apr 2013 13:25:57 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <3ZnKcN5SG6zNwL@mail.python.org>


Roundup Robot added the comment:

New changeset cd785c9d26c2 by Ezio Melotti in branch '3.3':
#6696: add documentation for the Profile objects, and improve profile/cProfile docs.  Patch by Tom Pinckney.
http://hg.python.org/cpython/rev/cd785c9d26c2

New changeset 81dabc1feb52 by Ezio Melotti in branch 'default':
#6696: merge with 3.3.
http://hg.python.org/cpython/rev/81dabc1feb52

New changeset b57245574717 by Ezio Melotti in branch '2.7':
#6696: add documentation for the Profile objects, and improve profile/cProfile docs.  Patch by Tom Pinckney.
http://hg.python.org/cpython/rev/b57245574717

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

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

From report at bugs.python.org  Fri Apr 12 15:26:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Apr 2013 13:26:56 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1365773215.93.0.0690287258496.issue6696@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee: eric.araujo -> ezio.melotti
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
type: behavior -> enhancement

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

From report at bugs.python.org  Fri Apr 12 15:31:45 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 12 Apr 2013 13:31:45 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1365773505.2.0.615989327984.issue6696@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Cool! Thanks.

----------

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

From report at bugs.python.org  Fri Apr 12 16:19:29 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Apr 2013 14:19:29 +0000
Subject: [docs] [issue17700] Update Curses HOWTO for 3.4
In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za>
Message-ID: <1365776368.58.0.00330521998532.issue17700@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Updated version of the patch:

* Correct the errors reported in the review.
* Restore 3-space indents.
* Mention the LINES and COLS variables.
* Add more links to the final section.

I believe everything in the howto also applies to 3.3; it would be fine if you want to apply it to the 3.3 branch as well.

----------
Added file: http://bugs.python.org/file29790/update-curses-howto.txt

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

From report at bugs.python.org  Fri Apr 12 18:20:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Apr 2013 16:20:27 +0000
Subject: [docs] [issue17653] fix typo in socketserver.rst
Message-ID: <3ZnPTk3dFYz7LlC@mail.python.org>


New submission from Roundup Robot:

New changeset 26639365e62b by Ezio Melotti in branch '3.3':
#17653: fix typo in socketserver docs.  Patch by Tshepang Lekhonkhobe.
http://hg.python.org/cpython/rev/26639365e62b

New changeset 5118304a4c9c by Ezio Melotti in branch 'default':
#17653: merge with 3.3.
http://hg.python.org/cpython/rev/5118304a4c9c

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

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

From report at bugs.python.org  Fri Apr 12 18:22:02 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Apr 2013 16:22:02 +0000
Subject: [docs] [issue17653] fix typo in socketserver.rst
In-Reply-To: <3ZnPTk3dFYz7LlC@mail.python.org>
Message-ID: <1365783722.84.0.876529392586.issue17653@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

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

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

From report at bugs.python.org  Fri Apr 12 20:32:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Apr 2013 18:32:15 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365791535.44.0.169763835523.issue17661@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I don't think the style is so important, especially since this issue only affects 2.7.

----------
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Fri Apr 12 21:17:25 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Apr 2013 19:17:25 +0000
Subject: [docs] [issue17670] Improve str.expandtabs() doc
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1365794245.06.0.69351620398.issue17670@psf.upfronthosting.co.za>


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


----------
title: expandtabs() weirdness -> Improve str.expandtabs() doc

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

From report at bugs.python.org  Fri Apr 12 21:48:35 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Apr 2013 19:48:35 +0000
Subject: [docs] [issue17686] Doc using/unix broken link
	(http://linuxmafia.com/)
In-Reply-To: <1365599495.88.0.846759502226.issue17686@psf.upfronthosting.co.za>
Message-ID: <1365796115.61.0.711983069781.issue17686@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Do you know of a replacement, or should be just delete?

----------
nosy: +terry.reedy
versions: +Python 3.4

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

From report at bugs.python.org  Fri Apr 12 22:26:08 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Apr 2013 20:26:08 +0000
Subject: [docs] [issue15657] Error in Python 3 docs for PyMethodDef
In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za>
Message-ID: <1365798368.13.0.913737836367.issue15657@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I just ran into this too.

----------
nosy: +barry

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

From report at bugs.python.org  Fri Apr 12 22:27:52 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 12 Apr 2013 20:27:52 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1365798471.34.0.605530387856.issue17386@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a new patch to address Ezio's review comments, including more updates to Doc/README.txt, the addition of an 'htmlview' target to make.bat, and documentation of the 'htmlview' target in the Makefile usage message.

----------
Added file: http://bugs.python.org/file29792/win_doc_make.v3.diff

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

From report at bugs.python.org  Fri Apr 12 22:31:58 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Apr 2013 20:31:58 +0000
Subject: [docs] [issue15657] Error in Python 3 docs for PyMethodDef
In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za>
Message-ID: <1365798718.81.0.279788597147.issue15657@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

We should fix the code for 3.2 through 3.4, but change the docs for 3.2 and 3.3 to remove the parenthetical note.  For 3.4 we can leave the parenthetical note but say this is new in 3.4 (or maybe, that it doesn't actually work in some versions < 3.4).  I agree that for code to work consistently across all Python 3.2 and 3.3 microversions, extension code is going to have to include both flags anyway.

----------
versions: +Python 3.4

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

From report at bugs.python.org  Fri Apr 12 23:02:00 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Apr 2013 21:02:00 +0000
Subject: [docs] [issue17686] Doc using/unix broken link
	(http://linuxmafia.com/)
In-Reply-To: <1365599495.88.0.846759502226.issue17686@psf.upfronthosting.co.za>
Message-ID: <1365800520.54.0.549962516699.issue17686@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Perhaps http://en.opensuse.org/Portal:Packaging is a good replacement.

----------
nosy: +akuchling

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

From report at bugs.python.org  Sat Apr 13 03:19:21 2013
From: report at bugs.python.org (Tom Pinckney)
Date: Sat, 13 Apr 2013 01:19:21 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1365815961.3.0.425373122217.issue6696@psf.upfronthosting.co.za>


Tom Pinckney added the comment:

Thanks everyone for helping me through my first python patch submission.

----------

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

From report at bugs.python.org  Sat Apr 13 05:03:55 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 13 Apr 2013 03:03:55 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1365822235.1.0.973221346181.issue12768@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Issue #17375 supersedes this one. Please post updated patches there.

----------

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

From report at bugs.python.org  Sat Apr 13 05:04:07 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 13 Apr 2013 03:04:07 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1365822247.43.0.0358401560047.issue12768@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Sat Apr 13 05:12:03 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 13 Apr 2013 03:12:03 +0000
Subject: [docs] [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1365822723.12.0.656478040945.issue16575@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I've opened a libffi issue in an attempt to get this fixed upstream:

  https://github.com/atgreen/libffi/issues/33

----------

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

From report at bugs.python.org  Sat Apr 13 05:16:39 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 13 Apr 2013 03:16:39 +0000
Subject: [docs] [issue17670] Improve str.expandtabs() doc
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1365822999.61.0.523078206663.issue17670@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I agree the doc could be clearer and Ned's example is very good. However I'd go one step forward and add a further elaboration of how the method works. This is the current doc (in default branch):

  Return a copy of the string where all tab characters are replaced by zero or more spaces, depending on the current column and the given tab size. The column number is reset to zero after each newline occurring in the string. If tabsize is not given, a tab size of 8 characters is assumed. This doesn?t understand other non-printing characters or escape sequences.

I'd say this (note new second sentence):

  Return a copy of the string where all tab characters are replaced by zero or more spaces, depending on the current column and the given tab size. Every time a \t char appears in the string, the text before it gets padded with spaces until the next tab position is reached. The column number is reset to zero after each newline occurring in the string. If tabsize is not given, a tab size of 8 characters is assumed. This doesn?t understand other non-printing characters or escape sequences.

And then follow with Ned's example.

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

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

From report at bugs.python.org  Sat Apr 13 05:19:56 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 13 Apr 2013 03:19:56 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1365823196.55.0.744639478536.issue16954@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

David, would you like to pursue this further (figuring out how to make docstrings show in help() without duplicating?)

----------

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

From report at bugs.python.org  Sat Apr 13 09:18:45 2013
From: report at bugs.python.org (Russell Stuart)
Date: Sat, 13 Apr 2013 07:18:45 +0000
Subject: [docs] [issue17709] http://docs.python.org/2.7/objects.inv doesn't
	support	:func:`repr` or :exc:`Exception`
Message-ID: <1365837524.98.0.624427340429.issue17709@psf.upfronthosting.co.za>


New submission from Russell Stuart:

.. topic:: http://docs.python.org/2.7/objects.inv doesn't support :func:`repr` or :exc:`Exception`

  A bug report for Python 2.7's docs.

.. _intro:

Bug
===

Running::

  sphinx-build -c conf2.7 -n -b html -E . html

Produces::

  Running Sphinx v1.1.3
  loading intersphinx inventory from http://docs.python.org/2.7/objects.inv...
  building [html]: targets for 1 source files that are out of date
  updating environment: 1 added, 0 changed, 0 removed
  reading sources... [100%] bug                                                                             
  looking for now-outdated files... none found
  pickling environment... done
  checking consistency... done
  preparing documents... done
  writing output... [100%] bug                                                                              
  /home/rstuart/zzz/bug.rst:1: WARNING: py:exc reference target not found: Exception
  /home/rstuart/zzz/bug.rst:1: WARNING: py:func reference target not found: repr
  writing additional files... genindex search
  copying static files... done
  dumping search index... done
  dumping object inventory... done
  build succeeded, 2 warnings.

Note the ``WARNING`` lines.  They should not be there.

Running::

  sphinx-build -c conf3.2 -b html -n -E . html

Produces::

  Running Sphinx v1.1.3
  loading intersphinx inventory from http://docs.python.org/3.2/objects.inv...
  building [html]: targets for 1 source files that are out of date
  updating environment: 1 added, 0 changed, 0 removed
  reading sources... [100%] bug                                                                             
  looking for now-outdated files... none found
  pickling environment... done
  checking consistency... done
  preparing documents... done
  writing output... [100%] bug                                                                              
  writing additional files... genindex search
  copying static files... done
  dumping search index... done
  dumping object inventory... done
  build succeeded.

I presume this means something is wrong with 
http://docs.python.org/2.7/objects.inv it downloads.

``conf2.7.py``:

  .. include:: conf2.7/conf.py
    :literal:

``conf3.2.py``:

  .. include:: conf3.2/conf.py
    :literal:

----------
assignee: docs at python
components: Documentation
files: bug.rst
messages: 186697
nosy: docs at python, ras
priority: normal
severity: normal
status: open
title: http://docs.python.org/2.7/objects.inv doesn't support :func:`repr` or :exc:`Exception`
versions: Python 2.7
Added file: http://bugs.python.org/file29794/bug.rst

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

From report at bugs.python.org  Sat Apr 13 09:19:36 2013
From: report at bugs.python.org (Russell Stuart)
Date: Sat, 13 Apr 2013 07:19:36 +0000
Subject: [docs] [issue17709] http://docs.python.org/2.7/objects.inv doesn't
	support	:func:`repr` or :exc:`Exception`
In-Reply-To: <1365837524.98.0.624427340429.issue17709@psf.upfronthosting.co.za>
Message-ID: <1365837576.3.0.108538365927.issue17709@psf.upfronthosting.co.za>


Changes by Russell Stuart <russell+python at stuart.id.au>:


Added file: http://bugs.python.org/file29795/conf.py

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

From report at bugs.python.org  Sat Apr 13 09:20:09 2013
From: report at bugs.python.org (Russell Stuart)
Date: Sat, 13 Apr 2013 07:20:09 +0000
Subject: [docs] [issue17709] http://docs.python.org/2.7/objects.inv doesn't
	support	:func:`repr` or :exc:`Exception`
In-Reply-To: <1365837524.98.0.624427340429.issue17709@psf.upfronthosting.co.za>
Message-ID: <1365837609.27.0.671714464812.issue17709@psf.upfronthosting.co.za>


Changes by Russell Stuart <russell+python at stuart.id.au>:


Added file: http://bugs.python.org/file29796/conf.py

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

From report at bugs.python.org  Sat Apr 13 10:00:11 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 13 Apr 2013 08:00:11 +0000
Subject: [docs] [issue17709] http://docs.python.org/2.7/objects.inv doesn't
	support	:func:`repr` or :exc:`Exception`
In-Reply-To: <1365837524.98.0.624427340429.issue17709@psf.upfronthosting.co.za>
Message-ID: <1365840011.96.0.345158772339.issue17709@psf.upfronthosting.co.za>


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


----------
nosy: +eric.araujo, georg.brandl

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

From report at bugs.python.org  Sat Apr 13 18:19:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Apr 2013 16:19:10 +0000
Subject: [docs] [issue17670] Improve str.expandtabs() doc
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1365869950.38.0.530498497321.issue17670@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

"This doesn?t understand other non-printing characters or escape sequences."

This might also be improved.  Does it mean that all characters are considered having len(c) == 1, even if they are not printable or escape sequence (and which escape sequences? \f, \v?)?

Adding an example with tabsize=8 might also help, but it might not be necessary if the wording is improved as Eli suggested.

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

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

From report at bugs.python.org  Sat Apr 13 18:19:43 2013
From: report at bugs.python.org (Dan Riti)
Date: Sat, 13 Apr 2013 16:19:43 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365869983.88.0.761925905617.issue17661@psf.upfronthosting.co.za>


Dan Riti added the comment:

Reproduced the issue and generated a patch following Kyle's documented approach. 

Please note that this patch addresses the link problem, but does not address the style issue. Thanks.

----------
keywords: +patch
nosy: +Dan.Riti
Added file: http://bugs.python.org/file29801/using-ref.patch

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

From ezio.melotti at gmail.com  Sat Apr 13 18:45:06 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sat, 13 Apr 2013 16:45:06 -0000
Subject: [docs] Update Curses HOWTO for 3.4 (issue 17700)
Message-ID: <20130413164506.459.28157@psf.upfronthosting.co.za>

Just a few markup-related nitpicks :)


http://bugs.python.org/review/17700/diff/7840/Doc/howto/curses.rst
File Doc/howto/curses.rst (right):

http://bugs.python.org/review/17700/diff/7840/Doc/howto/curses.rst#newcode40
Doc/howto/curses.rst:40: appearance--and the curses library will figure
out what control codes
These should be --- (-- creates an EN dash).  Also the spacing around
them is not consistent (I'm not sure if there is a convention about it,
but I usually put a space before and after it).

http://bugs.python.org/review/17700/diff/7840/Doc/howto/curses.rst#newcode44
Doc/howto/curses.rst:44: `Urwid
<https://pypi.python.org/pypi/urwid/>`__.
A single trailing _ is enough to create links.

http://bugs.python.org/review/17700/diff/7840/Doc/howto/curses.rst#newcode143
Doc/howto/curses.rst:143: for i in range(0, 20):
range(20)?

http://bugs.python.org/review/17700/diff/7840/Doc/howto/curses.rst#newcode180
Doc/howto/curses.rst:180: Note that the coordinate system used in curses
is unusual.  Coordinates are always passed
This line is too long.  There are a few more long lines later.

http://bugs.python.org/review/17700/diff/7840/Doc/howto/curses.rst#newcode250
Doc/howto/curses.rst:250: update the data structure, and then call
:func:`doupdate` to update
All these can be turned into links by using :func:`~curses.doupdate`. 
IIRC there was also a way to specify the current module, so that it's no
longer necessary to keep adding ~curses in each role.

http://bugs.python.org/review/17700/diff/7840/Doc/howto/curses.rst#newcode436
Doc/howto/curses.rst:436: window method. After ``nodelay(1)``,
:meth:`getch` and :meth:`getkey`
nodelay(True)?

http://bugs.python.org/review/17700/diff/7840/Doc/howto/curses.rst#newcode480
Doc/howto/curses.rst:480: spaces.   Here's an example::
Extra space.

http://bugs.python.org/review/17700/diff/7840/Doc/howto/curses.rst#newcode488
Doc/howto/curses.rst:488: editwin = curses.newwin(5,30,2,1)
Spaces after commas.

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

From report at bugs.python.org  Sat Apr 13 18:45:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Apr 2013 16:45:55 +0000
Subject: [docs] [issue17700] Update Curses HOWTO for 3.4
In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za>
Message-ID: <1365871555.22.0.535802688286.issue17700@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
versions: +Python 3.3

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

From report at bugs.python.org  Sat Apr 13 19:03:24 2013
From: report at bugs.python.org (Dan Riti)
Date: Sat, 13 Apr 2013 17:03:24 +0000
Subject: [docs] [issue17686] Doc using/unix broken link
	(http://linuxmafia.com/)
In-Reply-To: <1365599495.88.0.846759502226.issue17686@psf.upfronthosting.co.za>
Message-ID: <1365872604.17.0.836243823112.issue17686@psf.upfronthosting.co.za>


Dan Riti added the comment:

I second akuchling's link suggestion, as it seems to be the most up to date openSUSE packaging resource.

I have generated a patch to update the link.

Also, it seems this link is also broken in the 2.7 documentation:

http://docs.python.org/2/using/unix.html

----------
keywords: +patch
nosy: +dan.riti
Added file: http://bugs.python.org/file29806/update-link.patch

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

From report at bugs.python.org  Sat Apr 13 19:08:24 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Apr 2013 17:08:24 +0000
Subject: [docs] [issue17686] Doc using/unix broken link
	(http://linuxmafia.com/)
In-Reply-To: <1365599495.88.0.846759502226.issue17686@psf.upfronthosting.co.za>
Message-ID: <3Zp2Vb2cZ6zRWY@mail.python.org>


Roundup Robot added the comment:

New changeset 2ed694679b81 by Ezio Melotti in branch '3.3':
#17686: fix broken link in Doc/using/unix.rst.  Patch by Dan Riti.
http://hg.python.org/cpython/rev/2ed694679b81

New changeset 86a95813e5c3 by Ezio Melotti in branch 'default':
#17686: merge with 3.3.
http://hg.python.org/cpython/rev/86a95813e5c3

New changeset 0f31f38e8a17 by Ezio Melotti in branch '2.7':
#17686: fix broken link in Doc/using/unix.rst.  Patch by Dan Riti.
http://hg.python.org/cpython/rev/0f31f38e8a17

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

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

From report at bugs.python.org  Sat Apr 13 19:08:59 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Apr 2013 17:08:59 +0000
Subject: [docs] [issue17686] Doc using/unix broken link
	(http://linuxmafia.com/)
In-Reply-To: <1365599495.88.0.846759502226.issue17686@psf.upfronthosting.co.za>
Message-ID: <1365872939.83.0.397838185805.issue17686@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

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

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

From report at bugs.python.org  Sat Apr 13 19:13:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Apr 2013 17:13:06 +0000
Subject: [docs] [issue17571] broken links on Lib/datetime.py docstring
In-Reply-To: <1364543666.79.0.123809819447.issue17571@psf.upfronthosting.co.za>
Message-ID: <3Zp2c11jvBzQD5@mail.python.org>


Roundup Robot added the comment:

New changeset 70f9f6752d28 by Ezio Melotti in branch '3.3':
#17571: remove broken links in datetime.py docstring.
http://hg.python.org/cpython/rev/70f9f6752d28

New changeset 0d2c364c7e5d by Ezio Melotti in branch 'default':
#17571: merge with 3.3.
http://hg.python.org/cpython/rev/0d2c364c7e5d

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

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

From report at bugs.python.org  Sat Apr 13 19:13:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Apr 2013 17:13:38 +0000
Subject: [docs] [issue17571] broken links on Lib/datetime.py docstring
In-Reply-To: <1364543666.79.0.123809819447.issue17571@psf.upfronthosting.co.za>
Message-ID: <1365873218.52.0.0909663739102.issue17571@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From ezio.melotti at gmail.com  Sat Apr 13 19:17:06 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sat, 13 Apr 2013 17:17:06 -0000
Subject: [docs] SyntaxError in asdl when building 2.7 with system Python
	3 (issue 15964)
Message-ID: <20130413171706.20596.55930@psf.upfronthosting.co.za>


http://bugs.python.org/review/15964/diff/7830/Parser/spark.py
File Parser/spark.py (right):

http://bugs.python.org/review/15964/diff/7830/Parser/spark.py#newcode833
Parser/spark.py:833: s = '\t\t %s ::= ' % str(lhs)
The str() here is no longer necessary, since %s should call it already.

http://bugs.python.org/review/15964/diff/7830/Parser/spark.py#newcode834
Parser/spark.py:834: s += ' '.join(rhs[:pos]) + ' '
The trailing space here is no longer necessary, since it has been moved
on the next line.

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

From report at bugs.python.org  Sat Apr 13 19:21:41 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Apr 2013 17:21:41 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1365873701.63.0.184111642661.issue17386@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Terry, do you want to test and commit this?
Should it be backported to 3.3 (and possibly 2.7) too?

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Sat Apr 13 19:22:57 2013
From: report at bugs.python.org (Kent Johnson)
Date: Sat, 13 Apr 2013 17:22:57 +0000
Subject: [docs] [issue17719] IDLE help text refers to incorrect Python
	version
Message-ID: <1365873777.93.0.00334201360325.issue17719@psf.upfronthosting.co.za>


New submission from Kent Johnson:

The IDLE help text says, "Running without a subprocess: (DEPRECATED in Python 3.5 see Issue 16123)." According to the referenced issue, this feature is scheduled to be deprecated in *3.4* and *removed* in 3.5. The attached patch corrects the help text.

----------
assignee: docs at python
components: Documentation
files: deprecated_in_3.4.patch
keywords: patch
messages: 186769
nosy: docs at python, kjohnson
priority: normal
severity: normal
status: open
title: IDLE help text refers to incorrect Python version
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file29808/deprecated_in_3.4.patch

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

From report at bugs.python.org  Sat Apr 13 19:26:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 13 Apr 2013 17:26:55 +0000
Subject: [docs] [issue17719] IDLE help text refers to incorrect Python
	version
In-Reply-To: <1365873777.93.0.00334201360325.issue17719@psf.upfronthosting.co.za>
Message-ID: <1365874015.12.0.314603973409.issue17719@psf.upfronthosting.co.za>


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


----------
nosy: +asvetlov
stage:  -> patch review

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

From report at bugs.python.org  Sat Apr 13 19:30:23 2013
From: report at bugs.python.org (Kent Johnson)
Date: Sat, 13 Apr 2013 17:30:23 +0000
Subject: [docs] [issue17719] IDLE help text refers to incorrect Python
	version
In-Reply-To: <1365873777.93.0.00334201360325.issue17719@psf.upfronthosting.co.za>
Message-ID: <1365874222.99.0.108255130097.issue17719@psf.upfronthosting.co.za>


Kent Johnson added the comment:

Note: this text does not appear in Doc/library/idle.rst so it does not have to be corrected there.

----------

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

From sandro.tosi at gmail.com  Sat Apr 13 19:36:53 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 13 Apr 2013 19:36:53 +0200
Subject: [docs] Documentation Bug frm ActivePython User Guide
In-Reply-To: <515B3AD1.1070100@telus.net>
References: <515B3AD1.1070100@telus.net>
Message-ID: <CAB4XWXwMLTpdTbsY6xb-oBcnT9qsa0R9VMB0vMQp-v7UCYdzhA@mail.gmail.com>

Hello Kevin,

On Tue, Apr 2, 2013 at 10:08 PM, Kevin Smith <ksmith1 at telus.net> wrote:
>              Hello,
>     I tried the code from this section in the guide ...
>
> 4.4. break and continue Statements, and else Clauses on Loops

I suggest to look at
http://docs.python.org/2.7/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops
and the note below the code, reported here: "Yes, this is the correct
code. Look closely: the else clause belongs to the for loop, not the
if statement."

It's likely the code you entered was not correctly indented, hence the
misbehaviour you're seeing.

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 Apr 13 20:29:53 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 13 Apr 2013 18:29:53 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1365877793.25.0.0847012097733.issue17386@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I do want to test this. If my regular machine does not get fixed soon, I will install svn on my current substitute to do so.

----------

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

From report at bugs.python.org  Sat Apr 13 20:39:02 2013
From: report at bugs.python.org (peter recore)
Date: Sat, 13 Apr 2013 18:39:02 +0000
Subject: [docs] [issue9538] Replace confusing pseudoname 'object' in special
	methods	section.
In-Reply-To: <1281211479.21.0.733519342396.issue9538@psf.upfronthosting.co.za>
Message-ID: <1365878341.98.0.254543885784.issue9538@psf.upfronthosting.co.za>


peter recore added the comment:

Here is a patch that implements Eric's suggestion.  I am a new contributor and would welcome feedback on if this is correct or not.

----------
keywords: +patch
nosy: +peterrecore
Added file: http://bugs.python.org/file29815/issue9538.patch

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

From report at bugs.python.org  Sat Apr 13 21:29:18 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Apr 2013 19:29:18 +0000
Subject: [docs] [issue9538] Replace confusing pseudoname 'object' in special
	methods	section.
In-Reply-To: <1281211479.21.0.733519342396.issue9538@psf.upfronthosting.co.za>
Message-ID: <1365881358.37.0.31286932255.issue9538@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Note that Sphinx searches for "object.__foo__" when :meth:`__foo__` is used; this change will break all those links.

For that reason I'm -1 to this change: I don't see the perceived issue as problematic anyway.

----------

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

From report at bugs.python.org  Sat Apr 13 21:29:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Apr 2013 19:29:45 +0000
Subject: [docs] [issue17719] IDLE help text refers to incorrect Python
	version
In-Reply-To: <1365873777.93.0.00334201360325.issue17719@psf.upfronthosting.co.za>
Message-ID: <3Zp5dh6C5PzMHT@mail.python.org>


Roundup Robot added the comment:

New changeset eac4e23ce2fd by R David Murray in branch 'default':
#17719: fix incorrect version number in deprecation doc.
http://hg.python.org/cpython/rev/eac4e23ce2fd

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

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

From report at bugs.python.org  Sat Apr 13 21:31:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Apr 2013 19:31:33 +0000
Subject: [docs] [issue17719] IDLE help text refers to incorrect Python
	version
In-Reply-To: <1365873777.93.0.00334201360325.issue17719@psf.upfronthosting.co.za>
Message-ID: <1365881493.79.0.147308608803.issue17719@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Kent.  For the record, the issue for the deprecation is #16123, and the issue that introduced the incorrect line is #5066.

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

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

From report at bugs.python.org  Sat Apr 13 22:13:36 2013
From: report at bugs.python.org (Dan Riti)
Date: Sat, 13 Apr 2013 20:13:36 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1365884016.69.0.474383002635.issue13510@psf.upfronthosting.co.za>


Dan Riti added the comment:

After reading the comments, I generated a patch that does the following:

- Reorganize to present `for line in f:` as the first approach for reading lines. I refrained from saying it's the *preferred* approach, however I can add that if desired.
- Reorganize to present `f.readlines()` as the alternative approach.

Any feedback is more then welcome! Thanks.

----------
keywords: +patch
nosy: +dan.riti
Added file: http://bugs.python.org/file29822/demote-readlines.patch

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

From report at bugs.python.org  Sat Apr 13 22:16:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Apr 2013 20:16:07 +0000
Subject: [docs] [issue16273] f.tell() returning negative number on Windows
	build
In-Reply-To: <1350526122.97.0.103530434711.issue16273@psf.upfronthosting.co.za>
Message-ID: <1365884167.8.0.96880405251.issue16273@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation, IO -Interpreter Core
nosy: +docs at python
priority: high -> normal
stage: test needed -> patch review
versions: +Python 3.3, Python 3.4 -Python 2.7

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

From report at bugs.python.org  Sat Apr 13 22:20:52 2013
From: report at bugs.python.org (peter recore)
Date: Sat, 13 Apr 2013 20:20:52 +0000
Subject: [docs] [issue9538] Replace confusing pseudoname 'object' in special
	methods	section.
In-Reply-To: <1281211479.21.0.733519342396.issue9538@psf.upfronthosting.co.za>
Message-ID: <1365884452.87.0.320849678832.issue9538@psf.upfronthosting.co.za>


peter recore added the comment:

George,

When I build the docs with my changes, the links from the method names seem to work the same way as they do in the existing docs.

----------

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

From report at bugs.python.org  Sat Apr 13 22:25:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Apr 2013 20:25:35 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1365884735.58.0.333872706188.issue13510@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

In 3.x I think we'll want to drop the following sentence: "Since the two approaches manage line buffering differently, they should not be mixed". But it can wait for another issue.

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

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

From sandro.tosi at gmail.com  Sat Apr 13 22:25:22 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 13 Apr 2013 22:25:22 +0200
Subject: [docs] Preparing a Change for Requirementshandling in Python
	projects
In-Reply-To: <CAJqWTsLq9URMOwusG2KT2YMw-PEr9Kd9jVcKrBe=VUjS8yj7qQ@mail.gmail.com>
References: <CAJqWTsLq9URMOwusG2KT2YMw-PEr9Kd9jVcKrBe=VUjS8yj7qQ@mail.gmail.com>
Message-ID: <CAB4XWXzMK8k=KraPpMx=_4US9cMqNcxRq=6P938FHnbF1dOKhg@mail.gmail.com>

Hello Erik,
thanks for your interest in making the Python documentation even better.

On Mon, Mar 25, 2013 at 9:32 AM, Erik Bernoth <bernoth at dresearch-fe.de> wrote:
> Hi Documenters,
>
> some weeks ago I discussed a way to handle installation reqiurements with
> the Distutils people [1] and found that the working solution is *not*
> described in the documentation [2,3], while what is described in the
> documentation is rather confusing and doesn't work. Thus I want to change
> that documentation! But because it's my first change to an important project
> like Python, I want to make sure about the way to get there. I'd like your
> help on this first and hopefully not last change I want to make to the
> Python docs!

Sorry for this quite late reply, I hope this hadn't reduced your
enthusiasm in the Python project.

> Prerequisits I bring with me
> ======================
>
>  * Acceptable Skills with Python (and other programming languages)
>  * Wrote different parts of the documentation of a small open source
> framework in Sphinx before
>  * Ability to create patch files with git, and thus probably also with hg
>  * I've read the devguide [4] until and including chapter 7, which led me to
> this mailing list
>  * An idea about the change I want to make
>  * The willingness to see this change to a successful end, even if it takes
> days or weeks (actually I already spent some days preparing!)
>  * Downloaded and built the CPython 3.4 binary and docs

that's a really nice skills set!

> Challenges for me
> ===============
>
>  * English isn't my mothertounge (it's German)

no worries, there's a lot of developers writing documentation in
English even if it's not their mother tongue.

>  * no plan how to put everything into the different branches yet (verified
> the same documentation exists for all w.i.p. python branches)
>  * Haven't written the patch file yet
>
>
> Problem Details
> =============
>
> The chapter 2.4 [2,3] of the distutils documentation has the following
> mistakes/problems/unclearness:
>  * It describes the usage of an parameter `requires` to the setup()
> function, which should tell pip which other packages it needs to install for
> the current project to work. That doesn't work.
>  * There is another parameter called "install_requires" which does exactly,
> what you would expect. If you install the current project to your
> virtualenv, then the other packages are downloaded from the pypi server as
> well. This one is not mentioned at all.
>  * the application of either parameter is pretty much the same, but it is
> explained with a lot of text instead of a simple example. The concept isn't
> hard to grasp, but the documentation about it is.
>  * Some details, like setting spaces at the right points, are not described
> precisely enough and are open to interpretation by the learning reader.
> Experimenting while learning is nothing people really like to do. They want
> to get a clear guide and an example, implement it and see a working result.
>
>
>
> Idea for the new version
> ====================
>
>  1. The list of what you can do (already exists, but change "requires" and
> "install_requires"): require, provide and obsolete and a short explanation
> what each of them does.
>  2. A short example which has all three relationships preferably with a
> small diagram (shouldn't be too confusing, because all should be handled the
> same way).
>  3. The implementation of the corresponding setup() function.
>  4. A description of what exactly happens in the setup function.
>  5. A description of the grammatical details
>  6. A detailed explanation about how to deviate from the example
>
>
> What I want from you
> ==================
> 1) Do you like the idea?
> 2) Do you agree with the problem?
> 3) How would you handle the existing but seemingly not working paramter
> "requires" and tell the user that he should use "install_requires" instead?
> 4) How do I go about changing this page for every version? I'd like to start
> it for the current default branch and backtrace my way afterwards.
> 5) Anything unclear?

I think the idea might be good, but I encourage you to write a patch
(even as a draft) to the documentation and post it as a bug in the
Python issues tracking system at: bugs.python.org ; at that point,
people will start discussing your proposal, and you'd get a a wider
audience than this list.

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

From amachu at amachu.me  Thu Apr  4 22:29:04 2013
From: amachu at amachu.me (=?UTF-8?B?4K6G4K6u4K6+4K6a4K+N4K6a4K+B?=)
Date: Fri, 05 Apr 2013 01:59:04 +0530
Subject: [docs] docs.python.org source
Message-ID: <515DE290.4080508@amachu.me>

I am looking forward to checkout all rst files of docs.python.org to my
local for having a local copy of the site for quick reference.

I couldn't find it immediately, searching for few minutes now.  Any
pointers?

--

Sri Ramadoss M


From barry at abrahamsen.com  Tue Apr  9 18:43:53 2013
From: barry at abrahamsen.com (Barry E Abrahamsen)
Date: Tue, 9 Apr 2013 09:43:53 -0700
Subject: [docs] Python on Mac OS X
Message-ID: <7EE51540-5A6E-4549-81A2-A140A4C8C4BB@abrahamsen.com>

on this page:

http://docs.python.org/2/using/mac.html

Section 4.1 says "Mac OS X 10.5 comes with Python 2.5.1 pre-installed by Apple." That may have been true years ago, but the current version of the Mac OS is 10.8 and the version of Python provided by Apple is 2.7. 

I don't have enough experience with Python or the UNIX underpinnings of Mac OS X to say much more about this information. However, I expected, after installing Python 3.3.1 and running the shell script, that typing "which python" in a console session would tell me 3.3.1, but it continues to say 2.7 as does the Python Launcher. I only get 3.3.1 using IDLE, If this is what "you will have two different but functional Python installations on your computer" means, then it would be helpful for a beginner to understand that. 

Looking around on the internet for python-on-Mac resources, I find a lot of out-of-date and partial information. This is discouraging to a beginner. 

=====
Barry Abrahamsen
Seattle, Washington
http://www.abrahamsen.com/
http://www.AmericanBamboo.org/

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

From barry at abrahamsen.com  Tue Apr  9 18:58:47 2013
From: barry at abrahamsen.com (Barry E Abrahamsen)
Date: Tue, 9 Apr 2013 09:58:47 -0700
Subject: [docs] Python on Mac OS X
Message-ID: <A4F68B03-0F13-4DB4-8BD5-742ECFE9D5ED@abrahamsen.com>

Hi,

On this page:

http://docs.python.org/3.3/using/mac.html

in section 4.1.3. Configuration, it says "See Apple?s Technical Document QA1067 for details." 

If you go to this QA document, you find that Apple has "retired" that document:


Retired Document

Important: This document may not represent best practices for current development. Links to downloads and other resources may no longer be valid.

There is a note on that page referring me to this page:

https://developer.apple.com/library/mac/navigation/index.html

but that's just a link to the entire developer library. Searching for "environment variables" gets me:

https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPMultipleUsers/BPMultipleUsers.html#//apple_ref/doc/uid/10000180i

which isn't really very helpful.

Is there any possibility of getting this information updated, at least in the 3.3 documentation?


=====
Barry Abrahamsen
Seattle, Washington
http://www.abrahamsen.com/
http://www.AmericanBamboo.org/

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

From bobbleheadrock at gmail.com  Sat Apr  6 21:40:04 2013
From: bobbleheadrock at gmail.com (Liam Janis)
Date: Sat, 6 Apr 2013 15:40:04 -0400
Subject: [docs] unknown file bug
Message-ID: <CAFOKwc_M=xtd3RRadi4-AkmDdO_oWxguavLtwaDP3cAaDJCjuw@mail.gmail.com>

Hello,
I have just recently started using python and it worked for me last night.
for some strange reason when I logged on to windows, some of the icons
changed to the unknown icon and python was one of them. I'm not sure what
happened or how it happened but I re-installed python and when i right
click a .py file it says edit in idle. when i select that is gives me a
screen where i have to choose from a list of programs to launch it with. i
have done this process many times and i get the same outcome.

Thank You!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130406/0d565ccb/attachment-0001.html>

From bruce.mcgoveran at gmail.com  Sat Apr 13 01:02:03 2013
From: bruce.mcgoveran at gmail.com (Bruce McGoveran)
Date: Fri, 12 Apr 2013 19:02:03 -0400
Subject: [docs] Section 5.2.1 of the Documentation for v 2.7.3
Message-ID: <CAN30pSwPw0bAyiG8-m_0-JumGM-afqhVNsOncQS0rwwuVDcrNQ@mail.gmail.com>

Hi.  First, thank you for your collective efforts in maintaining Python's
documentation.  The documentation has been very helpful to me in
understanding better how the language works.

Please have a look at the paragraph beginning with *Private name
mangling*in section 5.2.1.  The paragraph details an example of how
private names
are transformed.  Based on the way the text explains the workings of the
transformation, I think the example should produce the string _Hamspam, not
_Ham__spam.  I say this because of the comment in line two (2) of the
paragraph that leading underscores (of the name) are removed during the
transformation.

For your consideration.


Best,
Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130412/fa26a4df/attachment.html>

From dan.viar at gmail.com  Fri Apr  5 14:56:40 2013
From: dan.viar at gmail.com (Daniel Viar)
Date: Fri, 5 Apr 2013 08:56:40 -0400
Subject: [docs] Small Error on Tutorial 3.1.1 Page
Message-ID: <CAMATNzE6eQqurhn4Tm4S+zqMN-f9navOFPSoHO7uCTzBHOHjfw@mail.gmail.com>

On the page, http://docs.python.org/3/tutorial/introduction.html
under 3.1.1 Numbers the following looks to be incorrect:

>>> # This is a comment... 2+24

I think that it should be

>>> # This is a comment>>> 2+24
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130405/5ffc7705/attachment.html>

From thomaspinckney3 at gmail.com  Fri Apr  5 20:59:33 2013
From: thomaspinckney3 at gmail.com (thomaspinckney3 at gmail.com)
Date: Fri, 05 Apr 2013 18:59:33 -0000
Subject: [docs] Profile objects should be documented (issue 6696)
Message-ID: <20130405185933.28804.28728@psf.upfronthosting.co.za>

I made some changes based on your comments and will be uploading a new
patch in a couple of minutes.


http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst
File Doc/library/profile.rst (left):

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#oldcode10
Doc/library/profile.rst:10: :synopsis: Python source profiler.
I moved it down to where the .. module definition for cProfile and the
actual module interface definition is. I suppose I could move them both
to the top, but seemed more helpful to jump people straight to the
actual API instead of the pre-amble if someone is clicking into this.

On 2013/04/04 02:26:18, ezio.melotti wrote:
> Why have you removed these?

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#oldcode10
Doc/library/profile.rst:10: :synopsis: Python source profiler.
On 2013/04/04 02:26:18, ezio.melotti wrote:
> Why have you removed these?

Done.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst
File Doc/library/profile.rst (right):

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode8
Doc/library/profile.rst:8: :source:`Modules/_lsprof.c` and
:source:`Lib/pstats.py`
Seems helpful to list ALL the source code instead of just some of it,
no? Or is there a convention about not doing this?

On 2013/04/04 02:26:18, ezio.melotti wrote:
> :source:`Lib/cProfile.py` and :source:`Modules/_lsprof.c` shouldn't be
included
> IMHO.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode8
Doc/library/profile.rst:8: :source:`Modules/_lsprof.c` and
:source:`Lib/pstats.py`
On 2013/04/04 02:26:18, ezio.melotti wrote:
> :source:`Lib/cProfile.py` and :source:`Modules/_lsprof.c` shouldn't be
included
> IMHO.

Done.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode63
Doc/library/profile.rst:63: cProfile.run('foo(x)')
This was addressing a specific confusion one of our developers had. They
wanted to profile a function that took parameters and they weren't
immediately clear on how to do it.

On 2013/04/04 02:26:18, ezio.melotti wrote:
> Why this change?
> It seems easier to me to say that if you want to profile the function
foo you
> can call .run('foo()').

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode63
Doc/library/profile.rst:63: cProfile.run('foo(x)')
On 2013/04/04 02:26:18, ezio.melotti wrote:
> Why this change?
> It seems easier to me to say that if you want to profile the function
foo you
> can call .run('foo()').

Done.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode77
Doc/library/profile.rst:77: 43/3    0.533    0.012    0.749    0.250
pobject.py:99(evaluate)
Great suggestion. I will use your re.compile example.

On 2013/04/04 02:26:18, ezio.melotti wrote:
> I think it would be even better to use a real-world example that users
can run
> (maybe you can thing about something better than re.compile), e.g.:
> >>> import cProfile
> >>> import re
> >>> cProfile.run('re.compile("foo|bar")')
>          197 function calls (192 primitive calls) in 0.002 seconds
> 
>    Ordered by: standard name
> 
>    ncalls  tottime  percall  cumtime  percall
filename:lineno(function)
>         1    0.000    0.000    0.001    0.001 <string>:1(<module>)
>         1    0.000    0.000    0.001    0.001 re.py:212(compile)
>         1    0.000    0.000    0.001    0.001 re.py:268(_compile)
>         1    0.000    0.000    0.000    0.000
> sre_compile.py:172(_compile_charset)
>         1    0.000    0.000    0.000    0.000
> sre_compile.py:201(_optimize_charset)
>         4    0.000    0.000    0.000    0.000
> sre_compile.py:25(_identityfunction)
>       3/1    0.000    0.000    0.000    0.000
sre_compile.py:33(_compile)

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode77
Doc/library/profile.rst:77: 43/3    0.533    0.012    0.749    0.250
pobject.py:99(evaluate)
On 2013/04/04 02:26:18, ezio.melotti wrote:
> I think it would be even better to use a real-world example that users
can run
> (maybe you can thing about something better than re.compile), e.g.:
> >>> import cProfile
> >>> import re
> >>> cProfile.run('re.compile("foo|bar")')
>          197 function calls (192 primitive calls) in 0.002 seconds
> 
>    Ordered by: standard name
> 
>    ncalls  tottime  percall  cumtime  percall
filename:lineno(function)
>         1    0.000    0.000    0.001    0.001 <string>:1(<module>)
>         1    0.000    0.000    0.001    0.001 re.py:212(compile)
>         1    0.000    0.000    0.001    0.001 re.py:268(_compile)
>         1    0.000    0.000    0.000    0.000
> sre_compile.py:172(_compile_charset)
>         1    0.000    0.000    0.000    0.000
> sre_compile.py:201(_optimize_charset)
>         4    0.000    0.000    0.000    0.000
> sre_compile.py:25(_identityfunction)
>       3/1    0.000    0.000    0.000    0.000
sre_compile.py:33(_compile)

Done.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode104
Doc/library/profile.rst:104: provides the respective data of each
function
Trailing comma removed. The trailing full stop under cumtime is kind of
strange to remove since it does really end a full sentence. But happy to
remove it if that what the style guidelines say to do.

On 2013/04/04 02:26:18, ezio.melotti wrote:
> The end of lines are inconsistent.  You can remove the trailing commas
and full
> stop.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode104
Doc/library/profile.rst:104: provides the respective data of each
function
On 2013/04/04 02:26:18, ezio.melotti wrote:
> The end of lines are inconsistent.  You can remove the trailing commas
and full
> stop.

Done.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode280
Doc/library/profile.rst:280: Profile the cmd via :func:`exec` with the
specified global and local environment.
Fixed. I reformatted some of the other paragraphs to make them fill out
to 80 chars too.

On 2013/04/04 02:26:18, ezio.melotti wrote:
> Line too long (there are a few others that are longer than 80 chars
too).

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode280
Doc/library/profile.rst:280: Profile the cmd via :func:`exec` with the
specified global and local environment.
On 2013/04/04 02:26:18, ezio.melotti wrote:
> Line too long (there are a few others that are longer than 80 chars
too).

Done.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode397
Doc/library/profile.rst:397: +------------------+----------------------+
This was from the prior author and I just didn't feel like reformatting
it all. Maybe in the next patch :)

On 2013/04/04 02:26:18, ezio.melotti wrote:
> Here you could use the simpler table syntax:
> ====== ======
> header header
> ====== ======
> row1   row1
> row2   row2
> ...    ...
> ====== ======

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode397
Doc/library/profile.rst:397: +------------------+----------------------+
On 2013/04/04 02:26:18, ezio.melotti wrote:
> Here you could use the simpler table syntax:
> ====== ======
> header header
> ====== ======
> row1   row1
> row2   row2
> ...    ...
> ====== ======

Done.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode418
Doc/library/profile.rst:418: .. For compatibility with the old profiler,
command executed!

On 2013/04/04 02:26:18, ezio.melotti wrote:
> s/,/./

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode418
Doc/library/profile.rst:418: .. For compatibility with the old profiler,
On 2013/04/04 02:26:18, ezio.melotti wrote:
> s/,/./

Done.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode447
Doc/library/profile.rst:447: printed; as of Python 1.5b1, this uses the
Perl-style regular
Removed.

On 2013/04/04 02:26:18, ezio.melotti wrote:
> This can probably be removed.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode447
Doc/library/profile.rst:447: printed; as of Python 1.5b1, this uses the
Perl-style regular
On 2013/04/04 02:26:18, ezio.melotti wrote:
> This can probably be removed.

Done.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode618
Doc/library/profile.rst:618: interpreted differently:
I do mention the new python 3 time functions, but I don't have enough
first hand experience with doing this to know what the best
recommendation is.

On 2013/04/04 02:26:18, ezio.melotti wrote:
> This could point to the different times available in the time module,
and
> possibly provide some suggestion.

http://bugs.python.org/review/6696/diff/7348/Doc/library/profile.rst#newcode618
Doc/library/profile.rst:618: interpreted differently:
On 2013/04/04 02:26:18, ezio.melotti wrote:
> This could point to the different times available in the time module,
and
> possibly provide some suggestion.

Done.

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

From wolfgang.maier at biologie.uni-freiburg.de  Thu Apr 11 11:35:21 2013
From: wolfgang.maier at biologie.uni-freiburg.de (Wolfgang Maier)
Date: Thu, 11 Apr 2013 11:35:21 +0200
Subject: [docs] path specs in
	http://docs.python.org/3.2/library/site.html#module-site
Message-ID: <006001ce3697$e34059d0$a9c10d70$@biologie.uni-freiburg.de>

Dear all,

the first paragraph of the documentation for the site module states that
site.py constructs four directories using a head and tail part, and that

one of the tail parts would be lib/pythonX.Y/site-packages on UNIX/Mac.

However, in my Python 3.2 installation on Ubuntu 12.04 this is actually
lib/python3/dist-packages (so no .Y and a different subdirectory) !

This is also stated in the module's doc string.

I don't know why the Python documentation says something else, but that
should be fixed.

Thanks,

Wolfgang Maier

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130411/61ddf89b/attachment-0001.html>

From report at bugs.python.org  Sat Apr 13 23:14:08 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 13 Apr 2013 21:14:08 +0000
Subject: [docs] [issue16273] f.tell() returning negative number on Windows
	build
In-Reply-To: <1350526122.97.0.103530434711.issue16273@psf.upfronthosting.co.za>
Message-ID: <1365887648.22.0.752184853596.issue16273@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
nosy:  -arigo

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

From fred at fdrake.net  Sat Apr 13 23:56:45 2013
From: fred at fdrake.net (Fred Drake)
Date: Sat, 13 Apr 2013 17:56:45 -0400
Subject: [docs] docs.python.org source
In-Reply-To: <515DE290.4080508@amachu.me>
References: <515DE290.4080508@amachu.me>
Message-ID: <CAFT4OTESLmG+w3U2X8d7ZEzP5YWMbSLtAaJf6zTh0gD8r25R_A@mail.gmail.com>

On Thu, Apr 4, 2013 at 4:29 PM, ??????? <amachu at amachu.me> wrote:
> I am looking forward to checkout all rst files of docs.python.org to my
> local for having a local copy of the site for quick reference.

The bulk of docs.python.org comes from the Python sources; download the
source distribution for the version of Python you're using, and check in
the Doc/ directory for sources and build information.


  -Fred

-- 
Fred L. Drake, Jr.    <fred at fdrake.net>
"A storm broke loose in my mind."  --Albert Einstein

From report at bugs.python.org  Sun Apr 14 01:19:57 2013
From: report at bugs.python.org (David Wolever)
Date: Sat, 13 Apr 2013 23:19:57 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365895197.05.0.450259710855.issue17701@psf.upfronthosting.co.za>


Changes by David Wolever <wolever at cs.toronto.edu>:


----------
hgrepos: +182

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

From report at bugs.python.org  Sun Apr 14 01:27:22 2013
From: report at bugs.python.org (David Wolever)
Date: Sat, 13 Apr 2013 23:27:22 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365895642.39.0.952720820407.issue17701@psf.upfronthosting.co.za>


Changes by David Wolever <wolever at cs.toronto.edu>:


Added file: http://bugs.python.org/file29836/b3b1dcdc8cee.diff

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

From report at bugs.python.org  Sun Apr 14 03:16:55 2013
From: report at bugs.python.org (David Wolever)
Date: Sun, 14 Apr 2013 01:16:55 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365902215.93.0.25421836547.issue17701@psf.upfronthosting.co.za>


Changes by David Wolever <wolever at cs.toronto.edu>:


Removed file: http://bugs.python.org/file29836/b3b1dcdc8cee.diff

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

From report at bugs.python.org  Sun Apr 14 03:17:26 2013
From: report at bugs.python.org (David Wolever)
Date: Sun, 14 Apr 2013 01:17:26 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365902246.09.0.544341997978.issue17701@psf.upfronthosting.co.za>


Changes by David Wolever <wolever at cs.toronto.edu>:


Added file: http://bugs.python.org/file29839/ae18c5ae2c4d.diff

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

From report at bugs.python.org  Sun Apr 14 03:20:58 2013
From: report at bugs.python.org (David Wolever)
Date: Sun, 14 Apr 2013 01:20:58 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365902458.5.0.328769271138.issue17701@psf.upfronthosting.co.za>


David Wolever added the comment:

Ok, I've added some locale examples and fixed up the note numbering. See diff in file29839, and there is a live version to preview here: http://hul.wolever.net/python-doc/library/datetime.html#strftime-and-strptime-behavior

If I can get a +1 on this, I'll port it to Python 3.

----------

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

From report at bugs.python.org  Sun Apr 14 03:34:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 14 Apr 2013 01:34:08 +0000
Subject: [docs] [issue9538] Replace confusing pseudoname 'object' in special
	methods	section.
In-Reply-To: <1281211479.21.0.733519342396.issue9538@psf.upfronthosting.co.za>
Message-ID: <1365903248.35.0.243754300849.issue9538@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The problem, for me, is that in 3.3 Data Model, 'object' is being used with a 3rd meaning, 'generic class' (or possibly 'subclass of object', if indeed every 'class' must be 'object' subclass, in the strict sense of 'object'). This is in addition to 'object' the specific class and generic Python object (which in CPython is a PyObject structure instance). The normal two meanings are often differentiated by typography: normal type for plain old object, something else for *object*.

To add a bit to the confusion, 3.3.4. Customizing instance and subclass checks changes the prefix to 'class' instead of 'object' (which is what I would do in the whole section...)

class.__instancecheck__(self, instance)
class.__subclasscheck__(self, subclass)

It then goes on to explain that it does not really mean 'generic class' but 'type/metaclass'. So, to me, the prefix here should really be 'metaclass'.

Peter, the patch applied fine to my copy of default. It is incomplete in that the replacement should be made everywhere or nowhere in 3.3, not just in 3.3.2(.0) and 3.3.2.1. However, do not bother making a new patch until there is more agreement on a change than there is now.

A possible alternative to the given proposal is an explanation in the short 3.3 header of the special use of 'object' within the section.

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

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

From report at bugs.python.org  Sun Apr 14 04:41:43 2013
From: report at bugs.python.org (David Wolever)
Date: Sun, 14 Apr 2013 02:41:43 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365907303.34.0.910312645528.issue17701@psf.upfronthosting.co.za>


Changes by David Wolever <wolever at cs.toronto.edu>:


Added file: http://bugs.python.org/file29841/53a0e908f787.diff

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

From report at bugs.python.org  Sun Apr 14 04:42:43 2013
From: report at bugs.python.org (David Wolever)
Date: Sun, 14 Apr 2013 02:42:43 +0000
Subject: [docs] [issue17701] Improving strftime documentation
In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>
Message-ID: <1365907363.05.0.895590637025.issue17701@psf.upfronthosting.co.za>


David Wolever added the comment:

Fixed a misleading note about Unicode in localized formatters in file29841.

----------

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

From report at bugs.python.org  Sun Apr 14 09:09:27 2013
From: report at bugs.python.org (Kyle Simpson)
Date: Sun, 14 Apr 2013 07:09:27 +0000
Subject: [docs] [issue17725] English mistake in Extending and Embedding
	Python doc	page.
Message-ID: <1365923367.93.0.414383739407.issue17725@psf.upfronthosting.co.za>


New submission from Kyle Simpson:

The second sentence in http://docs.python.org/3/extending/index.html says:

  Those modules can define new functions but also new
  object types and their methods.

The word "but" doesn't make sense here. I suppose that the
author meant to write:

  Those modules can not only define new functions but
  also new object types and their methods.

----------
assignee: docs at python
components: Documentation
messages: 186886
nosy: Kyle.Simpson, docs at python
priority: normal
severity: normal
status: open
title: English mistake in Extending and Embedding Python doc page.

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

From report at bugs.python.org  Sun Apr 14 09:53:25 2013
From: report at bugs.python.org (Kyle Simpson)
Date: Sun, 14 Apr 2013 07:53:25 +0000
Subject: [docs] [issue17725] English mistake in Extending and Embedding
	Python doc	page.
In-Reply-To: <1365923367.93.0.414383739407.issue17725@psf.upfronthosting.co.za>
Message-ID: <1365926005.15.0.305198044609.issue17725@psf.upfronthosting.co.za>


Kyle Simpson added the comment:

I have provided a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file29847/issue17725.patch

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

From georg at python.org  Sun Apr 14 10:14:54 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 10:14:54 +0200
Subject: [docs] Section 5.2.1 of the Documentation for v 2.7.3
In-Reply-To: <CAN30pSwPw0bAyiG8-m_0-JumGM-afqhVNsOncQS0rwwuVDcrNQ@mail.gmail.com>
References: <CAN30pSwPw0bAyiG8-m_0-JumGM-afqhVNsOncQS0rwwuVDcrNQ@mail.gmail.com>
Message-ID: <516A657E.3010704@python.org>

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

Am 13.04.2013 01:02, schrieb Bruce McGoveran:
> Hi.  First, thank you for your collective efforts in maintaining Python's 
> documentation.  The documentation has been very helpful to me in
> understanding better how the language works.
> 
> Please have a look at the paragraph beginning with *Private name mangling*
> in section 5.2.1.  The paragraph details an example of how private names
> are transformed.  Based on the way the text explains the workings of the 
> transformation, I think the example should produce the string _Hamspam,
> not _Ham__spam.  I say this because of the comment in line two (2) of the
> paragraph that leading underscores (of the name) are removed during the
> transformation.
> 
> For your consideration.

Hi Bruce,

the "with leading underscores removed" refers to the class name.  (I.e.,
if the class was named "__Ham", the mangled identifier would still be
"_Ham__spam".)

I've clarified the wording now and it should be online soon.

Georg

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

iEYEARECAAYFAlFqZX4ACgkQN9GcIYhpnLCtFACeI89IIdfT5L6fl4vgapoj1EW4
czYAnRxQqIQykwPV0awab3Fs75p1niV5
=Q2R5
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sun Apr 14 10:25:58 2013
From: report at bugs.python.org (Mike Hoy)
Date: Sun, 14 Apr 2013 08:25:58 +0000
Subject: [docs] [issue17668] re.split loses characters matching ungrouped
	parts of a	pattern
In-Reply-To: <1365445138.49.0.018016443065.issue17668@psf.upfronthosting.co.za>
Message-ID: <1365927958.34.0.0239187462187.issue17668@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

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

From report at bugs.python.org  Sun Apr 14 10:26:43 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 14 Apr 2013 08:26:43 +0000
Subject: [docs] [issue17726] faq/design: improve clarity
Message-ID: <1365928003.07.0.655847572974.issue17726@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

I puzzled a bit on what that sentence meant.

----------
assignee: docs at python
components: Documentation
files: diff
messages: 186891
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: faq/design: improve clarity
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29848/diff

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

From report at bugs.python.org  Sun Apr 14 10:31:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 14 Apr 2013 08:31:08 +0000
Subject: [docs] [issue17726] faq/design: improve clarity
In-Reply-To: <1365928003.07.0.655847572974.issue17726@psf.upfronthosting.co.za>
Message-ID: <3ZpQzH3GfGzQMn@mail.python.org>


Roundup Robot added the comment:

New changeset ab35b5e81317 by Georg Brandl in branch '2.7':
Closes #17726: small clarification in design FAQ.
http://hg.python.org/cpython/rev/ab35b5e81317

New changeset f6fdf3457f74 by Georg Brandl in branch '3.3':
Closes #17726: small clarification in design FAQ.
http://hg.python.org/cpython/rev/f6fdf3457f74

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

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

From report at bugs.python.org  Sun Apr 14 10:35:37 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 08:35:37 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <1365928537.64.0.268035149523.issue17661@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed, thanks.

----------

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

From report at bugs.python.org  Sun Apr 14 10:35:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 14 Apr 2013 08:35:43 +0000
Subject: [docs] [issue17661] documentation of '%r' links to the wrong repr
In-Reply-To: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>
Message-ID: <3ZpR4Z3J8GzRXH@mail.python.org>


Roundup Robot added the comment:

New changeset dd5e7aef4d5b by Georg Brandl in branch '2.7':
Closes #17661: fix references to repr() going to module repr.
http://hg.python.org/cpython/rev/dd5e7aef4d5b

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

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

From report at bugs.python.org  Sun Apr 14 10:43:34 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 08:43:34 +0000
Subject: [docs] [issue17727] document that some distributions change site.py
	defaults
Message-ID: <1365929014.79.0.72904930991.issue17727@psf.upfronthosting.co.za>


New submission from Georg Brandl:

>From the docs@ list:
"""
Dear all,

the first paragraph of the documentation for the site module states that site.py constructs four directories using a head and tail part, and that

one of the tail parts would be lib/pythonX.Y/site-packages on UNIX/Mac.

However, in my Python 3.2 installation on Ubuntu 12.04 this is actually lib/python3/dist-packages (so no .Y and a different subdirectory) !

This is also stated in the module?s doc string.

I don?t know why the Python documentation says something else, but that should be fixed.
"""

Attached a patch to explain why the defaults may look different on some distributions.  Please review.

----------
assignee: docs at python
components: Documentation
files: site-patch.diff
keywords: patch
messages: 186897
nosy: barry, docs at python, doko, georg.brandl
priority: normal
severity: normal
stage: patch review
status: open
title: document that some distributions change site.py defaults
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29849/site-patch.diff

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

From georg at python.org  Sun Apr 14 10:44:17 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 10:44:17 +0200
Subject: [docs] path specs in
	http://docs.python.org/3.2/library/site.html#module-site
In-Reply-To: <006001ce3697$e34059d0$a9c10d70$@biologie.uni-freiburg.de>
References: <006001ce3697$e34059d0$a9c10d70$@biologie.uni-freiburg.de>
Message-ID: <516A6C61.2080409@python.org>

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

Am 11.04.2013 11:35, schrieb Wolfgang Maier:
> Dear all,
> 
> the first paragraph of the documentation for the site module states that
> site.py constructs four directories using a head and tail part, and that
> 
> one of the tail parts would be lib/pythonX.Y/site-packages on UNIX/Mac.
> 
> However, in my Python 3.2 installation on Ubuntu 12.04 this is actually 
> lib/python3/dist-packages (so no .Y and a different subdirectory) !
> 
> This is also stated in the module?s doc string.
> 
> I don?t know why the Python documentation says something else, but that
> should be fixed.

Hi Wolfgang,

the rename of site-packages to dist-packages is a specialty of Debian/Ubuntu,
which patches Python in that regard (that's why the docstring is correct for
their version).  Of course the online docs cannot know that you are using
Debian :)

I've create a patch to add a note in the site module docs that some
distributions change the default module search path, and it is for discussion
with the Debian maintainers on <http://bugs.python.org/issue17727>.

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

iEYEARECAAYFAlFqbGEACgkQN9GcIYhpnLAWcwCeKHwfdLmjlets1fW/AkzSZ/wJ
Qt0AnRqXF2YT9lYCKD8PpPfX/iWKdJ1T
=X6Zs
-----END PGP SIGNATURE-----

From georg at python.org  Sun Apr 14 10:45:40 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 10:45:40 +0200
Subject: [docs] Python on Mac OS X
In-Reply-To: <7EE51540-5A6E-4549-81A2-A140A4C8C4BB@abrahamsen.com>
References: <7EE51540-5A6E-4549-81A2-A140A4C8C4BB@abrahamsen.com>
Message-ID: <516A6CB4.7010209@python.org>

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

Am 09.04.2013 18:43, schrieb Barry E Abrahamsen:
> on this page:
> 
> http://docs.python.org/2/using/mac.html
> 
> Section 4.1 says "Mac OS X 10.5 comes with Python 2.5.1 pre-installed by
> Apple." That may have been true years ago, but the current version of the
> Mac OS is 10.8 and the version of Python provided by Apple is 2.7.
> 
> I don't have enough experience with Python or the UNIX underpinnings of Mac
> OS X to say much more about this information. However, I expected, after
> installing Python 3.3.1 and running the shell script, that typing "which
> python" in a console session would tell me 3.3.1, but it continues to say
> 2.7 as does the Python Launcher. I only get 3.3.1 using IDLE, If this is
> what "you will have two different but functional Python installations on
> your computer" means, then it would be helpful for a beginner to understand
> that.
> 
> Looking around on the internet for python-on-Mac resources, I find a lot
> of out-of-date and partial information. This is discouraging to a beginner.
> 
Hi Barry,

I've quick-fixed the 10.5/2.5 version numbers.  For the rest of the problems
with the Mac documentation, it would help us immensely if you could open an
issue at http://bugs.python.org/ so that the Mac experts can take care of it.

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

iEYEARECAAYFAlFqbLQACgkQN9GcIYhpnLCcTACfTBRwEDMCFJ9Rx5j1rUhX9zam
cHsAoKNDx5is0ZVwHGTb14WqXt5JUVtC
=HXP9
-----END PGP SIGNATURE-----

From georg at python.org  Sun Apr 14 10:46:39 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 10:46:39 +0200
Subject: [docs] Small Error on Tutorial 3.1.1 Page
In-Reply-To: <CAMATNzE6eQqurhn4Tm4S+zqMN-f9navOFPSoHO7uCTzBHOHjfw@mail.gmail.com>
References: <CAMATNzE6eQqurhn4Tm4S+zqMN-f9navOFPSoHO7uCTzBHOHjfw@mail.gmail.com>
Message-ID: <516A6CEF.90105@python.org>

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

Am 05.04.2013 14:56, schrieb Daniel Viar:
> On the page, http://docs.python.org/3/tutorial/introduction.html under
> 3.1.1 Numbers the following looks to be incorrect:
> 
>>>> # This is a comment
> ... 2+2 4
> 
> I think that it should be
> 
>>>> # This is a comment 2+2
> 4

Hi Daniel,

if you try your example in the interactive shell, you will see that
Python indeed displays the secondary prompt ("...") for the second
line.

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

iEYEARECAAYFAlFqbO4ACgkQN9GcIYhpnLC3GgCfUtxUxEPIJ0OSV2QOCjcBcmhJ
jxQAni88lWSzWjGQx1Xj6rFRM4P++VJy
=lXaA
-----END PGP SIGNATURE-----

From georg at python.org  Sun Apr 14 10:50:28 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 10:50:28 +0200
Subject: [docs] Examples in Library/collections.abc in Python 3.3 Docs
In-Reply-To: <CAOY15XwCW-4qU+UeWKex2WusU71YBxO+OvHxZ4H38B9kP6vYMQ@mail.gmail.com>
References: <CAOY15XwCW-4qU+UeWKex2WusU71YBxO+OvHxZ4H38B9kP6vYMQ@mail.gmail.com>
Message-ID: <516A6DD4.6070508@python.org>

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

Am 31.03.2013 00:33, schrieb Anony Mous:
> I just wanted to mention that the example code on the page for the module 
> collections.abc (http://docs.python.org/3.3/library/collections.abc.html)
> has not been changed to reflect the new collections.abc module. For
> example, "collections.Set" is used instead of "collections.abc.Set".
> Thanks!

Hi,

thanks for the report, this has now been fixed.

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

iEYEARECAAYFAlFqbdQACgkQN9GcIYhpnLBv4QCfdz+uhxKSmwWJ8O1JmxNkQVBC
4rgAnAhndn+pSnDY/oJHd00wWI+uRAC2
=6Tkd
-----END PGP SIGNATURE-----

From sandro.tosi at gmail.com  Sun Apr 14 10:54:04 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 14 Apr 2013 10:54:04 +0200
Subject: [docs] unknown file bug
In-Reply-To: <CAFOKwc_M=xtd3RRadi4-AkmDdO_oWxguavLtwaDP3cAaDJCjuw@mail.gmail.com>
References: <CAFOKwc_M=xtd3RRadi4-AkmDdO_oWxguavLtwaDP3cAaDJCjuw@mail.gmail.com>
Message-ID: <CAB4XWXwYsqwapK3Lw8tO4NPN_ecFfevK2O9vBTQvPA3LBs6Xyw@mail.gmail.com>

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

Regards,
Sandro

On Sat, Apr 6, 2013 at 9:40 PM, Liam Janis <bobbleheadrock at gmail.com> wrote:
> Hello,
> I have just recently started using python and it worked for me last night.
> for some strange reason when I logged on to windows, some of the icons
> changed to the unknown icon and python was one of them. I'm not sure what
> happened or how it happened but I re-installed python and when i right click
> a .py file it says edit in idle. when i select that is gives me a screen
> where i have to choose from a list of programs to launch it with. i have
> done this process many times and i get the same outcome.
>
> Thank You!
>
> _______________________________________________
> 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 georg at python.org  Sun Apr 14 11:00:00 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 11:00:00 +0200
Subject: [docs] Apparent bug in python socket howto
In-Reply-To: <CAPz3yKcFn174eUSFDwkAKC440fVxMvSYqR6TcYrBVjJxi2-LzA@mail.gmail.com>
References: <CAPz3yKcFn174eUSFDwkAKC440fVxMvSYqR6TcYrBVjJxi2-LzA@mail.gmail.com>
Message-ID: <516A7010.7080508@python.org>

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

Am 07.12.2011 01:55, schrieb Patrick Maupin:
> Thanks for the howto.  It's a great conceptual introduction, and I was 
> happy to have it to read when I needed to get my hands a bit dirtier than
> using SocketServer.
> 
> But the statement  "If we had used s.bind(('', 80)) [the socket would only
> be] visible within the same machine." appears to be incorrect.
> 
> As the socket module documentation states, "the empty string represents
> INADDR_ANY."

Hi Patrick,

thanks for your report, this is now fixed (very very delayed, I know)
and will appear online soon.

cheers,
Georg

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

iEYEARECAAYFAlFqcBAACgkQN9GcIYhpnLA5AACdG877atIQbxfrlGTUoDehky/3
aEYAoIonQmHn3VcOI5BskiWfeX0eEvNn
=bmwZ
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sun Apr 14 11:16:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 14 Apr 2013 09:16:27 +0000
Subject: [docs] [issue13638] PyErr_SetFromErrnoWithFilenameObject is
	undocumented
In-Reply-To: <1324312876.6.0.318234215993.issue13638@psf.upfronthosting.co.za>
Message-ID: <3ZpRzb0QlFzNgb@mail.python.org>


Roundup Robot added the comment:

New changeset 4cc94d30926f by Georg Brandl in branch '2.7':
Closes #13638: document PyErr_SetFromErrnoWithFilenameObject,
http://hg.python.org/cpython/rev/4cc94d30926f

New changeset ee848457930f by Georg Brandl in branch '3.3':
Closes #13638: document PyErr_SetFromErrnoWithFilenameObject,
http://hg.python.org/cpython/rev/ee848457930f

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

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

From report at bugs.python.org  Sun Apr 14 11:40:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 14 Apr 2013 09:40:09 +0000
Subject: [docs] [issue14462] In re's named group the name cannot contain
	unicode	characters
In-Reply-To: <1333268208.65.0.802050679023.issue14462@psf.upfronthosting.co.za>
Message-ID: <3ZpSVx0jZfzPTH@mail.python.org>


Roundup Robot added the comment:

New changeset 2fa27a3818a2 by Georg Brandl in branch '3.3':
Closes #14462: allow any valid Python identifier in sre group names, as documented.
http://hg.python.org/cpython/rev/2fa27a3818a2

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

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

From georg at python.org  Sun Apr 14 11:41:08 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 11:41:08 +0200
Subject: [docs] Python 3 doc update (re) symbolic group: name validity.
In-Reply-To: <DUB102-W16B81C5DA08E5FF2F938B9999C0@phx.gbl>
References: <DUB102-W16B81C5DA08E5FF2F938B9999C0@phx.gbl>
Message-ID: <516A79B4.4020509@python.org>

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

Hi Patrice,

thanks for your report, this is now (belatedly) fixed in the code and in future
Python versions all valid Python identifiers will be allowed in group names.

cheers,
Georg

Am 13.01.2012 17:24, schrieb Patrice Joulain:
> *Hello,
> 
> I'd like to report a bug dealing with update from Python 2 to Python 3, in
> the Python 3.x Documentation.* * Python Standard Library / Chapter 6.2.1
> Regular Expression Syntax - says "Group names must be valid Python
> identifiers" which is not true for 3.x . (?P<name>...) **accepts Python 2
> valid identifier only (contrary to named fields of
> collections.namedtuple)*. ***I've checked re-HOWTO and tutorial: no
> specification about valididity of group name, hence no mistake.*
> 
>>>> re.match(r'(?P<DejaVu>test)','test')
> <_sre.SRE_Match object at 0x00BF25A0>
> 
>>>> assert 'D?j?Vu'.isidentifier()
> 
>>>> re.match(r'(?P<D?j?Vu>test)','test')
> Traceback (most recent call last): File "C:\Python32\lib\functools.py",
> line 176, in wrapper result = cache[key] KeyError: (<class 'str'>,
> '(?P<D?j?Vu>test)', 0)
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last): File "<stdin>", line 1, in <module> File
> "C:\Python32\lib\re.py", line 153, in match return _compile(pattern,
> flags).match(string) File "C:\Python32\lib\re.py", line 255, in _compile 
> return _compile_typed(type(pattern), pattern, flags) File
> "C:\Python32\lib\functools.py", line 180, in wrapper result =
> user_function(*args, **kwds) File "C:\Python32\lib\re.py", line 267, in
> _compile_typed return sre_compile.compile(pattern, flags) File
> "C:\Python32\lib\sre_compile.py", line 491, in compile p =
> sre_parse.parse(p, flags) File "C:\Python32\lib\sre_parse.py", line 692, in
> parse p = _parse_sub(source, pattern, 0) File
> "C:\Python32\lib\sre_parse.py", line 315, in _parse_sub 
> itemsappend(_parse(source, state)) File "C:\Python32\lib\sre_parse.py",
> line 552, in _parse raise error("bad character in group name") 
> sre_constants.error: bad character in group name
>>>> 
> 
> *=> From Lib\sre_parse.py:*
> 
> def isident(char): return "a" <= char <= "z" or "A" <= char <= "Z" or char
> == "_"
> 
> def isdigit(char): return "0" <= char <= "9"
> 
> def isname(name): # check that group name is a valid stringEnvoyer <#> if
> not isident(name[0]): return False for char in name[1:]: if not
> isident(char) and not isdigit(char): return False return True
> 
> *Thank you for dealing this report (Sorry for my bad english)*.
> 
> *Waiting for some response: <pat.jln at hotmail.fr>*
> 
> 
> 
> _______________________________________________ docs mailing list 
> docs at python.org http://mail.python.org/mailman/listinfo/docs
> 

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

iEYEARECAAYFAlFqebQACgkQN9GcIYhpnLB4jACfa4+03ZE6Azw240vMwQo7xIQz
2jMAoIbpVNcT+EbIcfO7H2K914VneTgF
=Aojl
-----END PGP SIGNATURE-----

From georg at python.org  Sun Apr 14 11:45:40 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 11:45:40 +0200
Subject: [docs] integer leak in refcount docs?
In-Reply-To: <20120124114633.GA22041@daniel3.local>
References: <20120124114633.GA22041@daniel3.local>
Message-ID: <516A7AC4.70802@python.org>

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

Am 24.01.2012 12:46, schrieb Daniel Shahaf:
> In <http://docs.python.org/c-api/intro.html#reference-count-details>, the
> example code reads:
> 
> 1	int 2	set_all(PyObject *target, PyObject *item) 3	{ 4	    int i, n; 5 6
> n = PyObject_Length(target); 7	    if (n < 0) 8	        return -1; 9
> for (i = 0; i < n; i++) { 10	        PyObject *index = PyInt_FromLong(i); 
> 11	        if (!index) 12	            return -1; 13	        if
> (PyObject_SetItem(target, index, item) < 0) 14	            return -1; 15
> Py_DECREF(index); 16	    } 17	    return 0; 18	}
> 
> Seems to me that line 14 leaks a reference to 'index'; that is:
> 
> @@ -13,2 +13,4 @@ -        if (PyObject_SetItem(target, index, item) < 0) +
> if (PyObject_SetItem(target, index, item) < 0) { +
> Py_DECREF(index); return -1; +        }
> 
> Does that make sense?

Hi Daniel,

thanks for the report, this is now fixed (belatedly) and should appear
online soon.

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

iEYEARECAAYFAlFqesQACgkQN9GcIYhpnLDk6QCgmnKpwgHAuyx4kJ6N8rtKs07b
srAAoLB7aWMeMwNGXvAMfaazkEQetgB1
=cI6J
-----END PGP SIGNATURE-----

From georg at python.org  Sun Apr 14 11:48:10 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 11:48:10 +0200
Subject: [docs] 'Bug' in modules tutorial
In-Reply-To: <4F26C077.7020307@wences.com.ar>
References: <4F26C077.7020307@wences.com.ar>
Message-ID: <516A7B5A.3060806@python.org>

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

Am 30.01.2012 17:08, schrieb Wenceslao Grillo:
> Hi, guys, I'm only starting out with Python, and the docs are a great help.
> Congrats on an excelent work! Found a bug though: in
> <http://docs.python.org/tutorial/modules.html> there's a footnote that
> reads:
> 
> In fact function definitions are also ?statements? that are ?executed?;
> the execution of a module-level function enters the function name in the
> module?s global symbol table.
> 
> It seems to me it should be:
> 
> In fact function definitions are also ?statements? that are ?executed?;
> the execution of a module-level function *definition* enters the function
> name in the module?s global symbol table.

Hi Wenceslao,

thanks for your report, this is now (belatedly) fixed and will appear online soon.

cheers,
Georg

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

iEYEARECAAYFAlFqe1oACgkQN9GcIYhpnLAWgwCfXRUpFEMN6Qwtw9+JuYbxxLdQ
/pMAnA8zcWr9cIMUtMBYgvRORkFZ1IC+
=4Kbh
-----END PGP SIGNATURE-----

From georg at python.org  Sun Apr 14 11:54:06 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 11:54:06 +0200
Subject: [docs] Bug in the Reference Data Model
In-Reply-To: <CALL10kpr1+ahWR690+nD+W15HRw2Kw3wDyw05YHnC8AaADRSAQ@mail.gmail.com>
References: <CALL10kpr1+ahWR690+nD+W15HRw2Kw3wDyw05YHnC8AaADRSAQ@mail.gmail.com>
Message-ID: <516A7CBE.7040405@python.org>

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

Am 02.02.2012 05:53, schrieb Ted Yin:
> It's said that :
> 
> When it would yield a class method object, it is transformed into a bound 
> user-defined method object whose im_class and im_self attributes are both
> C.
> 
> in the Reference <http://docs.python.org/reference/datamodel.html>
> 
> And I did an EX.
> 
> |>>> class C(object) :
> 
> ...     @classmethod ...     def cm(cls) : print cls
> 
> ...
>>>> C.cm
> <bound method type.cm of <class '__main__.C'>>
> 
>>>> C.cm.im_self
> <class '__main__.C'>
> 
>>>> C.cm.im_class
> <type 'type'>
> 
> |
> 
> It's not hard for me to understand the result.
> 
> But unfortunately, in the reference, it's told that im_self should be *the
> same* as im_class.
> 
> And in my opinion , 'im_self' shold be C, but im_class is 'type' since C's 
> metaclass is type. So they're obviously *not* 'both C'.

Hi Ted,

thanks for the report, this has now been (belatedly) fixed and should
appear online soon.

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

iEUEARECAAYFAlFqfL4ACgkQN9GcIYhpnLA6IgCYyKJG4tP9DQu4pKmgsYsdbV0l
LgCdHa43mO+x62CrniBTC0wr07/5oVU=
=XCYb
-----END PGP SIGNATURE-----

From georg at python.org  Sun Apr 14 11:59:46 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 11:59:46 +0200
Subject: [docs] Bug Report: Incorrect Abstract Method Requirements in
 numbers.Integral Documentation
In-Reply-To: <CB56E185.697B%matthew.lefavor@nasa.gov>
References: <CB56E185.697B%matthew.lefavor@nasa.gov>
Message-ID: <516A7E12.9090109@python.org>

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

Am 07.02.2012 20:11, schrieb Lefavor, Matthew (GSFC-582.0)[MICROTEL LLC]:
> To whom it may concern:
> 
> The documentation for numbers.Integral reports incorrect abstract method 
> requirements for numbers.Integral.
> 
> The documentation for numbers.Integral (in both Python 2.7 and Python 3.2)
> states:
> 
> Subtypes Rational 
> <http://docs.python.org/library/numbers.html#numbers.Rational> and adds a 
> conversion to int <http://docs.python.org/library/functions.html#int>.
> Provides defaults for float() 
> <http://docs.python.org/library/functions.html#float>, numerator 
> <http://docs.python.org/library/numbers.html#numbers.Rational.numerator>, 
> and denominator 
> <http://docs.python.org/library/numbers.html#numbers.Rational.denominator>,
> and bit-string operations: <<, >>, &, ^, |, ~.
> 
> Defaults for operations <<, >>, &, ^, |, and ~ are not provided, and a look
> at the source code shows that they are all given as abstract methods. In
> addition, in Python 2.x, numbers.Integral adds an abstract conversion to
> long. This is not recorded in the documentation.
> 
> Originally, I was going to report this as a bug, because PEP 3141 
> <http://www.python.org/dev/peps/pep-3141/> (the PEP that specifies the
> numbers module) goes so far as to include the <<, >>, &, ^, |, and ~ in the
> source code for numbers.Integral. It looks like somebody already had
> reported this years ago, however, to python-dev with Issue 3056
> <http://bugs.python.org/issue3056>. The issue was never resolved, but has
> since been closed.
> 
> Since the development community does not seem interested in adding these 
> features, the features should be removed from documentation.

Hi Matthew,

thanks for your report, this is now fixed (belatedly) and should appear online
soon.

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

iEYEARECAAYFAlFqfhIACgkQN9GcIYhpnLDqWACgicAscvinCw1kDYMo4dVUD08R
+KsAnR8ac+gQ5WU9jnZ08JbtT3EnYBad
=IcjV
-----END PGP SIGNATURE-----

From georg at python.org  Sun Apr 14 12:03:31 2013
From: georg at python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 12:03:31 +0200
Subject: [docs] compileall module: exclusion example is path
	separator-specific
In-Reply-To: <CAEq8tJSfeR1WjJO-LPGCYsK3tp=B9v=XkiSXVHB1Cg3-p4k3vw@mail.gmail.com>
References: <CAEq8tJSfeR1WjJO-LPGCYsK3tp=B9v=XkiSXVHB1Cg3-p4k3vw@mail.gmail.com>
Message-ID: <516A7EF3.9090404@python.org>

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

Am 16.02.2012 13:12, schrieb Paul A. Giannaros:
> Hi,
> 
> 
> 
> The docs for compileall give an example of compiling pyc files in a
> directory while excluding '.svn' subdirectories:
> 
> compileall.compile_dir('Lib/', rx=re.compile('/[.]svn'), force=True)
> 
> Neither this part nor documentation for the 'rx' attribute make clear that
> the paths searched with the regular expression will have OS specific
> separators. This example doesn't work on Windows, for example. I think the
> example should be explicit that the paths will contain the native
> separators (or it should use pathsep instead of '/', or maybe '[/\\]', to
> make it clearer in the example).

Hi Paul,

thanks for the report, I've fixed the example now (sorry for the delay)
and it should appear online soon.

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

iEYEARECAAYFAlFqfvMACgkQN9GcIYhpnLC+2QCgrtDHvxNhv/NZaxPgKgHbzltK
6O0AnjKZS1ZS+qqNeqePAti8gyqePR+x
=QI2w
-----END PGP SIGNATURE-----

From ted.sybil at gmail.com  Sun Apr 14 12:02:18 2013
From: ted.sybil at gmail.com (Ted Yin)
Date: Sun, 14 Apr 2013 18:02:18 +0800
Subject: [docs] Bug in the Reference Data Model
In-Reply-To: <516A7CBE.7040405@python.org>
References: <CALL10kpr1+ahWR690+nD+W15HRw2Kw3wDyw05YHnC8AaADRSAQ@mail.gmail.com>
	<516A7CBE.7040405@python.org>
Message-ID: <CALL10ko8jKsO4wuop1e3==39EvjZ22E0FLpE2vkR2_9q8-8nPQ@mail.gmail.com>

Hi Georg,

I'm glad to get your reply. Hard to imagine how a sophisticated document
project like python reference is maintained. Your work is really
appreciated.
Cheer up and move on!

Ted


On Sun, Apr 14, 2013 at 5:54 PM, Georg Brandl <georg at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 02.02.2012 05:53, schrieb Ted Yin:
> > It's said that :
> >
> > When it would yield a class method object, it is transformed into a bound
> > user-defined method object whose im_class and im_self attributes are both
> > C.
> >
> > in the Reference <http://docs.python.org/reference/datamodel.html>
> >
> > And I did an EX.
> >
> > |>>> class C(object) :
> >
> > ...     @classmethod ...     def cm(cls) : print cls
> >
> > ...
> >>>> C.cm
> > <bound method type.cm of <class '__main__.C'>>
> >
> >>>> C.cm.im_self
> > <class '__main__.C'>
> >
> >>>> C.cm.im_class
> > <type 'type'>
> >
> > |
> >
> > It's not hard for me to understand the result.
> >
> > But unfortunately, in the reference, it's told that im_self should be
> *the
> > same* as im_class.
> >
> > And in my opinion , 'im_self' shold be C, but im_class is 'type' since
> C's
> > metaclass is type. So they're obviously *not* 'both C'.
>
> Hi Ted,
>
> thanks for the report, this has now been (belatedly) fixed and should
> appear online soon.
>
> cheers,
> Georg
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iEUEARECAAYFAlFqfL4ACgkQN9GcIYhpnLA6IgCYyKJG4tP9DQu4pKmgsYsdbV0l
> LgCdHa43mO+x62CrniBTC0wr07/5oVU=
> =XCYb
> -----END PGP SIGNATURE-----
>



-- 
--- This information is automatically generated ---
Welcome to My Blog : http://www.tedyin.com/blog/

ted.sybil aka. ymfoi aka. Ted Yin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130414/35ffb55b/attachment.html>

From dan.viar at gmail.com  Sun Apr 14 12:12:56 2013
From: dan.viar at gmail.com (Daniel Viar)
Date: Sun, 14 Apr 2013 06:12:56 -0400
Subject: [docs] Small Error on Tutorial 3.1.1 Page
In-Reply-To: <516A6CEF.90105@python.org>
References: <CAMATNzE6eQqurhn4Tm4S+zqMN-f9navOFPSoHO7uCTzBHOHjfw@mail.gmail.com>
	<516A6CEF.90105@python.org>
Message-ID: <CAMATNzG2m-9om5eNdpF9D9mi64zFCTw3mez8D+eV27ipUbgGvA@mail.gmail.com>

Thanks.  I see.  I was using IDLE.  In IDLE, you see:

>>> 2 + 2
4
>>>



On Sun, Apr 14, 2013 at 4:46 AM, Georg Brandl <georg at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 05.04.2013 14:56, schrieb Daniel Viar:
> > On the page, http://docs.python.org/3/tutorial/introduction.html under
> > 3.1.1 Numbers the following looks to be incorrect:
> >
> >>>> # This is a comment
> > ... 2+2 4
> >
> > I think that it should be
> >
> >>>> # This is a comment 2+2
> > 4
>
> Hi Daniel,
>
> if you try your example in the interactive shell, you will see that
> Python indeed displays the secondary prompt ("...") for the second
> line.
>
> cheers,
> Georg
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iEYEARECAAYFAlFqbO4ACgkQN9GcIYhpnLC3GgCfUtxUxEPIJ0OSV2QOCjcBcmhJ
> jxQAni88lWSzWjGQx1Xj6rFRM4P++VJy
> =lXaA
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130414/208c4f1e/attachment.html>

From report at bugs.python.org  Sun Apr 14 12:24:39 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 10:24:39 +0000
Subject: [docs] [issue17729] advocacy howto improvements
Message-ID: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>


New submission from Georg Brandl:

>From docs@:

"""
The howto-advocacy is interesting.

You might consider removing the following sentences, which I found personally gave me a negative impression:

"python hasn't had all the publicity" to my mind gives the impression that python is not popular.

"python is definitely not a toy language that only usable for small tasks". This gives to me the impression that you feel many people think it is.

Section "who's going to support it?" a company needs to be able to call someone, pay for support right now, within one hour, not on a maybe basis. I feel either remove this section or suggest links to three companies providing python support.

Section "python is freely available , how good can it be?" I felt what I wanted to see was not that Linux and apache are good, but why python is good.
"""

I think the advocacy howto was written quite a while ago and could use a makeover.

----------
assignee: docs at python
components: Documentation
messages: 186903
nosy: akuchling, docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: advocacy howto improvements
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Apr 14 12:30:05 2013
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 14 Apr 2013 10:30:05 +0000
Subject: [docs] [issue17727] document that some distributions change site.py
	defaults
In-Reply-To: <1365929014.79.0.72904930991.issue17727@psf.upfronthosting.co.za>
Message-ID: <1365935405.91.0.650038320955.issue17727@psf.upfronthosting.co.za>


Matthias Klose added the comment:

the local patch adds as documentation on Debian/Ubuntu:

"""
For Debian and derivatives, this sys.path is augmented with directories
for packages distributed within the distribution. Local addons go
into /usr/local/lib/python<version>/dist-packages, Debian addons
install into /usr/lib/python3/dist-packages.
/usr/lib/python<version>/site-packages is not used.
"""

I can improve the local information, but I'm not sure how much should be added/changed in the upstream documentation.

So maybe we should add an option for python-config to get the site dirs, or the list of site dirs too?

----------

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

From report at bugs.python.org  Sun Apr 14 12:31:29 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 10:31:29 +0000
Subject: [docs] [issue13050] RLock support the context manager protocol but
	this is	not documented
In-Reply-To: <1318172715.77.0.360303466185.issue13050@psf.upfronthosting.co.za>
Message-ID: <1365935489.73.0.967017456606.issue13050@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks, closing.

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

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

From bgailer at gmail.com  Sun Apr 14 15:20:22 2013
From: bgailer at gmail.com (bob gailer)
Date: Sun, 14 Apr 2013 09:20:22 -0400
Subject: [docs] Small Error on Tutorial 3.1.1 Page
In-Reply-To: <CAMATNzG2m-9om5eNdpF9D9mi64zFCTw3mez8D+eV27ipUbgGvA@mail.gmail.com>
References: <CAMATNzE6eQqurhn4Tm4S+zqMN-f9navOFPSoHO7uCTzBHOHjfw@mail.gmail.com>
	<516A6CEF.90105@python.org>
	<CAMATNzG2m-9om5eNdpF9D9mi64zFCTw3mez8D+eV27ipUbgGvA@mail.gmail.com>
Message-ID: <516AAD16.6050200@gmail.com>


>     >>>> # This is a comment
>     > ... 2+2 4
>     >
>     > I think that it should be
>     >
>     >>>> # This is a comment 2+2
>     > 4
>
>     Hi Daniel,
>
>     if you try your example in the interactive shell, you will see that
>     Python indeed displays the secondary prompt ("...") for the second
>     line.
>
I find almost no documentation regarding the secondary prompt ("..."). 
Only in the tutorial do I see

"... for continuation lines it prompts with the /secondary prompt/, by 
default three dots (...)."

No way do I see a comment requiring a continuation line! That would seem 
like a bug in the interactive shell!

Should we file it as a bug report?

-- 
Bob Gailer
919-636-4239
Chapel Hill NC

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

From report at bugs.python.org  Sun Apr 14 17:59:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 14 Apr 2013 15:59:50 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <3Zpcx10mLGzR7W@mail.python.org>


Roundup Robot added the comment:

New changeset dbb943399c9b by Serhiy Storchaka in branch '2.7':
Issue #17221: Resort Misc/NEWS.
http://hg.python.org/cpython/rev/dbb943399c9b

New changeset 7da08495b497 by Serhiy Storchaka in branch '3.3':
Issue #17221: Resort Misc/NEWS.
http://hg.python.org/cpython/rev/7da08495b497

New changeset 6fdcea9e89a3 by Serhiy Storchaka in branch 'default':
Issue #17221: Resort Misc/NEWS.
http://hg.python.org/cpython/rev/6fdcea9e89a3

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

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

From report at bugs.python.org  Sun Apr 14 18:12:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 14 Apr 2013 16:12:28 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1365955947.94.0.965708852831.issue17221@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I commit patches since no one objected.

Not all errors are corrected. There are duplicates (`cat Misc/NEWS | sort | uniq -cd | sort -n`). I'm not sure that the line "What's New in Python 3.3.1 release candidate 1?" in Misc/NEWS for 3.4 correct. The difference between 3.3 and 3.4 is more than expected (`hg diff -r 3.3 -r default Misc/NEWS`).

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Sun Apr 14 19:40:29 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 14 Apr 2013 17:40:29 +0000
Subject: [docs] [issue10438] list an example for calling static methods from
	WITHIN	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1365961229.79.0.611289338929.issue10438@psf.upfronthosting.co.za>


R. David Murray added the comment:

After a discussion (at the Boston Python sprint, unfortunately I forget with who) of how difficult this could be to explain succinctly without confusing either java/C++ programmers on the one hand or Python programmers on the other hand, this, the wording in the attached patch occurred to me.  I'm not certain that adding the extra words is worth it, but if so this might do.

----------
keywords: +patch
Added file: http://bugs.python.org/file29854/static_method_call_examples_10438.patch

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

From report at bugs.python.org  Sun Apr 14 19:51:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Apr 2013 17:51:29 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1365961888.99.0.57311746796.issue13510@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I would actually remove the whole section about readlines() or possibly just mention it briefly (something like "If you want to read all the lines of a file in a list you can also use f.readlines().")
The sizehint arg is rarely used, so I don't see the point of going in such details about it in the tutorial.  In Lib/, there are only a couple of places where it's actually used:
Lib/fileinput.py:358: self._buffer = self._file.readlines(self._bufsize)
Lib/idlelib/GrepDialog.py:90: block = f.readlines(100000)

----------

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

From report at bugs.python.org  Sun Apr 14 19:52:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Apr 2013 17:52:46 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1365961888.99.0.57311746796.issue13510@psf.upfronthosting.co.za>
Message-ID: <1365961964.2427.2.camel@fsol>


Antoine Pitrou added the comment:

> I would actually remove the whole section about readlines() or
> possibly just mention it briefly (something like "If you want to read
> all the lines of a file in a list you can also use f.readlines().")
> The sizehint arg is rarely used, so I don't see the point of going in
> such details about it in the tutorial.

You are right, Ezio.

----------

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

From report at bugs.python.org  Sun Apr 14 19:59:47 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 14 Apr 2013 17:59:47 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1365962387.45.0.366573739976.issue13510@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree with removing .readlines section. If .readlines did not exist, I do not think we would add it now.

----------

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

From report at bugs.python.org  Sun Apr 14 20:44:19 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 14 Apr 2013 18:44:19 +0000
Subject: [docs] [issue10438] list an example for calling static methods from
	WITHIN	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1365965059.3.0.136833608031.issue10438@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/issue10438>
_______________________________________

From report at bugs.python.org  Sun Apr 14 21:16:28 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 14 Apr 2013 19:16:28 +0000
Subject: [docs] [issue10438] list an example for calling static methods from
	WITHIN	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1365966988.58.0.145585340729.issue10438@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Note that in Python 3 you can also do __class__.f() in a staticmethod.  Not sure if that is encouraged though.

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

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

From report at bugs.python.org  Sun Apr 14 21:37:37 2013
From: report at bugs.python.org (David Lam)
Date: Sun, 14 Apr 2013 19:37:37 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1365968257.38.0.338332630582.issue16954@psf.upfronthosting.co.za>


David Lam added the comment:

Hi Eli, I sure would!

(Though, if anyone finds this issue and can figure out a solution, I'd encourage them to post it!)

----------

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

From report at bugs.python.org  Sun Apr 14 22:38:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 14 Apr 2013 20:38:51 +0000
Subject: [docs] [issue17135] imp doc should direct to importlib
In-Reply-To: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>
Message-ID: <1365971931.43.0.912014031184.issue17135@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Kristian.  The 3.x docs were a "fresh start", so if we want to mark something as deprecated it would be a Python3 version number, the number current at the time of the deprecation.

There is another open issue, 17177, that speaks specifically about deprecating the module, but it sounds like a documentation deprecation to start with is a good idea; I believe that at this point all the imp functions can be replicated with suitable importlib calls (Eric can correct me if I'm wrong).  It would thus be as of version 3.4, at this point, since we didn't do it before the 3.3 release.

This issue also mentions linking to "importlib instead of the import statement", which refers to the ':keyword:`import`' statement in the title.

Do you want to resubmit the patch with those changes?  Otherwise I can just make them when I commit it.

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

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

From report at bugs.python.org  Sun Apr 14 23:47:17 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 14 Apr 2013 21:47:17 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1365976037.76.0.17976192847.issue16954@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

You can ask on the python-dev mailing list. It's possible that other Python developers ran into a similar issue.

----------

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

From report at bugs.python.org  Mon Apr 15 03:43:29 2013
From: report at bugs.python.org (Dan Riti)
Date: Mon, 15 Apr 2013 01:43:29 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1365990209.75.0.226100131167.issue13510@psf.upfronthosting.co.za>


Dan Riti added the comment:

Added a new version of the patch to incorporate Ezio's comment!

----------
Added file: http://bugs.python.org/file29859/demote-readlines-v2.patch

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

From report at bugs.python.org  Mon Apr 15 05:20:23 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Apr 2013 03:20:23 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1365996023.08.0.932413599822.issue13510@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Patch LGTM.  I think it would also be better to say something like "Note that it's already possible to iterate on file objects using ``for line in file: ...`` without calling file.readlines()." in Doc/library/io.rst:readlines, as suggested in msg148703.

----------

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

From report at bugs.python.org  Mon Apr 15 17:40:40 2013
From: report at bugs.python.org (Dan Riti)
Date: Mon, 15 Apr 2013 15:40:40 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1366040440.71.0.519810302396.issue13510@psf.upfronthosting.co.za>


Dan Riti added the comment:

Agreed Ezio, I've updated the patch to include the change to Doc/library/io.rst:readlines.

----------
Added file: http://bugs.python.org/file29868/demote-readlines-v3.patch

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

From report at bugs.python.org  Mon Apr 15 18:09:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Apr 2013 16:09:59 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <3ZqF6H0HWVzSD5@mail.python.org>


Roundup Robot added the comment:

New changeset 1e8be05a4039 by Ezio Melotti in branch '3.3':
#13510: clarify that f.readlines() is note necessary to iterate over a file.  Patch by Dan Riti.
http://hg.python.org/cpython/rev/1e8be05a4039

New changeset 7f4325dc4256 by Ezio Melotti in branch 'default':
#13510: merge with 3.3.
http://hg.python.org/cpython/rev/7f4325dc4256

New changeset 6a4746b0afaf by Ezio Melotti in branch '2.7':
#13510: clarify that f.readlines() is note necessary to iterate over a file.  Patch by Dan Riti.
http://hg.python.org/cpython/rev/6a4746b0afaf

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

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

From report at bugs.python.org  Mon Apr 15 18:13:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Apr 2013 16:13:13 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1366042393.2.0.350208372394.issue13510@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!
I also realized I missed Terry suggestion about file.readlines() == list(file), so I added that too.

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

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

From ezio.melotti at gmail.com  Mon Apr 15 18:51:23 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 15 Apr 2013 16:51:23 -0000
Subject: [docs] Improving strftime documentation (issue 17701)
Message-ID: <20130415165123.21865.40850@psf.upfronthosting.co.za>


http://bugs.python.org/review/17701/diff/7875/Doc/library/datetime.rst
File Doc/library/datetime.rst (right):

http://bugs.python.org/review/17701/diff/7875/Doc/library/datetime.rst#newcode1631
Doc/library/datetime.rst:1631: |           |                            
   |  ??? (ja_JP)        |       |
IIRC non-latin1 chars are not allowed in the doc, because the pdf
builder doesn't support them.  (To test this, it should be `make latex`
and `make all-pdf`, or something similar.)

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

From report at bugs.python.org  Mon Apr 15 20:06:48 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 15 Apr 2013 18:06:48 +0000
Subject: [docs] [issue17740] :func:`socket` in socket.rst links to socket
	module, not socket.socket
Message-ID: <1366049208.35.0.954231970702.issue17740@psf.upfronthosting.co.za>


New submission from Zachary Ware:

In Doc/library/socket.rst, :func:`socket` links to #module-socket, not #socket.socket.  The attached patch changes all occurances of :func:`socket` to :func:`~socket.socket`, except the first one which keeps the explicit module name (no ~).

----------
assignee: docs at python
components: Documentation
files: socket_func_link.diff
keywords: patch
messages: 187009
nosy: docs at python, zach.ware
priority: normal
severity: normal
status: open
title: :func:`socket` in socket.rst links to socket module, not socket.socket
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29871/socket_func_link.diff

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

From report at bugs.python.org  Mon Apr 15 20:07:04 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 15 Apr 2013 18:07:04 +0000
Subject: [docs] [issue17740] :func:`socket` in socket.rst links to socket
	module, not socket.socket
In-Reply-To: <1366049208.35.0.954231970702.issue17740@psf.upfronthosting.co.za>
Message-ID: <1366049224.85.0.0604403907426.issue17740@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


Added file: http://bugs.python.org/file29872/socket_func_link_2.7.diff

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

From report at bugs.python.org  Mon Apr 15 20:17:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Apr 2013 18:17:39 +0000
Subject: [docs] [issue17740] :func:`socket` in socket.rst links to socket
	module, not socket.socket
In-Reply-To: <1366049208.35.0.954231970702.issue17740@psf.upfronthosting.co.za>
Message-ID: <1366049859.1.0.20827324178.issue17740@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think :func:`.socket` should work too.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
stage:  -> patch review

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

From report at bugs.python.org  Mon Apr 15 20:51:43 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 15 Apr 2013 18:51:43 +0000
Subject: [docs] [issue17740] :func:`socket` in socket.rst links to socket
	module, not socket.socket
In-Reply-To: <1366049208.35.0.954231970702.issue17740@psf.upfronthosting.co.za>
Message-ID: <1366051903.44.0.305194950607.issue17740@psf.upfronthosting.co.za>


Zachary Ware added the comment:

So it does.  Would you like a new pair of patches?  It is just a search-and-replace from ":func:`socket`" to ":func:`.socket`".

----------

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

From report at bugs.python.org  Mon Apr 15 23:02:03 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 15 Apr 2013 21:02:03 +0000
Subject: [docs] [issue17670] Improve str.expandtabs() doc
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1366059723.18.0.306365979506.issue17670@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the suggested.  Here's a revised wording and a slightly more legible example:


   Return a copy of the string where all tab characters are replaced by zero or
   more spaces, depending on the current tab column and the given tab size.
   Starting at the first character of the string, the tab column is set to
   zero.  Whenever a tab character (``\t``) is encountered, space characters
   are inserted as needed until the next tab position is reached and the tab
   column is set to that tab position; the tab character itself is not copied.
   Whenever a newline character (``\n`` or ``\r``) is encountered, it is copied
   and the tab column is reset to zero.  Any other character is copied unchanged
   and the tab column is incremented by one regardless of how it may be
   represented when printed.  If *tabsize* is not given, a tab size of 8
   characters is assumed.

      >>> '012\t4\t89'.expandtabs(4)
      '012 4   89'

----------
Added file: http://bugs.python.org/file29875/issue17670_doc_rev_1.patch

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

From report at bugs.python.org  Mon Apr 15 23:13:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Apr 2013 21:13:15 +0000
Subject: [docs] [issue17739] ssl.SSLSocket.getpeercert does not return
	client	certificate
In-Reply-To: <1366038894.17.0.187002314395.issue17739@psf.upfronthosting.co.za>
Message-ID: <1366060394.94.0.614898996561.issue17739@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks for reporting this. This is a documentation issue. As stated in the OpenSSL docs:

"Due to the protocol definition, a TLS/SSL server will always send a certificate, if present. A client will only send a certificate when explicitly requested to do so by the server (see SSL_CTX_set_verify(3))."

(Note that you can use CERT_OPTIONAL on the server. This will let through clients without a certificate, but will reject clients with an invalid certificate.)

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou
stage:  -> needs patch
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Apr 15 23:25:22 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 15 Apr 2013 21:25:22 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1366061121.74.0.709749750539.issue17386@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I caught a small oversight.  This new patch changes the example in README.txt to ``make html "PYTHON2=C:\Python27\python.exe"`` (PYTHON->PYTHON2).  Also, I added a bit of backward compatibility to make.bat; %PYTHON2% will default to %PYTHON% if it is set.  Otherwise, %PYTHON% is ignored and unchanged.

----------
Added file: http://bugs.python.org/file29876/win_doc_make.v4.diff

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

From report at bugs.python.org  Tue Apr 16 02:01:03 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 16 Apr 2013 00:01:03 +0000
Subject: [docs] [issue17745] "packaging" no longer planned to be included
Message-ID: <1366070463.53.0.324723238706.issue17745@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

attached patch reflects current reality (me assuming that PEPs are living documents)

----------
assignee: docs at python
components: Documentation
files: diff
messages: 187040
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: "packaging" no longer planned to be included
Added file: http://bugs.python.org/file29879/diff

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

From report at bugs.python.org  Tue Apr 16 03:16:48 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 16 Apr 2013 01:16:48 +0000
Subject: [docs] [issue17670] Improve str.expandtabs() doc
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1366075008.51.0.412088061309.issue17670@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

It's better, although the distinction between "tab column" and "tab position" is not entirely clear.

----------

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

From report at bugs.python.org  Tue Apr 16 09:09:45 2013
From: report at bugs.python.org (paul j3)
Date: Tue, 16 Apr 2013 07:09:45 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1366096185.32.0.672667122425.issue14191@psf.upfronthosting.co.za>


paul j3 added the comment:

This patch permits the mixing of optionals with positionals, with the caveat that a particular positional cannot be split up.

If:

    parser = ArgumentParser()
    parser.add_argument('-f','--foo')
    parser.add_argument('cmd')
    parser.add_argument('rest', nargs='*')

    '-f1 cmd 1 2 3', 
    'cmd -f1 1 2 3', 
    'cmd 1 2 3 -f1' 

all give {cmd='cmd', rest=['1','2','3'], foo='1'}.  

But 'cmd 1 -f1 2 3', does not recognize ['2','3'].

Previously 'cmd -f1 1 2 3' would return rest=[], and not recognize ['1','2','3'].  With this change the nargs='*' behaves more like nargs='+', surviving to parse the 2nd group of positional strings.

The trick is to modify arg_counts in consume_positionals(), removing matches that don't do anything (don't consume argument strings). 

    if 'O' in arg_strings_pattern[start_index:]:
        # if there is an optional after this, remove
        # 'empty' positionals from the current match
        while len(arg_counts)>1 and arg_counts[-1]==0:
            arg_counts = arg_counts[:-1]

This change passes all of the existing test_argparse.py tests.  It also passes the optparse tests that I added in http://bugs.python.org/issue9334#msg184987
I added 4 cases to illustrate this change.

----------
Added file: http://bugs.python.org/file29880/mixed.patch

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

From report at bugs.python.org  Tue Apr 16 11:03:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Apr 2013 09:03:40 +0000
Subject: [docs] [issue17745] "packaging" no longer planned to be included
In-Reply-To: <1366070463.53.0.324723238706.issue17745@psf.upfronthosting.co.za>
Message-ID: <1366103020.29.0.370854922179.issue17745@psf.upfronthosting.co.za>


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


----------
components: +Distutils, Distutils2
nosy: +alexis, tarek

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

From report at bugs.python.org  Tue Apr 16 20:27:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 16 Apr 2013 18:27:31 +0000
Subject: [docs] [issue17739] ssl.SSLSocket.getpeercert does not return
	client	certificate
In-Reply-To: <1366038894.17.0.187002314395.issue17739@psf.upfronthosting.co.za>
Message-ID: <3Zqw6Q4Gt8zSTh@mail.python.org>


Roundup Robot added the comment:

New changeset 8dffb76faacc by Antoine Pitrou in branch '2.7':
Issue #17739: fix the description of SSLSocket.getpeercert(binary_form=True) for server sockets.
http://hg.python.org/cpython/rev/8dffb76faacc

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

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

From report at bugs.python.org  Tue Apr 16 20:28:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 16 Apr 2013 18:28:49 +0000
Subject: [docs] [issue17739] ssl.SSLSocket.getpeercert does not return
	client	certificate
In-Reply-To: <1366038894.17.0.187002314395.issue17739@psf.upfronthosting.co.za>
Message-ID: <3Zqw805ftTzSTh@mail.python.org>


Roundup Robot added the comment:

New changeset 908f1a61b907 by Antoine Pitrou in branch '3.3':
Issue #17739: fix the description of SSLSocket.getpeercert(binary_form=True) for server sockets.
http://hg.python.org/cpython/rev/908f1a61b907

New changeset 537c1f1ab53c by Antoine Pitrou in branch 'default':
Issue #17739: fix the description of SSLSocket.getpeercert(binary_form=True) for server sockets.
http://hg.python.org/cpython/rev/537c1f1ab53c

----------

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

From report at bugs.python.org  Tue Apr 16 20:29:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Apr 2013 18:29:25 +0000
Subject: [docs] [issue17739] ssl.SSLSocket.getpeercert does not return
	client	certificate
In-Reply-To: <1366038894.17.0.187002314395.issue17739@psf.upfronthosting.co.za>
Message-ID: <1366136965.02.0.721160455626.issue17739@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I have now fixed the documentation. Thank you!

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

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

From report at bugs.python.org  Wed Apr 17 03:12:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 17 Apr 2013 01:12:33 +0000
Subject: [docs] [issue17740] :func:`socket` in socket.rst links to socket
	module, not socket.socket
In-Reply-To: <1366049208.35.0.954231970702.issue17740@psf.upfronthosting.co.za>
Message-ID: <3Zr55r3RLVz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 7041401699e9 by Ezio Melotti in branch '3.3':
#17740: fix links to the socket function.  Initial patch by Zachary Ware.
http://hg.python.org/cpython/rev/7041401699e9

New changeset b6802d2a6c4e by Ezio Melotti in branch 'default':
#17740: merge with 3.3.
http://hg.python.org/cpython/rev/b6802d2a6c4e

New changeset 053d55ab495c by Ezio Melotti in branch '2.7':
#17740: fix links to the socket function.  Initial patch by Zachary Ware.
http://hg.python.org/cpython/rev/053d55ab495c

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

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

From report at bugs.python.org  Wed Apr 17 03:13:51 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 17 Apr 2013 01:13:51 +0000
Subject: [docs] [issue17740] :func:`socket` in socket.rst links to socket
	module, not socket.socket
In-Reply-To: <1366049208.35.0.954231970702.issue17740@psf.upfronthosting.co.za>
Message-ID: <1366161231.35.0.425420874172.issue17740@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patches!

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

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

From report at bugs.python.org  Wed Apr 17 06:01:31 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Wed, 17 Apr 2013 04:01:31 +0000
Subject: [docs] [issue17771] Missing period in concurrent execution doc in
	standard	library
Message-ID: <1366171291.19.0.507321849064.issue17771@psf.upfronthosting.co.za>


New submission from Andriy Mysyk:

No period after the first sentence of the first paragraph in /Doc/build/html/library/concurrency.html.

"The appropriate choice of tool will depend on the task to be executed (CPU bound vs IO bound) and preferred style of development (event driven cooperative multitasking vs preemptive multitasking) Here?s an overview:"

----------
assignee: docs at python
components: Documentation
messages: 187137
nosy: amysyk, docs at python
priority: normal
severity: normal
status: open
title: Missing period in concurrent execution doc in standard library
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 17 06:08:49 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Wed, 17 Apr 2013 04:08:49 +0000
Subject: [docs] [issue17771] Missing period in concurrent execution doc in
	standard	library
In-Reply-To: <1366171291.19.0.507321849064.issue17771@psf.upfronthosting.co.za>
Message-ID: <1366171729.84.0.127891556583.issue17771@psf.upfronthosting.co.za>


Andriy Mysyk added the comment:

I will create a patch for this issue by Apr 23, 2013.

----------

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

From report at bugs.python.org  Wed Apr 17 06:14:36 2013
From: report at bugs.python.org (paul j3)
Date: Wed, 17 Apr 2013 04:14:36 +0000
Subject: [docs] [issue16988] argparse: PARSER option for nargs not documented
In-Reply-To: <1358458215.07.0.403888123098.issue16988@psf.upfronthosting.co.za>
Message-ID: <1366172076.48.0.619707550201.issue16988@psf.upfronthosting.co.za>


paul j3 added the comment:

I've experimented with an argparse adaptation of profile.py:

    parser = argparse.ArgumentParser(usage=usage)
    parser.add_argument('-o', '--outfile', dest="outfile",
        help="Save stats to <outfile>", metavar="path")
    parser.add_argument('-s', '--sort', dest="sort",
        help="Sort order when printing to stdout ...",
        default=-1)
    parser.add_argument('args', nargs=argparse.PARSER,
        metavar="scriptfile [arg] ...") 
        # expect at least one positional, a py module

It is somewhat like subparsers, but without defined subparser choices.  Or you could say that PARSER (A...) is to REMAINDER (...) as '+' is to '*'.  It requires at least one argument.  I could, just as well, have created two arguments, 'scriptfile' and 'args' (with '...').

I don't know if that is an argument for documenting it or not.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Wed Apr 17 06:21:03 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Wed, 17 Apr 2013 04:21:03 +0000
Subject: [docs] [issue17771] Missing period in concurrent execution doc in
	standard	library
In-Reply-To: <1366171291.19.0.507321849064.issue17771@psf.upfronthosting.co.za>
Message-ID: <1366172463.44.0.58050384199.issue17771@psf.upfronthosting.co.za>


Andriy Mysyk added the comment:

Added a missing period to concurrency.rst

----------
keywords: +patch
type: enhancement -> 
Added file: http://bugs.python.org/file29898/mywork.patch

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

From report at bugs.python.org  Wed Apr 17 06:32:34 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Wed, 17 Apr 2013 04:32:34 +0000
Subject: [docs] [issue17771] Missing period in concurrent execution doc in
	standard	library
In-Reply-To: <1366171291.19.0.507321849064.issue17771@psf.upfronthosting.co.za>
Message-ID: <1366173154.18.0.675528166074.issue17771@psf.upfronthosting.co.za>


Changes by Andriy Mysyk <andriy.mysyk at gmail.com>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Wed Apr 17 06:34:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 17 Apr 2013 04:34:56 +0000
Subject: [docs] [issue17771] Missing period in concurrent execution doc in
	standard	library
In-Reply-To: <1366171291.19.0.507321849064.issue17771@psf.upfronthosting.co.za>
Message-ID: <3Zr9bM73NBzSJp@mail.python.org>


Roundup Robot added the comment:

New changeset 72b650a99b36 by Ezio Melotti in branch '3.3':
#17771: fix typo.  Patch by Andriy Mysyk.
http://hg.python.org/cpython/rev/72b650a99b36

New changeset 61a17d9e58e2 by Ezio Melotti in branch 'default':
#17771: merge with 3.3.
http://hg.python.org/cpython/rev/61a17d9e58e2

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

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

From report at bugs.python.org  Wed Apr 17 06:35:36 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 17 Apr 2013 04:35:36 +0000
Subject: [docs] [issue17771] Missing period in concurrent execution doc in
	standard	library
In-Reply-To: <1366171291.19.0.507321849064.issue17771@psf.upfronthosting.co.za>
Message-ID: <1366173336.24.0.128278092129.issue17771@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

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

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

From report at bugs.python.org  Wed Apr 17 17:37:35 2013
From: report at bugs.python.org (Reynir Reynisson)
Date: Wed, 17 Apr 2013 15:37:35 +0000
Subject: [docs] [issue17777] Unrecognized string literal escape sequences
	give	SyntaxErrors
Message-ID: <1366213055.37.0.161368185198.issue17777@psf.upfronthosting.co.za>


New submission from Reynir Reynisson:

Strings like "\u" trigger a SyntaxError. According to the language reference "all unrecognized escape sequences are left in the string unchanged"[0]. The string "\u" clearly doesn't match any of the escape sequences (in particular \uxxxx).

This may be intentional, but it is not clear from the language reference that this is the case. If it is intentional it should probably be stated more explicit in the language reference.

I think this may be confusing for new users since the syntax errors may lead them to believe the interpreter will give syntax error for all unrecognized escape sequences.

[0]: http://docs.python.org/3/reference/lexical_analysis.html#literals

----------
assignee: docs at python
components: Documentation, Unicode
messages: 187173
nosy: docs at python, ezio.melotti, reynir
priority: normal
severity: normal
status: open
title: Unrecognized string literal escape sequences give SyntaxErrors
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 17 17:54:45 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Apr 2013 15:54:45 +0000
Subject: [docs] [issue17777] Unrecognized string literal escape sequences
	give	SyntaxErrors
In-Reply-To: <1366213055.37.0.161368185198.issue17777@psf.upfronthosting.co.za>
Message-ID: <1366214085.3.0.887671301368.issue17777@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is a recognized escape sequence, but the syntax of the escape sequence is wrong, thus the syntax error.  An "escape sequence" is a backslash character followed by a letter.  Perhaps that is the bit that needs to be clarified in the docs?

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

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

From report at bugs.python.org  Wed Apr 17 22:00:30 2013
From: report at bugs.python.org (Reynir Reynisson)
Date: Wed, 17 Apr 2013 20:00:30 +0000
Subject: [docs] [issue17777] Unrecognized string literal escape sequences
	give	SyntaxErrors
In-Reply-To: <1366213055.37.0.161368185198.issue17777@psf.upfronthosting.co.za>
Message-ID: <1366228830.4.0.578619601375.issue17777@psf.upfronthosting.co.za>


Reynir Reynisson added the comment:

Thank you for the quick reply. Yes, something along those lines would help. Maybe adding "The escape sequence \x expects exactly two hex digits" would make it even clearer.

----------

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

From report at bugs.python.org  Thu Apr 18 00:51:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 17 Apr 2013 22:51:26 +0000
Subject: [docs] [issue17135] imp doc should direct to importlib
In-Reply-To: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>
Message-ID: <3ZrdwY5Sh9zS1k@mail.python.org>


Roundup Robot added the comment:

New changeset f22c463ce73c by R David Murray in branch 'default':
#17135: mark imp as deprecated as of 3.4.
http://hg.python.org/cpython/rev/f22c463ce73c

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

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

From report at bugs.python.org  Thu Apr 18 15:53:52 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Apr 2013 13:53:52 +0000
Subject: [docs] [issue17135] imp doc should direct to importlib
In-Reply-To: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>
Message-ID: <3Zs1xq1RqtzSKq@mail.python.org>


Roundup Robot added the comment:

New changeset 8f15a46a8c76 by R David Murray in branch '3.3':
#17135: Add note in imp to use importlib for new programs.
http://hg.python.org/cpython/rev/8f15a46a8c76

----------

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

From report at bugs.python.org  Thu Apr 18 15:54:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Apr 2013 13:54:33 +0000
Subject: [docs] [issue17135] imp doc should direct to importlib
In-Reply-To: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>
Message-ID: <1366293273.91.0.21948185283.issue17135@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Kristian.

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

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

From report at bugs.python.org  Thu Apr 18 17:16:08 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 18 Apr 2013 15:16:08 +0000
Subject: [docs] [issue1626300] 'Installing Python Modules' does not work for
	Windows
Message-ID: <1366298167.89.0.489011860357.issue1626300@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Is any more work needed on this issue or can it be closed?

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Thu Apr 18 18:19:03 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 18 Apr 2013 16:19:03 +0000
Subject: [docs] [issue1626300] 'Installing Python Modules' does not work for
	Windows
Message-ID: <1366301943.25.0.0497557604794.issue1626300@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I consider it ?ric's decision.
3.3 on Windows comes with the new py launcher. That might be incorporated into the docs if it has not. That might also be a separate issue.

----------

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

From report at bugs.python.org  Thu Apr 18 18:46:44 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Apr 2013 16:46:44 +0000
Subject: [docs] [issue1626300] 'Installing Python Modules' does not work for
	Windows
Message-ID: <1366303604.77.0.627294361337.issue1626300@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I consider documentation for the py launched a distinct issue.  The original complaint here was fixed, the part about packaging does not apply anymore, so I will close this.  If one of the changed instructions still does not work (e.g. ?setup.py build? does not work), please reopen.

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

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

From report at bugs.python.org  Thu Apr 18 19:14:41 2013
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 18 Apr 2013 17:14:41 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1366305281.81.0.0697370278189.issue14191@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

Paul, your comments are interesting, but your proposed patch doesn't actually solve the problem.

So here I am typing away at my command prompt, and I type in a couple optional parameters I know I'll need and start on the sequence of positional ones, and half way through I remember "oh, I need another optional paremeter" so I type it in next before I forget, and then go on with the positional ones.

No prior Unix-style argument parsing mechanism that I have ever seen or heard of would be confused by that, but argparse is.

This bug is about providing a facility in argparse that supports intermixing optional parameters into strings of positional parameters, just like all prior Unix-style argument parsing mechanisms, so that an application can be ported to use argparse without breaking command lines that their users have stored in command files. Otherwise argparse is not an upgrade path for an application, yet optparse has been deprecated.

----------

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

From report at bugs.python.org  Thu Apr 18 19:33:56 2013
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 18 Apr 2013 17:33:56 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1366306436.14.0.0105250870337.issue14191@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

I should clarify, before someone jumps in: some particular applications do implement restrictions on order of optional and positional arguments; I'm aware of that. getopt easily supported application defined order restrictions, because it processed arguments sequentially, and the processing loop was user code. optparse, as has been pointed out, parses the optionals, and leaves a single list of positionals, combined from between all the optionals, for the user code to process in any manner, but would actually make it harder for user code to implement order restrictions. argparse goes the other way, taking over all the user parsing (which is a good thing), but not providing sufficient features to implement flexible mixing of optional and positional arguments.

----------

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

From report at bugs.python.org  Thu Apr 18 23:03:27 2013
From: report at bugs.python.org (Phil Connell)
Date: Thu, 18 Apr 2013 21:03:27 +0000
Subject: [docs] [issue16355] inspect.getcomments() does not work in the
	interactive	shell
In-Reply-To: <1351511930.82.0.59071323276.issue16355@psf.upfronthosting.co.za>
Message-ID: <1366319007.8.0.51378306763.issue16355@psf.upfronthosting.co.za>


Phil Connell added the comment:

Here's a patch that updates getcomments to match the behaviour of getsource, raising OSError if the source file can't be found and TypeError when passed a built-in.

Since this is a backwards-incompatible change, presumably it can only be applied to 3.4.

This is ready for review.

----------
keywords: +patch
nosy: +pconnell
Added file: http://bugs.python.org/file29926/issue16355.diff

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

From report at bugs.python.org  Fri Apr 19 03:36:29 2013
From: report at bugs.python.org (paul j3)
Date: Fri, 19 Apr 2013 01:36:29 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1366335389.12.0.0604379330527.issue14191@psf.upfronthosting.co.za>


paul j3 added the comment:

Glenn
Take a look at http://bugs.python.org/issue15427

I took a stab at changing the documentation, including recommending parse_known_args when porting optparse uses.

----------

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

From report at bugs.python.org  Fri Apr 19 03:50:35 2013
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 19 Apr 2013 01:50:35 +0000
Subject: [docs] [issue15427] Describe use of args parameter
	of	argparse.ArgumentParser.parse_args
In-Reply-To: <1342995154.12.0.902919829048.issue15427@psf.upfronthosting.co.za>
Message-ID: <1366336235.91.0.469878649634.issue15427@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

These docs changes seem reasonable, from a side-by-side view (I didn't attempt to look at the formatted results of applying the patch), to better document the current behavior.

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

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

From report at bugs.python.org  Fri Apr 19 04:40:54 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Apr 2013 02:40:54 +0000
Subject: [docs] [issue17777] Unrecognized string literal escape sequences
	give	SyntaxErrors
In-Reply-To: <1366213055.37.0.161368185198.issue17777@psf.upfronthosting.co.za>
Message-ID: <1366339254.45.0.539630011625.issue17777@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 2.7, Python 3.4

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

From report at bugs.python.org  Fri Apr 19 05:51:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Apr 2013 03:51:25 +0000
Subject: [docs] [issue16355] inspect.getcomments() does not work in the
	interactive	shell
In-Reply-To: <1351511930.82.0.59071323276.issue16355@psf.upfronthosting.co.za>
Message-ID: <1366343485.81.0.649173857056.issue16355@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> patch review
versions:  -Python 3.2

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

From report at bugs.python.org  Fri Apr 19 05:51:55 2013
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 19 Apr 2013 03:51:55 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1366343515.53.0.375956654023.issue14191@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

Docs look good as mentioned there, for the current behavior, although it would be good to improve the behavior.  

Note that I have supplied a wrapper (t18a.py) (if it hasn't bit-rotted for 3.4, I'm still using 3.3) that provides the needed functionality. The problem is, that I have no clue how to modify the internals of argparse to allow it to simply be a method of the current argparse class.  One could achieve the goal by renaming the current argparse class to _argparse, and renaming my wrapper class to be the "real" argparse, and that would work, but would seem to be inefficient.

It would be nice if someone could move the needed functionality, a new API called parse_intermixed_args, already approved by msg166175, that does the same thing as my wrapper does, but without the wrapper class. This would be a cure to the problem, and it could be tested against my wrapper class by comparison to ensure the needed functionality is provided. I'd be glad to help with testing and understanding the requirements, but don't have time to figure out the internals of argparse at present.

----------

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

From report at bugs.python.org  Fri Apr 19 15:54:13 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Apr 2013 13:54:13 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366379653.27.0.993663807477.issue17468@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

A documentation patch sounds good to me.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type: resource usage -> behavior

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

From report at bugs.python.org  Fri Apr 19 18:03:24 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 19 Apr 2013 16:03:24 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366387404.87.0.542770090305.issue17468@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Adding Guido because this appears to be due to a longstanding difference between the handling of tp_del and most other slots

Specifically, the reason for the odd behaviour appears to be that generator objects define tp_del [1] (which is what the cyclic gc *really* looks for), but while defining __del__ in Python will populate tp_del in the type slots, defining tp_del directly in a builtin or extension type doesn't create an exposed __del__ at the Python level (there's no wrapper function identified in the slot definition).

So, at the very least, the fact that builtin and extension types can define tp_del without creating a visible __del__ method needs to be documented as a CPython implementation detail.

However, I'm not sure we actually have a good *reason* for tp_del failing to generate __del__ automatically - it's been that way since Guido implemented it [2], but Guido's comment in that commit message about not needing a wrapper because types written in C can't define tp_del is clearly no longer accurate.

[1] http://hg.python.org/cpython/file/2.7/Objects/genobject.c#l328
[2] http://hg.python.org/cpython/annotate/71dca7c76fa2/Objects/typeobject.c#3955

----------
nosy: +gvanrossum
versions: +Python 3.4

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

From report at bugs.python.org  Fri Apr 19 18:25:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Apr 2013 16:25:59 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366388759.57.0.180530752584.issue17468@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

With the advent of yield-based asynchronous programming, it is going to be problematic if a generator caught in a reference cycle can create a memory leak.

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

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

From report at bugs.python.org  Fri Apr 19 18:33:33 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Apr 2013 16:33:33 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366389213.8.0.127297511455.issue17468@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I think the creation of __del__ wrappers for extension types is separate from this issue of generator finalization.

----------

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

From report at bugs.python.org  Fri Apr 19 18:37:42 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 19 Apr 2013 16:37:42 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366389462.5.0.948171251947.issue17468@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Yes. Hopefully, the async framework using generators can properly can close() on them, though.

----------

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

From report at bugs.python.org  Fri Apr 19 18:39:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Apr 2013 16:39:47 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1366389462.5.0.948171251947.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366389584.2550.3.camel@fsol>


Antoine Pitrou added the comment:

> Yes. Hopefully, the async framework using generators can properly can
> close() on them, though.

With yield from-based generators, you don't need a trampoline anymore,
so the close() call is now left to the application developers (if I'm
not mistaken).

----------

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

From report at bugs.python.org  Fri Apr 19 20:11:30 2013
From: report at bugs.python.org (Martin Morrison)
Date: Fri, 19 Apr 2013 18:11:30 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366395090.96.0.811615304003.issue17468@psf.upfronthosting.co.za>


Changes by Martin Morrison <mm at ensoft.co.uk>:


----------
nosy: +pconnell

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

From report at bugs.python.org  Fri Apr 19 20:32:52 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 19 Apr 2013 18:32:52 +0000
Subject: [docs] [issue17729] advocacy howto improvements
In-Reply-To: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>
Message-ID: <1366396372.0.0.946714966228.issue17729@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/issue17729>
_______________________________________

From report at bugs.python.org  Fri Apr 19 20:43:35 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 19 Apr 2013 18:43:35 +0000
Subject: [docs] [issue17729] advocacy howto improvements
In-Reply-To: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>
Message-ID: <1366397015.49.0.275825402901.issue17729@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe added the comment:

I would rather the page be removed, at least from the official docs. I wonder how useful it actually is, and as already pointed, it really feels outdated (and Apache is not kool no more).

----------

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

From report at bugs.python.org  Fri Apr 19 20:49:21 2013
From: report at bugs.python.org (Phil Connell)
Date: Fri, 19 Apr 2013 18:49:21 +0000
Subject: [docs] [issue16394] Reducing tee() memory footprint
In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>
Message-ID: <1366397361.9.0.292543976967.issue16394@psf.upfronthosting.co.za>


Changes by Phil Connell <pconnell at gmail.com>:


----------
nosy: +pconnell

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

From report at bugs.python.org  Fri Apr 19 20:49:41 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Apr 2013 18:49:41 +0000
Subject: [docs] [issue17729] advocacy howto improvements
In-Reply-To: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>
Message-ID: <1366397381.79.0.649459390185.issue17729@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Apr 19 20:59:27 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Apr 2013 18:59:27 +0000
Subject: [docs] [issue17714] str.encode('base64') add trailing new line
	character. It	is not documented.
In-Reply-To: <1365867569.46.0.547710519327.issue17714@psf.upfronthosting.co.za>
Message-ID: <1366397967.85.0.764677132834.issue17714@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch

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

From report at bugs.python.org  Fri Apr 19 21:38:01 2013
From: report at bugs.python.org (Phil Connell)
Date: Fri, 19 Apr 2013 19:38:01 +0000
Subject: [docs] [issue16863] Python 2 error in Argparse tutorial
In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za>
Message-ID: <1366400281.44.0.282372847975.issue16863@psf.upfronthosting.co.za>


Changes by Phil Connell <pconnell at gmail.com>:


----------
nosy: +pconnell

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

From report at bugs.python.org  Fri Apr 19 22:02:15 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 19 Apr 2013 20:02:15 +0000
Subject: [docs] [issue16394] Reducing tee() memory footprint
In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>
Message-ID: <1366401735.54.0.285632584498.issue16394@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Apr 20 04:59:21 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 20 Apr 2013 02:59:21 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366426761.56.0.773952068638.issue17468@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Unless I'm the only person on earth who can understand this I beg to be left out of this bug. I just don't have the bandwidth right now to look into it. If it's really about GC and __del__ and generators, maybe Tim Peters would be willing to look into it? Or perhaps Neil Schemenauer, who IIRC did a lot of the early work on GC.

----------

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

From report at bugs.python.org  Sat Apr 20 05:23:58 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Apr 2013 03:23:58 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366428238.0.0.589715422456.issue17468@psf.upfronthosting.co.za>


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


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Sat Apr 20 05:36:20 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 20 Apr 2013 03:36:20 +0000
Subject: [docs] [issue17799] settrace docs are wrong about "c_call" events
Message-ID: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

Looking into this Stack Overflow question:  http://stackoverflow.com/questions/16115027/pythons-sys-settrace-wont-create-c-call-events

Reading the code in c_eval.c and friends, it looks like "c_call" events are never passed to the trace function, only to the profile function.  The docs are wrong and should be fixed.

The setprofile docs simply point to settrace for details, so the text needs to accommodate both functions' needs.

----------
assignee: docs at python
components: Documentation
messages: 187406
nosy: docs at python, nedbat
priority: low
severity: normal
status: open
title: settrace docs are wrong about "c_call" events
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Apr 20 08:30:49 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Apr 2013 06:30:49 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366439449.19.0.493146773076.issue17468@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I'll create a separate issue for the tp_del -> __del__ question, since that's a language design decision that *does* need Guido's input, but doesn't relate to the broader question of generators, cycles and potential memory leaks.

----------

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

From report at bugs.python.org  Sat Apr 20 08:40:14 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Apr 2013 06:40:14 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366440014.37.0.173162504598.issue17468@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 17800 is anyone wants to weigh in on the tp_del -> __del__ question (I ended up not adding Guido back to that one either, since the original design was based on an assumption that's now demonstrably false, so it makes sense to update the behaviour)

----------

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

From report at bugs.python.org  Sat Apr 20 11:44:53 2013
From: report at bugs.python.org (=?utf-8?b?QW5zc2kgS8Okw6RyacOkaW5lbg==?=)
Date: Sat, 20 Apr 2013 09:44:53 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366451093.72.0.532401371988.issue17468@psf.upfronthosting.co.za>


Anssi K??ri?inen added the comment:

I wonder if it would be better to reword the garbage collection docs to mention that Python can't collect objects if they are part of a reference cycle, and some of the objects in the reference cycle need to run code at gc time. Then mention that such objects include objects with __del__ and also generators if they do have some other blocks than loops in them (for example try or with blocks).

To me it seems this issue could be mitigated somewhat by collecting the objects if there is just one object with finalizer code in the cycle. It should be safe to run the single finalizer, then collect the whole cycle, right?

----------

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

From report at bugs.python.org  Sat Apr 20 13:31:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Apr 2013 11:31:12 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1366451093.72.0.532401371988.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366457468.2512.15.camel@fsol>


Antoine Pitrou added the comment:

> I wonder if it would be better to reword the garbage collection docs
> to mention that Python can't collect objects if they are part of a
> reference cycle, and some of the objects in the reference cycle need
> to run code at gc time. Then mention that such objects include objects
> with __del__ and also generators if they do have some other blocks
> than loops in them (for example try or with blocks).
> 
> To me it seems this issue could be mitigated somewhat by collecting
> the objects if there is just one object with finalizer code in the
> cycle. It should be safe to run the single finalizer, then collect the
> whole cycle, right?

This is tricky because it relies on the fact that the object with
finalizer will be collected before any objects the finalizer relies on.
For a generator, this means it has to be finalized before its frame
object is cleared (otherwise, the finally block can't execute
correctly).

However, the GC doesn't collect those objects directly. It calls
tp_clear on each of them, hoping that tp_clear will break the reference
cycle (and at the same time collect some of the objects in the cycle).
But it's difficult to influence which objects are collected first. 

In gcgen.py's case, the reference cycle is comprised of the MyObj
instance, the generator, and the generator's frame:

  `self` (MyObj) -> generator -> frame -> `self` (MyObj)

So if `self` is collected first, it will collect the generator before
the frame, and the generator's finally block can execute fine.

But if the frame is collected first, it will clear itself and it will be
too late for the generator's finally block to execute.

And if the generator is collected first... well, it can't, as it doesn't
have a tp_clear slot; but if it had, that would clear the frame and make
the finally block uncallable. One might argue that a generator's
tp_clear should call the finally block *before* clearing the frame.

----------

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

From report at bugs.python.org  Sat Apr 20 14:19:32 2013
From: report at bugs.python.org (=?utf-8?b?QW5zc2kgS8Okw6RyacOkaW5lbg==?=)
Date: Sat, 20 Apr 2013 12:19:32 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366460372.15.0.650901872155.issue17468@psf.upfronthosting.co.za>


Anssi K??ri?inen added the comment:

I was imagining that the collection should happen in two passes. First check for tp_dels and call them if safe (single tp_del in cycle allowed). Then free the memory. The first pass is already there, it just doesn't collect callable tp_dels.

If it would be possible to turn an object into inaccessible state after tp_del was called it would be possible to call multiple tp_dels in a cycle. If the del tries to use already deleted object you will get some sort of runtime exception indicating access of already collected object (another option is to allow access to object which has already had __del__ called, but that seems problematic).

Now, both of the above are likely way more complicated to implement than what I imagine. I have very little knowledge of the technical details involved.

If I understand correctly your idea was to do something similar to above, but only for generators.

The current situation is somewhat ugly. First, I can imagine people wishing to do try-finally or something "with self.lock:" in a generator. These will leak in circular reference cases. The generator case is surprising, so surprising that even experienced programmers will do such mistakes (see the django ticket for one example). Second, from application programmers perspective the fact that __del__ wasn't called is usually similar to having a silent failure in their code - for example this can result in leaking database connections or other resources, not to mention possible problems if one has a "with self.lock:" block in a generator.

----------

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

From report at bugs.python.org  Sat Apr 20 15:19:43 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Apr 2013 13:19:43 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366463983.04.0.0778469066172.issue17468@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

In a sense, doing something like "with self.lock" in a generator is already a leak. Even if there wasn't a cycle, collection could be arbitrarily delayed (in partincular on non-CPython VMs). I wonder if making generators context managers which call close() on exit would help.

----------

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

From report at bugs.python.org  Sat Apr 20 15:27:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Apr 2013 13:27:23 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1366463983.04.0.0778469066172.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366464441.2512.25.camel@fsol>


Antoine Pitrou added the comment:

Those are two different issues:
- not calling the finalizer in a timely manner
- never calling the finalizer and creating a memory leak through
gc.garbage

----------

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

From report at bugs.python.org  Sat Apr 20 15:33:36 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Apr 2013 13:33:36 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366464816.14.0.475507864589.issue17468@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I realize, but if people were responsible and closed their generators, the second one would be as much of a problem.

----------

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

From report at bugs.python.org  Sat Apr 20 16:55:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Apr 2013 14:55:34 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366469734.15.0.287079498013.issue17468@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

We can't make ordinary generators innately context managers, as it makes the error too hard to detect when you accidentally leave out @contextmanager when using a generator to write a custom one.

You can already use contextlib.closing to forcibly close them when appropriate, so providing a decorator to implicitly map __exit__ to close wouldn't really save much.

----------

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

From report at bugs.python.org  Sat Apr 20 17:12:20 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Apr 2013 15:12:20 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366470740.88.0.874457532153.issue17468@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

To get back to Anssi's original suggestion... I think Anssi's proposal to allow finalisation to be skipped for try/except/else is legitimate. It's only finally clauses that we try to guarantee will execute, there's no such promise implied for ordinary except clauses.

We *don't care* if the generator *would* have caught the thrown GeneratorExit, we only care about ensuring that finally blocks are executed (including those implied by with statements). So if there aren't any finally clauses or with statements in the block stack, we should be able to just let the generator and frame get collected (as Anssi suggested), without trying to allow execution to complete.

----------

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

From report at bugs.python.org  Sat Apr 20 17:53:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Apr 2013 15:53:29 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1366470740.88.0.874457532153.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366473206.2623.1.camel@fsol>


Antoine Pitrou added the comment:

> We *don't care* if the generator *would* have caught the thrown
> GeneratorExit, we only care about ensuring that finally blocks are
> executed (including those implied by with statements). So if there
> aren't any finally clauses or with statements in the block stack, we
> should be able to just let the generator and frame get collected (as
> Anssi suggested), without trying to allow execution to complete.

That's a good point.

I'm also contemplating that the generator close() could be done from the
*frame*'s tp_clear, which would sidestep the issue of collect order
entirely: the finally block doesn't actually need the generator to
execute, it only needs the frame and its locals.

----------

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

From report at bugs.python.org  Sat Apr 20 19:40:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Apr 2013 17:40:57 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <3ZtLtw4jDkzSB8@mail.python.org>


Roundup Robot added the comment:

New changeset 186f6bb3e46a by R David Murray in branch '3.3':
#17409: Document RLIM_INFINITY and use it to clarify the setrlimit docs.
http://hg.python.org/cpython/rev/186f6bb3e46a

New changeset 9c4db76d073e by R David Murray in branch '2.7':
#17409: Document RLIM_INFINITY and use it to clarify the setrlimit docs.
http://hg.python.org/cpython/rev/9c4db76d073e

New changeset f1d95b0ab66e by R David Murray in branch 'default':
Merge #17409: Document RLIM_INFINITY and use it to clarify the setrlimit docs.
http://hg.python.org/cpython/rev/f1d95b0ab66e

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

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

From report at bugs.python.org  Sat Apr 20 19:41:52 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Apr 2013 17:41:52 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1366479712.45.0.778491849422.issue17409@psf.upfronthosting.co.za>


R. David Murray added the comment:

There being no objection :) I've committed the patch.

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

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

From report at bugs.python.org  Sat Apr 20 19:48:44 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 20 Apr 2013 17:48:44 +0000
Subject: [docs] [issue16942] urllib still doesn't support persistent
	connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1366480124.88.0.742826347127.issue16942@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Agree with Demian Brecht. This issue is being closed in when two issues cover the requirements discussed here.

* issue# 16901 - For Enhancing FileCookieJar
* issue# 9740 - For supporting persistant HTTP 1.1 connections. 

(:-( on me)

----------
nosy: +orsenthil
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work

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

From report at bugs.python.org  Sat Apr 20 20:08:06 2013
From: report at bugs.python.org (Paul Price)
Date: Sat, 20 Apr 2013 18:08:06 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1366481286.5.0.232507392707.issue17409@psf.upfronthosting.co.za>


Paul Price added the comment:

Thanks!

----------

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

From report at bugs.python.org  Sat Apr 20 20:32:39 2013
From: report at bugs.python.org (Alex Leach)
Date: Sat, 20 Apr 2013 18:32:39 +0000
Subject: [docs] [issue4934] tp_del and tp_version_tag undocumented
In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za>
Message-ID: <1366482759.49.0.330968043051.issue4934@psf.upfronthosting.co.za>


Alex Leach added the comment:

I've just ran into tp_version_tag, when running the boost python testsuite and wondered what it was... Since upgrading to GCC 4.8, I've started to get a lot more warnings with Python extensions, e.g.:-

boost/python/opaque_pointer_converter.hpp:122:14: warning: missing initializer for member ?_typeobject::tp_version_tag? [-Wmissing-field-initializers]

In this instance the testsuite was made to compile with the '-Wextra' flag. The fix was pretty simple; add another zero to the opaque_pointer_convert struct.

I have used the following preprocessor macro to test whether or not to do this. Would this be a good way to test for the addition?

#if PY_VERSION_HEX >= 0x02060000
  0,    /* tp_version_tag */
#endif

Cheers,
Alex

----------
nosy: +Alex.Leach

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

From report at bugs.python.org  Sat Apr 20 23:44:09 2013
From: report at bugs.python.org (Takafumi Arakaki)
Date: Sat, 20 Apr 2013 21:44:09 +0000
Subject: [docs] [issue17805] No such class: multiprocessing.pool.AsyncResult
Message-ID: <1366494249.42.0.0654021028594.issue17805@psf.upfronthosting.co.za>


New submission from Takafumi Arakaki:

Document mentions AsyncResult but there is no such class.
http://docs.python.org/2/library/multiprocessing.html#multiprocessing.pool.AsyncResult

You can check it by simply running:
python -c 'from multiprocessing.pool import AsyncResult'

I think it means ApplyResult so I made a patch (attached).

Note that there managers.py also uses name 'AsyncResult':
% hg grep AsyncResult
Doc/library/multiprocessing.rst:83232:.. class:: AsyncResult
Lib/multiprocessing/managers.py:81039:    'apply_async': 'AsyncResult',
Lib/multiprocessing/managers.py:81039:    'map_async': 'AsyncResult',
Lib/multiprocessing/managers.py:81039:    'starmap_async': 'AsyncResult',
Lib/multiprocessing/managers.py:81039:SyncManager.register('AsyncResult', create_method=False)

Probably renaming them would be better?

----------
assignee: docs at python
components: Documentation
files: ApplyResult.patch
keywords: patch
messages: 187466
nosy: docs at python, tkf
priority: normal
severity: normal
status: open
title: No such class: multiprocessing.pool.AsyncResult
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29954/ApplyResult.patch

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

From report at bugs.python.org  Sun Apr 21 00:07:18 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 20 Apr 2013 22:07:18 +0000
Subject: [docs] [issue17805] No such class: multiprocessing.pool.AsyncResult
In-Reply-To: <1366494249.42.0.0654021028594.issue17805@psf.upfronthosting.co.za>
Message-ID: <1366495638.82.0.471439666042.issue17805@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +sbt
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

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

From report at bugs.python.org  Sun Apr 21 02:58:54 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Apr 2013 00:58:54 +0000
Subject: [docs] [issue17670] Improve str.expandtabs() doc
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1366505934.13.0.336457431425.issue17670@psf.upfronthosting.co.za>


Ned Deily added the comment:

Another round based on comments.  I also just noticed that the current doc incorrectly claims that tabs are replaced by *zero* or more spaces.


   Return a copy of the string where all tab characters are replaced by one or
   more spaces, depending on the current column and the given tab size.  Tab
   positions occur every *tabsize* characters (default is 8, giving tab
   positions at columns 0, 8, 16 and so on).  To expand the string, the current
   column is set to zero and the string is examined character by character.  If
   the character is a tab (``\t``), one or more space characters are inserted
   in the result until the current column is equal to the next tab position.
   (The tab character itself is not copied.)  If the character is a newline
   (``\n``) or return (``\r``), it is copied and the current column is reset to
   zero.  Any other character is copied unchanged and the current column is
   incremented by one regardless of how the character is represented when
   printed.

      >>> '01\t012\t0123\t01234'.expandtabs()
      '01      012     0123    01234'
      >>> '01\t012\t0123\t01234'.expandtabs(4)
      '01  012 0123    01234'

----------

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

From report at bugs.python.org  Sun Apr 21 03:04:30 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Apr 2013 01:04:30 +0000
Subject: [docs] [issue17670] Improve str.expandtabs() doc
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1366506270.83.0.507425246839.issue17670@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file29957/issue17670_doc_rev_2.patch

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

From report at bugs.python.org  Sun Apr 21 03:38:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Apr 2013 01:38:59 +0000
Subject: [docs] [issue17468] Generator memory leak
In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za>
Message-ID: <1366508339.16.0.942284107462.issue17468@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've opened issue17807 for an alternative generator cleanup scheme which solves the present issue.

----------

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

From report at bugs.python.org  Sun Apr 21 05:33:02 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sun, 21 Apr 2013 03:33:02 +0000
Subject: [docs] [issue17808] No code example for Event object in threading
	module
In-Reply-To: <1366513053.37.0.736959521672.issue17808@psf.upfronthosting.co.za>
Message-ID: <1366515182.77.0.692754126407.issue17808@psf.upfronthosting.co.za>


Andriy Mysyk added the comment:

See the patch with a code example attached.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +patch
nosy: +docs at python
Added file: http://bugs.python.org/file29963/bug17808.patch

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

From report at bugs.python.org  Sun Apr 21 05:36:20 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sun, 21 Apr 2013 03:36:20 +0000
Subject: [docs] [issue17808] No code example for Event object in threading
	module
In-Reply-To: <1366513053.37.0.736959521672.issue17808@psf.upfronthosting.co.za>
Message-ID: <1366515380.5.0.899163704229.issue17808@psf.upfronthosting.co.za>


Andriy Mysyk added the comment:

Example added to threading.rst


For example, the following code demonstrates a controlled thread termination using an event object.  The event is used to request the termination of several threads.

import threading
import time

stopevent = threading.Event()

class TestThread(threading.Thread):
    def run(self):
        """ main control loop """
        print ("Thread ", self.ident, " starts")
        count = 0
        while not stopevent.is_set():
            count += 1
            stopevent.wait(1.0)
            print ("loop ", count, "in thread ", self.ident)
        print ("Thread ", self.ident, " ends")

for i in range (2):
    testthread = TestThread()
    testthread.start()
time.sleep (3)
stopevent.set()

----------

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

From report at bugs.python.org  Sun Apr 21 14:41:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Apr 2013 12:41:45 +0000
Subject: [docs] [issue17808] No code example for Event object in threading
	module
In-Reply-To: <1366513053.37.0.736959521672.issue17808@psf.upfronthosting.co.za>
Message-ID: <1366548105.28.0.870372031484.issue17808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

An example should generally show something interesting or non-obvious, which isn't the case here. IMHO an Event is simple enough to use that it doesn't need an example; furthermore, the example you are proposing doesn't really showcase anything interesting, functionally :-)

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

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

From report at bugs.python.org  Sun Apr 21 15:42:31 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Apr 2013 13:42:31 +0000
Subject: [docs] [issue17670] Improve str.expandtabs() doc
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1366551750.99.0.463553738037.issue17670@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

LGTM!

----------

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

From report at bugs.python.org  Sun Apr 21 22:07:55 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Apr 2013 20:07:55 +0000
Subject: [docs] [issue17670] Improve str.expandtabs() doc
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <3Zv2623qwVz7Lkk@mail.python.org>


Roundup Robot added the comment:

New changeset 6a02d2af814f by Ned Deily in branch '2.7':
Issue #17670: Provide an example of expandtabs() usage.
http://hg.python.org/cpython/rev/6a02d2af814f

New changeset 5b6ccab52a4d by Ned Deily in branch '3.3':
Issue #17670: Provide an example of expandtabs() usage.
http://hg.python.org/cpython/rev/5b6ccab52a4d

New changeset 1a6cb6d8591a by Ned Deily in branch 'default':
Issue #17670: merge from 3.3
http://hg.python.org/cpython/rev/1a6cb6d8591a

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

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

From report at bugs.python.org  Sun Apr 21 22:08:57 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Apr 2013 20:08:57 +0000
Subject: [docs] [issue17670] Improve str.expandtabs() doc
In-Reply-To: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>
Message-ID: <1366574937.45.0.885119616867.issue17670@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


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

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

From report at bugs.python.org  Sun Apr 21 23:14:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 21 Apr 2013 21:14:51 +0000
Subject: [docs] [issue15575] Tutorial is unclear on multiple imports of a
	module.
In-Reply-To: <1344363062.87.0.467457264308.issue15575@psf.upfronthosting.co.za>
Message-ID: <3Zv3bG1jNSz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset 9df9931fae96 by R David Murray in branch '3.3':
#15575: Clarify tutorial description of when modules are executed.
http://hg.python.org/cpython/rev/9df9931fae96

New changeset dac847938326 by R David Murray in branch 'default':
#15575: Clarify tutorial description of when modules are executed.
http://hg.python.org/cpython/rev/dac847938326

New changeset a1421d28393b by R David Murray in branch '2.7':
#15575: Clarify tutorial description of when modules are executed.
http://hg.python.org/cpython/rev/a1421d28393b

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

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

From report at bugs.python.org  Sun Apr 21 23:17:07 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Apr 2013 21:17:07 +0000
Subject: [docs] [issue15575] Tutorial is unclear on multiple imports of a
	module.
In-Reply-To: <1344363062.87.0.467457264308.issue15575@psf.upfronthosting.co.za>
Message-ID: <1366579026.92.0.890066956701.issue15575@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, James.  I wound up going with a different wording for the "elaboration": since the concept of running a python file as a script is mentioned just a bit earlier, I added a parenthetical that the statements are also executed if the module is run as a script.

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

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

From report at bugs.python.org  Sun Apr 21 23:24:28 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 21 Apr 2013 21:24:28 +0000
Subject: [docs] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
Message-ID: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

The os.writev and os.readv functions are currently documented as:

os.writev(fd, buffers)

    Write the contents of buffers to file descriptor fd, where buffers is an arbitrary sequence of buffers. Returns the total number of bytes written.

os.readv(fd, buffers)

    Read from a file descriptor into a number of writable buffers. buffers is an arbitrary sequence of writable buffers. Returns the total number of bytes read.


This is rather confusing, mostly because it's not clear what can be passed as *buffer* (since buffer objects don't exist in Python 3 anymore), and (as a consequence) how the input will be distributed among the list of buffers.

Reading the code, it seems to me that any object that implements the buffer protocol would be fine, but that still doesn't help much in practice. From the memoryview documentation, I can infer that `bytes` implements the buffer protocol, but is also immutable, so how can something be written into it?

I'd be happy to write a patch to the documentation, but someone would need to explain to me first what kind of buffers are actually acceptable (and I suspect this will be different for readv and writev).

----------
assignee: docs at python
components: Documentation
messages: 187526
nosy: Nikratio, docs at python
priority: normal
severity: normal
status: open
title: Improve os.readv() and os.writev() documentation and docstring
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Apr 21 23:34:51 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 21 Apr 2013 21:34:51 +0000
Subject: [docs] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>
Message-ID: <1366580091.86.0.836671070005.issue17811@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

Here's a first attempt at improvement based on my guess:

os.writev(fd, buffers)

    Write the contents of buffers to file descriptor fd, where buffers is an arbitrary sequence of buffers. In this context, a buffer may be any Python object that provides a Memory View, i.e. that may be used to instantiate a `memoryview` object (e.g. a bytes or bytearray object). writev writes the contents of each memory view to the file descriptor and returns the total number of bytes written.

os.readv(fd, buffers)

    Read from a file descriptor into a number of writable buffers. buffers is an arbitrary sequence of writable buffers. In this context, a buffer may be any Python object that provides a writeable Memory View, i.e. that may be used to instantiate a `memoryview` object whose `read_only` attribute is false (for example, a bytearray object). Writeable memory views have a fixed size, and readv will transfer data into each buffer until it is full and then move on to the next buffer in the sequence to hold the rest of the data. readv returns the total number of bytes read (which may be less than the total capacity of all the buffers).

----------

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

From report at bugs.python.org  Sun Apr 21 23:44:15 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Apr 2013 21:44:15 +0000
Subject: [docs] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>
Message-ID: <1366580655.82.0.810794582071.issue17811@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, the documentation is technically precise.  I'd even managed to forget that buffer objects existed in Python2 :)

As you observed, in Python3 a buffer is something that implements the buffer protocol.  What I would do is link the word 'buffer' to http://docs.python.org/3/c-api/buffer.html.  Perhaps mentioning bytes and bytearray as examples of read-only and writeable buffers would be worthwhile, but they are mentioned in the first paragraph of that section so it may not be necessary.

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

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

From report at bugs.python.org  Sun Apr 21 23:53:22 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 21 Apr 2013 21:53:22 +0000
Subject: [docs] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>
Message-ID: <1366581202.71.0.821284747699.issue17811@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

What section do you mean? bytearray is not mentioned anywhere in
http://docs.python.org/3.4/library/os.html.

I think the problem with just linking to the C API section is that it doesn't help people that are only using pure Python. You can't look at a Python object and tell whether it implements the buffer protocol or not. Therefore, I think it would be important to give at least a reference to memoryview as the Python equivalent of the buffer protocol.

----------

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

From report at bugs.python.org  Mon Apr 22 01:14:46 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 21 Apr 2013 23:14:46 +0000
Subject: [docs] [issue17814] Popen.stdin/stdout/stderr documentation should
	mention	object type
Message-ID: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

The subprocess documentation currently just says that Popen.stdin et all are "file objects", which is linked to the glossary entry. This isn't very helpful, as it doesn't tell whether the streams are bytes or text streams.

Suggested patch:

diff --git a/Doc/library/subprocess.rst b/Doc/library/subprocess.rst
--- a/Doc/library/subprocess.rst
+++ b/Doc/library/subprocess.rst
@@ -677,21 +677,29 @@
 
 .. attribute:: Popen.stdin
 
-   If the *stdin* argument was :data:`PIPE`, this attribute is a :term:`file
-   object` that provides input to the child process.  Otherwise, it is ``None``.
+   If the *stdin* argument was :data:`PIPE`, this attribute is a
+   :class:`io.BufferedWriter` (if the *universal_newlines* argument
+   was False) or :class:`io.TextIOWrapper` (if the
+   *universal_newlines* argument was True) object that provides input
+   to the child process. Otherwise, it is ``None``.
 
 
 .. attribute:: Popen.stdout
 
-   If the *stdout* argument was :data:`PIPE`, this attribute is a :term:`file
-   object` that provides output from the child process.  Otherwise, it is ``None``.
+   If the *stdout* argument was :data:`PIPE`, this attribute is a
+   :class:`io.BufferedReader` (if the *universal_newlines* argument
+   was False) or :class:`io.TextIOWrapper` (if the
+   *universal_newlines* argument was True) object that provides output
+   from the child process. Otherwise, it is ``None``.
 
 
 .. attribute:: Popen.stderr
 
-   If the *stderr* argument was :data:`PIPE`, this attribute is a :term:`file
-   object` that provides error output from the child process.  Otherwise, it is
-   ``None``.
+   If the *stderr* argument was :data:`PIPE`, this attribute is a
+   :class:`io.BufferedReader` (if the *universal_newlines* argument
+   was False) or :class:`io.TextIOWrapper` (if the
+   *universal_newlines* argument was True) object that provides output
+   from the child process. Otherwise, it is ``None``.
 
 
 .. attribute:: Popen.pid

----------
assignee: docs at python
components: Documentation
messages: 187535
nosy: Nikratio, docs at python
priority: normal
severity: normal
status: open
title: Popen.stdin/stdout/stderr documentation should mention object type
type: enhancement

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

From report at bugs.python.org  Mon Apr 22 01:19:34 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 21 Apr 2013 23:19:34 +0000
Subject: [docs] [issue17814] Popen.stdin/stdout/stderr documentation should
	mention	object type
In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za>
Message-ID: <1366586374.52.0.106573366001.issue17814@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think the specific classes are an implementation detail, but mentioning if the file object is a bytes or text stream seems reasonable.
(Also it's better if you attach patches, instead of pasting them in the message.)

----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Apr 22 01:27:50 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 21 Apr 2013 23:27:50 +0000
Subject: [docs] [issue17814] Popen.stdin/stdout/stderr documentation should
	mention	object type
In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za>
Message-ID: <1366586870.18.0.0965102273717.issue17814@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

I think it would also be rather important to know if the streams are buffered or not.

----------

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

From report at bugs.python.org  Mon Apr 22 02:21:50 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Mon, 22 Apr 2013 00:21:50 +0000
Subject: [docs] [issue17808] No code example for Event object in threading
	module
In-Reply-To: <1366513053.37.0.736959521672.issue17808@psf.upfronthosting.co.za>
Message-ID: <1366590109.11.0.274482877795.issue17808@psf.upfronthosting.co.za>


Andriy Mysyk added the comment:

Thank you for the feedback, Antoine. 

The example shows how to essentially kill threads through an event facilitated request, something that I consider to be useful and non-obvious.

I trust that you and others will make the right decision and will keep your feedback in mind for any future patches.

----------

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

From report at bugs.python.org  Mon Apr 22 17:15:08 2013
From: report at bugs.python.org (Theodoros Ikonomou)
Date: Mon, 22 Apr 2013 15:15:08 +0000
Subject: [docs] [issue17815] itertools.combinations example is overly
	complicated
Message-ID: <1366643708.73.0.241168668546.issue17815@psf.upfronthosting.co.za>


New submission from Theodoros Ikonomou:

I find the code presented as equivalent for itertools.combinations is overly complex.
I think we can change it to something easier like the following:

def combinations(iterable, r):
    i, size = 0, len(iterable)
    while i + r - 1 < size:
        subindex = i+1
        while subindex + r - 2 < size:
                yield (iterable[i],) + tuple(iterable[subindex:subindex+r-1])
                subindex += r - 1
        i += 1

----------
assignee: docs at python
components: Documentation
messages: 187566
nosy: Theodoros.Ikonomou, docs at python
priority: normal
severity: normal
status: open
title: itertools.combinations example is overly complicated
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 22 17:30:52 2013
From: report at bugs.python.org (Theodoros Ikonomou)
Date: Mon, 22 Apr 2013 15:30:52 +0000
Subject: [docs] [issue17815] itertools.combinations example is overly
	complicated
In-Reply-To: <1366643708.73.0.241168668546.issue17815@psf.upfronthosting.co.za>
Message-ID: <1366644652.37.0.90053642986.issue17815@psf.upfronthosting.co.za>


Changes by Theodoros Ikonomou <thikonom at gmail.com>:


----------
resolution:  -> postponed
status: open -> closed

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

From report at bugs.python.org  Mon Apr 22 23:10:53 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Apr 2013 21:10:53 +0000
Subject: [docs] [issue17729] advocacy howto improvements
In-Reply-To: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>
Message-ID: <1366665053.86.0.110146478321.issue17729@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

I suggest just dropping this HOWTO.  

It was written to contrast using Python with using only a low-level language such as C.  Today there may still be some people arguing over whether to use a low-level or high-level language, but I think the idea of using high-level languages has certainly won out.  An advocacy howto written today would be completely different.  

Today we're more likely to write an advocacy micro website instead of a howto, so we should just discard this document.

----------

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

From report at bugs.python.org  Mon Apr 22 23:25:36 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 22 Apr 2013 21:25:36 +0000
Subject: [docs] [issue17729] advocacy howto improvements
In-Reply-To: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>
Message-ID: <1366665936.16.0.417630119207.issue17729@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe added the comment:

That's great to hear, especially coming from the author.

----------

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

From report at bugs.python.org  Tue Apr 23 00:29:54 2013
From: report at bugs.python.org (paul j3)
Date: Mon, 22 Apr 2013 22:29:54 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1366669793.78.0.628838614105.issue14191@psf.upfronthosting.co.za>


paul j3 added the comment:

The attached file has a 'parse_intermixed_args()' that has the same API as 'parse_known_args()'.

It follows the two parse step model

    args, remaining_args = optionals.parse_known_args()
    args, extras = positionals.parse_known_args(remaining_args, args)

except that the 'optionals parser' is self with the positional arguments 'deactivated' by setting their nargs to 0.  Similarly the 'positionals parser' is self with the optional arguments set to 'required=false'.

Here it is in a standalone test module illustrating its functionality and limitations.  I could provide a patch, but this form might easier to test in your own code.

When used to run test_argparse.py, it had problems in the cases where the distinction between positionals and optionals is blurred.  

For example, PARSER and REMAINDER are supposed to grab everything that follows regardless of what it looks like.  I choose to fall back on a single 'parse_know_args' call.  Raising an error would the alternative.

Similarly, a mutually exclusive group that includes a positional is difficult to handle.  Again I fall back on the single step.

So the two issues to be discussed are:

- does it provide the desired freedom to mix optionals and positionals?

- in the difficult cases, should it punt, or raise an error?

----------
Added file: http://bugs.python.org/file29982/test_intermixed.py

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

From report at bugs.python.org  Tue Apr 23 08:26:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Apr 2013 06:26:07 +0000
Subject: [docs] [issue17729] advocacy howto improvements
In-Reply-To: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>
Message-ID: <3Zvvms5ZDyz7LmZ@mail.python.org>


Roundup Robot added the comment:

New changeset 2ddfa8dbed1d by Ezio Melotti in branch '2.7':
#17729: remove the outdated Advocacy HOWTO, as suggested by the author.
http://hg.python.org/cpython/rev/2ddfa8dbed1d

New changeset a4804e0d4479 by Ezio Melotti in branch '3.3':
#17729: remove the outdated Advocacy HOWTO, as suggested by the author.
http://hg.python.org/cpython/rev/a4804e0d4479

New changeset f9a58f0203b6 by Ezio Melotti in branch 'default':
#17729: merge with 3.3.
http://hg.python.org/cpython/rev/f9a58f0203b6

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

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

From report at bugs.python.org  Tue Apr 23 08:27:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Apr 2013 06:27:29 +0000
Subject: [docs] [issue17729] advocacy howto improvements
In-Reply-To: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>
Message-ID: <1366698449.76.0.913713705036.issue17729@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Apr 23 08:47:30 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 23 Apr 2013 06:47:30 +0000
Subject: [docs] [issue17729] advocacy howto improvements
In-Reply-To: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>
Message-ID: <1366699650.23.0.430520040359.issue17729@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe added the comment:

the index file also needed changing; see attached

----------
Added file: http://bugs.python.org/file29987/diff

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

From report at bugs.python.org  Tue Apr 23 08:58:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Apr 2013 06:58:19 +0000
Subject: [docs] [issue17729] advocacy howto improvements
In-Reply-To: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>
Message-ID: <3ZvwV25Dhlz7Lq0@mail.python.org>


Roundup Robot added the comment:

New changeset 990c1bd26ef1 by Ezio Melotti in branch '2.7':
#17729: remove the Advocacy HOWTO from the index.
http://hg.python.org/cpython/rev/990c1bd26ef1

New changeset a4d294539f2e by Ezio Melotti in branch '3.3':
#17729: remove the Advocacy HOWTO from the index.
http://hg.python.org/cpython/rev/a4d294539f2e

New changeset ceb1ee4bc214 by Ezio Melotti in branch 'default':
#17729: merge with 3.3.
http://hg.python.org/cpython/rev/ceb1ee4bc214

----------

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

From report at bugs.python.org  Tue Apr 23 08:58:40 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Apr 2013 06:58:40 +0000
Subject: [docs] [issue17729] advocacy howto improvements
In-Reply-To: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>
Message-ID: <1366700320.47.0.577693082659.issue17729@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for noticing that and for the patch!

----------

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

From report at bugs.python.org  Tue Apr 23 10:14:53 2013
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 23 Apr 2013 08:14:53 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1366704893.04.0.909320745004.issue14191@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

Very nice, Paul.

I tested that with some of my applications, and some of my test cases. All of them initially failed, because you have parse_intermixed_args returning parameters like parse_known_args instead of like parse_args. Now I can understand that might be a little confusing in msg166175, but note that the implementation is "like" a call to parse_known_args followed by a call to parse_args... strongly implying that the return should be like parse_args.

After tweaking your implementation in that regard, then I was able to get all the same applications and test cases to pass, although I haven't tried all my applications and all my test cases, as yet.

Your techniques for disabling particular parameters are pretty clever.

I think the difficult cases should raise an error. 

Firstly, parse_intermixed_args is intended to be for functional compatibility with optparse functionality, which doesn't support the difficult cases, therefore use of the difficult cases would require additional restrictions on the allowed order of options on the command line, beyond what optparse supports... this would be an application interface change, and as part of that interface change, should such happen, the flexibility of intermixing optionals and positionals can be restricted.

Secondly, if an understanding of how to define the use parse_intermixed_args with one or more of the difficult cases is reached, replacing an error case with a functional case is possible, but replacing one silent functionality with a different one is a backwards compatibility problem. Throwing an error avoids limiting a future definition of these cases.

The freedom of mixing optionals and positionals that would available in the now deprecated optparse does seem to be restored by this patch.

I look forward to seeing a revised patch, this is a very promising solution to this bug.

----------

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

From report at bugs.python.org  Tue Apr 23 16:41:20 2013
From: report at bugs.python.org (Kyle Simpson)
Date: Tue, 23 Apr 2013 14:41:20 +0000
Subject: [docs] [issue12825] Missing and incorrect link to a command line
	option.
In-Reply-To: <1314089351.88.0.463176028953.issue12825@psf.upfronthosting.co.za>
Message-ID: <1366728080.06.0.616102589185.issue12825@psf.upfronthosting.co.za>


Kyle Simpson added the comment:

I can't reproduce this issue for v2.7.2 anymore, and none of the other versions have this problem.

Is it possible to regenerate the online docs for v2.7.2 before closing this issue?

----------

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

From report at bugs.python.org  Tue Apr 23 18:02:05 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Apr 2013 16:02:05 +0000
Subject: [docs] [issue12825] Missing and incorrect link to a command line
	option.
In-Reply-To: <1314089351.88.0.463176028953.issue12825@psf.upfronthosting.co.za>
Message-ID: <1366732925.24.0.113370623413.issue12825@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks for the update.  The docs under /release/x.y.z are snapshots from that release, so they are not continuously regenerated.  If the current /2 and /2.7 docs are good, this can be closed.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Apr 23 21:07:05 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 23 Apr 2013 19:07:05 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1366744024.4.0.429156761496.issue17386@psf.upfronthosting.co.za>


Zachary Ware added the comment:

After finally finding a way to check the status of the pushd stack, I found a bug in my patch whereby an extra directory is left on the pushd stack at the end of each run.  As such, the version 5 patch changes from using 'goto end' to using 'exit /B !ERRORLEVEL!', along with some other changes related to that change.  Also, because of that change, error handling is made a little easier, so I've changed around some of the messages and the conditions for printing them.  Everything still seems to work.

For anyone testing this patch, I would suggest using the command "prompt $+%PROMPT%" if "$+" is not already part of your prompt.  This will add a '+' character to the beginning of your prompt for every dir on the pushd stack.

----------
Added file: http://bugs.python.org/file29993/win_doc_make.v5.diff

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

From report at bugs.python.org  Tue Apr 23 23:22:13 2013
From: report at bugs.python.org (paul j3)
Date: Tue, 23 Apr 2013 21:22:13 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1366752133.34.0.173016193352.issue14191@psf.upfronthosting.co.za>


paul j3 added the comment:

Yes, http://bugs.python.org/msg166175 does use 'parse_args' in the second call.  But I think things would be more flexible if we had a second function:

    def parse_???(self, args=None, namespace=None):
        args, argv = self.parse_intermixed_args(args, namespace)
        if argv:
            msg = _('unrecognized arguments: %s')
            self.error(msg % ' '.join(argv))
        return args

But then what would a be a good pair of names?

parse??? and parse_intermixed_args
versus
parse_intermixed_args and parse_known_intermixed_args
or
something else?

----------

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

From report at bugs.python.org  Wed Apr 24 03:11:55 2013
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 24 Apr 2013 01:11:55 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1366765915.74.0.990934702291.issue14191@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

Yes, a second function would give more flexibility.

Due to the "approval" in msg166175 to use the name parse_intermixed_args for the functionality described there, it would probably be best to use that name for that functionality.

So then we are left naming your current function something else. parse_known_intermixed_args certainly is descriptive, and fits the naming conventions of the other methods in the class. Quite long, unfortunately... but then I doubt it will get used much. I am using parse_intermixed_args regularly (via my wrapper class), and it is quite long enough.

----------

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

From report at bugs.python.org  Wed Apr 24 11:09:27 2013
From: report at bugs.python.org (Yongzhi Pan)
Date: Wed, 24 Apr 2013 09:09:27 +0000
Subject: [docs] [issue12634] Random Remarks in class documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1366794566.95.0.150137708472.issue12634@psf.upfronthosting.co.za>


Yongzhi Pan added the comment:

It may be worth to noting that when creating property attribute using the property decorator, we may tend to name the method using nouns, like here:
http://docs.python.org/2/library/functions.html#property

This is when I once overided data attribute with method.

----------

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

From report at bugs.python.org  Wed Apr 24 15:45:40 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 24 Apr 2013 13:45:40 +0000
Subject: [docs] [issue17827] Document codecs.encode and codecs.decode
Message-ID: <1366811140.15.0.0983174574305.issue17827@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The codecs module has long offered encode() and decode() convenience functions (since 2004: http://hg.python.org/cpython-fullhistory/rev/8ea2cb1ec598), but they're not documented (except through docstrings). We should fix that.

>From the docstrings:
==========
encode(obj, [encoding[,errors]]) -> object

Encodes obj using the codec registered for encoding. encoding defaults
to the default encoding. errors may be given to set a different error
handling scheme. Default is 'strict' meaning that encoding errors raise
a ValueError. Other possible values are 'ignore', 'replace' and
'xmlcharrefreplace' as well as any other name registered with
codecs.register_error that can handle ValueErrors.
==========
decode(obj, [encoding[,errors]]) -> object

Decodes obj using the codec registered for encoding. encoding defaults
to the default encoding. errors may be given to set a different error
handling scheme. Default is 'strict' meaning that encoding errors raise
a ValueError. Other possible values are 'ignore' and 'replace'
as well as any other name registered with codecs.register_error that is
able to handle ValueErrors.
==========

Note that the difference between the convenience functions in the codecs module and the methods on str, bytes and bytearray is that the latter have additional type checks to limit their usage to text encodings. str.encode expects a str->bytes conversion, while bytes.decode and bytearray.decode both expect the codec to produce a str object. codecs.encode and codecs.decode are both arbitrary object->object conversions, limited only by whatever the chosen codec supports.

----------
assignee: docs at python
components: Documentation
messages: 187700
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Document codecs.encode and codecs.decode
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Apr 24 15:49:34 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Apr 2013 13:49:34 +0000
Subject: [docs] [issue17827] Document codecs.encode and codecs.decode
In-Reply-To: <1366811140.15.0.0983174574305.issue17827@psf.upfronthosting.co.za>
Message-ID: <1366811374.88.0.0969273318299.issue17827@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Wed Apr 24 16:23:57 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 24 Apr 2013 14:23:57 +0000
Subject: [docs] [issue17827] Document codecs.encode and codecs.decode
In-Reply-To: <1366811140.15.0.0983174574305.issue17827@psf.upfronthosting.co.za>
Message-ID: <1366813437.42.0.632311502141.issue17827@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Apr 25 09:51:29 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 25 Apr 2013 07:51:29 +0000
Subject: [docs] [issue17827] Document codecs.encode and codecs.decode
In-Reply-To: <1366811140.15.0.0983174574305.issue17827@psf.upfronthosting.co.za>
Message-ID: <1366876289.81.0.473331717408.issue17827@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Note that in 2.7, these docs should have a ":versionadded: 2.4" marker, while in 3.3 and 3.4, they shouldn't have a version added marker at all.

These functions should also get an entry in the 3.4 What's New, even though they're not actually new.

----------

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

From report at bugs.python.org  Thu Apr 25 10:31:07 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 25 Apr 2013 08:31:07 +0000
Subject: [docs] [issue17841] Remove missing aliases from codecs documentation
In-Reply-To: <1366878629.86.0.715834730144.issue17841@psf.upfronthosting.co.za>
Message-ID: <1366878667.31.0.745156021278.issue17841@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Thu Apr 25 13:37:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Apr 2013 11:37:22 +0000
Subject: [docs] [issue17844] Add link to alternatives for bytes-to-bytes
	codecs
Message-ID: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds link to alternative interfaces for bytes-to-bytes codecs. I.e. base64.b64encode and base64.b64decode for base64_codec.

Patch for 2.7 should mention other functions/modules (due to lack of some of them).

----------
assignee: docs at python
components: Documentation
files: doc_codecs_impl.patch
keywords: patch
messages: 187777
nosy: docs at python, doerwalter, lemburg, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add link to alternatives for bytes-to-bytes codecs
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30013/doc_codecs_impl.patch

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

From report at bugs.python.org  Thu Apr 25 15:54:08 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 25 Apr 2013 13:54:08 +0000
Subject: [docs] [issue17827] Document codecs.encode and codecs.decode
In-Reply-To: <1366811140.15.0.0983174574305.issue17827@psf.upfronthosting.co.za>
Message-ID: <1366898048.7.0.188895165175.issue17827@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

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

From report at bugs.python.org  Fri Apr 26 01:15:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Apr 2013 23:15:25 +0000
Subject: [docs] [issue15693] expose glossary link on hover
In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za>
Message-ID: <1366931725.0.0.165515551545.issue15693@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> georg.brandl
nosy: +georg.brandl
stage:  -> patch review
type: enhancement -> behavior
versions: +Python 3.1, Python 3.4

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

From report at bugs.python.org  Fri Apr 26 01:16:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Apr 2013 23:16:00 +0000
Subject: [docs] [issue15693] expose glossary link on hover
In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za>
Message-ID: <1366931760.43.0.167814543025.issue15693@psf.upfronthosting.co.za>


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


----------
stage: patch review -> needs patch

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

From report at bugs.python.org  Fri Apr 26 13:54:26 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 26 Apr 2013 11:54:26 +0000
Subject: [docs] [issue15693] expose glossary link on hover
In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za>
Message-ID: <1366977266.89.0.367524789184.issue15693@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Apr 26 19:38:50 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 26 Apr 2013 17:38:50 +0000
Subject: [docs] [issue17827] Document codecs.encode and codecs.decode
In-Reply-To: <1366811140.15.0.0983174574305.issue17827@psf.upfronthosting.co.za>
Message-ID: <1366997930.61.0.740335330993.issue17827@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe added the comment:

So, why place them in What's New?

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

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

From report at bugs.python.org  Fri Apr 26 19:51:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 26 Apr 2013 17:51:46 +0000
Subject: [docs] [issue17827] Document codecs.encode and codecs.decode
In-Reply-To: <1366811140.15.0.0983174574305.issue17827@psf.upfronthosting.co.za>
Message-ID: <1366998706.48.0.152610967079.issue17827@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

To advertise them?  It should be explained that they are not new, but that now they are documented and can/should be used.

----------

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

From report at bugs.python.org  Fri Apr 26 21:32:45 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 26 Apr 2013 19:32:45 +0000
Subject: [docs] [issue17827] Document codecs.encode and codecs.decode
In-Reply-To: <1366811140.15.0.0983174574305.issue17827@psf.upfronthosting.co.za>
Message-ID: <1367004765.01.0.837116014934.issue17827@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe added the comment:

I was not aware that such things are placed in What's New. I just looked at such a document for 3.3... makes a lot of sense.

----------

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

From report at bugs.python.org  Sat Apr 27 07:02:23 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sat, 27 Apr 2013 05:02:23 +0000
Subject: [docs] [issue17851] Grammar errors in threading.Lock documentation
In-Reply-To: <1367038556.41.0.738438135734.issue17851@psf.upfronthosting.co.za>
Message-ID: <1367038942.99.0.334903582717.issue17851@psf.upfronthosting.co.za>


Andriy Mysyk added the comment:

submitting a patch for both grammar errors

----------
assignee:  -> docs at python
components: +Documentation
keywords: +patch
nosy: +docs at python
Added file: http://bugs.python.org/file30029/issue17851.patch

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

From report at bugs.python.org  Sat Apr 27 13:47:20 2013
From: report at bugs.python.org (Amit Saha)
Date: Sat, 27 Apr 2013 11:47:20 +0000
Subject: [docs] [issue17854] symmetric difference operation applicable to
	more than	two sets
Message-ID: <1367063240.22.0.643670001227.issue17854@psf.upfronthosting.co.za>


New submission from Amit Saha:

The description of the symmetric difference operation implies that it cannot be applied to more than two sets (http://docs.python.org/3/library/stdtypes.html#set.symmetric_difference).

However, this is certainly possible:

>>> s={1,2}
>>> t={2,3}
>>> u={3,4}
>>> s^t^u
{1, 4}
>>> s.symmetric_difference(t).symmetric_difference(u)
{1, 4}

I am not sure how much of a "semantic" sense that makes, given that symmetric difference is by definition for two sets. (http://en.wikipedia.org/wiki/Symmetric_difference).

So, either the operator should be fixed to allow only two sets or the description be updated.

----------
assignee: docs at python
components: Documentation
messages: 187899
nosy: Amit.Saha, docs at python
priority: normal
severity: normal
status: open
title: symmetric difference operation applicable to more than two sets
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 27 13:49:10 2013
From: report at bugs.python.org (Amit Saha)
Date: Sat, 27 Apr 2013 11:49:10 +0000
Subject: [docs] [issue17854] symmetric difference operation applicable to
	more than	two sets
In-Reply-To: <1367063240.22.0.643670001227.issue17854@psf.upfronthosting.co.za>
Message-ID: <1367063350.66.0.176236021772.issue17854@psf.upfronthosting.co.za>


Amit Saha added the comment:

On some more thought, perhaps the description should be updated. Since s^t^u is effectively (s^t)^u and hence the implementation does not violate the definition.

----------

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

From report at bugs.python.org  Sat Apr 27 14:07:18 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 27 Apr 2013 12:07:18 +0000
Subject: [docs] [issue17854] symmetric difference operation applicable to
	more than	two sets
In-Reply-To: <1367063240.22.0.643670001227.issue17854@psf.upfronthosting.co.za>
Message-ID: <1367064438.66.0.515935211858.issue17854@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Can you suggest a change?  I don't see a problem here; giving multiple operators for the other operations does not imply that they are not treated as left-associative.

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

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

From report at bugs.python.org  Sat Apr 27 14:16:31 2013
From: report at bugs.python.org (Amit Saha)
Date: Sat, 27 Apr 2013 12:16:31 +0000
Subject: [docs] [issue17854] symmetric difference operation applicable to
	more than	two sets
In-Reply-To: <1367063240.22.0.643670001227.issue17854@psf.upfronthosting.co.za>
Message-ID: <1367064991.08.0.69934018018.issue17854@psf.upfronthosting.co.za>


Amit Saha added the comment:

I think the only change I am suggesting is the description of the ^ operator to be something like this:

set ^ other ^ ..
Return a new set with elements from the sets which are not present in more than one set

I do understand that this is not really what the operator and the corresponding operation symmetric_difference() allows semantically. But it does make it consistent with the description of operators such as the | or &, but then their operation allows multiple sets semantically.

Hmm may be it is fine as it is..

----------

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

From report at bugs.python.org  Sat Apr 27 16:22:40 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 27 Apr 2013 14:22:40 +0000
Subject: [docs] [issue17851] Grammar errors in threading.Lock documentation
In-Reply-To: <1367038556.41.0.738438135734.issue17851@psf.upfronthosting.co.za>
Message-ID: <1367072560.67.0.841665051857.issue17851@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

afaik they don't seem to be grammatical errors
"subsequent attempts to acquire it block" - block is the verb, don't see anything wrong
similar example: the crowd blocks me. (present tense)
"which one of the waiting threads proceeds is not defined, and may vary across implementations." - there is only one clause, so no comma needed.
If two separate clauses. are separated a coordinating conjunction (such as and), commas are required afaik.

----------
nosy: +Ramchandra Apte

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

From report at bugs.python.org  Sat Apr 27 16:26:27 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 27 Apr 2013 14:26:27 +0000
Subject: [docs] [issue17851] Grammar errors in threading.Lock documentation
In-Reply-To: <1367038556.41.0.738438135734.issue17851@psf.upfronthosting.co.za>
Message-ID: <1367072787.29.0.385720775733.issue17851@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

oops, should be "the crowd blocks me"

----------

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

From report at bugs.python.org  Sat Apr 27 16:48:39 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sat, 27 Apr 2013 14:48:39 +0000
Subject: [docs] [issue17851] Grammar errors in threading.Lock documentation
In-Reply-To: <1367038556.41.0.738438135734.issue17851@psf.upfronthosting.co.za>
Message-ID: <1367074119.36.0.629399233605.issue17851@psf.upfronthosting.co.za>


Andriy Mysyk added the comment:

Ramachandra, if I understand you correctly, I think what you are saying that both are grammar mistakes and the first one could addressed by adding "s" to block.

----------

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

From report at bugs.python.org  Sat Apr 27 17:21:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 27 Apr 2013 15:21:34 +0000
Subject: [docs] [issue17827] Document codecs.encode and codecs.decode
In-Reply-To: <1366811140.15.0.0983174574305.issue17827@psf.upfronthosting.co.za>
Message-ID: <1367076094.16.0.121430836696.issue17827@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

This is only the second case I'm aware of where a particularly interesting piece of functionality didn't get mentioned in the appropriate What's New doc. For the other case, the zipfile execution support, we just added it in to the 2.6 What's New long after 2.6 had been released. To this day, most people don't know about that capability, which is why I suggest it's worth handling the current case (codecs.encode and codecs.decode) differently and noting their existence in the next What's New doc that people are likely to read :)

----------

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

From report at bugs.python.org  Sat Apr 27 17:27:14 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 27 Apr 2013 15:27:14 +0000
Subject: [docs] [issue17851] Grammar errors in threading.Lock documentation
In-Reply-To: <1367038556.41.0.738438135734.issue17851@psf.upfronthosting.co.za>
Message-ID: <1367076434.77.0.489902548604.issue17851@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I see no problem with both points: "block" is the correct verb form in this context ("attempts" being plural), and the version including comma reads better to me.

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

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

From report at bugs.python.org  Sat Apr 27 18:59:08 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Apr 2013 16:59:08 +0000
Subject: [docs] [issue17841] Remove missing aliases from codecs documentation
In-Reply-To: <1366878629.86.0.715834730144.issue17841@psf.upfronthosting.co.za>
Message-ID: <1367081948.96.0.552673881957.issue17841@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +ezio.melotti

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

From report at bugs.python.org  Sun Apr 28 00:19:39 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 27 Apr 2013 22:19:39 +0000
Subject: [docs] [issue17851] Grammar errors in threading.Lock documentation
In-Reply-To: <1367038556.41.0.738438135734.issue17851@psf.upfronthosting.co.za>
Message-ID: <1367101179.6.0.604982479416.issue17851@psf.upfronthosting.co.za>


R. David Murray added the comment:

I (as a native English speaker, FWIW) agree that the existing text is correct insofar as the reported problems go.  I, however, would remove the comma after 'block'.  I don't know that it is wrong as written, but it reads strangely to my ear.

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

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

From report at bugs.python.org  Sun Apr 28 00:58:05 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sat, 27 Apr 2013 22:58:05 +0000
Subject: [docs] [issue17858] Different documentation for identical methods
Message-ID: <1367103485.02.0.041609834341.issue17858@psf.upfronthosting.co.za>


New submission from Andriy Mysyk:

Use _thread.Lock.acquire() documentation for threading.Lock.acquire().

threading.Lock inherits acquire() method from _thread.Lock.  The two acquire() methods are identical in their functionality yet have different documentation. Documentation for threading.Lock.acquire() creates the impression that the function is more complex or harder to use than it actually is. See http://docs.python.org/devguide/documenting.html#economy-of-expression for guidelines.

----------
assignee: docs at python
components: Documentation
messages: 187945
nosy: amysyk, docs at python
priority: normal
severity: normal
status: open
title: Different documentation for identical methods
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Apr 28 01:02:32 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sat, 27 Apr 2013 23:02:32 +0000
Subject: [docs] [issue17858] Different documentation for identical methods
In-Reply-To: <1367103485.02.0.041609834341.issue17858@psf.upfronthosting.co.za>
Message-ID: <1367103751.97.0.885702917858.issue17858@psf.upfronthosting.co.za>


Andriy Mysyk added the comment:

I am attaching a patch that applies _thread.Lock.acquire() documentation to the functionally identical threading.Lock.acquire().

----------
keywords: +patch
Added file: http://bugs.python.org/file30039/issue17858.patch

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

From report at bugs.python.org  Sun Apr 28 01:35:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 27 Apr 2013 23:35:23 +0000
Subject: [docs] [issue17858] Different documentation for identical methods
In-Reply-To: <1367103485.02.0.041609834341.issue17858@psf.upfronthosting.co.za>
Message-ID: <1367105723.43.0.464240855546.issue17858@psf.upfronthosting.co.za>


R. David Murray added the comment:

For the record, both the _thread docs and the threading docs for acquire were updated in 01d1fd775d16 as part of issue 7316.  Some at least of the differences come from 6ab4128acccc (issue 14823).  That makes it likely that the threading docs are the better of the two.

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

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

From report at bugs.python.org  Sun Apr 28 01:51:44 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sat, 27 Apr 2013 23:51:44 +0000
Subject: [docs] [issue17858] Different documentation for identical methods
In-Reply-To: <1367103485.02.0.041609834341.issue17858@psf.upfronthosting.co.za>
Message-ID: <1367106704.54.0.836621146441.issue17858@psf.upfronthosting.co.za>


Andriy Mysyk added the comment:

Issue 14823 indeed improved threading documentation. However, even with the improvement threading documentation makes acquire() appear to be more complex and harder to use than it actually is.

----------

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

From report at bugs.python.org  Sun Apr 28 08:02:20 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Apr 2013 06:02:20 +0000
Subject: [docs] [issue17858] Different documentation for identical methods
In-Reply-To: <1367103485.02.0.041609834341.issue17858@psf.upfronthosting.co.za>
Message-ID: <1367128939.94.0.667884339966.issue17858@psf.upfronthosting.co.za>


Georg Brandl added the comment:

This patch includes changes from #17851, please remove that (but you can remove the comma after "block").

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

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

From report at bugs.python.org  Sun Apr 28 10:46:05 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 28 Apr 2013 08:46:05 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1367138765.45.0.0698933047656.issue16518@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Apr 28 16:36:39 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 28 Apr 2013 14:36:39 +0000
Subject: [docs] [issue17860] subprocess docs lack info how to use output
	result
Message-ID: <1367159799.26.0.456231833917.issue17860@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://docs.python.org/3/library/subprocess.html

A common confusion is that result from subprocess calls in Python 3 is bytes, not string, and needs to be converted.

The problem is complicated because you need to know the encoding of input/output streams. This should be documented at least.

http://stackoverflow.com/questions/606191/convert-byte-array-to-python-string

----------
assignee: docs at python
components: Documentation
messages: 187982
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: subprocess docs lack info how to use output result
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 28 16:39:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Apr 2013 14:39:13 +0000
Subject: [docs] [issue17860] subprocess docs lack info how to use output
	result
In-Reply-To: <1367159799.26.0.456231833917.issue17860@psf.upfronthosting.co.za>
Message-ID: <1367159953.54.0.759559124436.issue17860@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, haypo
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Sun Apr 28 18:14:45 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 28 Apr 2013 16:14:45 +0000
Subject: [docs] [issue17860] subprocess docs lack info how to use output
	result
In-Reply-To: <1367159799.26.0.456231833917.issue17860@psf.upfronthosting.co.za>
Message-ID: <1367165685.23.0.793844948961.issue17860@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Actually stdin/stdout/stderr are string streams if universal_newline is True

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

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

From report at bugs.python.org  Sun Apr 28 19:02:28 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sun, 28 Apr 2013 17:02:28 +0000
Subject: [docs] [issue17858] Different documentation for identical methods
In-Reply-To: <1367103485.02.0.041609834341.issue17858@psf.upfronthosting.co.za>
Message-ID: <1367168548.49.0.598447445172.issue17858@psf.upfronthosting.co.za>


Andriy Mysyk added the comment:

Apologies.  I did not mean to include 17851 changes. Removed the changes, leaving out the comma after "block" in the attached patch.

----------
Added file: http://bugs.python.org/file30047/issue17858.patch

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

From report at bugs.python.org  Sun Apr 28 21:06:57 2013
From: report at bugs.python.org (Nathan Housel)
Date: Sun, 28 Apr 2013 19:06:57 +0000
Subject: [docs] [issue1722] Undocumented urllib functions
In-Reply-To: <1199298780.6.0.893928826633.issue1722@psf.upfronthosting.co.za>
Message-ID: <1367176017.05.0.151903006677.issue1722@psf.upfronthosting.co.za>


Nathan Housel added the comment:

This has been fixed in trunk, the split* methods have documentation and appear in the module docs. 

See:
>>> help('urllib')

----------
nosy: +plasticgap

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

From report at bugs.python.org  Sun Apr 28 21:19:00 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 28 Apr 2013 19:19:00 +0000
Subject: [docs] [issue17860] subprocess docs lack info how to use output
	result
In-Reply-To: <1367165685.23.0.793844948961.issue17860@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xLQEMP4V6fzExNDCd3OrcxYvf0PfsT2PSjneWZHXkYhvw@mail.gmail.com>


anatoly techtonik added the comment:

>
>
> Actually stdin/stdout/stderr are string streams if universal_newline is
> True
>

I believe that makes the issue even worse. =)

----------

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

From report at bugs.python.org  Sun Apr 28 23:21:26 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 28 Apr 2013 21:21:26 +0000
Subject: [docs] [issue17860] subprocess docs lack info how to use output
	result
In-Reply-To: <1367159799.26.0.456231833917.issue17860@psf.upfronthosting.co.za>
Message-ID: <1367184086.66.0.578348569125.issue17860@psf.upfronthosting.co.za>


R. David Murray added the comment:

Anatoly, do you have a specific suggestion for improved wording?  This *is* documented in the subprocess documentation, in several appropriate places, including the fact that the appropriate encoding to use may need to be determined at the application level.

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

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

From report at bugs.python.org  Mon Apr 29 10:15:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Apr 2013 08:15:18 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
	not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1367223318.84.0.993066751809.issue17866@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I don't remember how it went exactly, but there were a few similar methods (assertItemsEqual, assertSameElements, assertCountEqual).  In 3.x we eventually decide to remove the first 2 because it wasn't clear what they were doing, and only assertCountEqual survived.  In 2.7 this wasn't possible, so assertItemsEqual survived.
assertDictContainsSubset is another method that was in 2.7 but is not in 3.x anymore.
Do you think the docs for 2.x should mention this?

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

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

From report at bugs.python.org  Mon Apr 29 10:33:18 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 29 Apr 2013 08:33:18 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
	not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1367224398.14.0.647536617271.issue17866@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I do think this should be mentioned in the 2.7 docs, assertDictContainsSubset is mentioned as "deprecated since 3.2" in the 2.7 docs.  The only problem with that is that there doesn't seem to be a "versionremoved" directive in sphinx, the best alternative seems to be deprecated-removed.

I'm not to happy about the removal though, assertCountEqual is not in 2.7 which means it is unnecessarily hard to port tests from 2.7 to 3.3. I also don't quite understand the difference between assertCountEqual and assetItemsEqual, the documentation for the two (in the 3.3 and 2.7 docs) appears to indicate they have the same behavior (both assert that two sequence have the same contents when the order of items is ignored).

----------

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

From report at bugs.python.org  Mon Apr 29 10:37:01 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 29 Apr 2013 08:37:01 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
	not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1367224621.96.0.784544656592.issue17866@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Apr 29 10:40:28 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Apr 2013 08:40:28 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
	not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1367224828.8.0.147766026805.issue17866@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think they might actually be the same (i.e. the name changed but not the implementation).  See #10242.
If this is true the new name could be mentioned in 2.7.

----------

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

From report at bugs.python.org  Mon Apr 29 10:59:55 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 29 Apr 2013 08:59:55 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
	not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1367225995.5.0.460725981453.issue17866@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

You're right, according to #10242 the method was renamed in 3.2.

Something like the attached patch?


I'm somewhat flabbergasted that #10242 came to the conclusion that it would be a good idea to rename this method, given the folks that contributed the discussion.   It not that the new name is very good, I've seen it in the 3.3 docs and didn't notice that it was relevant for what I was trying to do until you mentioned the method and I actually read the description. When I first saw the method I thought it was related to list.count.

----------
Added file: http://bugs.python.org/file30058/issue17866.txt

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

From report at bugs.python.org  Mon Apr 29 11:08:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Apr 2013 09:08:55 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
	not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1367226535.08.0.142350592062.issue17866@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Apparently assertItemsEqual was added to 2.7 and 3.2 and, after the release of 2.7 but before the release of 3.2, assertItemsEqual has been renamed assertCountEqual (596239da3db7) and initially the assertItemsEqual was available too.  However, since the method was new in 3.2 the old alias got removed shortly after (bdd57841f5e2).  Eventually 3.2 was released with only assertCountEqual.

----------
keywords: +patch
Added file: http://bugs.python.org/file30059/issue17866.diff

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

From report at bugs.python.org  Mon Apr 29 11:19:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Apr 2013 09:19:46 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
	not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1367227186.38.0.0635334796593.issue17866@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Looks like we wrote a similar patch at the same time :)
We don't usually use versionchanged in the 2.x docs for things that changed in 3.x.  Using "named" instead of "renamed" is better, since in 3.x the name was assertCountEqual since the beginning, however saying "In Python 3.2" might be confusing (people might think that it's different for 3.3+).  I suggest to replace it with simply "Python 3", or perhaps "Python 3.2+".

----------
Added file: http://bugs.python.org/file30060/issue17866-2.diff

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

From report at bugs.python.org  Mon Apr 29 11:22:46 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 29 Apr 2013 09:22:46 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
	not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1367227366.6.0.0272391935106.issue17866@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Your patch looks good.

----------

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

From report at bugs.python.org  Mon Apr 29 11:26:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 29 Apr 2013 09:26:13 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
	not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <3ZzgTw3M7tz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset d9921cb6e3cd by Ezio Melotti in branch '2.7':
#17866: mention that in Python 3, assertItemsEqual is named assertCountEqual.
http://hg.python.org/cpython/rev/d9921cb6e3cd

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

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

From report at bugs.python.org  Mon Apr 29 11:27:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Apr 2013 09:27:15 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
	not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1367227635.21.0.247365552848.issue17866@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Applied.

----------
assignee: docs at python -> ezio.melotti
components:  -Library (Lib)
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7 -Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Apr 29 12:02:11 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 29 Apr 2013 10:02:11 +0000
Subject: [docs] [issue17851] Grammar errors in threading.Lock documentation
In-Reply-To: <1367074119.36.0.629399233605.issue17851@psf.upfronthosting.co.za>
Message-ID: <CAExgZOgfGVkMQsY4h90pP1-oJz4vqWv59U9aBUM1C_uziOiE6g@mail.gmail.com>


Ramchandra Apte added the comment:

I'm saying that they aren't valid grammar mistakes (there is no grammar
mistake). I agree with Georg Brandl's comment.

On 27 April 2013 20:18, Andriy Mysyk <report at bugs.python.org> wrote:

>
> Andriy Mysyk added the comment:
>
> Ramachandra, if I understand you correctly, I think what you are saying
> that both are grammar mistakes and the first one could addressed by adding
> "s" to block.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue17851>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Apr 29 19:32:03 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Apr 2013 17:32:03 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1367256723.87.0.92447101921.issue16518@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Here's a patch that adds "bytes-like object" to the glossary, links to the buffer protocol docs[0] and provides bytes and bytearray as examples.

[0]: http://docs.python.org/dev/c-api/buffer.html#buffer-protocol

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 2.7 -Python 3.2
Added file: http://bugs.python.org/file30065/issue16518.diff

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

From report at bugs.python.org  Mon Apr 29 22:00:47 2013
From: report at bugs.python.org (Dmi Baranov)
Date: Mon, 29 Apr 2013 20:00:47 +0000
Subject: [docs] [issue17714] str.encode('base64') add trailing new line
	character. It	is not documented.
In-Reply-To: <1365867569.46.0.547710519327.issue17714@psf.upfronthosting.co.za>
Message-ID: <1367265647.18.0.568669418501.issue17714@psf.upfronthosting.co.za>


Dmi Baranov added the comment:

Added a patch

----------
keywords: +patch
nosy: +dmi.baranov
Added file: http://bugs.python.org/file30069/issue17714.patch

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

From report at bugs.python.org  Mon Apr 29 23:06:32 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Mon, 29 Apr 2013 21:06:32 +0000
Subject: [docs] [issue17871] Wrong signature of TextTestRunner's init
	function
Message-ID: <1367269592.44.0.115946830805.issue17871@psf.upfronthosting.co.za>


New submission from Piotr Dobrogost:

TextTestRunner's init as of 3.3.1 has (http://hg.python.org/cpython/file/d9893d13c628/Lib/unittest/runner.py#l128) the following parameters:
stream, descriptions, verbosity, failfast, buffer, resultclass, warnings whereas docs (http://docs.python.org/3.3/library/unittest.html?highlight=unittest#loading-and-running-tests) show only the following parameters:
stream, descriptions, verbosity, runnerclass, warnings

'Failfast' and 'buffer' parameters are missing in the docs and there's 'runnerclass' parameter instead of 'resultclass' parameter.

----------
assignee: docs at python
components: Documentation
messages: 188104
nosy: docs at python, ezio.melotti, michael.foord, piotr.dobrogost
priority: normal
severity: normal
status: open
title: Wrong signature of TextTestRunner's init function
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr 29 23:16:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Apr 2013 21:16:38 +0000
Subject: [docs] [issue17871] Wrong signature of TextTestRunner's init
	function
In-Reply-To: <1367269592.44.0.115946830805.issue17871@psf.upfronthosting.co.za>
Message-ID: <1367270198.24.0.59607137931.issue17871@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Mon Apr 29 23:41:32 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 29 Apr 2013 21:41:32 +0000
Subject: [docs] [issue17700] Update Curses HOWTO for 3.4
In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za>
Message-ID: <1367271690.35.0.571218952945.issue17700@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Updated version of the patch, applying many changes suggested by merwok:

* use ~curses.funcname notation for links.
* use 3-hyphen em-dash
* minor fixes to various examples
* rewrap long paragraphs (this makes the diff larger -- sorry!)

----------
Added file: http://bugs.python.org/file30071/update-curses-howto.txt

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

From report at bugs.python.org  Mon Apr 29 23:47:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Apr 2013 21:47:08 +0000
Subject: [docs] [issue17700] Update Curses HOWTO for 3.4
In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za>
Message-ID: <1367272028.41.0.512814814773.issue17700@psf.upfronthosting.co.za>


STINNER Victor added the comment:

window.get_wch() and curses.unget_wch(ch) should be used instead of window.getch() and curses.ungetch(ch), when available. They work much better with non-ASCII characters.

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Apr 30 01:46:07 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 29 Apr 2013 23:46:07 +0000
Subject: [docs] [issue17700] Update Curses HOWTO for 3.4
In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za>
Message-ID: <1367279167.41.0.336500782213.issue17700@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Victor: I would like to add a section about using Unicode characters with curses, but found little material about doing that in either Python or the underlying C API.  Do you have any suggested references or example code that I could look at?

(It's probably better to commit the current patch if it's suitable, and commit the wide-character changes in a separate patch once they're ready.)

----------

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

From report at bugs.python.org  Tue Apr 30 08:06:25 2013
From: report at bugs.python.org (Xavier Ordoquy)
Date: Tue, 30 Apr 2013 06:06:25 +0000
Subject: [docs] [issue17876] Doc issue with threading.Event
Message-ID: <1367301985.85.0.51301072011.issue17876@psf.upfronthosting.co.za>


New submission from Xavier Ordoquy:

The documentation isn't correct for the threading.Event class under python 3.2.

In the threading doc page (http://docs.python.org/3.2/library/threading.html), Event is said to be at the same time a function and a class.

This is misleading and lead to a regression for celery under python 3.2 (https://github.com/celery/celery/pull/1333).

Could the doc be updated under python 3.2 so that threading.Event leads to the function and threading._Event leads to the class ?

Regards,
Xavier.

----------
assignee: docs at python
components: Documentation
messages: 188127
nosy: docs at python, xordoquy
priority: normal
severity: normal
status: open
title: Doc issue with threading.Event
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr 30 09:21:49 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Apr 2013 07:21:49 +0000
Subject: [docs] [issue17876] Doc issue with threading.Event
In-Reply-To: <1367301985.85.0.51301072011.issue17876@psf.upfronthosting.co.za>
Message-ID: <1367306509.54.0.869085437593.issue17876@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch

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

From report at bugs.python.org  Tue Apr 30 09:38:49 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Apr 2013 07:38:49 +0000
Subject: [docs] [issue17714] str.encode('base64') add trailing new line
	character. It	is not documented.
In-Reply-To: <1365867569.46.0.547710519327.issue17714@psf.upfronthosting.co.za>
Message-ID: <1367307529.02.0.285736916691.issue17714@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Apr 30 16:16:24 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Apr 2013 14:16:24 +0000
Subject: [docs] [issue17876] Doc issue with threading.Event
In-Reply-To: <1367301985.85.0.51301072011.issue17876@psf.upfronthosting.co.za>
Message-ID: <1367331384.4.0.0729897381841.issue17876@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm sorry, the 3.2 docs are no longer updated.  The effective way to become aware of these changes between versions is via the 'version changed' tags in the new documentation.  You will note that these tags exist in the 3.3 docs.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Apr 30 19:06:31 2013
From: report at bugs.python.org (Nathan Housel)
Date: Tue, 30 Apr 2013 17:06:31 +0000
Subject: [docs] [issue15088] PyGen_NeedsFinalizing is public,
	but undocumented
In-Reply-To: <1339906861.99.0.42415214654.issue15088@psf.upfronthosting.co.za>
Message-ID: <1367341591.81.0.316533652946.issue15088@psf.upfronthosting.co.za>


Nathan Housel added the comment:

Please correct me if I'm wrong, but I think PyGen_NeedsFinalizing should not be an API function because it is only used, nor _PyGen_FetchStopIterationValue. In the attached patch I've removed PyGen_NeedsFinalizing and _PyGen_FetchStopIterationValue fom the public API.

----------
keywords: +patch
nosy: +plasticgap
Added file: http://bugs.python.org/file30079/Issue15088.diff

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

From report at bugs.python.org  Tue Apr 30 19:20:23 2013
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 30 Apr 2013 17:20:23 +0000
Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1367342423.26.0.144490142.issue15984@psf.upfronthosting.co.za>


Brian Curtin added the comment:

In the "Otherwise it coerces" sentence, obj should probably be ``obj``.

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

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

From report at bugs.python.org  Tue Apr 30 19:23:14 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 30 Apr 2013 17:23:14 +0000
Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1367342594.99.0.315536952479.issue15984@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Apr 30 21:03:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Apr 2013 19:03:40 +0000
Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1367348620.45.0.983480324527.issue15984@psf.upfronthosting.co.za>


R. David Murray added the comment:

So (speaking from C API ignorance here), if you pass it a unicode subclass you get back an instance of the base unicode type?  Is that what coercion means here?

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

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

From report at bugs.python.org  Tue Apr 30 21:30:48 2013
From: report at bugs.python.org (Kyle Roberts)
Date: Tue, 30 Apr 2013 19:30:48 +0000
Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1367350247.95.0.96827371341.issue15984@psf.upfronthosting.co.za>


Kyle Roberts added the comment:

Thanks for the quick responses.

Brian: Nice catch, I'll add the ``obj`` shortly.

R. David: You're correct, that's exactly what happens, and what coercion means here. The language is almost the same as PyUnicode_FromEncodedObject()'s documentation, but if it's unclear I don't mind changing both. The code's comment offers another way of describing the "type modification":

/* For a Unicode subtype that's not a Unicode object, return a true Unicode object with the same data. */

----------

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

From report at bugs.python.org  Tue Apr 30 21:43:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 30 Apr 2013 19:43:48 +0000
Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject()
	and	PyUnicode_FromEncodedObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1367351028.28.0.763755270189.issue15984@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps we should correct a documentation for PyUnicode_FromEncodedObject() too. Coercing doesn't look as right term for decoding.

----------
title: Wrong documentation for PyUnicode_FromObject() -> Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject()

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

From report at bugs.python.org  Tue Apr 30 22:35:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 30 Apr 2013 20:35:17 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <3b0ZHT07csz7Lk4@mail.python.org>


Roundup Robot added the comment:

New changeset 474f28bf67b3 by Ezio Melotti in branch '3.3':
#16518: add "bytes-like object" to the glossary.
http://hg.python.org/cpython/rev/474f28bf67b3

New changeset 747cede24367 by Ezio Melotti in branch 'default':
#16518: merge with 3.3.
http://hg.python.org/cpython/rev/747cede24367

New changeset 1b92a0112f5d by Ezio Melotti in branch '2.7':
#16518: add "bytes-like object" to the glossary.
http://hg.python.org/cpython/rev/1b92a0112f5d

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

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

From Bernard.Lang at datcha.net  Sat Apr 20 10:12:03 2013
From: Bernard.Lang at datcha.net (Bernard Lang)
Date: Sat, 20 Apr 2013 08:12:03 -0000
Subject: [docs] Doc bug : os.readlink(path)
Message-ID: <20130420080623.GA6033@datcha.net.datcha.net>


Hi,

I think there is a bug in the documentation regarding     os.readlink(path)
on page
http://docs.python.org/2/library/os.html

The current description is :


Return a string representing the path to which the symbolic link points. The result may be either an absolute or relative pathname; if it is relative, it may be converted to an absolute pathname using os.path.join(os.path.dirname(path), result).
Changed in version 2.6: If the path is a Unicode object the result will also be a Unicode object.
Availability: Unix.


This did not make sense to me since os.path.dirname(path) is an
absolute path name iff path itself is one.

I think the correct description is :


Return a string representing the path to which the symbolic link points. This result may be either an absolute or relative pathname; if it is relative, it is relative to the directory os.path.dirname(path), which may not be the current working directory os.getcwd(); it may be converted to a path usable from the current working directory using os.path.join(os.path.dirname(path), os.readlink(path)). This may be an absolute or relative pathname depending on whether path is.
Changed in version 2.6: If the path is a Unicode object the result will also be a Unicode object.
Availability: Unix.


I am not subscribed to this list. Can you please send any comment or
reply directly to me.

Bien cordialement

Bernard Lang


PS  I have been wondering why you write 'Return' rather than 'Returns'
at the beginning of the description.  I am not sure how that is to be
understood grammatically (imperative ?).

-- 
SVP  Ne plus m'?crire ? Bernard.Lang at inria.fr mais ? l'adresse ci-dessous

Please  No longer write to Bernard.Lang at inria.fr but to the address below

  Bernard.Lang at datcha.net       ,_  /\o    \o/    gsm  +33 6 6206 1693
  http://www.datcha.net/       ^^^^^^^^^^^^^^^^^  tel  +33 1 3056 1693
        Je n'exprime que mon opinion - I express only my opinion
                 CAGED BEHIND WINDOWS or FREE WITH LINUX

From bbayles at gmail.com  Tue Apr 23 04:01:15 2013
From: bbayles at gmail.com (Bo Bayles)
Date: Tue, 23 Apr 2013 02:01:15 -0000
Subject: [docs] Typo in distutils document
Message-ID: <CALqAb4xVtwZ8Xxjgbj3HH4eeQ2foFRTKRdrmEhXMZF9OC5R=xg@mail.gmail.com>

Hello,

I noticed a typo in the distutils module's documentation, e.g. at:
http://docs.python.org/3/library/distutils.html

It currently reads:
" If also contains instructions for end-users..."

It should read:
"It also contains instructions for end-users..."

Best regards,
-Bo

From Adam.Talbot at radisys.com  Fri Apr 26 21:52:59 2013
From: Adam.Talbot at radisys.com (Adam Talbot)
Date: Fri, 26 Apr 2013 19:52:59 -0000
Subject: [docs] Document Suggestion
Message-ID: <00771BDE55D8D9468615916089B75BE809D1D9@BLUPRD0811MB400.namprd08.prod.outlook.com>

Hi,
I have a suggestion for an improvement in the documents.
In the threading module there are instructions to, "see the documentation string of the _threading_local module".
I am not familiar with documentation strings in modules and I don't know how to locate the "_threading_local" module, let alone the documentation string within it.  Some brief instructions on how to accomplish this would be nice.

<http://docs.python.org/2/library/threading.html#threading.local<http://docs.python.org/2/library/threading.html%23threading.local>>

Also, thanks for everything.  I am not a big fan of Python but the community support and documentation has been quite pleasant to work with.

Thanks,
Adam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130426/26d038af/attachment-0001.html>

From charlsbrick at gmail.com  Thu Apr 18 02:06:00 2013
From: charlsbrick at gmail.com (Charls Brick)
Date: Thu, 18 Apr 2013 00:06:00 -0000
Subject: [docs] bugs
Message-ID: <CAARBt-v5PW7ojD-u_gS+_Joq_o+0+izW8gaj_MeXe+rUWqGquA@mail.gmail.com>

OK, I have been trying to make a new python document on my desktop, but it
never works and I have re-installed the program over and over again but it
still won't work with me. I can make a new document on my other computers,
but this one is the only issue. Thanks!

-Charles Brick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130418/694b52cc/attachment.html>

From bobsavage at mac.com  Thu Apr 18 14:30:00 2013
From: bobsavage at mac.com (Bob Savage)
Date: Thu, 18 Apr 2013 12:30:00 -0000
Subject: [docs] Outdated macvim link in Python docs
References: <516E9908.5070904@synth.no>
Message-ID: <6BA579AD-CBD9-4695-B2E3-3D6F4085A61F@mac.com>

To Python Docs Team,

Attached is a suggestion to replace the existing link for a MacOS Vim editor to one for an active project. The change would require replacing the text:
Gvim (http://macvim.org)
with:
macvim (http://code.google.com/p/macvim/)

Best wishes!

Bob Savage


Begin forwarded message:

> From: Henrik Brautaset Aronsen <henrik at synth.no>
> Subject: Outdated macvim link in Python docs
> Date: April 17, 2013 8:43:52 AM EDT
> To: bobsavage at mac.com
> 
> Hi Bob.
> 
> I see that you link to macvim.org on http://docs.python.org/3.4/using/mac.html. That version is seriously outdated, and hasn't been updated since 2009.
> 
> Check out http://code.google.com/p/macvim/ instead, it is updated and is in active development.
> 
> Cheers,
> Henrik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130418/286710b6/attachment-0001.html>

From bernoth at dresearch-fe.de  Thu Apr 25 10:06:33 2013
From: bernoth at dresearch-fe.de (Erik Bernoth)
Date: Thu, 25 Apr 2013 08:06:33 -0000
Subject: [docs] Preparing a Change for Requirementshandling in Python
	projects
In-Reply-To: <CAB4XWXzMK8k=KraPpMx=_4US9cMqNcxRq=6P938FHnbF1dOKhg@mail.gmail.com>
References: <CAJqWTsLq9URMOwusG2KT2YMw-PEr9Kd9jVcKrBe=VUjS8yj7qQ@mail.gmail.com>
 <CAB4XWXzMK8k=KraPpMx=_4US9cMqNcxRq=6P938FHnbF1dOKhg@mail.gmail.com>
Message-ID: <CAJqWTsLVafe+Vs-RG-C8VqTyaCr1__mkrJP-GRyODB0E8SFvdg@mail.gmail.com>

2013/4/13 Sandro Tosi <sandro.tosi at gmail.com>

> Hello Erik,
> thanks for your interest in making the Python documentation even better.
>

Hi Sandro,


> Sorry for this quite late reply, I hope this hadn't reduced your
> enthusiasm in the Python project.
>

Not at all. I spend the time learning more about the packaging ecosystem
(chaos) we have right now.

no worries, there's a lot of developers writing documentation in
> English even if it's not their mother tongue.
>

Will mother-tongue speakers review it, or would my version be the final
version?

I think the idea might be good, but I encourage you to write a patch
> (even as a draft) to the documentation and post it as a bug in the
> Python issues tracking system at: bugs.python.org ; at that point,
> people will start discussing your proposal, and you'd get a a wider
> audience than this list.
>

I continued to talk with the distutils-sig list, which seems to be the best
approach. They also plan to do things about the documentation and I try to
add my ideas to their work, then everything should be fine.

Thanks for your help!

-- 
Mit freundlichen Gr??en / Kind Regards
Erik Bernoth
Student Assistant, Bachelor of Engineering, Telematics

DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515932 - 220
Fax: +49 (30) 515932 - 77
mailto:bernoth at dresearch-fe.de <mailadresse at dresearch-fe.de>
http://www.dresearch-fe.de
Amtsgericht Berlin Charlottenburg, HRB: 130120 B
Ust.-IDNr. DE273952058; WEEE Reg.-Nr. DE 60230558
Gesch?ftsf?hrer: Dr. Michael Weber, Werner M?gle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130425/08ccedf1/attachment-0001.html>

From pand at tietgen.dk  Tue Apr 23 12:48:08 2013
From: pand at tietgen.dk (Per Andersen)
Date: Tue, 23 Apr 2013 10:48:08 -0000
Subject: [docs] error in python introduction
Message-ID: <C3E1CB1A10AD6E45A877B6E83691C2C21874942D@mbx02.tietgen.dk>

Hi there

Dont know if this is the right email to send this to.

I'm just starting learning python and looking through the introduction. http://docs.python.org/2/tutorial/introduction.html

I've noticed an error in what is written there. The print example in the end of the page does not have the correct syntax for version 3.3.1

>>> # Fibonacci series:
... # the sum of two elements defines the next
... a, b = 0, 1
>>> while b < 10:
...     print b
...     a, b = b, a+b


Should be


>>> # Fibonacci series:

... # the sum of two elements defines the next

... a, b = 0, 1

>>> while b < 10:

...     print (b)

...     a, b = b, a+b

Print seems to need a () now

Kind regards
Per Andersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130423/699f8dd1/attachment-0001.html>

From r_kinstler at comcast.net  Tue Apr 23 23:02:34 2013
From: r_kinstler at comcast.net (Robert Kinstler)
Date: Tue, 23 Apr 2013 21:02:34 -0000
Subject: [docs] Tiny doc bug
Message-ID: <5176F645.6000803@comcast.net>

In http://docs.python.org/2/library/re.html I think that the last
regular expression in the paragraph quoted below is missing the '<' and
'>'.  It is supposed to be the non-greedy version of "<.*>", right?  (I
am writing my string literals as they are written in "C" source code.)

The '*', '+', and '?' qualifiers are all /greedy/; they match as much
text as possible. Sometimes this behaviour isn't desired; if the RE <.*>
is matched against '<H1>title</H1>', it will match the entire string,
and not just '<H1>'. Adding '?' after the qualifier makes it perform the
match in /non-greedy/ or /minimal/ fashion; as /few/ characters as
possible will be matched. Using .*? in the previous expression will
match only '<H1>'.

Thanks for reading this.

Robert Kinstler

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

From quentin at box.com  Sat Apr 20 01:00:06 2013
From: quentin at box.com (Quentin de Metz)
Date: Fri, 19 Apr 2013 23:00:06 -0000
Subject: [docs] Python 2.7 Profile module documentation
Message-ID: <CAPQdHqupBoZ1aRQYECinTyoezL-UXtn93dWbVkjiEe1S5R+TRQ@mail.gmail.com>

Hello to the Python documentation team,

I work in a software company in the Silicon Valley and we are using Python
(2.7) for one of our upcoming releases.

I'm working on performance testing for this software and have been fiddling
quite a bit with the profiling modules available. I believe there is a lack
of information in the official documentation and would like to report it.

I've been trying to profile our software to see where CPU bottlenecks are.
Despite reports of being able to use cProfile to measure CPU time, all of
the documentation I found on the internet seems to portray cProfile
measuring "wall time" - that is, time elapsed during a function, regardless
of actual CPU usage. (Have a look at the UNIX "time" command if you don't
know what I'm talking about.)

For example, take the following snippet:

import cProfile
import time

def sleep():
    time.sleep(2)

def count():
    for i in xrange(100000000):
        pass

def test():
    sleep()
    count()

*profiler = cProfile.Profile()*
profiler.run('test()')
profiler.print_stats

Let's take a look at the functions defined here.
Obviously the sleep function uses no CPU time, however the count function
should generate some CPU usage.

The output I get from this script is the following:

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    2.045    2.045    2.045    2.045 <stdin>:1(count)
        1    0.000    0.000    2.001    2.001 <stdin>:1(sleep)
*        1    0.000    0.000    4.046    4.046 <stdin>:1(test)*
        1    0.000    0.000    4.046    4.046 <string>:1(<module>)
        1    0.000    0.000    0.000    0.000 {method 'disable' of
'_lsprof.Profiler' objects}
        1    2.001    2.001    2.001    2.001 {time.sleep}

And reading the *line* corresponding to the "test" function does not show
the results I expect (I expect approx 2.045).
Once again I have scoured the Internet and found no clues as to how to
leverage cProfile to measure only CPU time.

I wrote to Mike Mueller from Python Academy who was able to provide me with
some useful information on how to obtain what I was looking for.

*On a UNIX system,* writing
profiler = cProfile.Profile(time.clock)
achieves the desired effet:

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    1.988    1.988    1.988    1.988 <stdin>:1(count)
        1    0.000    0.000    0.000    0.000 <stdin>:1(sleep)
*        1    0.000    0.000    1.989    1.989 <stdin>:1(test)*
        1    0.000    0.000    1.989    1.989 <string>:1(<module>)
        1    0.000    0.000    0.000    0.000 {method 'disable' of
'_lsprof.Profiler' objects}
        1    0.000    0.000    0.000    0.000 {time.sleep}


*On Windows*, one must first define:
def win_clock():     return os.times()[0]
and write
profiler = cProfile.Profile(win_clock)

which also achieves the desired effect:
ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    1    1.404    1.404    1.404    1.404 <stdin>:1(count)
    1    0.000    0.000    0.000    0.000 <stdin>:1(sleep)
*    1    0.000    0.000    1.404    1.404 <stdin>:1(test)*
    1    0.000    0.000    1.404    1.404 <string>:1(<module>)
    1    0.000    0.000    0.000    0.000 {method 'disable' of
'_lsprof.Profiler' objects}
    1    0.000    0.000    0.000    0.000 {time.sleep}


I sincerely believe some of this information belongs in the official Python
documentation. Without Mike Mueller I think I would never have found it. I
hope my description has been thorough and that you will have sufficient
information to complete the existing documentation which has never
disappointed me.

Thank you very much for your consideration,
Hoping to hear from you soon,

Quentin de Metz
Box, Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130419/728e16a1/attachment-0001.html>

From r_kinstler at comcast.net  Tue Apr 23 23:06:10 2013
From: r_kinstler at comcast.net (Robert Kinstler)
Date: Tue, 23 Apr 2013 21:06:10 -0000
Subject: [docs] Tiny doc bug
In-Reply-To: <5176F645.6000803@comcast.net>
References: <5176F645.6000803@comcast.net>
Message-ID: <5176F776.3060100@comcast.net>

Ignore that bug report.  I did not pay attention to the phrase, "in the
previous expression".  Of course, presuming that I am a normal reader,
maybe rephrasing that sentence will prevent others from being confused
as well.
Thanks for your documentation work.  I'm standing on your shoulders when
I do my job.

Robert

On 4/23/2013 4:59 PM, Robert Kinstler wrote:
> In http://docs.python.org/2/library/re.html I think that the last
> regular expression in the paragraph quoted below is missing the '<'
> and '>'.  It is supposed to be the non-greedy version of "<.*>",
> right?  (I am writing my string literals as they are written in "C"
> source code.)
>
> The '*', '+', and '?' qualifiers are all /greedy/; they match as much
> text as possible. Sometimes this behaviour isn't desired; if the RE
> <.*> is matched against '<H1>title</H1>', it will match the entire
> string, and not just '<H1>'. Adding '?' after the qualifier makes it
> perform the match in /non-greedy/ or /minimal/ fashion; as /few/
> characters as possible will be matched. Using .*? in the previous
> expression will match only '<H1>'.
>
> Thanks for reading this.
>
> Robert Kinstler
>

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

From pstrasser at cccom.at  Fri Apr 26 14:02:07 2013
From: pstrasser at cccom.at (Patrick Strasser)
Date: Fri, 26 Apr 2013 12:02:07 -0000
Subject: [docs] argparse add_help with prefix_chars example wrong
Message-ID: <517A6C5F.8020207@cccom.at>

Hello,

in
   http://docs.python.org/3.4/library/argparse.html#add-help

The last example reads:

The help option is typically -h/--help. The exception to this is if the 
prefix_chars= is specified and does not include -, in which case -h and 
--help are not valid options. In this case, the first character in 
prefix_chars is used to prefix the help options:

>>>

>>>parser  =  argparse.ArgumentParser(prog='PROG',  prefix_chars='+/')
>>>parser.print_help()
usage: PROG [-h]

optional arguments:
   -h, --help  show this help message and exit
  

This example does not show the effect.
On my Ubuntu I get:

% python3.2
Python 3.2.3 (default, Apr 10 2013, 05:07:54)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse
>>> parser = argparse.ArgumentParser(prog='PROG', prefix_chars='+/')
>>> parser.print_help()
usage: PROG [+h]

optional arguments:
   +h, ++help  show this help message and exit
>>>

Docs of 2.7, 3.3 and 3.4 show this error, 3.2 is correct.

Regards

Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130426/55d0b6a9/attachment-0001.html>

From toby at hartdyke.com  Tue Apr 16 02:35:13 2013
From: toby at hartdyke.com (Toby Hart Dyke)
Date: Tue, 16 Apr 2013 00:35:13 -0000
Subject: [docs] Doc Error
Message-ID: <516C8BC2.2030900@hartdyke.com>


On the first listing under 
http://docs.python.org/2/tutorial/introduction.html#numbers, it says:

>>># Integer division returns the floor:
...7/3

That may be true for python 2, but in my version of python 3 (3.3.1 on 
Windows 64-bit). It gives a float:

2.3333333333333335

There's a similar issue with the example before, where(50-5*6)/4 should 
give 5.0 rather than 5.

Thought you might like to know!

   Toby


From yongjie989 at gmail.com  Tue Apr 23 11:40:12 2013
From: yongjie989 at gmail.com (YongJie Huang)
Date: Tue, 23 Apr 2013 09:40:12 -0000
Subject: [docs] Is here have planning Python documents translator to Chinese?
Message-ID: <CAEt=5C33MpmwAB4SAjMrS3hze99muvU4RQP6Dv2R9ZSj_syuiw@mail.gmail.com>

Hi all,

Is here have planning Python documents translator to Chinese? or who
already gets involved?

Cheers,
Yong Jie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130423/351e8794/attachment-0001.html>