From report at bugs.python.org  Thu Nov  1 05:10:24 2012
From: report at bugs.python.org (Bradley Froehle)
Date: Thu, 01 Nov 2012 04:10:24 +0000
Subject: [docs] [issue16378] venv.EnvBuilder docstring inconsistencies
Message-ID: <1351743024.49.0.854763959686.issue16378@psf.upfronthosting.co.za>


New submission from Bradley Froehle:

Consider the docstring for venv.EnvBuilder::

    By default, the builder makes the system (global) site-packages dir
    available to the created environment.

    By default, the creation process uses symlinks wherever possible.

It seems to suggest that the `system_site_packages` and `symlink` parameters both default to True, even though the default values for each are False.

The docstring for venv.create is similarly misleading.

----------
assignee: docs at python
components: Documentation
messages: 174388
nosy: bfroehle, docs at python
priority: normal
severity: normal
status: open
title: venv.EnvBuilder docstring inconsistencies
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  1 07:39:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Nov 2012 06:39:46 +0000
Subject: [docs] [issue16378] venv.EnvBuilder docstring inconsistencies
In-Reply-To: <1351743024.49.0.854763959686.issue16378@psf.upfronthosting.co.za>
Message-ID: <1351751986.34.0.509937271598.issue16378@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Tagging for the bug day.

----------
keywords: +easy
nosy: +eric.araujo, vinay.sajip

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

From andrew.svetlov at gmail.com  Thu Nov  1 11:34:20 2012
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Thu, 1 Nov 2012 12:34:20 +0200
Subject: [docs] Inaccurate description of HtmlDiff.make_table,
	Python 3.1.5
In-Reply-To: <CAFAaeRXf_Fq=Sev4H+eX6+gf4oSK0g0YE5zhZyMiQGtAptx_gQ@mail.gmail.com>
References: <CAFAaeRXf_Fq=Sev4H+eX6+gf4oSK0g0YE5zhZyMiQGtAptx_gQ@mail.gmail.com>
Message-ID: <CAL3CFcWAdaAHfXv+qp6epTVN5cQMwRT7YSLv9et2ZEVgRkJMEw@mail.gmail.com>

It works, at least from my understanding of ?highlighting?.


On Tue, Oct 30, 2012 at 9:16 PM, rail shafigulin
<rail.shafigulin at gmail.com>wrote:

> The description of HtmlDiff.make_table is inaccurate,
> http://docs.python.org/release/3.1.5/library/difflib.html#difflib.HtmlDiff.make_table It
> says the following
>
> "Compares fromlines and tolines (lists of strings) and returns a string
> which is a complete HTML table showing line by line differences with
> inter-line and intra-line changes highlighted."
>
> However non of the rows in the tables are highlighted.
>
> There are two possible fixes for this.
>
> 1. The documentation is incorrect in describing what should happen when
> this method is called. Instead of what is says right now it should say that
> the table is generated without showing any differences.
> 2. The code does not reflect the documentation, i.e. make_table should
> generate the html string correctly.
>
> I'm running Python 3.1.5 on a Windows Xp Pro Version 2002, SP 3.
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>
>


-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121101/e13667af/attachment.html>

From report at bugs.python.org  Thu Nov  1 14:02:35 2012
From: report at bugs.python.org (abcdef)
Date: Thu, 01 Nov 2012 13:02:35 +0000
Subject: [docs] [issue16380] true/proper subset
Message-ID: <1351774954.98.0.350778906182.issue16380@psf.upfronthosting.co.za>


New submission from abcdef:

The documentation

http://docs.python.org/2.7/library/stdtypes.html#set-types-set-frozenset

http://docs.python.org/3/library/stdtypes.html#set-types-set-frozenset

of "<" for sets uses "true subset" and "true superset". The correct termininology is "proper subset" and "proper superset", as evidenced by Google searches

http://google.com/search?q="true subset"

http://google.com/search?q="proper subset"

and most set theory books.

----------
assignee: docs at python
components: Documentation
messages: 174410
nosy: abcdef, docs at python
priority: normal
severity: normal
status: open
title: true/proper subset
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Nov  1 14:12:49 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 01 Nov 2012 13:12:49 +0000
Subject: [docs] [issue16380] true/proper subset
In-Reply-To: <1351774954.98.0.350778906182.issue16380@psf.upfronthosting.co.za>
Message-ID: <1351775569.74.0.910619667707.issue16380@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

+1

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

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

From report at bugs.python.org  Thu Nov  1 20:06:06 2012
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 01 Nov 2012 19:06:06 +0000
Subject: [docs] [issue15067] Clean up the sqlite3 docs
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1351796765.71.0.512139916111.issue15067@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Coming back to this 5 months later and looking into it myself, I find that the sqlite3 docs really need a bit of a cleanup all around, especially in all three 3.x branches.  Several minor changes were made by Raymond Hettinger in d229032dc213 and a few subsequent changesets 6 months ago in the 2.7 branch, but none of those ever made it to 3.x. (Raymond, those changes in the past are why I made you nosy on this one)

To address the offending sentence that brought this issue about in the first place, after rereading it and thinking about it some more, what's there does make sense: this module uses the recipe of PEP 246, regardless of that PEP's status.  However, I don't think it's helpful to mention it in the documentation, as it kind of gives the impression that "this feature was rejected for the whole of Python, but this stdlib module goes ahead and does it anyway."  For that reason, I propose to just drop that two-line paragraph entirely.  Everything about that feature still makes sense without that paragraph, even though the 'protocol' bit seems a bit weird. I wonder though, should that feature be deprecated on the basis of using a rejected PEP as well as TOOWTDI violation (or should I open another issue to that effect anyway)?

In the same vein as Raymond's earlier 2.7 changes (namely the SQL cleanup and capitalization he did), the 2.7 patch I've attached goes through and does the same for all of the included scripts in Doc/includes/sqlite3 as well as removing the bit about PEP 246.

The 3.2 patch does everything in the 2.7 patch, plus bringing the 3.2 docs in line with the 2.7 docs.

I do have a question, though; the footnote about enabling loadable extensions is different in the 2.7 and 3.2 docs.  Which one is right, or are both right for their respective versions?

Thanks,

Zach

----------
keywords: +patch
nosy: +rhettinger
title: sqlite3 docs reference PEP 246, which was rejected -> Clean up the sqlite3 docs
versions: +Python 3.4
Added file: http://bugs.python.org/file27829/sqlite3_cleanup_2.7.patch

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

From report at bugs.python.org  Thu Nov  1 20:06:38 2012
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 01 Nov 2012 19:06:38 +0000
Subject: [docs] [issue15067] Clean up the sqlite3 docs
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1351796798.16.0.698356204148.issue15067@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


Added file: http://bugs.python.org/file27830/sqlite3_cleanup_3.2.patch

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

From report at bugs.python.org  Thu Nov  1 20:10:56 2012
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 01 Nov 2012 19:10:56 +0000
Subject: [docs] [issue15067] Clean up the sqlite3 docs
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1351797056.62.0.566241616286.issue15067@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I failed to mention, the 3.2 patch also removes the line (and comment) about "db_row based solutions" since it seems from a quick Google search that "db_row" is a library created back in the 2.2 days that I didn't quickly see a 3.x version for.  Also, the comment made it seem like that line wouldn't be missed too much anyway :).  I left it in the 2.7 version though; as I assume it would be reasonably easy to get db_row to work with 2.7 if someone wanted to.

----------

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

From report at bugs.python.org  Thu Nov  1 20:18:54 2012
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 01 Nov 2012 19:18:54 +0000
Subject: [docs] [issue14893] Tutorial: Add function annotation example to
	function	tutorial
In-Reply-To: <1337802155.15.0.316800230533.issue14893@psf.upfronthosting.co.za>
Message-ID: <1351797534.92.0.56470677451.issue14893@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


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

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

From report at bugs.python.org  Thu Nov  1 20:28:51 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Nov 2012 19:28:51 +0000
Subject: [docs] [issue14893] Tutorial: Add function annotation example to
	function	tutorial
In-Reply-To: <1337802155.15.0.316800230533.issue14893@psf.upfronthosting.co.za>
Message-ID: <3XsxKt323hzPCN@mail.python.org>


Roundup Robot added the comment:

New changeset 2bf99322218f by Andrew Svetlov in branch '3.2':
Issue #14893: Add function annotation example to function tutorial.
http://hg.python.org/cpython/rev/2bf99322218f

New changeset 45167091b5f9 by Andrew Svetlov in branch '3.3':
Merge issue #14893: Add function annotation example to function tutorial.
http://hg.python.org/cpython/rev/45167091b5f9

New changeset 63b495ff366b by Andrew Svetlov in branch 'default':
Merge issue #14893: Add function annotation example to function tutorial.
http://hg.python.org/cpython/rev/63b495ff366b

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

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

From report at bugs.python.org  Thu Nov  1 20:29:34 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 01 Nov 2012 19:29:34 +0000
Subject: [docs] [issue14893] Tutorial: Add function annotation example to
	function	tutorial
In-Reply-To: <1337802155.15.0.316800230533.issue14893@psf.upfronthosting.co.za>
Message-ID: <1351798174.73.0.811753869461.issue14893@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed. Thanks, Zachary.

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

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

From report at bugs.python.org  Thu Nov  1 20:48:47 2012
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 01 Nov 2012 19:48:47 +0000
Subject: [docs] [issue14893] Tutorial: Add function annotation example to
	function	tutorial
In-Reply-To: <1337802155.15.0.316800230533.issue14893@psf.upfronthosting.co.za>
Message-ID: <1351799327.6.0.0483494828377.issue14893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thank you ?ric for the approval, and Andrew for the commit!

----------

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

From report at bugs.python.org  Thu Nov  1 20:50:15 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Nov 2012 19:50:15 +0000
Subject: [docs] [issue15067] Clean up the sqlite3 docs
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1351799415.16.0.967357942829.issue15067@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think it would be better to keep the capitalization of the queries separate from the rest of the patch.

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

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

From report at bugs.python.org  Thu Nov  1 20:50:16 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 01 Nov 2012 19:50:16 +0000
Subject: [docs] [issue16380] true/proper subset
In-Reply-To: <1351774954.98.0.350778906182.issue16380@psf.upfronthosting.co.za>
Message-ID: <1351799416.33.0.59539798683.issue16380@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed in 56c3ab6f7f07, 56c3ab6f7f07, fa7311caa203, 7dda9dc5e830
Thanks.

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

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

From report at bugs.python.org  Thu Nov  1 21:38:08 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Nov 2012 20:38:08 +0000
Subject: [docs] [issue8402] Add a function to escape metacharacters in
	glob/fnmatch
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1351802288.33.0.941060275944.issue8402@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> 
components:  -Documentation
keywords: +needs review
resolution: invalid -> 
stage:  -> patch review

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

From report at bugs.python.org  Fri Nov  2 04:39:50 2012
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 02 Nov 2012 03:39:50 +0000
Subject: [docs] [issue15067] Clean up the sqlite3 docs
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1351827590.16.0.113662405671.issue15067@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


Added file: http://bugs.python.org/file27834/issue15067_2.7_dead_pep.patch

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

From report at bugs.python.org  Fri Nov  2 04:40:19 2012
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 02 Nov 2012 03:40:19 +0000
Subject: [docs] [issue15067] Clean up the sqlite3 docs
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1351827619.39.0.440105175281.issue15067@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


Added file: http://bugs.python.org/file27835/issue15067_2.7_sql_capitalization.patch

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

From report at bugs.python.org  Fri Nov  2 04:41:03 2012
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 02 Nov 2012 03:41:03 +0000
Subject: [docs] [issue15067] Clean up the sqlite3 docs
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1351827663.33.0.272214968977.issue15067@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


Added file: http://bugs.python.org/file27836/issue15067_3.2_updates.patch

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

From report at bugs.python.org  Fri Nov  2 04:45:08 2012
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 02 Nov 2012 03:45:08 +0000
Subject: [docs] [issue15067] Clean up the sqlite3 docs
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1351827908.1.0.374470797481.issue15067@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Ok then, here's the split patches.  3.2_updates does have a few SQL capitalization changes, but most of those are already present in 2.7, and splitting out the rest would be more work than it's worth, I think.

----------
Added file: http://bugs.python.org/file27837/issue15067_3.2_sql_capitalization.patch

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

From report at bugs.python.org  Fri Nov  2 08:20:40 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Fri, 02 Nov 2012 07:20:40 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1351840840.24.0.850473324595.issue15148@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

Any reason why this is still open?

----------

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

From report at bugs.python.org  Fri Nov  2 08:26:29 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Fri, 02 Nov 2012 07:26:29 +0000
Subject: [docs] [issue15104] Unclear language in __main__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1351841190.0.0.887805538803.issue15104@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  2 10:11:57 2012
From: report at bugs.python.org (Jan Duzinkiewicz)
Date: Fri, 02 Nov 2012 09:11:57 +0000
Subject: [docs] [issue16304] re: Match Objects always have a boolean value
	of True
In-Reply-To: <1350993549.54.0.0789320233606.issue16304@psf.upfronthosting.co.za>
Message-ID: <1351847517.37.0.675174313104.issue16304@psf.upfronthosting.co.za>


Jan Duzinkiewicz added the comment:

I agree this is unclear - If Match object always have a boolean value of True, it actually prevents me from using simple if statement - what's the point of "if True:" statement? - so the remark that matching functions do not always return match objects has some value. I've submitted a patch.

----------
keywords: +patch
nosy: +dhgmgn
Added file: http://bugs.python.org/file27838/16304.patch

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

From report at bugs.python.org  Fri Nov  2 11:26:10 2012
From: report at bugs.python.org (Jan Duzinkiewicz)
Date: Fri, 02 Nov 2012 10:26:10 +0000
Subject: [docs] [issue15962] Windows STDIN/STDOUT Redirection is actually
	FIXED
In-Reply-To: <1347970794.78.0.910609008076.issue15962@psf.upfronthosting.co.za>
Message-ID: <1351851970.89.0.727629355438.issue15962@psf.upfronthosting.co.za>


Jan Duzinkiewicz added the comment:

I've referenced the kb article in the docs. Please let me know if the fix is ok - maybe the whole registry change process should be included in the docs directly?

----------
keywords: +patch
nosy: +dhgmgn
Added file: http://bugs.python.org/file27839/15962.patch

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

From report at bugs.python.org  Fri Nov  2 12:33:06 2012
From: report at bugs.python.org (Jan Duzinkiewicz)
Date: Fri, 02 Nov 2012 11:33:06 +0000
Subject: [docs] [issue14878] Improve documentation for generator.send method
In-Reply-To: <1337662493.01.0.380911981252.issue14878@psf.upfronthosting.co.za>
Message-ID: <1351855986.55.0.164965765834.issue14878@psf.upfronthosting.co.za>


Jan Duzinkiewicz added the comment:

The latest docs have a crossrefence at the end of the section:

http://docs.python.org/3/reference/simple_stmts.html#grammar-token-yield_stmt

I copied  the reference to 2.7 docs

----------
keywords: +patch
nosy: +dhgmgn
Added file: http://bugs.python.org/file27842/14878.patch

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

From report at bugs.python.org  Fri Nov  2 12:43:21 2012
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Nov 2012 11:43:21 +0000
Subject: [docs] [issue15148] shutil.which() docstring could be clearer
In-Reply-To: <1340414189.13.0.761337231991.issue15148@psf.upfronthosting.co.za>
Message-ID: <1351856600.96.0.342070925224.issue15148@psf.upfronthosting.co.za>


R. David Murray added the comment:

Doesn't look like it.

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

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

From report at bugs.python.org  Fri Nov  2 13:36:07 2012
From: report at bugs.python.org (Jan Duzinkiewicz)
Date: Fri, 02 Nov 2012 12:36:07 +0000
Subject: [docs] [issue16386] imp.find_module does not specify registry key
	it	searches on windows
Message-ID: <1351859767.89.0.815277454803.issue16386@psf.upfronthosting.co.za>


New submission from Jan Duzinkiewicz:

quote from http://docs.python.org/3/library/imp.html#imp.find_module:

"...on some systems some other places are looked in as well (on Windows, it looks in the registry which may point to a specific file)."

I actually didn't know the registry key is listed in "using Python on Window" guide until I grepped for PythonCore (which kind of requires to know the key already) - so I'm submitting a patch that cross references find_module docs and using Python on Windows guide.

----------
assignee: docs at python
components: Documentation
files: import_nt_reg.patch
keywords: patch
messages: 174508
nosy: dhgmgn, docs at python
priority: normal
severity: normal
status: open
title: imp.find_module does not specify registry key it searches on windows
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file27843/import_nt_reg.patch

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

From report at bugs.python.org  Fri Nov  2 20:00:43 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Nov 2012 19:00:43 +0000
Subject: [docs] [issue16354] Remember python version choice on
	docs.python.org
In-Reply-To: <1351505767.0.0.302833012175.issue16354@psf.upfronthosting.co.za>
Message-ID: <1351882843.66.0.363755354252.issue16354@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  2 20:12:52 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Nov 2012 19:12:52 +0000
Subject: [docs] [issue16354] Remember python version choice on
	docs.python.org
In-Reply-To: <1351505767.0.0.302833012175.issue16354@psf.upfronthosting.co.za>
Message-ID: <1351883572.42.0.89850018006.issue16354@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

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

From andrew.svetlov at gmail.com  Fri Nov  2 21:46:23 2012
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Fri, 2 Nov 2012 22:46:23 +0200
Subject: [docs] Inaccurate description of HtmlDiff.make_table,
	Python 3.1.5
In-Reply-To: <CAFAaeRWwu0Rgn_PW3N242qx3bRyh243kSEUJM_ePxyztOamYRQ@mail.gmail.com>
References: <CAFAaeRXf_Fq=Sev4H+eX6+gf4oSK0g0YE5zhZyMiQGtAptx_gQ@mail.gmail.com>
	<CAL3CFcWAdaAHfXv+qp6epTVN5cQMwRT7YSLv9et2ZEVgRkJMEw@mail.gmail.com>
	<CAFAaeRWwu0Rgn_PW3N242qx3bRyh243kSEUJM_ePxyztOamYRQ@mail.gmail.com>
Message-ID: <CAL3CFcW+v2Rto2L7bL+=zRwK3rKgdOxJrQNbx3tn329yC_pj2w@mail.gmail.com>

Perhaps we have some misunderstanding.

I tried:

>>> from difflib import *
>>> s1 = ['bacon\n', 'eggs\n', 'ham\n', 'guido\n']
>>> s2 = ['python\n', 'eggy\n', 'hamster\n', 'guido\n']
>>> d.make_table(s1, s2)
... LONG ENOUGH OUTPUT

when I've opened that output in browser the differences was definitely
highlighted.

I've tried it on 3.2, 3.1 is open for security bugs only for now BTW.
Please inform me how to reproduce your problem.
Also please keep in mind: 3.1 in security-only stage, if your issue has
been fixed in 3.2 we'll do nothing to backport fix into 3.1

Thanks.


On Fri, Nov 2, 2012 at 8:47 PM, rail shafigulin
<rail.shafigulin at gmail.com>wrote:

> I can't see any highlighting. I'm attaching diff.html which I generated
> using the script provided here,
> http://docs.python.org/release/3.1.5/library/difflib.html#a-command-line-interface-to-difflib .
> In the script I changed make_file to make_table to demonstrate the effect.
> I'm also attaching two text files I used for diff generation.
>
> I'm running Python 3.1.5 on a Windows XP Pro Version 2002, SP 3.
>
> Thanks.
>
>
> On Thu, Nov 1, 2012 at 6:34 AM, Andrew Svetlov <andrew.svetlov at gmail.com>wrote:
>
>> It works, at least from my understanding of ?highlighting?.
>>
>>
>> On Tue, Oct 30, 2012 at 9:16 PM, rail shafigulin <
>> rail.shafigulin at gmail.com> wrote:
>>
>>> The description of HtmlDiff.make_table is inaccurate,
>>> http://docs.python.org/release/3.1.5/library/difflib.html#difflib.HtmlDiff.make_table It
>>> says the following
>>>
>>> "Compares fromlines and tolines (lists of strings) and returns a string
>>> which is a complete HTML table showing line by line differences with
>>> inter-line and intra-line changes highlighted."
>>>
>>> However non of the rows in the tables are highlighted.
>>>
>>> There are two possible fixes for this.
>>>
>>> 1. The documentation is incorrect in describing what should happen when
>>> this method is called. Instead of what is says right now it should say that
>>> the table is generated without showing any differences.
>>> 2. The code does not reflect the documentation, i.e. make_table should
>>> generate the html string correctly.
>>>
>>> I'm running Python 3.1.5 on a Windows Xp Pro Version 2002, SP 3.
>>>
>>> _______________________________________________
>>> docs mailing list
>>> docs at python.org
>>> http://mail.python.org/mailman/listinfo/docs
>>>
>>>
>>
>>
>> --
>> Thanks,
>> Andrew Svetlov
>>
>
>


-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121102/a9e1abcf/attachment-0001.html>

From report at bugs.python.org  Fri Nov  2 22:43:25 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Nov 2012 21:43:25 +0000
Subject: [docs] [issue16354] Remember python version choice on
	docs.python.org
In-Reply-To: <1351505767.0.0.302833012175.issue16354@psf.upfronthosting.co.za>
Message-ID: <1351892605.46.0.405017201482.issue16354@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It may be possible, but will not happen. A modern browser should displays your personal history options as you type. If I type 'docs' in Firefox, it gives me choices for the rest of the url, though there are a lot of obsolete entries to delete. Typing and selecting /2/ and /3/ enough will keep them at the top of the list.

----------
nosy: +terry.reedy
status: pending -> open

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

From report at bugs.python.org  Fri Nov  2 22:43:37 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Nov 2012 21:43:37 +0000
Subject: [docs] [issue16354] Remember python version choice on
	docs.python.org
In-Reply-To: <1351505767.0.0.302833012175.issue16354@psf.upfronthosting.co.za>
Message-ID: <1351892617.32.0.231510185308.issue16354@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov  3 03:42:50 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Nov 2012 02:42:50 +0000
Subject: [docs] [issue16354] Remember python version choice on
	docs.python.org
In-Reply-To: <1351505767.0.0.302833012175.issue16354@psf.upfronthosting.co.za>
Message-ID: <1351910570.29.0.82877707625.issue16354@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Maybe the OP wanted to get redirected when he reaches a doc page through e.g. Google or a direct link, rather than a bookmark/history/manually-entered URL.  I usually get to the docs via Google, and either pick whatever version comes up, or edit the URL manually.  That might get in the way when users open a link for a specific version and get redirected, so it's not a really good idea.

> If I type 'docs' in Firefox, it gives me choices for the rest of the url

You could even set keywords like 'pydoc' and 'py2doc' without relying on the history, and optionally they could supporting a search term too.

> That would remove the minor annoyance of always ending up at the
> Python 3 documentation and having to switch back to 2.7.

Or you could remove the annoyance by switching your code forward to Python 3 <wink>.

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

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

From report at bugs.python.org  Sat Nov  3 16:34:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Nov 2012 15:34:18 +0000
Subject: [docs] [issue16395] Documentation claims that PySequence_Fast
	returns a	tuple, when it actually returns a list.
In-Reply-To: <1351955901.81.0.627286470446.issue16395@psf.upfronthosting.co.za>
Message-ID: <1351956858.77.0.597681709839.issue16395@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Larry, any objection to backporting this?

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, eric.araujo, larry
stage:  -> patch review
versions:  -Python 3.3

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

From report at bugs.python.org  Sat Nov  3 16:59:26 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Sat, 03 Nov 2012 15:59:26 +0000
Subject: [docs] [issue16048] Tutorial-classes-remarks: replace paragraph
In-Reply-To: <1348603562.92.0.789475109772.issue16048@psf.upfronthosting.co.za>
Message-ID: <1351958366.32.0.692290999249.issue16048@psf.upfronthosting.co.za>


Changes by Yongzhi Pan <fossilet at users.sourceforge.net>:


----------
nosy: +fossilet

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

From report at bugs.python.org  Sat Nov  3 18:55:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Nov 2012 17:55:21 +0000
Subject: [docs] [issue16395] Documentation claims that PySequence_Fast
	returns a	tuple, when it actually returns a list.
In-Reply-To: <1351955901.81.0.627286470446.issue16395@psf.upfronthosting.co.za>
Message-ID: <1351965321.84.0.0887969953476.issue16395@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PySequence_Tuple() was changed to PySequence_List() in the changeset 4714aff4bf75 in 2004.  Are there any measurements which show PySequence_List() faster than PySequence_Tuple() on modern Python?  I don't see any references in 4714aff4bf75 description.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Nov  3 18:58:09 2012
From: report at bugs.python.org (Simon Law)
Date: Sat, 03 Nov 2012 17:58:09 +0000
Subject: [docs] [issue15125] argparse: positional arguments containing - in
	name not	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1351965488.96.0.04043398729.issue15125@psf.upfronthosting.co.za>


Simon Law added the comment:

>> But patching the module to allow explicitly setting dest via keyword 
>> argument shouldn't hurt anybody.
>
> I agree that it wouldn't hurt anybody. If you can find a way to do
> this, feel free to provide a patch.
>
> However, the correct way to have one name for the attribute (i.e.
> dest=) and one name for the help (i.e. metavar=) is to use the
> metavar argument like so:
>
>     parser.add_argument('positional_args', metavar='positional-args')

I don't think that making ``dest`` more magical is a good idea. In the
included patch, you'll find a change that makes the ValueError tell
people about ``metavar``, which is the right way to go about things
anyway.

> That said, this is not the first time I've seen someone run into this
> problem. I think the documentation could be improved in a few ways:
>
> (1) In the "name or flags" section, describe how the flags (for
> optional arguments) are translated into both a default "dest"
> (stripping initial '-' and converting '-' to '_') and into a default
> "metavar" (stripping initial '-' and uppercasing). Part of this is
> in the "dest" and "metavar" documentation, but probably belongs up
> in the "name or flags" documentation. Add cross-references to "dest"
> and "metavar" sections.

In the included patch.

> (2) In the "name or flags" section, describe how the name (for
> positional arguments) are translated into the same default "dest"
> and "metavar" (no string munging at all). Again, move stuff from the
> "dest" and "metavar" sections as necessary. Add cross-references to
> "dest" and "metavar" sections.
>
> (3) In the "dest" section and somewhere in the "parse_args" section,
> describe how "getattr" can be used to get attributes whose names
> aren't valid Python identifiers. Maybe cross-reference this section
> from the edits in (2).

If we make optional and positional arguments consistent, and provide
backwards-compatibility for positional arguments, then these two are
not necesssary.

----------
nosy: +sfllaw
Added file: http://bugs.python.org/file27859/15125-1.patch

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

From report at bugs.python.org  Sat Nov  3 19:01:11 2012
From: report at bugs.python.org (Simon Law)
Date: Sat, 03 Nov 2012 18:01:11 +0000
Subject: [docs] [issue15125] argparse: positional arguments containing - in
	name not	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1351965671.63.0.681439978278.issue15125@psf.upfronthosting.co.za>


Simon Law added the comment:

Sorry, there was a small typo in the previous patch. Here's the newer version.

----------
Added file: http://bugs.python.org/file27860/15125-1.patch

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

From report at bugs.python.org  Sat Nov  3 19:15:19 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Nov 2012 18:15:19 +0000
Subject: [docs] [issue15125] argparse: positional arguments containing - in
	name not	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1351966519.21.0.9511369062.issue15125@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file27859/15125-1.patch

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

From report at bugs.python.org  Sat Nov  3 19:26:47 2012
From: report at bugs.python.org (Simon Law)
Date: Sat, 03 Nov 2012 18:26:47 +0000
Subject: [docs] [issue15125] argparse: positional arguments containing - in
	name not	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1351967207.42.0.0919072776293.issue15125@psf.upfronthosting.co.za>


Simon Law added the comment:

Note that 15125-1.patch applies to Python 2.7 cleanly as it is a bugfix.

----------

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

From report at bugs.python.org  Sat Nov  3 20:03:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Nov 2012 19:03:24 +0000
Subject: [docs] [issue12634] Random Remarks in class documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1351969404.73.0.905960462459.issue12634@psf.upfronthosting.co.za>


?ric Araujo added the comment:

+1 to something like Terry?s proposal.

----------
keywords: +easy
stage:  -> needs patch
type: enhancement -> 
versions: +Python 3.4

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

From report at bugs.python.org  Sat Nov  3 20:11:44 2012
From: report at bugs.python.org (Carsten Milkau)
Date: Sat, 03 Nov 2012 19:11:44 +0000
Subject: [docs] [issue16394] Improving tee() memory footprint
In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>
Message-ID: <1351969904.24.0.218132229432.issue16394@psf.upfronthosting.co.za>


Changes by Carsten Milkau <chat.noir at arcor.de>:


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

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

From report at bugs.python.org  Sat Nov  3 20:25:20 2012
From: report at bugs.python.org (Simon Law)
Date: Sat, 03 Nov 2012 19:25:20 +0000
Subject: [docs] [issue15125] argparse: positional arguments containing - in
	name not	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1351970720.26.0.980080269554.issue15125@psf.upfronthosting.co.za>


Simon Law added the comment:

15125-2.patch applies to the default branch.

It makes dest behave the same for positional and optional arguments in terms of name mangling.

Also, there is a backward-compatibility path in Namespace to support old-style getattr() access. However, it's not documented as we really don't want people to use it.

----------
Added file: http://bugs.python.org/file27863/15125-2.patch

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

From report at bugs.python.org  Sat Nov  3 20:25:54 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Nov 2012 19:25:54 +0000
Subject: [docs] [issue16394] Improving tee() memory footprint
In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>
Message-ID: <1351970754.71.0.277102034876.issue16394@psf.upfronthosting.co.za>


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


----------
nosy:  -serhiy.storchaka
stage:  -> needs patch
type: performance -> enhancement
versions:  -Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Nov  3 21:17:08 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Nov 2012 20:17:08 +0000
Subject: [docs] [issue10796] readline completion flaw
In-Reply-To: <1293714489.48.0.717157988045.issue10796@psf.upfronthosting.co.za>
Message-ID: <1351973828.19.0.723784375739.issue10796@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I think I get it: Python sets custom delimiters that include '-' because for the Python REPL, it?s not possible to have one identifier with a dash, so it?s considered a delimiter and when you press tab, a new completion is started.  For a custom REPL however, you may want to have dashes as legal parts of your completed words, so you want to call set_completer_delims.  Reclassifying as a doc patch.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +easy
nosy: +docs at python
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov  3 21:18:10 2012
From: report at bugs.python.org (Guillaume P)
Date: Sat, 03 Nov 2012 20:18:10 +0000
Subject: [docs] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s?=
 =?utf-8?q?_new_opener_argument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1351973890.77.0.308595036317.issue13424@psf.upfronthosting.co.za>


Guillaume P added the comment:

Here is a proposed patch to the documentation.

----------
keywords: +patch
nosy: +guillaumep
Added file: http://bugs.python.org/file27866/13424.patch

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

From report at bugs.python.org  Sat Nov  3 22:10:12 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Nov 2012 21:10:12 +0000
Subject: [docs] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s?=
 =?utf-8?q?_new_opener_argument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <3XvCTs6DFQzMMp@mail.python.org>


Roundup Robot added the comment:

New changeset 17b094c08600 by ?ric Araujo in branch '3.3':
Add examples for opener argument of open (#13424).
http://hg.python.org/cpython/rev/17b094c08600

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

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

From storchaka at gmail.com  Sat Nov  3 22:11:54 2012
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Sat, 03 Nov 2012 21:11:54 -0000
Subject: [docs] =?utf-8?q?Add_examples_for_open=E2=80=99s_new_opener_argum?=
 =?utf-8?q?ent_=28issue_13424=29?=
Message-ID: <20121103211154.25828.48678@psf.upfronthosting.co.za>


http://bugs.python.org/review/13424/diff/6494/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13424/diff/6494/Doc/library/functions.rst#newcode938
Doc/library/functions.rst:938: The following example is an alternative
implementation for opening files
I doubt that an alternative implementation is a good usage example. 
First, this violates the "one obvious way" principle.  Second, this does
not justify the adding of the new parameter to already complicated
open(), because you can do this without it.

http://bugs.python.org/review/13424/diff/6494/Doc/library/functions.rst#newcode959
Doc/library/functions.rst:959: ...     dir_fd = os.open(dirname,
os.O_RDONLY)
Here is a file descriptor leak.

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

From report at bugs.python.org  Sat Nov  3 22:11:57 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Nov 2012 21:11:57 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <1351977117.69.0.296002352354.issue16339@psf.upfronthosting.co.za>


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


----------
keywords: +easy

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

From report at bugs.python.org  Sat Nov  3 22:13:53 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Nov 2012 21:13:53 +0000
Subject: [docs] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s?=
 =?utf-8?q?_new_opener_argument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1351977233.78.0.896434132889.issue13424@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Fixed, thanks!

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

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

From report at bugs.python.org  Sat Nov  3 22:14:35 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Nov 2012 21:14:35 +0000
Subject: [docs] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s?=
 =?utf-8?q?_new_opener_argument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1351977275.06.0.931814115928.issue13424@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See my comments in Rietveld.

----------
nosy: +serhiy.storchaka
type:  -> enhancement

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

From report at bugs.python.org  Sat Nov  3 22:15:32 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Nov 2012 21:15:32 +0000
Subject: [docs] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s?=
 =?utf-8?q?_new_opener_argument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1351977332.0.0.0131752643336.issue13424@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov  3 22:41:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Nov 2012 21:41:59 +0000
Subject: [docs] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s?=
 =?utf-8?q?_new_opener_argument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1351978919.26.0.789568685231.issue13424@psf.upfronthosting.co.za>


?ric Araujo added the comment:

fd leak fixed in 95ea024f0569.

----------

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

From report at bugs.python.org  Sat Nov  3 22:50:26 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Nov 2012 21:50:26 +0000
Subject: [docs] [issue16304] re: Match Objects always have a boolean value
	of True
In-Reply-To: <1350993549.54.0.0789320233606.issue16304@psf.upfronthosting.co.za>
Message-ID: <1351979426.77.0.626604710719.issue16304@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks for the patch.  Note that :const:`True` should be ``True``.

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

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

From report at bugs.python.org  Sat Nov  3 23:15:37 2012
From: report at bugs.python.org (George Peristerakis)
Date: Sat, 03 Nov 2012 22:15:37 +0000
Subject: [docs] [issue16190] Misleading warning in random module docs
In-Reply-To: <1349885590.41.0.193272073786.issue16190@psf.upfronthosting.co.za>
Message-ID: <1351980937.4.0.189083064635.issue16190@psf.upfronthosting.co.za>


Changes by George Peristerakis <peristerakis at gmail.com>:


----------
nosy: +George.Peristerakis

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

From report at bugs.python.org  Sun Nov  4 01:39:29 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 04 Nov 2012 00:39:29 +0000
Subject: [docs] [issue15125] argparse: positional arguments containing - in
	name not	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1351989569.45.0.362305257073.issue15125@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Will apply the doc patches soon? and wait for Steven?s feedback about the 3.4 behavior change.

----------

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

From report at bugs.python.org  Sun Nov  4 02:43:41 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Nov 2012 01:43:41 +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: <1351993421.52.0.216303967872.issue16355@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

That's arguably a bug though.  If the pragma was critical the program will silently do the wrong thing by ignoring an existing pragma when the source is missing (e.g. in production, even after passing all the tests locally).

----------

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

From report at bugs.python.org  Sun Nov  4 03:30:31 2012
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 04 Nov 2012 02:30:31 +0000
Subject: [docs] [issue11842] slice.indices with negative step and default
	stop
In-Reply-To: <1302727853.06.0.703796407001.issue11842@psf.upfronthosting.co.za>
Message-ID: <1351996231.52.0.995191223135.issue11842@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I think this should be closed as slice.indices behaves exactly as I expect it to, and the returned values are for any sequence and not just range().

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

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

From report at bugs.python.org  Sun Nov  4 03:53:33 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 04 Nov 2012 02:53:33 +0000
Subject: [docs] [issue16394] Reducing tee() memory footprint
In-Reply-To: <1351955719.4.0.453680036148.issue16394@psf.upfronthosting.co.za>
Message-ID: <1351997613.74.0.706218937977.issue16394@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
title: Improving tee() memory footprint -> Reducing tee() memory footprint

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

From report at bugs.python.org  Sun Nov  4 05:36:42 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Nov 2012 04:36:42 +0000
Subject: [docs] [issue16048] Tutorial-classes-remarks: replace paragraph
In-Reply-To: <1348603562.92.0.789475109772.issue16048@psf.upfronthosting.co.za>
Message-ID: <1352003802.06.0.23807741751.issue16048@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This seems to be a duplicate of #12634.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Random Remarks in class documentation

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

From report at bugs.python.org  Sun Nov  4 05:37:13 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Nov 2012 04:37:13 +0000
Subject: [docs] [issue12634] Random Remarks in class documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1352003832.96.0.777975347998.issue12634@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See also #16048.

----------

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

From report at bugs.python.org  Sun Nov  4 06:00:18 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Nov 2012 05:00:18 +0000
Subject: [docs] [issue16304] re: Match Objects always have a boolean value
	of True
In-Reply-To: <1350993549.54.0.0789320233606.issue16304@psf.upfronthosting.co.za>
Message-ID: <3XvPwK5s7kzR7r@mail.python.org>


Roundup Robot added the comment:

New changeset dc96df8556d8 by Ezio Melotti in branch '2.7':
#16304: clarify match objects docs.  Initial patch by Jan Duzinkiewicz.
http://hg.python.org/cpython/rev/dc96df8556d8

New changeset 1805fc284201 by Ezio Melotti in branch '3.2':
#16304: clarify match objects docs.  Initial patch by Jan Duzinkiewicz.
http://hg.python.org/cpython/rev/1805fc284201

New changeset 7fde4b4f7e56 by Ezio Melotti in branch '3.3':
#16304: merge with 3.2.
http://hg.python.org/cpython/rev/7fde4b4f7e56

New changeset 63b45c959a2a by Ezio Melotti in branch 'default':
#16304: merge with 3.3.
http://hg.python.org/cpython/rev/63b45c959a2a

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

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

From report at bugs.python.org  Sun Nov  4 06:00:58 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Nov 2012 05:00:58 +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: <1352005258.83.0.957742168424.issue16355@psf.upfronthosting.co.za>


R. David Murray added the comment:

It doesn't matter whether it is a bug or not (though it is not in the situation I described).  The point is that a working program would stop working.  That is the kind of breakage our backward compatibility policy is designed to protect against.

----------

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

From report at bugs.python.org  Sun Nov  4 06:01:53 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Nov 2012 05:01:53 +0000
Subject: [docs] [issue16304] re: Match Objects always have a boolean value
	of True
In-Reply-To: <1350993549.54.0.0789320233606.issue16304@psf.upfronthosting.co.za>
Message-ID: <1352005313.35.0.609233418925.issue16304@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for the patch!
I committed a slightly modified version.

----------
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/issue16304>
_______________________________________

From report at bugs.python.org  Sun Nov  4 06:05:18 2012
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 04 Nov 2012 05:05:18 +0000
Subject: [docs] [issue12634] Random Remarks in class documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1352005518.8.0.857800404971.issue12634@psf.upfronthosting.co.za>


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


----------
nosy: +cvrebert

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

From report at bugs.python.org  Sun Nov  4 06:07:01 2012
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Nov 2012 05:07:01 +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: <1352005621.28.0.916535171057.issue16399@psf.upfronthosting.co.za>


R. David Murray added the comment:

This behavior is inherited from optparse.  I think it is more-or-less intentional, and in any case it is of long enough standing that I don't think we can change it.  We documented it for optparse in another issue, but I don't think we made the corresponding improvement to the argparse docs.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +bethard, docs at python, r.david.murray
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov  4 06:07:39 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 04 Nov 2012 05:07:39 +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: <1352005659.3.0.528192188399.issue16355@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> The point is that a working program would stop working.

My point is that the program might not be a "working" program, if the function fails silently.

Anyway this function is probably not widely used, so I'm fine either ways.

----------

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

From report at bugs.python.org  Sun Nov  4 08:31:33 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 04 Nov 2012 07:31:33 +0000
Subject: [docs] [issue11842] slice.indices with negative step and default
	stop
In-Reply-To: <1302727853.06.0.703796407001.issue11842@psf.upfronthosting.co.za>
Message-ID: <1352014293.46.0.537889482309.issue11842@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Agreed.  Closing.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sun Nov  4 08:41:01 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Sun, 04 Nov 2012 07:41:01 +0000
Subject: [docs] [issue12634] Random Remarks in class documentation
In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za>
Message-ID: <1352014861.03.0.861136772992.issue12634@psf.upfronthosting.co.za>


Changes by Yongzhi Pan <fossilet at users.sourceforge.net>:


----------
nosy: +fossilet

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

From report at bugs.python.org  Sun Nov  4 12:09:55 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Nov 2012 11:09:55 +0000
Subject: [docs] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s?=
 =?utf-8?q?_new_opener_argument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1352027394.99.0.396110604586.issue13424@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Isn't it be clearer?

      >>> import os
      >>> dir_fd = os.open('somedir', os.O_RDONLY)
      >>> def opener(path, flags):
      ...     return os.open(path, flags, dir_fd=dir_fd)
      ...
      >>> with open('spamspam.txt', 'w', opener=opener) as f:
      ...     print('This will be written to somedir/spamspam.txt', file=f)
      ...
      >>> os.close(dir_fd)  # don't leak a file descriptor

Or if you want stronger example:

      >>> import os, contextlib, functools
      >>> @contextlib.contextmanager
      ... def open_relative(dirname):
      ...     dir_fd = os.open(dirname, os.O_RDONLY)
      ...     def opener(path, flags):
      ...         return os.open(path, flags, dir_fd=dir_fd)
      ...     try:
      ...         yield functools.partial(open, opener=opener)
      ...     finally:
      ...         os.close(dir_fd)
      ...
      >>> with open_relative('somedir') as open:
      ...     with open('spamspam.txt', 'w') as f:
      ...         print('This will be written to somedir/spamspam.txt', file=f)
      ...

Frankly speaking, all of these examples looks unconvincing to me.  Even the second example could be implemented without an "opener" argument.

----------

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

From report at bugs.python.org  Sun Nov  4 17:10:38 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Nov 2012 16:10:38 +0000
Subject: [docs] [issue16404] Uses of PyLong_FromLong that don't check for
	errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <1352045437.93.0.68539996659.issue16404@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue15989.

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

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

From report at bugs.python.org  Sun Nov  4 23:54:47 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 04 Nov 2012 22:54:47 +0000
Subject: [docs] [issue13740] winsound.SND_NOWAIT ignored on modern Windows
	platforms
In-Reply-To: <1326059265.01.0.0567556069676.issue13740@psf.upfronthosting.co.za>
Message-ID: <1352069687.99.0.12077407769.issue13740@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


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

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

From report at bugs.python.org  Mon Nov  5 05:09:33 2012
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 05 Nov 2012 04:09:33 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1352088571.95.0.37799156305.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Attached is a patch for 16 test cases.  All 16 test cases have been tested on Windows 7, Mac OS X, and Linux they seem to function well.  Before this patch there was only a single test case for rename.  For each test case I used "unittest.skipUnless" to make sure the platform was one of the three that I tested for Windows 7, Mac OS X, or Linux.  These test cases demonstrate that the documentation is incorrect and perhaps a little fuzzy.  I plan to submit updates to the documentation in the coming days.  This patch is only for Python 3.4 but I will backport to 2.7 in a few days.  


I wrote the following code to find all the combinations based on parameters of the function:

src = ['src_file','src_directory_empty', 'src_directory_not_empty', \
       'src_file_or_directory_not_exist']
dst = ['dst_file_exist','dst_not_exist','dst_directory_empty', \
        'dst_directory_not_empty']

print "Make sure you have functions in test_os for all of these"
for index_src in range(0, len(src)):
    for index_dst in range(0, len(dst)):
        function_name = "test_rename_" + src[index_src] + "_" + \
            dst[index_dst]
        print function_name

----------
versions:  -Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27890/OSRename_test_os_3point4.patch

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

From report at bugs.python.org  Mon Nov  5 05:46:08 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 05 Nov 2012 04:46:08 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1352090768.05.0.758401095704.issue16278@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Attached is a patch for 16 test cases.

The test cases look quite verbose (e.g. they're not DRY), but it's a good start.  Thanks.  For others' benefit, can you perhaps summarize your findings concisely in a table/chart of some form?

----------

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

From report at bugs.python.org  Mon Nov  5 12:24:28 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 05 Nov 2012 11:24:28 +0000
Subject: [docs] [issue16413] Non cross-platform behavior of os.path.split
Message-ID: <1352114668.34.0.500502059895.issue16413@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

os.path.split('c:foo') gives ('c:', 'foo') on Windows and ('', 'c:foo') on Linux, which is not documented. IIUC, the behavior change in os module is not possible, so a documentation note will be appreciated.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 174890
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Non cross-platform behavior of os.path.split
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Nov  5 12:29:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Nov 2012 11:29:36 +0000
Subject: [docs] [issue16413] Non cross-platform behavior of os.path.split
In-Reply-To: <1352114668.34.0.500502059895.issue16413@psf.upfronthosting.co.za>
Message-ID: <1352114976.92.0.229687086841.issue16413@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

.. note::

   Since different operating systems have different path name conventions, there
   are several versions of this module in the standard library.  The
   :mod:`os.path` module is always the path module suitable for the operating
   system Python is running on, and therefore usable for local paths.  However,
   you can also import and use the individual modules if you want to manipulate
   a path that is *always* in one of the different formats.  They all have the
   same interface:

   * :mod:`posixpath` for UNIX-style paths
   * :mod:`ntpath` for Windows paths
   * :mod:`macpath` for old-style MacOS paths

----------
nosy: +serhiy.storchaka
resolution:  -> invalid

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

From report at bugs.python.org  Mon Nov  5 12:55:09 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Nov 2012 11:55:09 +0000
Subject: [docs] [issue16413] Non cross-platform behavior of os.path.split
In-Reply-To: <1352114668.34.0.500502059895.issue16413@psf.upfronthosting.co.za>
Message-ID: <1352116509.11.0.666172901778.issue16413@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Nov  5 12:59:52 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 05 Nov 2012 11:59:52 +0000
Subject: [docs] [issue16413] Non cross-platform behavior of os.path.split
In-Reply-To: <1352114668.34.0.500502059895.issue16413@psf.upfronthosting.co.za>
Message-ID: <1352116792.51.0.405471499148.issue16413@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Historically os.path.split() on Windows is able to grok UNIX paths easily.

Don't you think that Python language reference for the os.path should include less vague definition of Windows, UNIX-style and old-style MacOS paths it works with?

----------
resolution: invalid -> 
status: closed -> open

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

From report at bugs.python.org  Mon Nov  5 13:01:22 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 05 Nov 2012 12:01:22 +0000
Subject: [docs] [issue16413] Non cross-platform behavior of os.path.split
In-Reply-To: <1352114668.34.0.500502059895.issue16413@psf.upfronthosting.co.za>
Message-ID: <1352116881.94.0.392468481556.issue16413@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

User story: as a Python programmer working with different systems, I'd like to know how os.path module threats paths on these systems.

----------

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

From report at bugs.python.org  Mon Nov  5 13:37:30 2012
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 05 Nov 2012 12:37:30 +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: <1352119050.46.0.0101675749246.issue8913@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

To Heikki Partanen excellent point in the review about date __format__ strings allowing you to combine date formatting with other types of formatting:

This is a great point. It's the lack of this that (for example) requires the logging module to have a separate datefmt parameter. With %-formatting, there's no easy way to say:

'{timestamp:%Y%m%d-%H%M%S} {hostname:^40} {count:02d}'.format(timestamp=ts, hostname=host, count=count)

That is, with %-formatting you can't have a single string that specifies both a date/time format and other formatting as well as other formatting specifiers.

I don't think the example in the patch is great, but I do think that it's a good point that needs to be emphasized.

----------

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

From report at bugs.python.org  Mon Nov  5 14:11:29 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Nov 2012 13:11:29 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <1352121089.2.0.427121128162.issue16339@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thread on #python-dev:  http://mail.python.org/pipermail/python-dev/2012-November/122543.html

If this is documented, direct tests for this form of exec should also be added.

----------

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

From andrew.svetlov at gmail.com  Mon Nov  5 16:04:56 2012
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Mon, 5 Nov 2012 17:04:56 +0200
Subject: [docs] Inaccurate description of HtmlDiff.make_table,
	Python 3.1.5
In-Reply-To: <CAFAaeRXnOHJ_R8GmSP9=zN2zXug3PTY7pEB=-0O8QcmYNFpGXw@mail.gmail.com>
References: <CAFAaeRXf_Fq=Sev4H+eX6+gf4oSK0g0YE5zhZyMiQGtAptx_gQ@mail.gmail.com>
	<CAL3CFcWAdaAHfXv+qp6epTVN5cQMwRT7YSLv9et2ZEVgRkJMEw@mail.gmail.com>
	<CAFAaeRWwu0Rgn_PW3N242qx3bRyh243kSEUJM_ePxyztOamYRQ@mail.gmail.com>
	<CAL3CFcW+v2Rto2L7bL+=zRwK3rKgdOxJrQNbx3tn329yC_pj2w@mail.gmail.com>
	<CAFAaeRXnOHJ_R8GmSP9=zN2zXug3PTY7pEB=-0O8QcmYNFpGXw@mail.gmail.com>
Message-ID: <CAL3CFcUPCVSXpJL7DosPSYifwbyBd6y1bEX11-W6Nv0SRNKe7w@mail.gmail.com>

Well, use HtmlDiff().make_file(s1, s2) method or provide css for
make_table by yourself.

On Mon, Nov 5, 2012 at 4:50 PM, rail shafigulin
<rail.shafigulin at gmail.com> wrote:
> I tried running the code you have given using Python 3.1.5 and Python 3.3.0.
> The result is always the same and I don't see any highlighting. Here is what
> I did on the Windows command line:
>
> C:\Documents and Settings\shafigulinr>python -c "from difflib import *; s1 =
> ['bacon\n', 'eggs\n', 'ham\n', 'guido\n']; s2 = ['python\n', 'eggy\n',
> 'hamster\n', 'guido\n']; print(HtmlDiff().make_table(s1, s2))" > diff.html
>
> I'm also attaching the result file.
>
> I'm running Python 3.1.5/3.3.0 on a Windows XP Pro Version 2002, SP 3,
> Google Chrome browser, Version 22.0.1229.94 m
>
>
> On Fri, Nov 2, 2012 at 4:46 PM, Andrew Svetlov <andrew.svetlov at gmail.com>
> wrote:
>>
>> Perhaps we have some misunderstanding.
>>
>> I tried:
>>
>> >>> from difflib import *
>> >>> s1 = ['bacon\n', 'eggs\n', 'ham\n', 'guido\n']
>> >>> s2 = ['python\n', 'eggy\n', 'hamster\n', 'guido\n']
>> >>> d.make_table(s1, s2)
>> ... LONG ENOUGH OUTPUT
>>
>> when I've opened that output in browser the differences was definitely
>> highlighted.
>>
>> I've tried it on 3.2, 3.1 is open for security bugs only for now BTW.
>> Please inform me how to reproduce your problem.
>> Also please keep in mind: 3.1 in security-only stage, if your issue has
>> been fixed in 3.2 we'll do nothing to backport fix into 3.1
>>
>> Thanks.
>>
>>
>> On Fri, Nov 2, 2012 at 8:47 PM, rail shafigulin
>> <rail.shafigulin at gmail.com> wrote:
>>>
>>> I can't see any highlighting. I'm attaching diff.html which I generated
>>> using the script provided here,
>>> http://docs.python.org/release/3.1.5/library/difflib.html#a-command-line-interface-to-difflib
>>> . In the script I changed make_file to make_table to demonstrate the effect.
>>> I'm also attaching two text files I used for diff generation.
>>>
>>> I'm running Python 3.1.5 on a Windows XP Pro Version 2002, SP 3.
>>>
>>> Thanks.
>>>
>>>
>>> On Thu, Nov 1, 2012 at 6:34 AM, Andrew Svetlov <andrew.svetlov at gmail.com>
>>> wrote:
>>>>
>>>> It works, at least from my understanding of ?highlighting?.
>>>>
>>>>
>>>> On Tue, Oct 30, 2012 at 9:16 PM, rail shafigulin
>>>> <rail.shafigulin at gmail.com> wrote:
>>>>>
>>>>> The description of HtmlDiff.make_table is inaccurate,
>>>>> http://docs.python.org/release/3.1.5/library/difflib.html#difflib.HtmlDiff.make_table
>>>>> It says the following
>>>>>
>>>>> "Compares fromlines and tolines (lists of strings) and returns a string
>>>>> which is a complete HTML table showing line by line differences with
>>>>> inter-line and intra-line changes highlighted."
>>>>>
>>>>> However non of the rows in the tables are highlighted.
>>>>>
>>>>> There are two possible fixes for this.
>>>>>
>>>>> 1. The documentation is incorrect in describing what should happen when
>>>>> this method is called. Instead of what is says right now it should say that
>>>>> the table is generated without showing any differences.
>>>>> 2. The code does not reflect the documentation, i.e. make_table should
>>>>> generate the html string correctly.
>>>>>
>>>>> I'm running Python 3.1.5 on a Windows Xp Pro Version 2002, SP 3.
>>>>>
>>>>> _______________________________________________
>>>>> docs mailing list
>>>>> docs at python.org
>>>>> http://mail.python.org/mailman/listinfo/docs
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Andrew Svetlov
>>>
>>>
>>
>>
>>
>> --
>> Thanks,
>> Andrew Svetlov
>
>



-- 
Thanks,
Andrew Svetlov

From andrew.svetlov at gmail.com  Mon Nov  5 16:28:50 2012
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Mon, 5 Nov 2012 17:28:50 +0200
Subject: [docs] Inaccurate description of HtmlDiff.make_table,
	Python 3.1.5
In-Reply-To: <CAFAaeRXZ=dsG9MK5ASnHU7GMCc+MObGpAuD6m7nRk+1phcR+=w@mail.gmail.com>
References: <CAFAaeRXf_Fq=Sev4H+eX6+gf4oSK0g0YE5zhZyMiQGtAptx_gQ@mail.gmail.com>
	<CAL3CFcWAdaAHfXv+qp6epTVN5cQMwRT7YSLv9et2ZEVgRkJMEw@mail.gmail.com>
	<CAFAaeRWwu0Rgn_PW3N242qx3bRyh243kSEUJM_ePxyztOamYRQ@mail.gmail.com>
	<CAL3CFcW+v2Rto2L7bL+=zRwK3rKgdOxJrQNbx3tn329yC_pj2w@mail.gmail.com>
	<CAFAaeRXnOHJ_R8GmSP9=zN2zXug3PTY7pEB=-0O8QcmYNFpGXw@mail.gmail.com>
	<CAL3CFcUPCVSXpJL7DosPSYifwbyBd6y1bEX11-W6Nv0SRNKe7w@mail.gmail.com>
	<CAFAaeRXZ=dsG9MK5ASnHU7GMCc+MObGpAuD6m7nRk+1phcR+=w@mail.gmail.com>
Message-ID: <CAL3CFcWswzWPbt8GVXjUKGyu84Z7_d=MXduQSfWKXLZsPdPAMw@mail.gmail.com>

The code definitely should  be unchanged. About documentation: it
would be useful to enumerate used css classes with appropriate
description for each one.
Would you make an issue with patch?

On Mon, Nov 5, 2012 at 5:17 PM, rail shafigulin
<rail.shafigulin at gmail.com> wrote:
> That's what I meant by inaccurate description. Documentation for make_table
> says that the differences will be highlighted,
> http://docs.python.org/release/3.1.5/library/difflib.html#difflib.HtmlDiff.make_table,
> while the output shows that it isn't. Either documentation needs to be fixed
> not to say that differences will be highlighted or the code needs to be
> fixed to generate appropriate highlighting.
>
> Thanks.
>
>
> On Mon, Nov 5, 2012 at 10:04 AM, Andrew Svetlov <andrew.svetlov at gmail.com>
> wrote:
>>
>> Well, use HtmlDiff().make_file(s1, s2) method or provide css for
>> make_table by yourself.
>>
>> On Mon, Nov 5, 2012 at 4:50 PM, rail shafigulin
>> <rail.shafigulin at gmail.com> wrote:
>> > I tried running the code you have given using Python 3.1.5 and Python
>> > 3.3.0.
>> > The result is always the same and I don't see any highlighting. Here is
>> > what
>> > I did on the Windows command line:
>> >
>> > C:\Documents and Settings\shafigulinr>python -c "from difflib import *;
>> > s1 =
>> > ['bacon\n', 'eggs\n', 'ham\n', 'guido\n']; s2 = ['python\n', 'eggy\n',
>> > 'hamster\n', 'guido\n']; print(HtmlDiff().make_table(s1, s2))" >
>> > diff.html
>> >
>> > I'm also attaching the result file.
>> >
>> > I'm running Python 3.1.5/3.3.0 on a Windows XP Pro Version 2002, SP 3,
>> > Google Chrome browser, Version 22.0.1229.94 m
>> >
>> >
>> > On Fri, Nov 2, 2012 at 4:46 PM, Andrew Svetlov
>> > <andrew.svetlov at gmail.com>
>> > wrote:
>> >>
>> >> Perhaps we have some misunderstanding.
>> >>
>> >> I tried:
>> >>
>> >> >>> from difflib import *
>> >> >>> s1 = ['bacon\n', 'eggs\n', 'ham\n', 'guido\n']
>> >> >>> s2 = ['python\n', 'eggy\n', 'hamster\n', 'guido\n']
>> >> >>> d.make_table(s1, s2)
>> >> ... LONG ENOUGH OUTPUT
>> >>
>> >> when I've opened that output in browser the differences was definitely
>> >> highlighted.
>> >>
>> >> I've tried it on 3.2, 3.1 is open for security bugs only for now BTW.
>> >> Please inform me how to reproduce your problem.
>> >> Also please keep in mind: 3.1 in security-only stage, if your issue has
>> >> been fixed in 3.2 we'll do nothing to backport fix into 3.1
>> >>
>> >> Thanks.
>> >>
>> >>
>> >> On Fri, Nov 2, 2012 at 8:47 PM, rail shafigulin
>> >> <rail.shafigulin at gmail.com> wrote:
>> >>>
>> >>> I can't see any highlighting. I'm attaching diff.html which I
>> >>> generated
>> >>> using the script provided here,
>> >>>
>> >>> http://docs.python.org/release/3.1.5/library/difflib.html#a-command-line-interface-to-difflib
>> >>> . In the script I changed make_file to make_table to demonstrate the
>> >>> effect.
>> >>> I'm also attaching two text files I used for diff generation.
>> >>>
>> >>> I'm running Python 3.1.5 on a Windows XP Pro Version 2002, SP 3.
>> >>>
>> >>> Thanks.
>> >>>
>> >>>
>> >>> On Thu, Nov 1, 2012 at 6:34 AM, Andrew Svetlov
>> >>> <andrew.svetlov at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> It works, at least from my understanding of ?highlighting?.
>> >>>>
>> >>>>
>> >>>> On Tue, Oct 30, 2012 at 9:16 PM, rail shafigulin
>> >>>> <rail.shafigulin at gmail.com> wrote:
>> >>>>>
>> >>>>> The description of HtmlDiff.make_table is inaccurate,
>> >>>>>
>> >>>>> http://docs.python.org/release/3.1.5/library/difflib.html#difflib.HtmlDiff.make_table
>> >>>>> It says the following
>> >>>>>
>> >>>>> "Compares fromlines and tolines (lists of strings) and returns a
>> >>>>> string
>> >>>>> which is a complete HTML table showing line by line differences with
>> >>>>> inter-line and intra-line changes highlighted."
>> >>>>>
>> >>>>> However non of the rows in the tables are highlighted.
>> >>>>>
>> >>>>> There are two possible fixes for this.
>> >>>>>
>> >>>>> 1. The documentation is incorrect in describing what should happen
>> >>>>> when
>> >>>>> this method is called. Instead of what is says right now it should
>> >>>>> say that
>> >>>>> the table is generated without showing any differences.
>> >>>>> 2. The code does not reflect the documentation, i.e. make_table
>> >>>>> should
>> >>>>> generate the html string correctly.
>> >>>>>
>> >>>>> I'm running Python 3.1.5 on a Windows Xp Pro Version 2002, SP 3.
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> docs mailing list
>> >>>>> docs at python.org
>> >>>>> http://mail.python.org/mailman/listinfo/docs
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Thanks,
>> >>>> Andrew Svetlov
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Thanks,
>> >> Andrew Svetlov
>> >
>> >
>>
>>
>>
>> --
>> Thanks,
>> Andrew Svetlov
>
>



-- 
Thanks,
Andrew Svetlov

From report at bugs.python.org  Mon Nov  5 18:12:47 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 05 Nov 2012 17:12:47 +0000
Subject: [docs] [issue16404] Uses of PyLong_FromLong that don't check for
	errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <1352135567.09.0.23536752572.issue16404@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Mon Nov  5 20:19:47 2012
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 05 Nov 2012 19:19:47 +0000
Subject: [docs] [issue16413] Non cross-platform behavior of os.path.split
In-Reply-To: <1352114668.34.0.500502059895.issue16413@psf.upfronthosting.co.za>
Message-ID: <1352143187.67.0.470010651007.issue16413@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Please submit a patch.

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

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

From report at bugs.python.org  Tue Nov  6 15:16:41 2012
From: report at bugs.python.org (Daniele Varrazzo)
Date: Tue, 06 Nov 2012 14:16:41 +0000
Subject: [docs] [issue16420] PEP 249 (DB-API 2.0) converted to
	reStructuredText
Message-ID: <1352211401.03.0.321684940203.issue16420@psf.upfronthosting.co.za>


New submission from Daniele Varrazzo:

I've converted the DBAPI to reST, mostly to allow linking from external documentation. It would be great to replace the current text only version with it. File attached.

----------
assignee: docs at python
components: Documentation
files: pep-0249.txt
messages: 174965
nosy: docs at python, lemburg, piro
priority: normal
severity: normal
status: open
title: PEP 249 (DB-API 2.0) converted to reStructuredText
type: enhancement
Added file: http://bugs.python.org/file27908/pep-0249.txt

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

From report at bugs.python.org  Tue Nov  6 15:42:53 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Tue, 06 Nov 2012 14:42:53 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
Message-ID: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>


New submission from V?clav ?milauer:

This issue was split off issue16194 (I am not copying the whole discussion here). It was suggested a new issue is opened for Python3, where a proper fix can be done.

Python internally caches dynamically loaded modules, but the cache is based on the filename only. If one file contains several modules, only the first of them is imported and initialized properly. This interface was previously exposed via imp.load_dynamic, the same codepath is used by importlib.machinery.ExtensionFileLoader now.

A solution is to cache by the (filename, modulename) tuple, which avoids any ambiguity.

I am attaching a simple patch for that, agains current hg tip (80272:ec00f8570c55), and tested with the scripot attached to issue16194.

I have not modified the test suite, I am not sure whether testing compiled modules is actually supported (did not see any compiled files in there), I will be glad for help.

----------
components: Extension Modules
files: many-modules-in-one-so_1.diff
keywords: patch
messages: 174967
nosy: Arfrever, amaury.forgeotdarc, brett.cannon, docs at python, eudoxos, ncoghlan, r.david.murray
priority: normal
severity: normal
status: open
title: importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file27909/many-modules-in-one-so_1.diff

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

From report at bugs.python.org  Tue Nov  6 15:54:36 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 06 Nov 2012 14:54:36 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352213676.72.0.232876824898.issue16421@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Storing several modules in single so/pyd file is crazy idea from my perspective.

The test is definitely required.

BTW, Why version is set to 3.5?
Should component be set to "Interpreter code"?

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

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

From report at bugs.python.org  Tue Nov  6 15:59:06 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 06 Nov 2012 14:59:06 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352213946.23.0.309007058098.issue16421@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

It's not that crazy, if you consider that all builtin modules are stored in python33.dll.

----------

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

From report at bugs.python.org  Tue Nov  6 15:59:58 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Tue, 06 Nov 2012 14:59:58 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352213998.55.0.261765664416.issue16421@psf.upfronthosting.co.za>


V?clav ?milauer added the comment:

Storing several modules in one .so file offloads some issues which have to be dealt with manually (like one module needing symbols from other module, or even cross-dependencies) to the linker. In any case, unless forbidden and signalled, it should be supported.

I set version to 3.4 and component to "Interpreter core", as you suggested, it is probably more appropriate.

How do I write test which requires a custom module to be compiled?

----------

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

From report at bugs.python.org  Tue Nov  6 16:08:12 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Tue, 06 Nov 2012 15:08:12 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352214492.05.0.454600486501.issue16421@psf.upfronthosting.co.za>


Changes by V?clav ?milauer <eu at doxos.eu>:


----------
components: +Interpreter Core -Extension Modules
versions: +Python 3.4 -Python 3.5

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

From report at bugs.python.org  Tue Nov  6 16:09:30 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 06 Nov 2012 15:09:30 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352214570.6.0.548749368558.issue16421@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Amaury, I'm ok with pushing several modules into python33.dll or embedding it directly into executable. 
For standard so/dll files you have to use different file names for modules to make regular import statement work. It can be done via symlink/hardlink, but looks a bit hairy.

V?clav, python already have _testbuffer and _testcapi modules used for testing only. I think you can add yet another one.

----------

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

From report at bugs.python.org  Tue Nov  6 16:10:40 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Nov 2012 15:10:40 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352214640.56.0.713426393004.issue16421@psf.upfronthosting.co.za>


R. David Murray added the comment:

There is an example in the test suite somewhere.  Probably in the distutils tests.  Search for xxmodule...but you'll need to create your own source.  I'd see if you can write it out from the test rather than checking in another data file, but a data file is an option if needed.

----------
components: +Extension Modules -Interpreter Core
type: behavior -> enhancement

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

From report at bugs.python.org  Tue Nov  6 16:12:03 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Tue, 06 Nov 2012 15:12:03 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352214723.65.0.606102016752.issue16421@psf.upfronthosting.co.za>


V?clav ?milauer added the comment:

@Andrew: I was using symlinks to achieve this, until I found recently that some exotic systems (read: windows) have still troubles there, like not letting non-admins create symlinks.

----------
type: enhancement -> behavior
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Tue Nov  6 16:13:44 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Tue, 06 Nov 2012 15:13:44 +0000
Subject: [docs] [issue16194] imp.load_dynamic imports wrong module when
	called	several times on a multi-module .so
In-Reply-To: <1349953870.22.0.50760531633.issue16194@psf.upfronthosting.co.za>
Message-ID: <1352214824.7.0.264827257372.issue16194@psf.upfronthosting.co.za>


V?clav ?milauer added the comment:

issue16421 was opened for py3k. Just for the sport of writing, I fixed that in python 2.7 (tip) as well, though other seemed to defend the view it was not a bug, hence not fixable in 2.7.

----------
keywords: +patch
versions:  -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27910/py2_many-modules-in-one-so_1.diff

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

From report at bugs.python.org  Tue Nov  6 16:16:54 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Nov 2012 15:16:54 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352215014.03.0.211605970658.issue16421@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sorry, didn't mean to change the component back.

----------
components: +Interpreter Core -Extension Modules
type: behavior -> enhancement
versions: +Python 3.4 -Python 3.5

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

From report at bugs.python.org  Tue Nov  6 16:29:46 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 06 Nov 2012 15:29:46 +0000
Subject: [docs] [issue16420] PEP 249 (DB-API 2.0) converted to
	reStructuredText
In-Reply-To: <1352211401.03.0.321684940203.issue16420@psf.upfronthosting.co.za>
Message-ID: <1352215781.79.0.378358364708.issue16420@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Original file has been changed just now.
Also it would be nice to get diff, not just new file (to check correctness of transition).

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

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

From report at bugs.python.org  Tue Nov  6 16:33:56 2012
From: report at bugs.python.org (Daniele Varrazzo)
Date: Tue, 06 Nov 2012 15:33:56 +0000
Subject: [docs] [issue16420] PEP 249 (DB-API 2.0) converted to
	reStructuredText
In-Reply-To: <1352211401.03.0.321684940203.issue16420@psf.upfronthosting.co.za>
Message-ID: <1352216036.43.0.595689672459.issue16420@psf.upfronthosting.co.za>


Daniele Varrazzo added the comment:

Andrew, I've probably changed every single line (as almost all the original was indented), so diff wouldn't show anything useful.

----------

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

From report at bugs.python.org  Tue Nov  6 16:43:33 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 06 Nov 2012 15:43:33 +0000
Subject: [docs] [issue16420] PEP 249 (DB-API 2.0) converted to
	reStructuredText
In-Reply-To: <1352216036.43.0.595689672459.issue16420@psf.upfronthosting.co.za>
Message-ID: <50993020.8070704@egenix.com>


Marc-Andre Lemburg added the comment:

On 06.11.2012 16:33, Daniele Varrazzo wrote:
> 
> Daniele Varrazzo added the comment:
> 
> Andrew, I've probably changed every single line (as almost all the original was indented), so diff wouldn't show anything useful.

I'll go through the text and double check for typos.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Nov 06 2012)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

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

From report at bugs.python.org  Tue Nov  6 16:54:14 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Tue, 06 Nov 2012 15:54:14 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352217253.72.0.843396152373.issue16421@psf.upfronthosting.co.za>


V?clav ?milauer added the comment:

I added the test, with a module Modules/_testimportmultiple.c.

The test uses the (undocumented) imp module, but all othet tests in Lib/test/test_imp.py do the same, so I assume it is OK?

----------
Added file: http://bugs.python.org/file27911/many-modules-in-one-so_2.diff

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

From report at bugs.python.org  Tue Nov  6 17:39:44 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 06 Nov 2012 16:39:44 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352219984.21.0.795981565087.issue16421@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It's fine to cheat in tests, although test_imp predates importlib which is why it uses an undocumented API.

----------

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

From andrew.svetlov at gmail.com  Tue Nov  6 20:52:03 2012
From: andrew.svetlov at gmail.com (andrew.svetlov at gmail.com)
Date: Tue, 06 Nov 2012 19:52:03 -0000
Subject: [docs] importlib.machinery.ExtensionFileLoader cannot load several
 modules from the same shared object (issue 16421)
Message-ID: <20121106195203.21672.10288@psf.upfronthosting.co.za>

Respect Windows: make projects for test module in PC/VS9.0 and PCBuild,
add these projects into corresponding pcbuild.sln
Also mention test module in Tools/msi/msi.py

Thanks for patch!


http://bugs.python.org/review/16421/diff/6527/Lib/test/test_imp.py
File Lib/test/test_imp.py (right):

http://bugs.python.org/review/16421/diff/6527/Lib/test/test_imp.py#newcode223
Lib/test/test_imp.py:223: f = imp.find_module(m)[1]
file returned from find_module call should be closed at end of test. Use
self.addCleanup

http://bugs.python.org/review/16421/diff/6527/Python/import.c
File Python/import.c (right):

http://bugs.python.org/review/16421/diff/6527/Python/import.c#newcode508
Python/import.c:508: PyDict_SetItem(extensions, PyTuple_Pack(2,filename,
name), (PyObject*)def);
check result of PyTuple_Pack and PyDict_SetItem, return -1 if error.

http://bugs.python.org/review/16421/diff/6527/Python/import.c#newcode532
Python/import.c:532: def = (PyModuleDef*)PyDict_GetItem(extensions,
PyTuple_Pack(2, filename, name));
check result of PyTuple_Pack, return NULL if error

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

From report at bugs.python.org  Tue Nov  6 20:52:47 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 06 Nov 2012 19:52:47 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352231567.21.0.278278702685.issue16421@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Reviewed and commented the last patch.

----------

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

From report at bugs.python.org  Wed Nov  7 04:28:02 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Wed, 07 Nov 2012 03:28:02 +0000
Subject: [docs] [issue16423] urllib data URL recipe
Message-ID: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>


New submission from Mathias Panzenb?ck:

I think it would be really helpful if urllib would support data URLs. However, I was told on the python-ideas mailing list that it would probably only added as recipe in the documentation. The attached patch adds such an recipe to the urllib.request documentation. I've never written a doc patch (or any patch) for python before, so I don't know if I added it at the right place in the right format.

----------
assignee: docs at python
components: Documentation
files: doc-urllib.request-data-url-recipe.patch
hgrepos: 160
keywords: patch
messages: 175041
nosy: docs at python, panzi
priority: normal
severity: normal
status: open
title: urllib data URL recipe
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file27914/doc-urllib.request-data-url-recipe.patch

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

From report at bugs.python.org  Wed Nov  7 06:08:37 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 07 Nov 2012 05:08:37 +0000
Subject: [docs] [issue16423] urllib data URL recipe
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1352264917.81.0.345135183019.issue16423@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


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

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

From report at bugs.python.org  Wed Nov  7 06:17:26 2012
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 07 Nov 2012 05:17:26 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1352265446.54.0.22977772835.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Chris,
   That is an excellent suggestion.  I modified my OSRenameCombinations.py program and attached.  This program prints a table with the src parameters as columns and the dst as rows.  Hopefully it will show up ok in the bug tracker.


For Unix
                              src_file                       src_directory_empty            src_directory_not_empty        src_file_or_directory_not_exist 
dst_file_exist                 rename overwrite               raises OSError                 raises OSError                 raises OSError                 
dst_not_exist                  rename                         rename                         rename                         raises OSError                 
dst_directory_empty            raises OSError                 rename overwrite               rename overwrite               raises OSError                 
dst_directory_not_empty        raises OSError                 raises OSError                 raises OSError                 raises OSError                 
For Windows
                              src_file                       src_directory_empty            src_directory_not_empty        src_file_or_directory_not_exist 
dst_file_exist                 raises OSError                 raises OSError                 raises OSError                 raises OSError                 
dst_not_exist                  rename                         rename                         rename                         raises OSError                 
dst_directory_empty            raises OSError                 raises FileExistsError         raises FileExistsError         raises OSError                 
dst_directory_not_empty        raises OSError                 raises OSError                 raises OSError                 raises OSError

----------
Added file: http://bugs.python.org/file27915/OSRenameCombinations.py

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

From report at bugs.python.org  Wed Nov  7 09:35:12 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 07 Nov 2012 08:35:12 +0000
Subject: [docs] [issue16413] Non cross-platform behavior of os.path.split
In-Reply-To: <1352114668.34.0.500502059895.issue16413@psf.upfronthosting.co.za>
Message-ID: <1352277312.83.0.331311231853.issue16413@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

I don't know about the differences. An expert is required.

----------

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

From report at bugs.python.org  Wed Nov  7 09:46:59 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 07 Nov 2012 08:46:59 +0000
Subject: [docs] [issue16420] PEP 249 (DB-API 2.0) converted to
	reStructuredText
In-Reply-To: <1352211401.03.0.321684940203.issue16420@psf.upfronthosting.co.za>
Message-ID: <1352278019.33.0.285191054202.issue16420@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

For some reason, the roundup bot didn't pick up the check in, so here's the reference by hand:

http://hg.python.org/peps/rev/95a73d5a3af7
changeset:   4578:95a73d5a3af7
user:        Marc-Andre Lemburg <mal at egenix.com>
date:        Wed Nov 07 09:42:07 2012 +0100
summary:
  Issue #16420:
Convert PEP 249 (DB-API 2.0) to ReST format to allow linking to the
various parts.

The conversion was done mostly by Daniele Varrazzo.

----------

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

From report at bugs.python.org  Wed Nov  7 09:47:13 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 07 Nov 2012 08:47:13 +0000
Subject: [docs] [issue16420] PEP 249 (DB-API 2.0) converted to
	reStructuredText
In-Reply-To: <1352211401.03.0.321684940203.issue16420@psf.upfronthosting.co.za>
Message-ID: <1352278033.44.0.802118344349.issue16420@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Nov  7 10:45:19 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Wed, 07 Nov 2012 09:45:19 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352281518.14.0.307458879907.issue16421@psf.upfronthosting.co.za>


V?clav ?milauer added the comment:

Attaching patch based on Andrew's review, agains latest hg (80291:859ef54bdce).

For the MSVC files, I copied what was there for _testcapimodule in PC/VS9.0 and PCbuild, and created two new UUIDs: one for _testimportmultiple itself (36D0C52C-DF4E-45D0-8BC7-E294C3ABC781; used in .sln, .vcproj and .vcxproj files), and one for _testimportmultiple.vcxproj.filters (1ec38ad9-1abf-4b80-8628-ac43ccba324b; used only once).

Please check that I did that correctly. (I am wondering how can one maintain such a build system.)

I also added myself to Misc/ACKS (and sent contributor agreement by mail), added the entry to Misc/NEWS.

----------
components: +Extension Modules -Interpreter Core
type: enhancement -> behavior
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file27918/many-modules-in-one-so_3.diff

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

From report at bugs.python.org  Wed Nov  7 12:57:03 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 07 Nov 2012 11:57:03 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352289423.08.0.0859003267152.issue16421@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Looks better, will check on Windows a bit later.

BTW, ACKS and NEWS are usually edited by committer, but leave that as is for now.

----------
versions: +Python 3.4 -Python 3.5

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

From report at bugs.python.org  Wed Nov  7 13:12:05 2012
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=)
Date: Wed, 07 Nov 2012 12:12:05 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352290325.18.0.429442221663.issue16421@psf.upfronthosting.co.za>


V?clav ?milauer added the comment:

Good, will let editors do that next time.

I was following http://docs.python.org/devguide/patch.html#preparation which says "Sixth, if you are not already in the Misc/ACKS file then add your name."

For NEWS, I was reading http://docs.python.org/devguide/committing.html#news-entries, but it is true it talks about commits, not about patches.

----------

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

From report at bugs.python.org  Wed Nov  7 14:48:41 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Nov 2012 13:48:41 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352296121.29.0.744546844852.issue16421@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yeah, ACKS is fine (we just don't mind doing it if the submitter leaves it out). Updating NEWS is less useful because it almost inevitably causes a conflict when the patch is applied. (We occasionally mutter about adopting a less conflict-prone approach to handling NEWS entries, but nobody has ever found it annoying enough to design a solution and officially propose switching to it)

----------

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

From report at bugs.python.org  Wed Nov  7 22:28:24 2012
From: report at bugs.python.org (Andrew Gorcester)
Date: Wed, 07 Nov 2012 21:28:24 +0000
Subject: [docs] [issue16432] Template strings documentation in Python 3
	refers to %	substitution in present tense
Message-ID: <1352323704.72.0.0858754286751.issue16432@psf.upfronthosting.co.za>


New submission from Andrew Gorcester:

Documentation here: http://docs.python.org/3/library/string.html#template-strings says "Instead of the normal %-based substitutions, Templates support $-based substitutions..."

I believe it is confusing to refer to %-based substitutions in a way that implies they still exist in Python 3.  It would be better to fix this to either refer to {} substitution or to remove the reference comparing it to normal string substitution altogether.

----------
assignee: docs at python
components: Documentation
messages: 175123
nosy: andrewsg, docs at python
priority: normal
severity: normal
status: open
title: Template strings documentation in Python 3 refers to % substitution in present tense
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov  7 22:29:12 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 07 Nov 2012 21:29:12 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352323752.39.0.9770161135.issue16421@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

V?clav, your patch passed on Windows.
Will commit it after double check. 
Thanks.

----------
assignee:  -> asvetlov

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

From report at bugs.python.org  Wed Nov  7 22:59:35 2012
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 07 Nov 2012 21:59:35 +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: <1352325575.41.0.00869400892347.issue16432@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Who said % substitution doesn't exist anymore in Python 3?

That said, it's certainly not wrong to replace this with {} substitution.

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

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

From report at bugs.python.org  Wed Nov  7 23:08:17 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Nov 2012 22:08:17 +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: <1352326097.66.0.402663251481.issue16432@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is not a bug.  %-based substitutions exist in Python 3.

http://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Thu Nov  8 01:41:57 2012
From: report at bugs.python.org (Andrew Gorcester)
Date: Thu, 08 Nov 2012 00:41:57 +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: <1352335317.1.0.465080295545.issue16432@psf.upfronthosting.co.za>


Andrew Gorcester added the comment:

Sorry, my mistake -- I thought that %-based formatting had been deprecated and removed by now, because it wasn't documented in library/string.html .  However, I still think referring to %-based formatting as "normal" in Python 3 is confusing to readers as it is not the preferred system.

----------

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

From report at bugs.python.org  Thu Nov  8 05:01:20 2012
From: report at bugs.python.org (Todd Rovito)
Date: Thu, 08 Nov 2012 04:01:20 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1352347279.93.0.861802849409.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Here is a draft suggestion for the documentation change, not all the formatting is worked out:

.. function:: rename(src, dst, *, src_dir_fd=None, dst_dir_fd=None)

   Rename the file or directory *src* to *dst*. If *src* exists as either
   a file or directory and *dst* does not exist the rename will occur with
   no error raised.  In some cases the rename function will behave
   differently across platforms which are noted below. In all cases
   if *src* does not exist :exc: 'OSError' will be raised.

   Unix
   If *dst* exists and is a file, it will be replaced silently if the user
   has permission and src is a file.  If *src* is a directory and *dst* is a
   file :exc: 'OSError' will be raised.  In the case where *src* is a
   directory and *dst* is a empty directory the rename will occur and the
   *src* directory name will overwrite the *dst* directory name.Yet a special
   case is noted where *src* is a directory and *dst* is a non-empty directory
   the rename will not occur and :exc: `OSError` will be raised.  

   Windows
   If *src* is a file and *dst* exists either as a file or directory :exc:
   'OSError` will be raised and the rename will not occur.  In the case where
   *src* is a directory, either empty or not empty, and *dst* exists as a
   file or not empty directory :exc: `OSError` will be raised.  If *src* is
   a directory, either empty or not empty, and *dst* is a empty directory
   then :exc: `FileExistsError` will be raised.
        

   If successful, the renaming will be an atomic operation (this is a POSIX
   requirement).
   
   This function can support specifying *src_dir_fd* and/or *dst_dir_fd* to
   supply :ref:`paths relative to directory descriptors <dir_fd>`.

   If you want cross-platform overwriting of the destination, use
   :func:`replace`.

   Availability: Unix, Windows.

   .. versionadded:: 3.3
      The *src_dir_fd* and *dst_dir_fd* arguments.

----------

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

From report at bugs.python.org  Thu Nov  8 08:55:04 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 07:55:04 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1352361304.79.0.581603737003.issue8939@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

What's the status of this?

----------
type:  -> enhancement
versions: +Python 3.3, Python 3.4 -Python 3.1

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

From report at bugs.python.org  Thu Nov  8 08:58:54 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 07:58:54 +0000
Subject: [docs] [issue10358] Doc styles for print should only use dark colors
In-Reply-To: <1289224086.88.0.0372722217541.issue10358@psf.upfronthosting.co.za>
Message-ID: <1352361533.96.0.694796685937.issue10358@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The docs already have a print stylesheet and its colors looks good to me.

----------
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Nov  8 09:26:58 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 08:26:58 +0000
Subject: [docs] [issue10434] Document the rules for "public names"
In-Reply-To: <1289919338.9.0.394057770971.issue10434@psf.upfronthosting.co.za>
Message-ID: <1352363218.88.0.288039237449.issue10434@psf.upfronthosting.co.za>


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


----------
keywords: +easy
type:  -> enhancement
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 09:29:46 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 08:29:46 +0000
Subject: [docs] [issue10589] I/O ABC docs should specify which methods
	have	implementations
In-Reply-To: <1291143953.85.0.0204032538698.issue10589@psf.upfronthosting.co.za>
Message-ID: <1352363386.92.0.909058523173.issue10589@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> patch review
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 09:31:55 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 08:31:55 +0000
Subject: [docs] [issue11479] Add discussion of trailing slash in raw string
	to	tutorial
In-Reply-To: <1299985803.24.0.199507309731.issue11479@psf.upfronthosting.co.za>
Message-ID: <1352363515.06.0.931674177332.issue11479@psf.upfronthosting.co.za>


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


----------
type: behavior -> enhancement
versions: +Python 3.4 -Python 3.1

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

From report at bugs.python.org  Thu Nov  8 09:34:04 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 08:34:04 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1352363644.88.0.402825712546.issue11974@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 09:35:00 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 08:35:00 +0000
Subject: [docs] [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1352363700.26.0.631888798101.issue11762@psf.upfronthosting.co.za>


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


----------
keywords: +easy -patch
type:  -> enhancement
versions: +Python 3.4 -Python 3.1

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

From report at bugs.python.org  Thu Nov  8 09:36:48 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 08:36:48 +0000
Subject: [docs] [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1352363808.36.0.929758406788.issue8824@psf.upfronthosting.co.za>


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


----------
nosy: +mark.dickinson
type:  -> enhancement
versions: +Python 3.4 -Python 3.1

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

From report at bugs.python.org  Thu Nov  8 09:37:48 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 08:37:48 +0000
Subject: [docs] [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1352363868.89.0.570152315026.issue12077@psf.upfronthosting.co.za>


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


----------
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Thu Nov  8 09:41:12 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 08:41:12 +0000
Subject: [docs] [issue11975] Fix referencing of built-in types (list, int,
	...)
In-Reply-To: <1304281262.53.0.265979216697.issue11975@psf.upfronthosting.co.za>
Message-ID: <1352364072.67.0.798104867431.issue11975@psf.upfronthosting.co.za>


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


----------
nosy: +chris.jerdonek
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Thu Nov  8 09:48:02 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 08:48:02 +0000
Subject: [docs] [issue12645] test.support. import_fresh_module - incorrect
	doc
In-Reply-To: <1311789815.76.0.639942891335.issue12645@psf.upfronthosting.co.za>
Message-ID: <1352364482.43.0.2729230979.issue12645@psf.upfronthosting.co.za>


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


----------
nosy: +ncoghlan
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Thu Nov  8 10:06:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Nov 2012 09:06:31 +0000
Subject: [docs] [issue11481] The copy module already uses copyreg
In-Reply-To: <1300009670.98.0.0546201477777.issue11481@psf.upfronthosting.co.za>
Message-ID: <3XxzBY6X9xzM1V@mail.python.org>


Roundup Robot added the comment:

New changeset 2bd6150b48ea by Ezio Melotti in branch '2.7':
#11481: update copy_reg docs and add example.
http://hg.python.org/cpython/rev/2bd6150b48ea

New changeset e089bdca9d9c by Ezio Melotti in branch '2.7':
#11481: fix markup.
http://hg.python.org/cpython/rev/e089bdca9d9c

New changeset 12dbb3187105 by Ezio Melotti in branch '3.2':
#11481: update copyreg docs and add example.
http://hg.python.org/cpython/rev/12dbb3187105

New changeset 87ec3ce3a04e by Ezio Melotti in branch '3.3':
#11481: merge with 3.2.
http://hg.python.org/cpython/rev/87ec3ce3a04e

New changeset 20b65b88e0a0 by Ezio Melotti in branch 'default':
#11481: merge with 3.3.
http://hg.python.org/cpython/rev/20b65b88e0a0

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

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

From report at bugs.python.org  Thu Nov  8 10:07:21 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 09:07:21 +0000
Subject: [docs] [issue11481] The copy module already uses copyreg
In-Reply-To: <1300009670.98.0.0546201477777.issue11481@psf.upfronthosting.co.za>
Message-ID: <1352365641.8.0.326517983147.issue11481@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I made a few minor changes and applied the patch.

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

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

From report at bugs.python.org  Thu Nov  8 11:39:16 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Nov 2012 10:39:16 +0000
Subject: [docs] [issue11479] Add discussion of trailing backslash in raw
	string to	tutorial
In-Reply-To: <1299985803.24.0.199507309731.issue11479@psf.upfronthosting.co.za>
Message-ID: <1352371156.35.0.48799528002.issue11479@psf.upfronthosting.co.za>


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


----------
title: Add discussion of trailing slash in raw string to tutorial -> Add discussion of trailing backslash in raw string to tutorial

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

From report at bugs.python.org  Thu Nov  8 14:50:12 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 13:50:12 +0000
Subject: [docs] [issue16435] Python 3 doc link to Python 2 FAQ
Message-ID: <1352382611.96.0.563665281353.issue16435@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

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

The last paragraph links to http://www.python.org/doc/faq/, which defaults to Python 2 FAQ.

----------
assignee: docs at python
components: Documentation
messages: 175156
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Python 3 doc link to Python 2 FAQ
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov  8 14:59:17 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 13:59:17 +0000
Subject: [docs] [issue16436] Missing anchor in doc
Message-ID: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/library/functions.html#func-frozenset

http://docs.python.org/3/library/functions.html#func-set

frozenset and set function have no links to their definitions. Also the anchor name is prefixed with func, which is different to other builtin functions.

----------
assignee: docs at python
components: Documentation
messages: 175157
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Missing anchor in doc
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 15:04:41 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 14:04:41 +0000
Subject: [docs] [issue16437] issubclass doc improvement
Message-ID: <1352383480.96.0.515607744563.issue16437@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/library/functions.html#issubclass

"classinfo may be a tuple of class objects."

I suggest make it clear like isinstance, use something like this:

classinfo may be a tuple of class objects and such tuples.

----------
assignee: docs at python
components: Documentation
messages: 175158
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: issubclass doc improvement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 15:07:06 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 08 Nov 2012 14:07:06 +0000
Subject: [docs] [issue16436] Missing anchor in doc
In-Reply-To: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>
Message-ID: <1352383626.2.0.866067428826.issue16436@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

I guess the reason is that names are classes, not functions. See http://docs.python.org/3/library/functions.html#func-dict also for example.

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

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

From report at bugs.python.org  Thu Nov  8 15:11:57 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Nov 2012 14:11:57 +0000
Subject: [docs] [issue16435] Python 3 doc link to Python 2 FAQ
In-Reply-To: <1352382611.96.0.563665281353.issue16435@psf.upfronthosting.co.za>
Message-ID: <3Xy5z025yfzMPk@mail.python.org>


Roundup Robot added the comment:

New changeset 64527cb2e13a by Andrew Svetlov in branch '3.2':
Issue #16435: Link in tutorial now points to python3 FAQ.
http://hg.python.org/cpython/rev/64527cb2e13a

New changeset 1d5ca20f73e2 by Andrew Svetlov in branch '3.3':
Merge issue #16435: Link in tutorial now points to python3 FAQ.
http://hg.python.org/cpython/rev/1d5ca20f73e2

New changeset e1e019b3d903 by Andrew Svetlov in branch 'default':
Merge issue #16435: Link in tutorial now points to python3 FAQ.
http://hg.python.org/cpython/rev/e1e019b3d903

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

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

From report at bugs.python.org  Thu Nov  8 15:12:59 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 08 Nov 2012 14:12:59 +0000
Subject: [docs] [issue16435] Python 3 doc link to Python 2 FAQ
In-Reply-To: <1352382611.96.0.563665281353.issue16435@psf.upfronthosting.co.za>
Message-ID: <1352383979.93.0.445414338757.issue16435@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed. Thanks.

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

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

From report at bugs.python.org  Thu Nov  8 15:13:22 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 08 Nov 2012 14:13:22 +0000
Subject: [docs] [issue16435] Python 3 doc link to Python 2 FAQ
In-Reply-To: <1352382611.96.0.563665281353.issue16435@psf.upfronthosting.co.za>
Message-ID: <1352384002.16.0.934786850513.issue16435@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From report at bugs.python.org  Thu Nov  8 15:19:31 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 14:19:31 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
Message-ID: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex

"All numeric types (except complex) support the following operations, sorted by ascending priority."

It list '-' after '+', '/' after '*'. That is to mean '-' has higher precedence than '+'. That is wrong, and is contradicting with here:

http://docs.python.org/3/reference/expressions.html#summary

This should be made clear.

----------
assignee: docs at python
components: Documentation
messages: 175163
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Numeric operator predecence confusing
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 15:20:27 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 08 Nov 2012 14:20:27 +0000
Subject: [docs] [issue16436] Missing anchor in doc
In-Reply-To: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>
Message-ID: <1352384427.94.0.423761821806.issue16436@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Thu Nov  8 15:27:06 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 08 Nov 2012 14:27:06 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1352384826.64.0.821724728653.issue16438@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Precedence ordered per row. Same row, same precedence. I don't see any problem. It is natural math precedence. Closed as invalid.

----------
nosy: +jcea
resolution:  -> invalid

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

From report at bugs.python.org  Thu Nov  8 15:30:58 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Nov 2012 14:30:58 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1352385058.16.0.160513070023.issue16438@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Nov  8 16:08:23 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 15:08:23 +0000
Subject: [docs] [issue16439] Code not collapsed correctly
Message-ID: <1352387303.13.0.2311383576.issue16439@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/library/stdtypes.html#str.title

The second snippets is not collapsed correctly.

----------
assignee: docs at python
components: Documentation
messages: 175171
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Code not collapsed correctly
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 16:16:08 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 08 Nov 2012 15:16:08 +0000
Subject: [docs] [issue16439] Code not collapsed correctly
In-Reply-To: <1352387303.13.0.2311383576.issue16439@psf.upfronthosting.co.za>
Message-ID: <1352387768.7.0.144582267577.issue16439@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Thu Nov  8 16:18:05 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 15:18:05 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1352387885.5.0.00872374468759.issue16438@psf.upfronthosting.co.za>


Yongzhi Pan added the comment:

I mean the text at the first link need fix. '+' and '-' are not on the same row. And the doc says: "sorted by ascending priority", that means they have ascending priority.

The table in the reference is just right.

----------

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

From report at bugs.python.org  Thu Nov  8 16:19:21 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 08 Nov 2012 15:19:21 +0000
Subject: [docs] [issue16439] Code not collapsed correctly
In-Reply-To: <1352387303.13.0.2311383576.issue16439@psf.upfronthosting.co.za>
Message-ID: <1352387961.96.0.134997509518.issue16439@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Looks like a sphinx bug :-??.

----------

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

From report at bugs.python.org  Thu Nov  8 16:22:55 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 08 Nov 2012 15:22:55 +0000
Subject: [docs] [issue16440] Exception type
Message-ID: <1352388175.4.0.551627843013.issue16440@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

http://docs.python.org/3/library/stdtypes.html#methods

"Attempting to set a method attribute results in a TypeError being raised."

But in the example, if we do c.method.whoami = 'c', we get AttributeError instead of TypeError.

----------
assignee: docs at python
components: Documentation
messages: 175174
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Exception type
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 16:23:39 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 08 Nov 2012 15:23:39 +0000
Subject: [docs] [issue16439] Code not collapsed correctly
In-Reply-To: <1352387303.13.0.2311383576.issue16439@psf.upfronthosting.co.za>
Message-ID: <1352388219.72.0.477172954466.issue16439@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

No, it isn't sphinx bug, it's markup problem.
Will commit a fix in few minutes.

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

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

From report at bugs.python.org  Thu Nov  8 16:29:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Nov 2012 15:29:14 +0000
Subject: [docs] [issue16439] Code not collapsed correctly
In-Reply-To: <1352387303.13.0.2311383576.issue16439@psf.upfronthosting.co.za>
Message-ID: <3Xy7h950nGzN6c@mail.python.org>


Roundup Robot added the comment:

New changeset aeb5c53a1d69 by Andrew Svetlov in branch '3.2':
Issue #16439: Fix markup in example for stdtypes.
http://hg.python.org/cpython/rev/aeb5c53a1d69

New changeset 65499860c6f8 by Andrew Svetlov in branch '3.3':
Merge issue #16439: Fix markup in example for stdtypes.
http://hg.python.org/cpython/rev/65499860c6f8

New changeset ce6fc4531d26 by Andrew Svetlov in branch 'default':
Merge issue #16439: Fix markup in example for stdtypes.
http://hg.python.org/cpython/rev/ce6fc4531d26

New changeset f068c3e7743d by Andrew Svetlov in branch '2.7':
Issue #16439: Fix markup in example for stdtypes.
http://hg.python.org/cpython/rev/f068c3e7743d

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

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

From report at bugs.python.org  Thu Nov  8 16:29:14 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 08 Nov 2012 15:29:14 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1352388554.94.0.472813916593.issue16438@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

You are right, Yongzhi Pan. Reopening. Not sure how to solve it. Delegating to docs at python.

----------
resolution: invalid -> 
status: closed -> open

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

From report at bugs.python.org  Thu Nov  8 16:29:51 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 08 Nov 2012 15:29:51 +0000
Subject: [docs] [issue16439] Code not collapsed correctly
In-Reply-To: <1352387303.13.0.2311383576.issue16439@psf.upfronthosting.co.za>
Message-ID: <1352388591.61.0.9404781935.issue16439@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed. Thanks.

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

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

From report at bugs.python.org  Thu Nov  8 17:19:08 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 08 Nov 2012 16:19:08 +0000
Subject: [docs] [issue16439] Code not collapsed correctly
In-Reply-To: <1352387303.13.0.2311383576.issue16439@psf.upfronthosting.co.za>
Message-ID: <1352391548.52.0.547057456208.issue16439@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Good catch. I was not aware of this feature :-).

----------

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

From report at bugs.python.org  Thu Nov  8 21:07:12 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 08 Nov 2012 20:07:12 +0000
Subject: [docs] [issue16443] Add docstrings to regular expression match
	objects
Message-ID: <1352405232.66.0.722959472058.issue16443@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The match objects currently do not have useful docstrings.  An easy task is to add docstrings modeled after the text in the regular docs.

  import re
  mo = re.search('abc', 'abc')
  help(mo)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 175188
nosy: docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Add docstrings to regular expression match objects
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  8 21:42:47 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 08 Nov 2012 20:42:47 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1352407367.8.0.96913475287.issue16438@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Nov  8 22:02:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 08 Nov 2012 21:02:35 +0000
Subject: [docs] [issue16436] Missing anchor in doc
In-Reply-To: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>
Message-ID: <1352408555.38.0.840943227369.issue16436@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Currently, the built-in types are not treated consistently as to whether their constructors are documented in the "Built-in Functions" or "Built-in Types" page.  There are some open issues related to this topic (see, for example, issue 16209).

For the purposes of this issue though, yes, I agree that the abbreviated built-in function versions of the documentation for set and frozenset should contain direct links to the more complete constructor documentation in the "Built-in Types" page (as is already done for dict, for example, as Andrew pointed out).

----------
nosy: +chris.jerdonek

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

From report at bugs.python.org  Thu Nov  8 22:03:53 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 08 Nov 2012 21:03:53 +0000
Subject: [docs] [issue16436] Missing anchor in doc
In-Reply-To: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>
Message-ID: <1352408633.54.0.297577018286.issue16436@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


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

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

From report at bugs.python.org  Thu Nov  8 22:31:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 08 Nov 2012 21:31:11 +0000
Subject: [docs] [issue16436] Link directly to set and frozenset in built-in
	function	docs
In-Reply-To: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>
Message-ID: <1352410271.96.0.532781845424.issue16436@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
title: Missing anchor in doc -> Link directly to set and frozenset in built-in function docs
type:  -> enhancement
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Nov  8 22:39:25 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 08 Nov 2012 21:39:25 +0000
Subject: [docs] [issue16436] Link directly to set and frozenset in built-in
	function	docs
In-Reply-To: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>
Message-ID: <1352410765.82.0.653775563323.issue16436@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I recommend copying for set and frozenset the documentation pattern for dict (and in particular by stating explicitly in its own sentence that the object is a class):

http://docs.python.org/3/library/functions.html#func-dict

----------

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

From report at bugs.python.org  Thu Nov  8 22:56:57 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 21:56:57 +0000
Subject: [docs] [issue16443] Add docstrings to regular expression match
	objects
In-Reply-To: <1352405232.66.0.722959472058.issue16443@psf.upfronthosting.co.za>
Message-ID: <1352411817.5.0.286624482446.issue16443@psf.upfronthosting.co.za>


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


----------
components: +Regular Expressions
nosy: +ezio.melotti, mrabarnett
stage:  -> needs patch
versions:  -Python 3.1

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

From report at bugs.python.org  Thu Nov  8 23:01:20 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 22:01:20 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1352412080.17.0.575889477381.issue16438@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/issue16438>
_______________________________________

From report at bugs.python.org  Thu Nov  8 23:17:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 08 Nov 2012 22:17:35 +0000
Subject: [docs] [issue16435] Python 3 doc link to Python 2 FAQ
In-Reply-To: <1352382611.96.0.563665281353.issue16435@psf.upfronthosting.co.za>
Message-ID: <1352413055.01.0.611819793696.issue16435@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Isn't it better to do this type of within-doc linking with a :ref: (which would prevent issues like this)?

----------
nosy: +chris.jerdonek

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

From report at bugs.python.org  Thu Nov  8 23:29:03 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 22:29:03 +0000
Subject: [docs] [issue16440] Exception type
In-Reply-To: <1352388175.4.0.551627843013.issue16440@psf.upfronthosting.co.za>
Message-ID: <1352413743.34.0.054264599897.issue16440@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  9 00:09:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Nov 2012 23:09:48 +0000
Subject: [docs] [issue16440] Exception type
In-Reply-To: <1352388175.4.0.551627843013.issue16440@psf.upfronthosting.co.za>
Message-ID: <3XyKvb6N8wzPsn@mail.python.org>


Roundup Robot added the comment:

New changeset 8b181c75792f by Ezio Melotti in branch '2.7':
#16440: fix exception type and clarify example.
http://hg.python.org/cpython/rev/8b181c75792f

New changeset bb39ca6bcd7a by Ezio Melotti in branch '3.2':
#16440: fix exception type and clarify example.
http://hg.python.org/cpython/rev/bb39ca6bcd7a

New changeset 8c7f2f6f3375 by Ezio Melotti in branch '3.3':
#16440: merge with 3.2.
http://hg.python.org/cpython/rev/8c7f2f6f3375

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

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

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

From report at bugs.python.org  Fri Nov  9 00:10:57 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 23:10:57 +0000
Subject: [docs] [issue16440] Exception type
In-Reply-To: <1352388175.4.0.551627843013.issue16440@psf.upfronthosting.co.za>
Message-ID: <1352416257.6.0.690785827053.issue16440@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

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

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

From report at bugs.python.org  Fri Nov  9 00:46:28 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Nov 2012 23:46:28 +0000
Subject: [docs] [issue16437] issubclass doc improvement
In-Reply-To: <1352383480.96.0.515607744563.issue16437@psf.upfronthosting.co.za>
Message-ID: <1352418388.79.0.681492891513.issue16437@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

While this is documented for isinstance, I'm not sure it should be advertised too much, as it seems to me an implementation detail and doesn't seem too useful in practice.

This is a side-effect of the fact that
  isinstance(x, (A, B, ...))
is equivalent to
  isinstance(x, A) or isinstance(x, B) or ...
and therefore
  isinstance(x, (A, (B, C)))
is equivalent to
  isinstance(x, A) or isinstance(x, (B, C))
which in turn is equivalent to
  isinstance(x, A) or (isinstance(x, B) or isinstance(x, C))

While this behavior seems intentional [0], it doesn't seem to be tested [1].  FTR this is supported by PyPy too.

[0]: http://hg.python.org/cpython/file/default/Objects/abstract.c#l2494
[1]: http://hg.python.org/cpython/file/default/Lib/test/test_builtin.py#l704

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

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

From report at bugs.python.org  Fri Nov  9 15:28:11 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Nov 2012 14:28:11 +0000
Subject: [docs] [issue16443] Add docstrings to regular expression match
	objects
In-Reply-To: <1352405232.66.0.722959472058.issue16443@psf.upfronthosting.co.za>
Message-ID: <1352471291.7.0.591657993303.issue16443@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Do you mean http://docs.python.org/2/library/re.html#match-objects ?
This doesn't seem to say anything too useful.

----------

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

From report at bugs.python.org  Fri Nov  9 16:01:05 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Nov 2012 15:01:05 +0000
Subject: [docs] [issue13574] refresh example in doc for Extending and
	Embedding
In-Reply-To: <1323546725.7.0.960922330938.issue13574@psf.upfronthosting.co.za>
Message-ID: <1352473265.76.0.379315113133.issue13574@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  9 16:04:15 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Nov 2012 15:04:15 +0000
Subject: [docs] [issue15474] Differentiate decorator and decorator factory
	in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1352473455.69.0.775379056816.issue15474@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Fri Nov  9 16:06:19 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Nov 2012 15:06:19 +0000
Subject: [docs] [issue12217] Cross-link docs for faulthandler,
	traceback and pdb
In-Reply-To: <1306770313.4.0.799430970978.issue12217@psf.upfronthosting.co.za>
Message-ID: <1352473579.79.0.419010291399.issue12217@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Fri Nov  9 16:07:07 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Nov 2012 15:07:07 +0000
Subject: [docs] [issue10048] urllib.request documentation confusing
In-Reply-To: <1286535990.46.0.129844190964.issue10048@psf.upfronthosting.co.za>
Message-ID: <1352473627.32.0.300776024374.issue10048@psf.upfronthosting.co.za>


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


----------
type:  -> enhancement
versions: +Python 3.3, Python 3.4 -Python 3.1

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

From report at bugs.python.org  Fri Nov  9 16:10:20 2012
From: report at bugs.python.org (George Peristerakis)
Date: Fri, 09 Nov 2012 15:10:20 +0000
Subject: [docs] [issue16190] Misleading warning in random module docs
In-Reply-To: <1349885590.41.0.193272073786.issue16190@psf.upfronthosting.co.za>
Message-ID: <1352473820.34.0.179713641449.issue16190@psf.upfronthosting.co.za>


Changes by George Peristerakis <peristerakis at gmail.com>:


----------
nosy:  -George.Peristerakis

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

From report at bugs.python.org  Sat Nov 10 02:56:23 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Nov 2012 01:56:23 +0000
Subject: [docs] [issue16435] Python 3 doc link to Python 2 FAQ
In-Reply-To: <1352382611.96.0.563665281353.issue16435@psf.upfronthosting.co.za>
Message-ID: <3Xz1YK6VhGzN1s@mail.python.org>


Roundup Robot added the comment:

New changeset da0b3735be27 by Chris Jerdonek in branch '3.2':
Improve FAQ link in documentation (for issue #16435).
http://hg.python.org/cpython/rev/da0b3735be27

New changeset 3951264b0763 by Chris Jerdonek in branch '3.3':
Merge from 3.2: improve FAQ link in documentation (for issue #16435).
http://hg.python.org/cpython/rev/3951264b0763

New changeset 7cfe8cd4d65e by Chris Jerdonek in branch 'default':
Merge from 3.3: improve FAQ link in documentation (for issue #16435).
http://hg.python.org/cpython/rev/7cfe8cd4d65e

----------

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

From report at bugs.python.org  Sat Nov 10 03:04:47 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Nov 2012 02:04:47 +0000
Subject: [docs] [issue16435] Python 3 doc link to Python 2 FAQ
In-Reply-To: <1352382611.96.0.563665281353.issue16435@psf.upfronthosting.co.za>
Message-ID: <3Xz1l23fpWzPsW@mail.python.org>


Roundup Robot added the comment:

New changeset 5b3648f5e452 by Chris Jerdonek in branch '2.7':
Backport from 3.2: improve FAQ link in documentation (for issue #16435).
http://hg.python.org/cpython/rev/5b3648f5e452

----------

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

From report at bugs.python.org  Sat Nov 10 04:02:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Nov 2012 03:02:35 +0000
Subject: [docs] [issue16436] Link directly to set and frozenset in built-in
	function	docs
In-Reply-To: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>
Message-ID: <3Xz31j5JhbzMy3@mail.python.org>


Roundup Robot added the comment:

New changeset 16fa6462dfe1 by Chris Jerdonek in branch '3.2':
Link set and frozenset function docs to their class definitions (issue #16436).
http://hg.python.org/cpython/rev/16fa6462dfe1

New changeset d534da27ca8b by Chris Jerdonek in branch '3.3':
Merge from 3.2: adjust set and frozenset function docs (issue #16436).
http://hg.python.org/cpython/rev/d534da27ca8b

New changeset 1fde0d70f2b8 by Chris Jerdonek in branch 'default':
Merge from 3.3: adjust set and frozenset function docs (issue #16436).
http://hg.python.org/cpython/rev/1fde0d70f2b8

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

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

From report at bugs.python.org  Sat Nov 10 04:13:20 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Nov 2012 03:13:20 +0000
Subject: [docs] [issue16436] Link directly to set and frozenset in built-in
	function	docs
In-Reply-To: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>
Message-ID: <3Xz3G74XSPzN42@mail.python.org>


Roundup Robot added the comment:

New changeset 24db5292c2c9 by Chris Jerdonek in branch '2.7':
Backport from 3.2: adjust set and frozenset function docs (issue #16436).
http://hg.python.org/cpython/rev/24db5292c2c9

----------

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

From report at bugs.python.org  Sat Nov 10 04:14:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 10 Nov 2012 03:14:35 +0000
Subject: [docs] [issue16436] Link directly to set and frozenset in built-in
	function	docs
In-Reply-To: <1352383157.6.0.676029239429.issue16436@psf.upfronthosting.co.za>
Message-ID: <1352517275.66.0.791723876716.issue16436@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Fixed.  Thanks a lot for the report, Yongzhi.

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

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

From report at bugs.python.org  Sat Nov 10 04:35:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 10 Nov 2012 03:35:20 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1352518519.63.0.186860712592.issue13538@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

New patch incorporating Ezio's suggestions, along with some other changes.

----------
Added file: http://bugs.python.org/file27939/issue-13538-4-default.patch

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

From report at bugs.python.org  Sat Nov 10 17:41:40 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Nov 2012 16:41:40 +0000
Subject: [docs] [issue16240] Document a way to escape metacharacters in
	glob/fnmatch
In-Reply-To: <1350312209.74.0.651951907427.issue16240@psf.upfronthosting.co.za>
Message-ID: <1352565700.81.0.83272549014.issue16240@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ezio, feel free to finalize this.  For me all variants look good.

----------
keywords:  -patch
stage: patch review -> needs patch

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

From report at bugs.python.org  Sat Nov 10 19:06:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 10 Nov 2012 18:06:41 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1352570801.46.0.382787745256.issue13538@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


Added file: http://bugs.python.org/file27944/issue-13538-5-default.patch

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

From report at bugs.python.org  Sat Nov 10 19:13:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 10 Nov 2012 18:13:29 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1352571209.02.0.637933980139.issue13538@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


Removed file: http://bugs.python.org/file27939/issue-13538-4-default.patch

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

From report at bugs.python.org  Sat Nov 10 20:10:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 10 Nov 2012 19:10:41 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352574641.21.0.916872171675.issue16418@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Proposed documentation patch attached.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy, patch
nosy: +docs at python, ezio.melotti
stage:  -> patch review
type: behavior -> enhancement
versions: +Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27946/issue-16418-1-default.patch

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

From report at bugs.python.org  Sun Nov 11 10:34:55 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Nov 2012 09:34:55 +0000
Subject: [docs] [issue15677] Gzip/zlib allows for compression level=0
In-Reply-To: <1345062923.32.0.954619584637.issue15677@psf.upfronthosting.co.za>
Message-ID: <1352626495.07.0.360153319408.issue15677@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
nosy: +nadeem.vawda, serhiy.storchaka
stage: needs patch -> commit review
versions: +Python 3.4

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

From report at bugs.python.org  Sun Nov 11 11:11:03 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Nov 2012 10:11:03 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1352628663.02.0.542477995688.issue5784@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
versions: +Python 3.4 -Python 3.1

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

From report at bugs.python.org  Sun Nov 11 14:20:35 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Nov 2012 13:20:35 +0000
Subject: [docs] [issue15677] Gzip/zlib allows for compression level=0
In-Reply-To: <1345062923.32.0.954619584637.issue15677@psf.upfronthosting.co.za>
Message-ID: <3XzwhL2ZcHzQBX@mail.python.org>


Roundup Robot added the comment:

New changeset 735ef27fa231 by Nadeem Vawda in branch '2.7':
Issue #15677: Document that zlib and gzip accept a compression level of 0 to mean 'no compression'.
http://hg.python.org/cpython/rev/735ef27fa231

New changeset f6c4c178da56 by Nadeem Vawda in branch '2.7':
Issue #15677: Also fix docstrings in zlib module.
http://hg.python.org/cpython/rev/f6c4c178da56

New changeset 9dde30690f44 by Nadeem Vawda in branch '3.2':
Issue #15677: Document that zlib and gzip accept a compression level of 0 to mean 'no compression'.
http://hg.python.org/cpython/rev/9dde30690f44

New changeset 0e48bf45313c by Nadeem Vawda in branch '3.3':
Issue #15677: Document that zlib and gzip accept a compression level of 0 to mean 'no compression'.
http://hg.python.org/cpython/rev/0e48bf45313c

New changeset 21335c9fcec0 by Nadeem Vawda in branch 'default':
Issue #15677: Document that zlib and gzip accept a compression level of 0 to mean 'no compression'.
http://hg.python.org/cpython/rev/21335c9fcec0

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

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

From report at bugs.python.org  Sun Nov 11 14:25:21 2012
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 11 Nov 2012 13:25:21 +0000
Subject: [docs] [issue15677] Gzip/zlib allows for compression level=0
In-Reply-To: <1345062923.32.0.954619584637.issue15677@psf.upfronthosting.co.za>
Message-ID: <1352640321.53.0.322583933578.issue15677@psf.upfronthosting.co.za>


Nadeem Vawda added the comment:

Committed. Thanks for the patch!

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

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

From report at bugs.python.org  Sun Nov 11 18:53:22 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Nov 2012 17:53:22 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352656402.38.0.843121187183.issue16418@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Juraj: Is the example behavior from Py2 or Py3? The meaning of 'range' changed. In Py2, xrange would be the correct choice for 'choice'.

Does argparse actually convert (x)range objects to a list or set (the help indicates the latter) for internal use? That would be foolish as 'n in <range>' is an O(1) operation. (I don't remember is that works for xrange.) For instance, range(0, 1000, 2) is a nice way to say 'even count less than 1000'.

If it is not so converted, converting for display is also foolish.
'range(0, 1000, 2)' is clearer than an explicit sequence.

----------
nosy: +bethard, terry.reedy

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

From report at bugs.python.org  Sun Nov 11 20:32:47 2012
From: report at bugs.python.org (Juraj Variny)
Date: Sun, 11 Nov 2012 19:32:47 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352662367.49.0.199145887353.issue16418@psf.upfronthosting.co.za>


Juraj Variny added the comment:

It was Python 2.7 . But if range shouldn't be used for large number of options, arguing whether it's O(1) is splitting hairs, no?

I'll remove the choices from my code. Adding new type for port is overkill, users should know what legal TCP port numbers are.

----------

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

From report at bugs.python.org  Sun Nov 11 20:55:05 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Nov 2012 19:55:05 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352663705.72.0.543471051014.issue16418@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am arguing that (x)range *should* be usable for large numbers of options *because* the containment test is O(1). What happens is you *do* use xrange instead of range in 2.7 or 3.x instead of 2.7?

In 2.x, range(n) *is* a list so that is a bad choice for large n, regardless of the display issue, which could be fixed separately as is being done on other issues.

----------

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

From report at bugs.python.org  Mon Nov 12 03:53:16 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Nov 2012 02:53:16 +0000
Subject: [docs] [issue16267] order of decorators @abstractmethod and
	@classmethod is	significant (is not documented to be in
	@abstractclassmethod	which advises their combined use)
In-Reply-To: <1350488481.01.0.487550684008.issue16267@psf.upfronthosting.co.za>
Message-ID: <1352688796.68.0.698120788773.issue16267@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

It took me a while to get my brain back up to speed with the full rationale behind the current design (mostly by rereading the multitude of comment on #11610).

As Darren says, the main advantage of the current scheme is that the wrapper descriptors deliberately *don't* have any concept of abstract/non-abstract independent of the methods that make them up. So I think the main thing to do is change the documentation of the affected descriptors to be more explicit about the required order of the replacement decorators. Otherwise people are likely to map "abstractXmethod" to "@abstractmethod + @Xmethod" and write them in that order (which won't work).

----------

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

From report at bugs.python.org  Tue Nov 13 01:52:34 2012
From: report at bugs.python.org (Hobs)
Date: Tue, 13 Nov 2012 00:52:34 +0000
Subject: [docs] [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1352767954.43.0.860416175407.issue11076@psf.upfronthosting.co.za>


Hobs added the comment:

Seems like a great idea. `foo(**dict(args))` is very useful.

I tested `foo(**dict(iter(o.__dict__.items())))` on python 2.7 Mac OSX for my foo and it worked well.

----------
nosy: +Hobson.Lane

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

From report at bugs.python.org  Tue Nov 13 02:21:50 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 13 Nov 2012 01:21:50 +0000
Subject: [docs] [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1352769710.05.0.34268557446.issue11076@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Tue Nov 13 04:02:02 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 13 Nov 2012 03:02:02 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1352775722.67.0.319118648439.issue16421@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Tue Nov 13 06:47:29 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 13 Nov 2012 05:47:29 +0000
Subject: [docs] [issue11776] Constructor signatures missing in types
	module	documentation
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1352785649.67.0.495651687983.issue11776@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Tue Nov 13 07:45:05 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 13 Nov 2012 06:45:05 +0000
Subject: [docs] [issue16144] misleading sentence in reference/import
In-Reply-To: <1349459459.97.0.290795741864.issue16144@psf.upfronthosting.co.za>
Message-ID: <1352789105.45.0.693405920736.issue16144@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Tue Nov 13 08:14:37 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 13 Nov 2012 07:14:37 +0000
Subject: [docs] [issue15104] Unclear language in __main__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1352790877.72.0.516669596292.issue15104@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Tue Nov 13 08:15:01 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 13 Nov 2012 07:15:01 +0000
Subject: [docs] [issue16386] imp.find_module does not specify registry key
	it	searches on windows
In-Reply-To: <1351859767.89.0.815277454803.issue16386@psf.upfronthosting.co.za>
Message-ID: <1352790901.14.0.32397212578.issue16386@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Tue Nov 13 08:23:29 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 13 Nov 2012 07:23:29 +0000
Subject: [docs] [issue16194] imp.load_dynamic imports wrong module when
	called	several times on a multi-module .so
In-Reply-To: <1349953870.22.0.50760531633.issue16194@psf.upfronthosting.co.za>
Message-ID: <1352791409.0.0.97657787348.issue16194@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Tue Nov 13 10:03:20 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Nov 2012 09:03:20 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <1352797400.56.0.0240363919431.issue16339@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> mark.dickinson

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

From report at bugs.python.org  Tue Nov 13 15:03:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 13 Nov 2012 14:03:28 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352815408.63.0.60817332787.issue16418@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Does argparse actually convert (x)range objects to a list or set (the help indicates the latter) for internal use?

No, it leaves the provided choices argument as is.

Here is what the documentation says argparse accepts: "Any object that supports the *in* operator can be passed as the choices value, so dict objects, set objects, custom containers, etc. are all supported."  And here is the code for testing containment:

http://hg.python.org/cpython/file/ee7b713fec71/Lib/argparse.py#l2284

Terry, are you okay with the proposed documentation patch?

Special-casing the display of range values seems like an enhancement request to me rather than a bug.  I would suggest that be handled as an enhancement request targeted initially for Python 3.4.  I would be happy to create a new issue for that.  Alternatively, it could be considered as a second patch on this issue.

----------

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

From report at bugs.python.org  Tue Nov 13 19:39:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 13 Nov 2012 18:39:10 +0000
Subject: [docs] [issue16157] Irrelevant references to Misc/News
In-Reply-To: <1349628852.45.0.324394497616.issue16157@psf.upfronthosting.co.za>
Message-ID: <1352831950.05.0.157727213585.issue16157@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +chris.jerdonek

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

From report at bugs.python.org  Tue Nov 13 20:32:45 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 13 Nov 2012 19:32:45 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352835165.22.0.00473803487316.issue16418@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I do not agree with the patch. A summary of my view: Range objects support the 'in' operator and they are an intended option for choices, and, as I said before, are exactly the right option for arithmetic sequences with more than a few items. The problem is that they are now, in effect, special-cased relative to other builtins by having their compact representation replaced by an expanded tuple display. Moreover, the iteration required to do this introduces a discrepancy relative to the doc. This bug might be better fixed by a code change.

(The OP did not pass a (x)range object but a list. That was unnecessary and easily fixed in itself. But such a fix leaves the issue above. Condensing long sequences is a somewhat separate issue.)

As to intent:

"The choices keyword argument may be more convenient for type checkers that simply check against a range of values:
>>>

>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('foo', type=int, choices=range(5, 10))
>>> parser.parse_args('7'.split())
Namespace(foo=7)
>>> parser.parse_args('11'.split())
usage: PROG [-h] {5,6,7,8,9}
PROG: error: argument foo: invalid choice: 11 (choose from 5, 6, 7, 8, 9)"

Note the expansion instead of the normal representation. It is not a big deal here, but obviously can be.

">>> parser.add_argument(
...     'integers', metavar='int', type=int, choices=range(10),
...  nargs='+', help='an integer in the range 0..9')"

As to tuple display expansion: the link points to

2284 def _check_value(self, action, value):
2285   # converted value must be one of the choices (if specified)
2286   if action.choices is not None and value not in action.choices:
2287     args = {'value': value,
2288     'choices': ', '.join(map(repr, action.choices))}
2289     msg = _('invalid choice: %(value)r (choose from %(choices)s)')
2290     raise ArgumentError(action, msg % args)

In 2288 "', '.join(map(repr, action.choices))" produces a tuple display without parentheses. It essentially reproduced str/repr for tuples, lists, frozensets, sets, dicts, dict views, etc., leaving off the irrelevant fence characters. In doing so, by iteration, it introduces a bug --see below.

For range objects, the tuple representation is a drastic change from the normal representation. In that sense, it special cases range among built-ins, and in a bad way when the range represents many values. (Help messages apparently do the same.) I consider this to be something of a bug. So the code as it is would have to special case range objects to avoid special-casing them in the sense above.

The same would apply to any custom objects that have a succinct description for a large, possible infinite set. Here are two examples: "a word containing no 'e's" and "a 'word' containing only the letters a, b, c, d, e". Objects representing such infinite sets of strings could easily have a __contains__ method but not an __iter__ method.

The code above requires the choices object to be iterable as well as supporting 'in'. This contradicts the doc statement "Any object that supports the in operator can be passed as the choices value,". That discrepancy is a bug. It should be fixed by either adding the restriction to the doc or removing it from the code. I recommend the latter.

The code could simply use the str or repr of the choice object without trying to be fancy with a custom, fence-stripped, representation that does not work correctly or at all for all possible choice objects. In other words

if action.choices is not None and value not in action.choices:
  msg = "invalid choice: %r (choose from %r)" % (value, action.choices)
  raise ArgumentError(action, msg)

If the custom representation for non-range builtins is desired, then they are the ones that should be special-cased to not use their default representation.

----------
assignee: docs at python -> 
keywords:  -easy

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

From report at bugs.python.org  Wed Nov 14 08:19:19 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Nov 2012 07:19:19 +0000
Subject: [docs] [issue16157] Irrelevant references to Misc/News
In-Reply-To: <1349628852.45.0.324394497616.issue16157@psf.upfronthosting.co.za>
Message-ID: <1352877559.4.0.374215076449.issue16157@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Even better would be to link to the changelog page instead, but that's only available for Python 3.3/3.4 (does this issue affect 2.7/3.2?).

http://docs.python.org/3.3/whatsnew/changelog.html

----------
nosy: +ezio.melotti, georg.brandl
stage:  -> needs patch

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

From report at bugs.python.org  Wed Nov 14 08:43:37 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Wed, 14 Nov 2012 07:43:37 +0000
Subject: [docs] [issue16470] Backport set and dictionary comprehensions in
	tutorial	to 2.7
Message-ID: <1352879017.7.0.397020464451.issue16470@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

Dictionary and set comprehensions are backported to 2.7 in issue #2333. The are not documented in the tutorial of 2.7, though they are in the language reference. Is it OK to add these to the tutorial? I've uploaded a patch.

----------
assignee: docs at python
components: Documentation
files: set_and_dict_comprehensions.diff
keywords: patch
messages: 175547
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Backport set and dictionary comprehensions in tutorial to 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file27982/set_and_dict_comprehensions.diff

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

From report at bugs.python.org  Wed Nov 14 08:45:42 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Nov 2012 07:45:42 +0000
Subject: [docs] [issue16470] Backport set and dictionary comprehensions in
	tutorial	to 2.7
In-Reply-To: <1352879017.7.0.397020464451.issue16470@psf.upfronthosting.co.za>
Message-ID: <1352879142.76.0.267967394974.issue16470@psf.upfronthosting.co.za>


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


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

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

From berker.peksag at gmail.com  Wed Nov 14 09:23:23 2012
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Wed, 14 Nov 2012 08:23:23 -0000
Subject: [docs] Backport set and dictionary comprehensions in tutorial to
	2.7 (issue 16470)
Message-ID: <20121114082323.24969.93979@psf.upfronthosting.co.za>


http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst
File Doc/tutorial/datastructures.rst (right):

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst#newcode490
Doc/tutorial/datastructures.rst:490: Curly braces or the :func:`set`
function can be used to create sets.  Note: To
It would be good to use `.. note::` here.

See http://sphinx-doc.org/markup/para.html#directive-note

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst#newcode492
Doc/tutorial/datastructures.rst:492: empty dictionary, a data structure
that we discuss in the next section.
s/we/we'll/?

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst#newcode524
Doc/tutorial/datastructures.rst:524: {'r', 'd'}
In 2.7.3:

    >>> a = {x for x in 'abracadabra' if x not in 'abc'}
    >>> a
    set(['r', 'd'])

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

From report at bugs.python.org  Wed Nov 14 09:24:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Nov 2012 08:24:21 +0000
Subject: [docs] [issue16157] Irrelevant references to Misc/News
In-Reply-To: <1349628852.45.0.324394497616.issue16157@psf.upfronthosting.co.za>
Message-ID: <1352881461.39.0.682363409211.issue16157@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This issue affects only 3.3+ (see links above).

----------

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

From ezio.melotti at gmail.com  Wed Nov 14 09:32:19 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Wed, 14 Nov 2012 08:32:19 -0000
Subject: [docs] Backport set and dictionary comprehensions in tutorial
 to 2.7 (issue 16470)
Message-ID: <20121114083219.24969.96347@psf.upfronthosting.co.za>

If these are documented in the 3.x tutorial, you could backport the
changes from there.


http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst
File Doc/tutorial/datastructures.rst (right):

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst#newcode490
Doc/tutorial/datastructures.rst:490: Curly braces or the :func:`set`
function can be used to create sets.  Note: To
On 2012/11/14 09:23:23, berkerpeksag wrote:
> It would be good to use `.. note::` here.
> 
> See http://sphinx-doc.org/markup/para.html#directive-note

Not necessary IMHO.  The "note" directive should be used sparingly.

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst#newcode520
Doc/tutorial/datastructures.rst:520: Like :ref:`for lists
<tut-listcomps>`, there is a set comprehension syntax::
The first part of the sentence doesn't sound too good to me.
Maybe it could be rephrased to something like "Similarly to list
comprehensions, set comprehensions are also supported::"

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

From report at bugs.python.org  Wed Nov 14 09:51:31 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 14 Nov 2012 08:51:31 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352883091.73.0.0238903581059.issue16418@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

To simplify the discussion and for issue resolution purposes, I propose that the discussion about "large" choices containers be divided into separate discussions for (1) changes that should be applied to all maintenance releases (i.e. bug fix changes), and (2) changes that should be applied only to the in-development branch (i.e. enhancements).

I propose that the current issue be used for the former.  3.4-only enhancements can be dealt with as part of a separate issue.

I also created issue 16468 for the bug that Terry observed above that ArgumentParser does not in general support "choices" values that support the "in" operator.  That issue exists and can be resolved independent of whether the choices collection is large.

----------

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

From report at bugs.python.org  Wed Nov 14 09:58:32 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 14 Nov 2012 08:58:32 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352883512.92.0.381576631172.issue16418@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> (1) changes that should be applied to all maintenance releases (i.e. bug fix changes)

This should instead read, "(1) changes that should be applied to all maintenance releases (e.g. bug fix and/or documentation changes)."

----------

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

From fossilet at users.sourceforge.net  Wed Nov 14 10:09:02 2012
From: fossilet at users.sourceforge.net (fossilet at users.sourceforge.net)
Date: Wed, 14 Nov 2012 09:09:02 -0000
Subject: [docs] Backport set and dictionary comprehensions in tutorial
 to 2.7 (issue 16470)
Message-ID: <20121114090902.24969.4011@psf.upfronthosting.co.za>

Reviewers: berkerpeksag, ezio.melotti,


http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst
File Doc/tutorial/datastructures.rst (right):

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst#newcode524
Doc/tutorial/datastructures.rst:524: {'r', 'd'}
I copied all of these from the default branch, not noting the repr is
different.  But this is my first time cloning the Python source code..
On 2012/11/14 09:23:23, berkerpeksag wrote:
> In 2.7.3:
> 
>     >>> a = {x for x in 'abracadabra' if x not in 'abc'}
>     >>> a
>     set(['r', 'd'])



Please review this at http://bugs.python.org/review/16470/

Affected files:
  Doc/tutorial/datastructures.rst


diff -r bb21c800cf49 Doc/tutorial/datastructures.rst
--- a/Doc/tutorial/datastructures.rst	Mon Nov 12 20:35:29 2012 +0100
+++ b/Doc/tutorial/datastructures.rst	Wed Nov 14 14:55:09 2012 +0800
@@ -487,6 +487,10 @@
 eliminating duplicate entries.  Set objects also support mathematical operations
 like union, intersection, difference, and symmetric difference.
 
+Curly braces or the :func:`set` function can be used to create sets.  Note: To
+create an empty set you have to use ``set()``, not ``{}``; the latter creates an
+empty dictionary, a data structure that we discuss in the next section.
+
 Here is a brief demonstration::
 
    >>> basket = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']
@@ -513,6 +517,13 @@
    >>> a ^ b                              # letters in a or b but not both
    set(['r', 'd', 'b', 'm', 'z', 'l'])
 
+Like :ref:`for lists <tut-listcomps>`, there is a set comprehension syntax::
+
+   >>> a = {x for x in 'abracadabra' if x not in 'abc'}
+   >>> a
+   {'r', 'd'}
+
+
 
 .. _tut-dictionaries:
 
@@ -564,19 +575,18 @@
    >>> 'guido' in tel
    True
 
-The :func:`dict` constructor builds dictionaries directly from lists of
-key-value pairs stored as tuples.  When the pairs form a pattern, list
-comprehensions can compactly specify the key-value list. ::
+The :func:`dict` constructor builds dictionaries directly from sequences of
+key-value pairs::
 
    >>> dict([('sape', 4139), ('guido', 4127), ('jack', 4098)])
    {'sape': 4139, 'jack': 4098, 'guido': 4127}
-   >>> dict([(x, x**2) for x in (2, 4, 6)])     # use a list comprehension
+
+In addition, dict comprehensions can be used to create dictionaries from
+arbitrary key and value expressions::
+
+   >>> {x: x**2 for x in (2, 4, 6)}
    {2: 4, 4: 16, 6: 36}
 
-Later in the tutorial, we will learn about Generator Expressions which are even
-better suited for the task of supplying key-values pairs to the :func:`dict`
-constructor.
-
 When the keys are simple strings, it is sometimes easier to specify pairs using
 keyword arguments::
 



From report at bugs.python.org  Wed Nov 14 10:38:27 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 14 Nov 2012 09:38:27 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352885907.07.0.0721329345291.issue16418@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> The code could simply use the str or repr of the choice object

It seems to me that this would result in less user-friendly behavior in many cases.  It would also require the end-user to understand Python (e.g. xrange and dictionaries), which I don't think should be necessary for the user of a command-line script.

For example, in Python 2.7 the containers xrange(5, 10), xrange(2, 10, 2), and {1: "foo", 2: "bar"} currently yield the following user-friendly messages for choice 0:

invalid choice: 0 (choose from 5, 6, 7, 8, 9)
invalid choice: 0 (choose from 2, 4, 6, 8)
invalid choice: 0 (choose from 1, 2)

With the proposed change, these messages would be as follows, which seem unnecessarily obfuscated:

invalid choice: 0 (choose from xrange(5, 10))
invalid choice: 0 (choose from xrange(2, 10, 2))
invalid choice: 0 (choose from {1: 'foo', 2: 'bar'})

Thus, I think the proposal above would be a regression if applied.  I think any changes to maintenance releases should preserve the current user-friendly messages (when those messages are user-friendly, e.g. when the containers are small).

----------

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

From report at bugs.python.org  Wed Nov 14 11:27:50 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 14 Nov 2012 10:27:50 +0000
Subject: [docs] [issue16471] upgrade to sphinx 1.1
Message-ID: <1352888870.05.0.523269386726.issue16471@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to upgrade Python's Sphinx from version 1.0 to 1.1.

I don't already see an issue for this, and I'm not sure what upgrading entails.

Personally, I'm interested in the enhanced indexing capabilities, e.g. the "see" and "seealso" entry types, as well as marking main index entries:

http://sphinx-doc.org/markup/misc.html#directive-index

I'm sure other reasons for upgrading have been floated, though I don't know what they are.

----------
assignee: docs at python
components: Documentation
messages: 175560
nosy: chris.jerdonek, docs at python
priority: normal
severity: normal
status: open
title: upgrade to sphinx 1.1
type: enhancement

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

From report at bugs.python.org  Wed Nov 14 12:06:06 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Nov 2012 11:06:06 +0000
Subject: [docs] [issue16471] upgrade to sphinx 1.1
In-Reply-To: <1352888870.05.0.523269386726.issue16471@psf.upfronthosting.co.za>
Message-ID: <1352891166.32.0.0707139218982.issue16471@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Nov 14 12:19:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Nov 2012 11:19:58 +0000
Subject: [docs] [issue16378] venv.EnvBuilder docstring inconsistencies
In-Reply-To: <1351743024.49.0.854763959686.issue16378@psf.upfronthosting.co.za>
Message-ID: <3Y1jsn6j0ZzRPy@mail.python.org>


Roundup Robot added the comment:

New changeset afb476dc202f by Vinay Sajip in branch '3.3':
Issue #16378: Updated docstrings to reflect the defaults present in the code.
http://hg.python.org/cpython/rev/afb476dc202f

New changeset 6f0e49ed0589 by Vinay Sajip in branch 'default':
Closes #16378: Merged docstring changes from 3.3.
http://hg.python.org/cpython/rev/6f0e49ed0589

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

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

From report at bugs.python.org  Wed Nov 14 13:23:09 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Nov 2012 12:23:09 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352895788.96.0.372618071671.issue16418@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree with Chris that using the repr in the general case would be a regression in usability for the end user (and certainly not suitable for a maintenance release).

Here is some brainstorming:

We could "special case" this via duck typing.  If the object that represents the choices has 'start' and 'stop' attributes, use those to generate a message.  ("from {start} up to but not including {stop}"). [*] If it doesn't, or it also has a 'step' that is not 1, check the len, generate the list if it is less than, say, 50, and if it is more give up and use the repr.

If there is no len, do the expansion (which is what happens now) and throw it away in favor of the repr if there are more than 50 elements.

If there is no iter, use the repr.

Then as an enhancement we can also look for a special attribute (values_description?) that gives the entire text to use in the parenthesis in the help phrase to provide a way to customize the help text in 3.4+.

[*] Or, at the risk of being too clever, if there is a 'step' use the message above and if there isn't a step attribute at all use "between {start} and {stop}.

----------

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

From report at bugs.python.org  Wed Nov 14 18:14:00 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 14 Nov 2012 17:14:00 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352913239.92.0.228955714328.issue16418@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

For maintenance releases, I think I would favor abbreviating the list only if it is "lossless" (e.g. for xrange objects).  I think I would also be okay with abbreviating for arbitrary xranges -- in particular for arbitrary steps.  For example, for xrange(0, 50, 3), I think something like the following might be better: "0, 3, 6, 9, ... 45, 48" (we could also include a difference hint).

----------

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

From report at bugs.python.org  Wed Nov 14 20:38:07 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Nov 2012 19:38:07 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352921887.44.0.27554750719.issue16418@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that my extreme, strawman-ish, proposal, was, well, too extreme. Here is a more realistic proposal similar to David's.

if isinstance(choices, range) and len(choices) > 50:
  choice_txt = range_rep(choices)  # details to be determined
try:
  choice_txt = <iterated version of choices as now>
except TypeError:  # because choices not iterable
  choice_txt = repr(choices)  # can be anything for custom class

Then display help or error message.

If someone passes a non-(x)range iterable with 1000s of choices, I am willing to say they deserve what they asked for, once that the docs make clearer that such collections will be displayed in full. Any iterable container too large to display in full can be wrapped as a non-iterable container. ('Container' means that 'in' works.)

class NonIterableContainer:
  def __init__(self, container, description):
    self.container = container
    self.description = description
  def __repr__(self):
    return self.description
  def __contains__(self, item):
    return item in self.container

The description could point one to a file or doc that has an explicit list.

If such a listing enumerates the items, the program arg could instead be an int in the appropriate range. Then the program would look up the actual arg. Ranges *are* special because items from any finite enumerated collection can be replaced, for input, by the corresponding int in the enumerated range. They are therefore worth special attention in help and error displays.

----------

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

From report at bugs.python.org  Wed Nov 14 20:50:35 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Nov 2012 19:50:35 +0000
Subject: [docs] [issue16418] argparse with many choices can generate
	absurdly long	usage message
In-Reply-To: <1352157111.52.0.432994430995.issue16418@psf.upfronthosting.co.za>
Message-ID: <1352922635.89.0.860199129422.issue16418@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I see that in #16468, Chris proposes that existing versions should let the TypeError propagate, possibly with an improved error message, and call the use of repr for non-iterables a new feature (partly on the basis that more fixes than this are needed to use them).

----------

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

From report at bugs.python.org  Thu Nov 15 05:52:14 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Nov 2012 04:52:14 +0000
Subject: [docs] [issue16470] Backport set and dictionary comprehensions in
	tutorial	to 2.7
In-Reply-To: <1352879017.7.0.397020464451.issue16470@psf.upfronthosting.co.za>
Message-ID: <1352955134.54.0.943920073256.issue16470@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Good idea.  Could you add a note that this is new in 2.7?  (Either using versionadded Sphinx directives or just remarks in plain English, not sure which one would be best.)

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

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

From report at bugs.python.org  Thu Nov 15 07:10:44 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 15 Nov 2012 06:10:44 +0000
Subject: [docs] [issue16470] Backport set and dictionary comprehensions in
	tutorial	to 2.7
In-Reply-To: <1352879017.7.0.397020464451.issue16470@psf.upfronthosting.co.za>
Message-ID: <1352959844.59.0.0591163531405.issue16470@psf.upfronthosting.co.za>


Georg Brandl added the comment:

We don't use versionadded/changed directives in the tutorial. (There was only one until 2 minutes ago, which was misplaced in any case.)

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

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

From fossilet at users.sourceforge.net  Thu Nov 15 07:16:18 2012
From: fossilet at users.sourceforge.net (fossilet at users.sourceforge.net)
Date: Thu, 15 Nov 2012 06:16:18 -0000
Subject: [docs] Backport set and dictionary comprehensions in tutorial
 to 2.7 (issue 16470)
Message-ID: <20121115061618.25001.74979@psf.upfronthosting.co.za>


http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst
File Doc/tutorial/datastructures.rst (right):

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst#newcode520
Doc/tutorial/datastructures.rst:520: Like :ref:`for lists
<tut-listcomps>`, there is a set comprehension syntax::
Sounds good.  Will this rephrasing also be applied to 3.x?
On 2012/11/14 09:32:19, ezio.melotti wrote:
> The first part of the sentence doesn't sound too good to me.
> Maybe it could be rephrased to something like "Similarly to list
comprehensions,
> set comprehensions are also supported::"

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

From ezio.melotti at gmail.com  Thu Nov 15 08:46:40 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Thu, 15 Nov 2012 07:46:40 -0000
Subject: [docs] Backport set and dictionary comprehensions in tutorial
 to 2.7 (issue 16470)
Message-ID: <20121115074640.25001.25699@psf.upfronthosting.co.za>


http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst
File Doc/tutorial/datastructures.rst (right):

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.rst#newcode520
Doc/tutorial/datastructures.rst:520: Like :ref:`for lists
<tut-listcomps>`, there is a set comprehension syntax::
Whoever commits the patch can take care of it, just make sure to add a
comment about it on the tracker.

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

From report at bugs.python.org  Thu Nov 15 15:38:18 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Nov 2012 14:38:18 +0000
Subject: [docs] [issue16144] misleading sentence in reference/import
In-Reply-To: <1349459459.97.0.290795741864.issue16144@psf.upfronthosting.co.za>
Message-ID: <1352990297.98.0.301178563023.issue16144@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed in a8ca14983ab1 and 9961a0dafcc7. Thanks, Manuel.

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

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

From report at bugs.python.org  Thu Nov 15 15:38:38 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Nov 2012 14:38:38 +0000
Subject: [docs] [issue16144] misleading sentence in reference/import
In-Reply-To: <1349459459.97.0.290795741864.issue16144@psf.upfronthosting.co.za>
Message-ID: <1352990318.37.0.924688801195.issue16144@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From report at bugs.python.org  Thu Nov 15 16:29:11 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Nov 2012 15:29:11 +0000
Subject: [docs] [issue16470] Backport set and dictionary comprehensions in
	tutorial	to 2.7
In-Reply-To: <1352879017.7.0.397020464451.issue16470@psf.upfronthosting.co.za>
Message-ID: <1352993351.5.0.551493673893.issue16470@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From report at bugs.python.org  Thu Nov 15 16:35:24 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Nov 2012 15:35:24 +0000
Subject: [docs] [issue16386] imp.find_module does not specify registry key
	it	searches on windows
In-Reply-To: <1351859767.89.0.815277454803.issue16386@psf.upfronthosting.co.za>
Message-ID: <1352993724.69.0.656870904645.issue16386@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

I think much more important to mention registry key in http://docs.python.org/3/library/importlib.html#importlib.machinery.WindowsRegistryFinder 
``imp`` is private module to access implementation internals but ``importlib`` is public interface to import system

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

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

From report at bugs.python.org  Thu Nov 15 16:46:01 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Nov 2012 15:46:01 +0000
Subject: [docs] [issue16404] Uses of PyLong_FromLong that don't check for
	errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <1352994361.47.0.161707464748.issue16404@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From report at bugs.python.org  Fri Nov 16 00:49:51 2012
From: report at bugs.python.org (Eric Snow)
Date: Thu, 15 Nov 2012 23:49:51 +0000
Subject: [docs] [issue16386] imp.find_module does not specify registry key
	it	searches on windows
In-Reply-To: <1351859767.89.0.815277454803.issue16386@psf.upfronthosting.co.za>
Message-ID: <1353023391.6.0.661781157106.issue16386@psf.upfronthosting.co.za>


Eric Snow added the comment:

I agree with Andrew.

----------

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

From report at bugs.python.org  Fri Nov 16 04:45:11 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Fri, 16 Nov 2012 03:45:11 +0000
Subject: [docs] [issue16423] urllib data URL recipe
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353037511.11.0.221623647517.issue16423@psf.upfronthosting.co.za>


Mathias Panzenb?ck added the comment:

New patch. Instead of adding the data URL support to the doc as a recipe I added it to urllib.request directly. I think this is better and justified, because the old legacy URLopener had (some kind) of support for data URLs.

OT: I think that the legacy URLopener has bugs. It only unquotes the data if it's base64 encoded, but it should be unquoted in any case. Also it returns a StringIO and decodes the content as latin-1. This is wrong, the content is a binary string. It could be text encoded in any kind of charset or not text at all (e.g. an image).

----------
Added file: http://bugs.python.org/file27994/urllib.request-data-url.patch

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

From report at bugs.python.org  Fri Nov 16 04:50:36 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Fri, 16 Nov 2012 03:50:36 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353037836.19.0.695648672461.issue16423@psf.upfronthosting.co.za>


Changes by Mathias Panzenb?ck <grosser.meister.morti at gmx.net>:


----------
components: +Library (Lib) -Documentation
title: urllib data URL recipe -> urllib data URL
type:  -> enhancement

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

From report at bugs.python.org  Fri Nov 16 09:19:04 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Nov 2012 08:19:04 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353053944.36.0.897953012672.issue16423@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
versions:  -Python 3.1, Python 3.2, Python 3.3, Python 3.5

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

From report at bugs.python.org  Fri Nov 16 09:41:23 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Fri, 16 Nov 2012 08:41:23 +0000
Subject: [docs] [issue16470] Backport set and dictionary comprehensions in
	tutorial	to 2.7
In-Reply-To: <1352879017.7.0.397020464451.issue16470@psf.upfronthosting.co.za>
Message-ID: <1353055283.04.0.953363573716.issue16470@psf.upfronthosting.co.za>


Yongzhi Pan added the comment:

I updated the patch according to the code review. Hope now it is OK.

----------
Added file: http://bugs.python.org/file27995/set_and_dict_comprehensions_1.diff

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

From report at bugs.python.org  Fri Nov 16 11:46:29 2012
From: report at bugs.python.org (Marius Gedminas)
Date: Fri, 16 Nov 2012 10:46:29 +0000
Subject: [docs] [issue16484] Missing/broken documentation redirect
	for	http://docs.python.org/library/xml.etree.ElementTree
Message-ID: <1353062789.06.0.457819088795.issue16484@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

Do this:

  pydoc2.7 xml.etree.ElementTree

then click on the MODULE DOCS link, which is http://docs.python.org/library/xml.etree.ElementTree

You're redirected to http://docs.python.org/2/library/xml.etree.ElementTree which is a 404 page.

----------
assignee: docs at python
components: Documentation
messages: 175675
nosy: docs at python, mgedmin
priority: normal
severity: normal
status: open
title: Missing/broken documentation redirect for http://docs.python.org/library/xml.etree.ElementTree
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 16 16:15:38 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Fri, 16 Nov 2012 15:15:38 +0000
Subject: [docs] [issue15346] Tkinter extention modules have no documentation
In-Reply-To: <1342198047.2.0.619885102312.issue15346@psf.upfronthosting.co.za>
Message-ID: <1353078938.14.0.0177638817793.issue15346@psf.upfronthosting.co.za>


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


----------
status: open -> languishing

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

From report at bugs.python.org  Fri Nov 16 16:32:34 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Fri, 16 Nov 2012 15:32:34 +0000
Subject: [docs] [issue15346] Tkinter extention modules have no documentation
In-Reply-To: <1342198047.2.0.619885102312.issue15346@psf.upfronthosting.co.za>
Message-ID: <1353079954.81.0.930091362988.issue15346@psf.upfronthosting.co.za>


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


----------
status: languishing -> open

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

From report at bugs.python.org  Fri Nov 16 18:25:08 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Nov 2012 17:25:08 +0000
Subject: [docs] [issue16323] Wrong C API documentation for locale encoding
In-Reply-To: <1351173455.0.0.737976146006.issue16323@psf.upfronthosting.co.za>
Message-ID: <1353086708.53.0.697626414672.issue16323@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Nov 16 20:15:14 2012
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 16 Nov 2012 19:15:14 +0000
Subject: [docs] [issue16484] Missing/broken documentation redirect
	for	http://docs.python.org/library/xml.etree.ElementTree
In-Reply-To: <1353062789.06.0.457819088795.issue16484@psf.upfronthosting.co.za>
Message-ID: <1353093313.96.0.389675106868.issue16484@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The redirect is not the problem.  The page never existed.

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

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

From report at bugs.python.org  Fri Nov 16 21:25:47 2012
From: report at bugs.python.org (Marius Gedminas)
Date: Fri, 16 Nov 2012 20:25:47 +0000
Subject: [docs] [issue16484] Missing/broken documentation redirect
	for	http://docs.python.org/library/xml.etree.ElementTree
In-Reply-To: <1353062789.06.0.457819088795.issue16484@psf.upfronthosting.co.za>
Message-ID: <1353097547.66.0.759603451911.issue16484@psf.upfronthosting.co.za>


Marius Gedminas added the comment:

A working link is http://docs.python.org/2/library/xml.etree.elementtree.html or http://docs.python.org/2/library/xml.etree.elementtree (with no .html at the end).

Looks like capitalization is causing a problem.

Did these pydoc links ever work?

Would it be possible to make them work?

There's a limited number of standard library modules with names that contain capital letters.  find /usr/lib/python2.7 -name dist-packages -prune -o -name '*[A-Z]*' | wc -l gives me 211 names, but this is an imprecise upper bound because it includes files like 'distutils/README' that aren't modules or packages.

Can I do anything to help?

----------

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

From report at bugs.python.org  Sat Nov 17 00:38:07 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Nov 2012 23:38:07 +0000
Subject: [docs] [issue16471] upgrade to sphinx 1.1
In-Reply-To: <1352888870.05.0.523269386726.issue16471@psf.upfronthosting.co.za>
Message-ID: <1353109087.24.0.603101777513.issue16471@psf.upfronthosting.co.za>


STINNER Victor added the comment:

According to the changelog, Sphinx 1.1 now supports Python 3. Cool!

Doc/Makefile may be modified to use "PYTHON = python3".

----------
nosy: +haypo

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

From report at bugs.python.org  Sat Nov 17 11:06:57 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Nov 2012 10:06:57 +0000
Subject: [docs] [issue16470] Backport set and dictionary comprehensions in
	tutorial	to 2.7
In-Reply-To: <1352879017.7.0.397020464451.issue16470@psf.upfronthosting.co.za>
Message-ID: <3Y3X685L44zRKp@mail.python.org>


Roundup Robot added the comment:

New changeset 2e2e7f398864 by Ezio Melotti in branch '2.7':
#16470: mention set and dict comprehension in the tutorial.  Patch by Yongzhi Pan.
http://hg.python.org/cpython/rev/2e2e7f398864

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

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

From report at bugs.python.org  Sat Nov 17 11:08:06 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Nov 2012 10:08:06 +0000
Subject: [docs] [issue16470] Backport set and dictionary comprehensions in
	tutorial	to 2.7
In-Reply-To: <1352879017.7.0.397020464451.issue16470@psf.upfronthosting.co.za>
Message-ID: <1353146886.54.0.909490762034.issue16470@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!
I also rephrased the sentence on 3.x.

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

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

From report at bugs.python.org  Sat Nov 17 15:17:27 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 17 Nov 2012 14:17:27 +0000
Subject: [docs] [issue15346] Tkinter extention modules have no documentation
In-Reply-To: <1342198047.2.0.619885102312.issue15346@psf.upfronthosting.co.za>
Message-ID: <1353161847.27.0.928847933454.issue15346@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From report at bugs.python.org  Sat Nov 17 16:39:24 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Nov 2012 15:39:24 +0000
Subject: [docs] [issue16420] PEP 249 (DB-API 2.0) converted to
	reStructuredText
In-Reply-To: <1352211401.03.0.321684940203.issue16420@psf.upfronthosting.co.za>
Message-ID: <3Y3gTl2PJ6zRdV@mail.python.org>


Roundup Robot added the comment:

New changeset 333fe4c4897a by Ezio Melotti in branch '2.7':
#16420: document a way to escape metacharacters in glob/fnmatch.
http://hg.python.org/cpython/rev/333fe4c4897a

New changeset 168f36c2b5ea by Ezio Melotti in branch '3.2':
#16420: document a way to escape metacharacters in glob/fnmatch.
http://hg.python.org/cpython/rev/168f36c2b5ea

New changeset 2208061d863c by Ezio Melotti in branch '3.3':
#16420: merge with 3.2.
http://hg.python.org/cpython/rev/2208061d863c

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

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

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

From report at bugs.python.org  Sat Nov 17 16:40:21 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Nov 2012 15:40:21 +0000
Subject: [docs] [issue16420] PEP 249 (DB-API 2.0) converted to
	reStructuredText
In-Reply-To: <1352211401.03.0.321684940203.issue16420@psf.upfronthosting.co.za>
Message-ID: <1353166821.49.0.717121107733.issue16420@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov 17 16:52:48 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Nov 2012 15:52:48 +0000
Subject: [docs] [issue16493] Document the 'optimize' argument to compile()
Message-ID: <1353167567.95.0.716171753234.issue16493@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Looks like Georg added the flag in 2010 after Python 2.7 was already out, so this doesn't need to be backported.

The possible values are:

-1 : optimization level the interpreter is already executing with
0 : no optimization
1 : -O
2 : -OO

----------
assignee: docs at python
components: Documentation
messages: 175757
nosy: brett.cannon, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Document the 'optimize' argument to compile()
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov 17 16:53:09 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Nov 2012 15:53:09 +0000
Subject: [docs] [issue16240] Document a way to escape metacharacters in
	glob/fnmatch
In-Reply-To: <1350312209.74.0.651951907427.issue16240@psf.upfronthosting.co.za>
Message-ID: <1353167589.54.0.388967756151.issue16240@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Finalized!

----------
assignee: docs at python -> ezio.melotti
priority: high -> normal
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Nov 17 16:54:47 2012
From: report at bugs.python.org (Kushal Das)
Date: Sat, 17 Nov 2012 15:54:47 +0000
Subject: [docs] [issue16493] Document the 'optimize' argument to compile()
In-Reply-To: <1353167567.95.0.716171753234.issue16493@psf.upfronthosting.co.za>
Message-ID: <1353167687.15.0.643862894462.issue16493@psf.upfronthosting.co.za>


Kushal Das added the comment:

I will submit a patch if no one is working on it.

----------
nosy: +kushaldas

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

From report at bugs.python.org  Sat Nov 17 17:05:56 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Nov 2012 16:05:56 +0000
Subject: [docs] [issue16240] Document a way to escape metacharacters in
	glob/fnmatch
In-Reply-To: <1350312209.74.0.651951907427.issue16240@psf.upfronthosting.co.za>
Message-ID: <1353168356.49.0.678612646464.issue16240@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you, Ezio.  Can we now continue with issue8402?

----------

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

From ezio.melotti at gmail.com  Sat Nov 17 17:09:02 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sat, 17 Nov 2012 16:09:02 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121117160902.18020.57191@psf.upfronthosting.co.za>


http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst#newcode1263
Doc/library/functions.rst:1263: If neither *encoding* nor *errors* is
given, ``str(object)`` returns
s/returns/calls/?

http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst#newcode1264
Doc/library/functions.rst:1264: :meth:`object.__str__`, which is the
"informal" representation of *object*.
Why not keeping the "nicely printable representation" used in the
original text?

http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst#newcode1264
Doc/library/functions.rst:1264: :meth:`object.__str__`, which is the
"informal" representation of *object*.
Doesn't it also fall back on __repr__ if __str__ is missing?

http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst#newcode1266
Doc/library/functions.rst:1266: function with related behavior.
"with related behavior" doesn't add much IMHO.
Either drop it and use "See also the repr function." or say what repr
does.

http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst#newcode1271
Doc/library/functions.rst:1271: :class:`bytes` (or :class:`bytearray`)
object in this case, then
s/in this case//?

http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst#newcode1279
Doc/library/functions.rst:1279: or *errors* arguments uses the first
mode (see also the :option:`-b`
s/uses the first mode/calls b.__str__()/?

http://bugs.python.org/review/13538/diff/6548/Doc/reference/datamodel.rst
File Doc/reference/datamodel.rst (right):

http://bugs.python.org/review/13538/diff/6548/Doc/reference/datamodel.rst#newcode1168
Doc/reference/datamodel.rst:1168: Called by :func:`str(object) <str>`
and the built-in function :func:`print`
Should string formatting be mentioned too?

http://bugs.python.org/review/13538/diff/6548/Doc/reference/datamodel.rst#newcode1176
Doc/reference/datamodel.rst:1176: back to calling :meth:`__repr__`.
Where does this happen?  Is it done by str/print or it happens
automatically?

http://bugs.python.org/review/13538/diff/6548/Lib/test/test_unicode.py
File Lib/test/test_unicode.py (right):

http://bugs.python.org/review/13538/diff/6548/Lib/test/test_unicode.py#newcode1194
Lib/test/test_unicode.py:1194: self.assertEqual(str(b'foo',
errors="strict"), "foo")
A test with non-ascii (most likely utf-8) bytes should be added.

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

From report at bugs.python.org  Sat Nov 17 17:15:05 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Nov 2012 16:15:05 +0000
Subject: [docs] [issue8402] Add a function to escape metacharacters in
	glob/fnmatch
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1353168905.37.0.763472479424.issue8402@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The workaround is now documented.
I'm still not sure if this should still be added, or if it should be closed as rejected now that the workaround is documented.
A third option would be adding it as a recipe in the doc, given that the whole functions boils down to a single re.sub (the user can take care of picking the bytes/str regex depending on his input).

----------

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

From report at bugs.python.org  Sat Nov 17 17:21:11 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Nov 2012 16:21:11 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1353169271.7.0.0713844661458.issue10224@psf.upfronthosting.co.za>


Brett Cannon added the comment:

What exactly is blocking this? From looking on PyPI it seems Jinja2, Pygments, and Sphinx have all been ported to Python 3 at this point. Is it a matter of porting any custom code in Doc/ to Python 3 and then updating the Makefile to grab Python 3 versions of the required libraries?

----------
dependencies:  -Fix doctest runable examples in python manual

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

From report at bugs.python.org  Sat Nov 17 17:44:58 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Nov 2012 16:44:58 +0000
Subject: [docs] [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>
Message-ID: <1353170698.14.0.193698346418.issue15292@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Closing as "works for me" due to lack of reply from OP.

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

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

From report at bugs.python.org  Sat Nov 17 18:30:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Nov 2012 17:30:59 +0000
Subject: [docs] [issue16157] Irrelevant references to Misc/News
In-Reply-To: <1349628852.45.0.324394497616.issue16157@psf.upfronthosting.co.za>
Message-ID: <3Y3jyV4DLrzN9n@mail.python.org>


Roundup Robot added the comment:

New changeset d6cd283bb4c2 by Ezio Melotti in branch '3.3':
#16157: fix links in the whatsnew files.
http://hg.python.org/cpython/rev/d6cd283bb4c2

New changeset 9a08c9443c54 by Ezio Melotti in branch 'default':
#16157: merge with 3.3.
http://hg.python.org/cpython/rev/9a08c9443c54

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

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

From report at bugs.python.org  Sat Nov 17 18:32:05 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Nov 2012 17:32:05 +0000
Subject: [docs] [issue16157] Irrelevant references to Misc/News
In-Reply-To: <1349628852.45.0.324394497616.issue16157@psf.upfronthosting.co.za>
Message-ID: <1353173525.55.0.655896565158.issue16157@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This should be fixed now.
I linked to http://hg.python.org/cpython/file/3.2/Misc/NEWS for the 3.2 whatsnew and to http://docs.python.org/3.3/whatsnew/changelog.html and http://docs.python.org/3.4/whatsnew/changelog.html for 3.3 and 3.4 respectively.

----------
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/issue16157>
_______________________________________

From report at bugs.python.org  Sat Nov 17 18:36:02 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Nov 2012 17:36:02 +0000
Subject: [docs] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s?=
 =?utf-8?q?_new_opener_argument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1353173762.53.0.412508697733.issue13424@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

There's also a Sphinx warning that should be fixed:
3.3/Doc/library/functions.rst:955: WARNING: undefined label: dir_fd (if the link has no caption the label must precede a section header)

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

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

From ezio.melotti at gmail.com  Sat Nov 17 18:38:56 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sat, 17 Nov 2012 17:38:56 -0000
Subject: [docs] argparse with many choices can generate absurdly long usage
 message (issue 16418)
Message-ID: <20121117173856.21218.96954@psf.upfronthosting.co.za>


http://bugs.python.org/review/16418/diff/6550/Doc/library/argparse.rst
File Doc/library/argparse.rst (right):

http://bugs.python.org/review/16418/diff/6550/Doc/library/argparse.rst#newcode1025
Doc/library/argparse.rst:1025: values.  These can be handled by passing
a container object as the ``choices``
Not your fault, but this should be *choices*.

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

From report at bugs.python.org  Sat Nov 17 18:42:38 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Nov 2012 17:42:38 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1353174158.54.0.721811216764.issue10224@psf.upfronthosting.co.za>


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


----------
dependencies: +upgrade to sphinx 1.1

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

From chris.jerdonek at gmail.com  Sat Nov 17 18:49:14 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Sat, 17 Nov 2012 17:49:14 -0000
Subject: [docs] argparse with many choices can generate absurdly long
 usage message (issue 16418)
Message-ID: <20121117174914.18020.18334@psf.upfronthosting.co.za>


http://bugs.python.org/review/16418/diff/6550/Doc/library/argparse.rst
File Doc/library/argparse.rst (right):

http://bugs.python.org/review/16418/diff/6550/Doc/library/argparse.rst#newcode1025
Doc/library/argparse.rst:1025: values.  These can be handled by passing
a container object as the ``choices``
On 2012/11/17 18:38:56, ezio.melotti wrote:
> Not your fault, but this should be *choices*.

I noticed and thought about this when creating the patch.  All of the
surrounding documentation uses the `` formatting.  For example,
``choices`` occurs that way four times in that section, and similarly
for the documentation of the other keyword arguments.  So it was for
consistency.

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

From report at bugs.python.org  Sat Nov 17 18:52:13 2012
From: report at bugs.python.org (Jan Duzinkiewicz)
Date: Sat, 17 Nov 2012 17:52:13 +0000
Subject: [docs] [issue16386] imp.find_module does not specify registry key
	it	searches on windows
In-Reply-To: <1351859767.89.0.815277454803.issue16386@psf.upfronthosting.co.za>
Message-ID: <1353174733.06.0.592460924059.issue16386@psf.upfronthosting.co.za>


Jan Duzinkiewicz added the comment:

Ok, didn't knew much about importlib, I can work on a patch but have a few questions/suggestions:

1. For importlib, simply referencing the "Using on Windows" guide imo won't be ok - the importlib sources show that the key being used is "Software\\Python\\PythonCore\\{sys_version}\\Modules\\{fullname}", while guide refers to \\PythonPath. Am I missing something here?
2. Considering that importlib code is Python, easy to retrieve without having C sources (which is common case on Windows) - do you think this should go into 3.3 docs? 
3. Do you think the current version of the patch is applicable to Python 2.7?

----------

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

From ezio.melotti at gmail.com  Sat Nov 17 19:05:22 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sat, 17 Nov 2012 18:05:22 -0000
Subject: [docs] argparse with many choices can generate absurdly long
 usage message (issue 16418)
Message-ID: <20121117180522.21277.65854@psf.upfronthosting.co.za>

On 2012/11/17 18:49:14, cjerdonek wrote:
> http://bugs.python.org/review/16418/diff/6550/Doc/library/argparse.rst
> File Doc/library/argparse.rst (right):
> 
>
http://bugs.python.org/review/16418/diff/6550/Doc/library/argparse.rst#newcode1025
> Doc/library/argparse.rst:1025: values.  These can be handled by
passing a
> container object as the ``choices``
> On 2012/11/17 18:38:56, ezio.melotti wrote:
> > Not your fault, but this should be *choices*.
> 
> I noticed and thought about this when creating the patch.  All of the
> surrounding documentation uses the `` formatting.  For example,
``choices``
> occurs that way four times in that section, and similarly for the
documentation
> of the other keyword arguments.  So it was for consistency.

OK, maybe they should be fixed in a separate commit.

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

From chris.jerdonek at gmail.com  Sat Nov 17 22:37:49 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Sat, 17 Nov 2012 21:37:49 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121117213749.21277.90381@psf.upfronthosting.co.za>


http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst#newcode1264
Doc/library/functions.rst:1264: :meth:`object.__str__`, which is the
"informal" representation of *object*.
On 2012/11/17 17:09:02, ezio.melotti wrote:
> Why not keeping the "nicely printable representation" used in the
original text?

I switched to using the same language that the object.__str__()
documentation used.  I can include both phrasings as that documentation
now includes both.

http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst#newcode1264
Doc/library/functions.rst:1264: :meth:`object.__str__`, which is the
"informal" representation of *object*.
On 2012/11/17 17:09:02, ezio.melotti wrote:
> Doesn't it also fall back on __repr__ if __str__ is missing?

str() (unicode_new() in the source code) only calls object.__str__()
(PyObject_Str() in the source code):

http://hg.python.org/cpython/file/e9af9b1ca67e/Objects/unicodeobject.c#l14012

The fallback logic is part of PyObject_Str:

http://hg.python.org/cpython/file/e9af9b1ca67e/Objects/object.c#l396

which is documented as part of the object.__str__() documentation (which
is linked to).  You can confirm this by defining a class that defines
__repr__() but not __str__(), and then calling __str__() on it:

  >>> class Foo(object):
  ...   def __repr__(self):
  ...     return "foo"
  ... 
  >>> f = Foo()
  >>> f.__str__()
  'foo'

http://bugs.python.org/review/13538/diff/6548/Doc/reference/datamodel.rst
File Doc/reference/datamodel.rst (right):

http://bugs.python.org/review/13538/diff/6548/Doc/reference/datamodel.rst#newcode1176
Doc/reference/datamodel.rst:1176: back to calling :meth:`__repr__`.
On 2012/11/17 17:09:02, ezio.melotti wrote:
> Where does this happen?  Is it done by str/print or it happens
automatically?

It's done in PyObject_Str.  See my reply to your other comment in
functions.rst.

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

From report at bugs.python.org  Sun Nov 18 00:36:39 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Nov 2012 23:36:39 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353195399.15.0.631545740871.issue16423@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

A couple of comments:

- the patch needs a test (and docs too)
- are you sure ignoring POSTed data is the right thing to do? Shouldn't we forbid it instead?
- I think it would be nice to reference the RFC number somewhere
- not sure why you raise IOError on a bad URL; I would say ValueError is the right exception here

+1 on the general idea, by the way.

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

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

From report at bugs.python.org  Sun Nov 18 00:42:08 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Sat, 17 Nov 2012 23:42:08 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1353195399.15.0.631545740871.issue16423@psf.upfronthosting.co.za>
Message-ID: <50A820CE.4070300@gmx.net>


Mathias Panzenb?ck added the comment:

On 11/18/2012 12:36 AM, Antoine Pitrou wrote:
>
> Antoine Pitrou added the comment:
>
> A couple of comments:
>
> - the patch needs a test (and docs too)

Will do (when I have time).

> - are you sure ignoring POSTed data is the right thing to do? Shouldn't we forbid it instead?
> - I think it would be nice to reference the RFC number somewhere
> - not sure why you raise IOError on a bad URL; I would say ValueError is the right exception here
>

I did that because that's what the old URLopener code does (ignoring POSTed data and raising an 
IOError). The comment is actually a 1:1 copy of the old code.

> +1 on the general idea, by the way.
>
> ----------
> nosy: +pitrou
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16423>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Nov 18 00:43:19 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Nov 2012 23:43:19 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <50A820CE.4070300@gmx.net>
Message-ID: <1353195749.3331.27.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> > - are you sure ignoring POSTed data is the right thing to do? Shouldn't we forbid it instead?
> > - I think it would be nice to reference the RFC number somewhere
> > - not sure why you raise IOError on a bad URL; I would say ValueError is the right exception here
> >
> 
> I did that because that's what the old URLopener code does (ignoring POSTed data and raising an 
> IOError). The comment is actually a 1:1 copy of the old code.

Ok. I think it's better to take a fresh start here :-)

----------

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

From report at bugs.python.org  Sun Nov 18 02:31:16 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Sun, 18 Nov 2012 01:31:16 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1353195399.15.0.631545740871.issue16423@psf.upfronthosting.co.za>
Message-ID: <50A83A62.5010607@gmx.net>


Mathias Panzenb?ck added the comment:

On 11/18/2012 12:36 AM, Antoine Pitrou wrote:
>
> - the patch needs a test (and docs too)
> - are you sure ignoring POSTed data is the right thing to do? Shouldn't we forbid it instead?

Btw.: The file:// protocol handler also just ignores posted data, so I think the data url handler 
shouldn't deviate from that. Either both raise an error when data is posted or none.

----------

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

From chris.jerdonek at gmail.com  Sun Nov 18 03:00:46 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Sun, 18 Nov 2012 02:00:46 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121118020046.21218.5780@psf.upfronthosting.co.za>


http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6548/Doc/library/functions.rst#newcode1264
Doc/library/functions.rst:1264: :meth:`object.__str__`, which is the
"informal" representation of *object*.
On 2012/11/17 22:37:49, cjerdonek wrote:
> On 2012/11/17 17:09:02, ezio.melotti wrote:
> > Doesn't it also fall back on __repr__ if __str__ is missing?
> 
> str() (unicode_new() in the source code) only calls object.__str__()
> (PyObject_Str() in the source code):

What I wrote isn't quite correct.  str() calls PyObject_Str(), but
PyObject_Str() isn't called by object.__str__().  However,
object.__str__() (or at least the default implementation?) seems to
implement its own equivalent fallback logic:

http://hg.python.org/cpython/file/eb3714863872/Objects/typeobject.c#l5262

So in distinct ways both code paths seem to contain this fallback logic.

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

From report at bugs.python.org  Sun Nov 18 05:16:02 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Sun, 18 Nov 2012 04:16:02 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353212162.38.0.982224306705.issue16423@psf.upfronthosting.co.za>


Mathias Panzenb?ck added the comment:

Ok, I've added a documentation and some tests. Is it ok this way? More tests? More/other documentation?

----------
Added file: http://bugs.python.org/file28017/urllib.request-data-url.patch

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

From report at bugs.python.org  Sun Nov 18 05:41:33 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Sun, 18 Nov 2012 04:41:33 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353213693.12.0.666715656697.issue16423@psf.upfronthosting.co.za>


Changes by Mathias Panzenb?ck <grosser.meister.morti at gmx.net>:


Removed file: http://bugs.python.org/file28017/urllib.request-data-url.patch

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

From report at bugs.python.org  Sun Nov 18 05:41:48 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Sun, 18 Nov 2012 04:41:48 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353213708.01.0.973930447542.issue16423@psf.upfronthosting.co.za>


Changes by Mathias Panzenb?ck <grosser.meister.morti at gmx.net>:


Added file: http://bugs.python.org/file28018/urllib.request-data-url.patch

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

From report at bugs.python.org  Sun Nov 18 05:42:11 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Sun, 18 Nov 2012 04:42:11 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353213731.25.0.888704844087.issue16423@psf.upfronthosting.co.za>


Changes by Mathias Panzenb?ck <grosser.meister.morti at gmx.net>:


Removed file: http://bugs.python.org/file27994/urllib.request-data-url.patch

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

From davidzgz123 at gmail.com  Mon Nov 12 18:03:05 2012
From: davidzgz123 at gmail.com (David Ceresuela)
Date: Mon, 12 Nov 2012 18:03:05 +0100
Subject: [docs] Documentation bug in 2.7.3 version 4.4 section
Message-ID: <CAKs9=yMiuoC5ib6UBiOP+U352Wku76bwQbKNxD9wUcekVNXhkA@mail.gmail.com>

Hello everyone!

In the
http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loopsthere
are two print statements that I think are not correct.
These are:
- print("Found an even number", num)
- print("Found a number", num)

The output should be:
>>> Found an even number 2
>>> Found a number 3

But instead I get:
>>> ('Found an even number', 2)
>>> ('Found a number', 3)


Proposed solution is to delete the parentheses:
Change
print("Found an even number", num)
to
print "Found an even number", num

That way the output I get matches the expected output
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121112/ff4a48d2/attachment.html>

From ertymail at gmail.com  Sat Nov 17 21:12:38 2012
From: ertymail at gmail.com (Dmitry Tolstoy)
Date: Sun, 18 Nov 2012 00:12:38 +0400
Subject: [docs] docs bug
Message-ID: <CAAj=Cf-s7eUbz6jM9AB-pvK9Dxex+gUvO_XA3se-xE=jwWOVyg@mail.gmail.com>

http://docs.python.org/3.3/library/multiprocessing.html

if __name__ == '__main__':
    with Pool(processes=4) as pool         # start 4 worker processes

Must be:

if __name__ == '__main__':
    with Pool(processes=4) as pool:         # start 4 worker processes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121118/ccdfb0d5/attachment.html>

From ezio.melotti at gmail.com  Sun Nov  4 05:29:40 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sun, 04 Nov 2012 04:29:40 -0000
Subject: [docs] Document that datetime.__format__ is datetime.strftime
	(issue 8913)
Message-ID: <20121104042940.25828.2222@psf.upfronthosting.co.za>


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'
I'm not sure what 'John in 2002' means.
I would re-use one of the previous examples to show the symmetry between
strftime and format.

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

From flairyu at gmail.com  Tue Nov 13 16:50:06 2012
From: flairyu at gmail.com (Flair Yu)
Date: Tue, 13 Nov 2012 23:50:06 +0800
Subject: [docs] Hi all, I want to translate Python 2.7's doc to Chinese,
	what shall i do?
Message-ID: <CALMyDCm9=h+hD+jf--1TmbBj2yAoeGV8ue-WQTUgn1m+r5MJ7w@mail.gmail.com>

Hi all!

 I like python, it's simple and easy to use.  I want to translate Python
2.7's documents to Chinese, so lots of Chinese can know it and learn. I
wander what shall I do next? Is there somebody i should report for? thanks.

flair yu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121113/22e14165/attachment.html>

From gurleym at gmail.com  Tue Nov 13 22:05:23 2012
From: gurleym at gmail.com (gurleym at gmail.com)
Date: Tue, 13 Nov 2012 21:05:23 +0000
Subject: [docs] Python 2.7.2
Message-ID: <27E0026F-50E4-4C1C-BEED-9A4E59B50AF4@gmail.com>

Greetings,

I'm using Python 2.7.2 on windows 7.  From the tutorial page chapter 3.1.1,we start going into numbers and comments. In following the examples I type the code

8/5 # Fractions aren't lost when dividing integers <hit enter>
1

Per the example on the web page I should get 1.6 not 1

Am I doing something wrong?  

Also I purchased your app for iPad. I can't figure out where to do these tutorials on it. I understand the reference page and found the links but where/ how do I input the code in the app. Even just the simple math part. 


Thank you for your time

-Matt

From hcp at pobox.com  Thu Nov  8 13:57:16 2012
From: hcp at pobox.com (Hugh Parker)
Date: Thu, 8 Nov 2012 12:57:16 +0000
Subject: [docs] http://docs.python.org/2/library/hashlib.html
Message-ID: <CAOw2TN_vksS4n87amKDs4vxUbu+Gdng2daHPjHpX_3iO=91sBw@mail.gmail.com>

http://docs.python.org/2/library/hashlib.html has an error:

m.update("Blah") doesn't work.  It gives a type error.  To work, it needs
to be m.update("Blah".encode('utf-8'))

I'm using Python 3.3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121108/c456fe06/attachment.html>

From heikki.partanen at gmail.com  Sun Nov  4 20:02:49 2012
From: heikki.partanen at gmail.com (heikki.partanen at gmail.com)
Date: Sun, 04 Nov 2012 19:02:49 -0000
Subject: [docs] Document that datetime.__format__ is datetime.strftime
	(issue 8913)
Message-ID: <20121104190249.29901.94866@psf.upfronthosting.co.za>


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. 

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 knleeds at gmail.com  Thu Nov 15 00:40:14 2012
From: knleeds at gmail.com (Kevin Leeds)
Date: Wed, 14 Nov 2012 17:40:14 -0600
Subject: [docs] Bug: I can't find documentation for the "apply" function,
 and then I can't find documentation for "extended call syntax"
Message-ID: <CAJnwqem37yWo+xBJRPHAogAs81=MzoUFmWY4qR8sdDzj3q95hQ@mail.gmail.com>

Sorry! I am trying to figure out from the documentation a good way to
use "call" instead of "apply", and am finding myself frustrated by the
documentation site

Apparently there's no way to search among functions names only, and
perhaps not for phrases either.

On one page I found out the "apply" function is deprecated, and that I
should use the "extended call syntax".
At one point I'm informed that the description of "extended call
syntax" is described "above".

There should be a hyperlink to the actual description.  It's not
possible to find the material being referenced without guessing
sections or reading the entire document perhaps.

:) Thank you for your prompt attention to this important matter :)

From knleeds at gmail.com  Thu Nov 15 01:12:50 2012
From: knleeds at gmail.com (Kevin Leeds)
Date: Wed, 14 Nov 2012 18:12:50 -0600
Subject: [docs] Bug: I can't find documentation for the "apply" function,
 and then I can't find documentation for "extended call syntax"
In-Reply-To: <CAJnwqem37yWo+xBJRPHAogAs81=MzoUFmWY4qR8sdDzj3q95hQ@mail.gmail.com>
References: <CAJnwqem37yWo+xBJRPHAogAs81=MzoUFmWY4qR8sdDzj3q95hQ@mail.gmail.com>
Message-ID: <CAJnwqek57v5AfzvpduY=U3Q1TzaD33RQ+uFTV1o8Di9GwhFQzA@mail.gmail.com>

P.S. I still can't find it when I read the Python Tutorial.
There's a section on Defining Functions, then there's More About
Defining Functions.
However there's no section about calling functions.


On Wed, Nov 14, 2012 at 5:40 PM, Kevin Leeds <knleeds at gmail.com> wrote:
> Sorry! I am trying to figure out from the documentation a good way to
> use "call" instead of "apply", and am finding myself frustrated by the
> documentation site
>
> Apparently there's no way to search among functions names only, and
> perhaps not for phrases either.
>
> On one page I found out the "apply" function is deprecated, and that I
> should use the "extended call syntax".
> At one point I'm informed that the description of "extended call
> syntax" is described "above".
>
> There should be a hyperlink to the actual description.  It's not
> possible to find the material being referenced without guessing
> sections or reading the entire document perhaps.
>
> :) Thank you for your prompt attention to this important matter :)

From latias100 at gmail.com  Sat Nov  3 02:30:12 2012
From: latias100 at gmail.com (Matthew Lakier)
Date: Sat, 03 Nov 2012 01:30:12 -0000
Subject: [docs] PEP8 conformance regarding the "Idioms and Anti-Idioms in
	Python" page
Message-ID: <CAHeJjUL94q8MeSzCuedN6nEtA185upS=kS3LS15zna_bHTky7A@mail.gmail.com>

This is nothing major, but I guess every bit helps.

Under the "Using Backslash to Continue Statements" section of
http://docs.python.org/2/howto/doanddont.html (also in the Python 3 docs),
the last two code samples:

value = foo.bar()['first'][0]*baz.quux(1, 2)[5:9] \
        + calculate_number(10, 20)*forbulate(500, 360)

and

value = (foo.bar()['first'][0]*baz.quux(1, 2)[5:9]
        + calculate_number(10, 20)*forbulate(500, 360))

have the operator after the line break instead of before, like:

value = (foo.bar()['first'][0]*baz.quux(1, 2)[5:9] +
         calculate_number(10, 20)*forbulate(500, 360))

It would be good if these code samples could be changed to have the
operator before the line break in order to conform with PEP8 ("The
preferred place to break around a binary operator is after the operator,
not before it.") and the rest of the documentation.

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

From list at qtrac.plus.com  Thu Nov  1 15:47:40 2012
From: list at qtrac.plus.com (Mark Summerfield)
Date: Thu, 01 Nov 2012 14:47:40 -0000
Subject: [docs] Confusion over NotImplemented constant
Message-ID: <20121101144737.773971d2@dino>

Hi,

On this page

http://docs.python.org/3/library/constants.html?highlight=notimplemented#NotImplemented

It says that NotImplemented should be returned by rich comparison
special methods.

But it doesn't mention using it with the abc module. Yet on this page

http://docs.python.org/3/library/abc.html#module-abc

It says that __subclasshook__() methods should return NotImplemented.

However, on this page

http://docs.python.org/3/library/exceptions.html?highlight=notimplemented#NotImplementedError

It says that abstract methods should raise NotImplementedError.

Maybe someone could unify the coverage of NotImplemented and
NotImplementedError and explain when to use one and when to use the
other?

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
        "Programming in Go" - ISBN 0321774639
            http://www.qtrac.eu/gobook.html

From marshall at bgc-jena.mpg.de  Tue Nov 13 15:23:27 2012
From: marshall at bgc-jena.mpg.de (Julia Marshall)
Date: Tue, 13 Nov 2012 15:23:27 +0100 (CET)
Subject: [docs] minor error in Tutorial section 4.4
Message-ID: <475012176.604.1352816607482.JavaMail.open-xchange@cal.bgc-jena.mpg.de>

Hello,

this is really a small thing, but there's an inconsistency between the input and
output in the second example (showing the "continue" statement) in section 4.4
of the tutorial.  The example reads as follows:


>>> for num in range(2, 10):
...     if num % 2 == 0:
...         print("Found an even number", num)
...         continue
...     print("Found a number", num)
Found an even number 2
Found a number 3
Found an even number 4
Found a number 5
Found an even number 6
Found a number 7
Found an even number 8
Found a number 9


and it should read like this:


>>> for num in range(2, 10):
...     if num % 2 == 0:
...         print "Found an even number", num
...         continue
...     print "Found a number", num
...
Found an even number 2
Found a number 3
Found an even number 4
Found a number 5
Found an even number 6
Found a number 7
Found an even number 8
Found a number 9


Otherwise there are unsightly parentheses and quotation marks in the output.  I
know this is really nit-picking, but the documentation is really good, so I
figured it might as well be perfect. ;)

Cheers,

-Julia

-------------------------------------------------------
Julia Marshall, Ph.D.
Max-Planck-Institut f?r Biogeochemie
Hans-Kn?ll-Str. 10
07745 Jena
Germany

Tel.: +49 (36 41) 57 6383
Fax.: +49 (36 41) 57 7300
mobile.: +49 (176) 6433 2265
email: marshall at bgc-jena.mpg.de
http://www.bgc-jena.mpg.de/~marshall
-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121113/f08908e6/attachment.html>

From michellebarton39 at gmail.com  Mon Nov 12 05:44:28 2012
From: michellebarton39 at gmail.com (Michelle Barton)
Date: Sun, 11 Nov 2012 20:44:28 -0800
Subject: [docs] A Broken Link on Your Site About Geany and GTK
Message-ID: <3FPK73FB-7FA6-634G-8G8T-DPQX0QMHOL6E@gmail.com>

Hi Administrator,

I came across your website and wanted to notify you about a broken link on your page in case you weren't aware of it. The link on pythonexperts.com/_sources/using/unix.txt which links to http://geany.uvena.de/ is no longer working. I've included a link to a useful page on Geany and GTK that you could replace the broken link with if you're interested in updating your website. Thanks for providing a great resource!

Link: http://www.onlinecomputersciencedegree.com/resources/geany-and-gtk/

Best,
Michelle Barton


From nikolay.plotnik at phystech.edu  Wed Nov  7 14:33:22 2012
From: nikolay.plotnik at phystech.edu (=?KOI8-R?B?7snLz8zByiDzxdLHxcXXyd4g8MzP1M7Jyw==?=)
Date: Wed, 7 Nov 2012 17:33:22 +0400
Subject: [docs] Wrong output in quoted string
Message-ID: <CAK=v8oZdF1nE+W8tMpbYea7Rxdqrf0x6mJn-iXsLwkTD=Y=inw@mail.gmail.com>

Hi, everyone!

Today I was reading python tutorial, and find such bug:

http://docs.python.org/3/tutorial/introduction.html
Section - 3.1.2. Strings

Last output:

>>> '"Isn\'t," she said.''"Isn\'t," she said.'

This is no backslash \ in output before 't,"

I use python 3.3.0

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64
bit (AM
D64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print('"Isn\'t," she said.')
"Isn't," she said.

Thank you for such documentation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121107/988b2564/attachment-0001.html>

From pf at artcom-gmbh.de  Fri Nov  9 16:46:00 2012
From: pf at artcom-gmbh.de (Peter Funk)
Date: Fri, 9 Nov 2012 16:46:00 +0100
Subject: [docs] Explanation of the term "cell" in Python reference missing
 or hard to find
Message-ID: <20121109154600.GG18028@artcom0.artcom-gmbh.de>

Hello,

while reading in the Python reference manual I stumbled about 
this table entry:
  "__closure__ : None or a tuple of cells that contain bindings for 
                 the function?s free variables."
  http://docs.python.org/3.2/reference/datamodel.html
This text block is inherited unchanged from Python 2 as in 
  http://docs.python.org/2/reference/datamodel.html
In both cases this is first and only use of the term "cell" in 
the whole data model chapter.  I believe the term cell can have
very different meanings in computer science (AFAIK: english 
is not my native language) and should be better defined or
replaced by something else here.  Or not?

Regards, Peter Funk
P.S.: Please Cc: me since I'm currently not subscribed to the
docs mailing list.
-- 
Peter Funk, home: ?Oldenburger Str.86, D-27777 Ganderkesee
mobile:+49-179-640-8878 phone:+49-421-20419-0 <http://www.artcom-gmbh.de/>
office: ArtCom GmbH, ?Haferwende 2, D-28357 Bremen, Germany

From rail.shafigulin at gmail.com  Fri Nov  2 19:47:48 2012
From: rail.shafigulin at gmail.com (rail shafigulin)
Date: Fri, 02 Nov 2012 18:47:48 -0000
Subject: [docs] Inaccurate description of HtmlDiff.make_table,
	Python 3.1.5
In-Reply-To: <CAL3CFcWAdaAHfXv+qp6epTVN5cQMwRT7YSLv9et2ZEVgRkJMEw@mail.gmail.com>
References: <CAFAaeRXf_Fq=Sev4H+eX6+gf4oSK0g0YE5zhZyMiQGtAptx_gQ@mail.gmail.com>
	<CAL3CFcWAdaAHfXv+qp6epTVN5cQMwRT7YSLv9et2ZEVgRkJMEw@mail.gmail.com>
Message-ID: <CAFAaeRWwu0Rgn_PW3N242qx3bRyh243kSEUJM_ePxyztOamYRQ@mail.gmail.com>

I can't see any highlighting. I'm attaching diff.html which I generated
using the script provided here,
http://docs.python.org/release/3.1.5/library/difflib.html#a-command-line-interface-to-difflib
.
In the script I changed make_file to make_table to demonstrate the effect.
I'm also attaching two text files I used for diff generation.

I'm running Python 3.1.5 on a Windows XP Pro Version 2002, SP 3.

Thanks.


On Thu, Nov 1, 2012 at 6:34 AM, Andrew Svetlov <andrew.svetlov at gmail.com>wrote:

> It works, at least from my understanding of ?highlighting?.
>
>
> On Tue, Oct 30, 2012 at 9:16 PM, rail shafigulin <
> rail.shafigulin at gmail.com> wrote:
>
>> The description of HtmlDiff.make_table is inaccurate,
>> http://docs.python.org/release/3.1.5/library/difflib.html#difflib.HtmlDiff.make_table It
>> says the following
>>
>> "Compares fromlines and tolines (lists of strings) and returns a string
>> which is a complete HTML table showing line by line differences with
>> inter-line and intra-line changes highlighted."
>>
>> However non of the rows in the tables are highlighted.
>>
>> There are two possible fixes for this.
>>
>> 1. The documentation is incorrect in describing what should happen when
>> this method is called. Instead of what is says right now it should say that
>> the table is generated without showing any differences.
>> 2. The code does not reflect the documentation, i.e. make_table should
>> generate the html string correctly.
>>
>> I'm running Python 3.1.5 on a Windows Xp Pro Version 2002, SP 3.
>>
>> _______________________________________________
>> docs mailing list
>> docs at python.org
>> http://mail.python.org/mailman/listinfo/docs
>>
>>
>
>
> --
> Thanks,
> Andrew Svetlov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121102/5e80819c/attachment-0002.html>
-------------- next part --------------
RFE4BMCZ3XPAJ1AE1RUWXBUUGKLIL82YGBG3RQC3D5TLKVBPIE8XKGHR1N7LJYEAS3T083JPQH2HQ5Z8
GNIVWV26AFNPDCUSJ25PANXO4W1YB3JVW7CJTUSSLBM5IGDAB00DFP8OWMMJX32MI41JOJRXN2YKP8BQ
66DD944CCB6M8BJL8IFQ4KFJ92IAR1GIHD2PKEHUKAHY2DQ5RIREOZTT8UNC3PK4711F8CDDAG13LTBF
RCRCSRLEYYU59B6HKF8L1HJSTDQQZA4D0KC6NKKVBNUZWY1RNE389I52B6AWAPZP51GV1O9EM0LPMQBA
2A1CPFVJVQUSZ946PAYE5GIFEIL9OJT8L2QD0S10DFGSBZ7YJPKU6LHATVTTSA2QKV5YZB5UY9P8AQQO
83H4QMQ21HWD4QU69UYIIW2RV9930KQPEG8XY93D3GU5WBE1YP2FMPGDHQ54BAU3XDMWYNNM0JELV2MB
44BE0RU0JLDQBQ7P27NDXKKMS69IBMXPY674Y0PH2D3KSSUOKMXL3YHOB4CAR3UNJUC6UF1TRGSAZRI0
E67JI8QXKE1RJB7IQVJG71F52M90I1T8FTIGVR22XS7NTGTDY00IJQXOPQAR9NCY3KFL5SQENO50CBQ4
OWQJ59W9KZ7KU920CCYMMOWGXQIPF3I7CWI14Z1P4MLW2VNU3LAXGZ1BHT9AC45EAMMA6TN44P8A0YV0
8888Y4PG2NKRMNUS9MPFMS101EMPT0T0WBUOCG94P2307RLOOAJI47ZDVVGBNN1PLCHVFH8UTD8NDH8F
6JUNEW4BCXZSPBCE9MDTPS9NUPTBVQ5V6CEGOIC74G1M61G4A55SXNS0V9U5UTT2WQUJC7Y5SVLW2G38
MXE9PN4P5LEK56QEQCOVY1HAPFJW2YXDPOK0LZED8GJ0OGKC05IWL66S0IQGV959KCTFHHADMU8UP1W2
U0ZTT7J766TZGCQA7Q0JVD1UKYPDUWWLX7K35LMSX5N1VAJAGHBUMYUN2XWBOPSMTVMUGLNLTSAQORY8
556D1ALGPHAABIO7117W78I9EFW53BGVA7BE7ZG3X381WA4034PO8IDTSPJ47RFDTGW2XUVCHHQXK4E7
TXEQ84PJBKG16TZ96HN6JFNNAEE4AML1426ZS1HA6GZRCJ3FQQQ8ASQWVFUQQ0O1C93FUYMEYLUHRFFJ
3KXIU5USO024Y5674SI8KCEPRVX9TANX6TZ4S5VHP6HEC7NEFRQM0O82J3AB5BQO5Z6ELFM03JU18ECK
54SY142FODYKR2DGZF9KTS4XMHFAQI96BCL50K7JQ75O5R9289W3GGJUKSF9OMAPCXPRAS6J4GLH0P4J
3PF2V594CU3YGKADY39RUSX85H61A5XCM8JSV5CGUITWPR2Q8JIQ0I8YQNYVL56KRZ3BYPJ6YP6D925J
232D47FDRFNE03BZ9VQGHCY5RU93CO25R0TD9VNEEBSM743BTSZ4HWUQVNU59ZQ88AGACPCD5VFYAK4P
98X8H95HTIATO8XR1RJZ3FN91FBIQEN3ISPP7O41AN2NWAYFBTPUUX69DBTB43ZINNF78KJWNN0ZOR28
NW99WV1BT1KES6YVTBAKSSFTEPFYJ9X1TWXOIFX0JEEFNHTHAJ1JAA239D2RISC2E28KQTRUUMBLTXG2
KLCR08JNX186I7P48VDRDY9U6BBO8AZ98W59GUEVF7KZ0M2U2UNQOYFTUPG8EZWS5NTEBQT5SW40V0C4
IV04B0I0YIQGWB36DI44GS186E6ZD3FHJAD81IO484M7OICSRSJQSM63KRBM2K0CVE69MURPBV2P8A7C
OPH4APCXTFEKORI4OJYCG5BT5QNJJJZWU15ZCU40RHAB72U00J9F6JVEAVA9TRPICWQ8FD4D9Y30NGK0
M46EW0JWF9LJDR8JJLA7YAOI27RVRLK4NB552PHQJGTH4R628MSDDMTR96ERT4AA8GVMLCH4IE6PAFU6
XIWAU9A3VNNUOMDBDRFMQPYS9RP4VT2VBLUZO5NRWGZSREOVDLEGHZOMRLGSW192KXCDT0709M5EYKOW
TNY8I50MJE24I6I6BA3U5B1A4EJW05NCYVTHJCNLJBNASACK2GOEFIGJ8XR0QQMBZRVDEXU1VW2N8BTO
V31QXNL13F92VFD9NACLXYH5M45597FPQYIRAF5RKETWELH0XELI9KLMQWXAJYSN48OA95CYECMKPRD9
J3IW4OMZIQQX1Y4LR7RCHT1QUB7J71KHBC6KBLUWWWU2Q07FEW4U077MZH22JPPQOWOX2ZBBS0O51SCS
MXNJE9TLQ4ZC3ZSWDUQ4GY16CC4IIFK62C5C54JH8NCG1JR7T1P0GFJQOK7Z2YGFJSIVUIUMROGNGWO1
BJXEQSA4MQ2IJQN8ZA5NILUHHHL2D1AFW5NGJBRQZNGRSX134OGJTEG8VNS0SVHCQ1SRNVN25L40VYYJ
FAN6UC2G201VE98WDSCGSYWPXD7U1L9HWFRSWWSG41597MCB491N4KYRAX1ATWYNQ2MKBVXYKTC1OOFX
XB6S6KN2H4WL507PBR5KO1FXDZMKGIFX4GP0Q3TB991TCPLQDDG91HJMXE36RBU7K60J2O2GMLQRUNZ9
82JIN07GYT4M3CPG1ZO311UJR5ROO9RYRJPWNT4C8MRCTI4B4GLMFYX3G68MFSEZBMPA2098RJVQK4AT
P8S8W8YKWIJM5Y8WU6RJLYDWW8B50XI1MI5EX7YW4ZHS5XF1RS7E0CLNH1612HW78KA3J1CMFPXET6GG
Z969O8P9RKIN7TG62M2B1SP7YJ6AMR520EUXVJRV4KQBAMED9W10PQYOC99BW0PTVD4LZLXUEE27H74Y
F2LWIQ14VCHA603XYXSFFM9TJME7EXD6KB4B1KKV5INEVNARPLTVCBACI0F4G7WUHZDI4AH8EB1NIJ4P
IR1IZIJTR6BFLVXQGW2CDKQXEFAE5KQ0WV0H25CZEWUHOTOTFXMLWFMOI77DMQSFBAMRQSL7HS1MSAET
RX9T6M2IBHXGI8R97X8O3ZFCHKEXRO58B5XV6V7KV4CBFNQYNSS46A6KSD8T7SZAHG1H2VQGKF1CD80E
UV4W9IEEBY321RMHBIIHD176GW71240GIXH38KNH2EPB4COV121RG1ZI3806KFDH9SPQJZ4HA7WKG607
0DNFWJ5JMXWS4HD8QNDBX0IBAKCNM0TWS7RFEXCGEMWVG7BINDHLYY2NC4XVKUC85O7SKAXCMM6XNIUV
7HMJBN34XVJGPRDSVEH40AM7JHHM7BCZ8ZPV12FQPIXYDPHX8BQ2G88Y4ZBMFK3PIIKMUIW2ISW43GH3
Y1042M3ZG61VGZ5U77105O63WXUPSQ1XN3BCNEIXDTMOX51TPB27SNL9Z0G98SCMD4KE33WWHP7WFCL1
1RBS8GHWP9QT4AB9NWRM8KODO7561CH9E3YDYIB79H7AX6Z3IWFSXQNSCMOZOMZ1TILJP497C5OF5P8R
RTUI2DTC6KQE3SD3QB9AE7YOCPQIMMDEFSQ84HK432EZETMOQ4572325Z0UPZBH58HWL27RTRRU0SNPP
D6OUI1SA6424RIFNO35L7QQ639OB5VGFX4HJTY6EXVGK1EWOH5S0Y3IMGNZ3AP6ZW7EJR45GWA3F1MG4
1OLLONQB32469YF4XXBH6VA6LD8GOGV6RTQ2B75GYKKB334E3VD8Y2VF6SCK70B35M186LMVQJBFNYBS
NY4HZU4T7PDU9209RWHQ4R85HIDSEOOYGAGNIHA3H7JNY3D63JZBP7LBZBIS619SK0FFY3SE2FF40C8Y
BVPF55KOY1N62YVZ7O9OLEH1IQHYOEKF8E6Y9M7K8CTJ229ER4WKWJTQBFIQY2UCKA0YXNRE5635YB6H
T4T80KNNGRIDKSA7RUIV4WB41QDBGPI85BAR5X8SV00CXHL6E235XEVL8AGBG45NLQNUQ8J7BT6HPRBK
VWY9ZH9YZQFAM80K59YJJWO5SU32UG0XLX8ZBGJ3WRJECB4TD1FXVED7YLS1AYBM2Y0K1OOY2VNO6LK4
CHSABJHEP3Y9F4D4P4OT45RTERXKQV84G6S9XT6BS5MR4IDILV3EZU3YAQATG3TS0Q5ETXT0V2MJ4CHF
87SYF65RPOO2QID27RVJDOVXQHO09A2LCXNAWRCJ8VGWNSHDQEYLG2UYKBNZYMUKY3PRLGF2D5RQEWLE
1I36L4XWI0L3GX11DLVH7OZHCTCQIDN5YZ5SH9P0QHVDXX9FMAJU5PVZJPFJ3AHFXMM8A17KLIVSC6R8
FT5PY48HBNOD45AZTUR8TS6HG0C1YUMRHZJXE2Z2XTU41DPDSWN1B7BKR9C0B71J8FCC105Q8MN15KGP
UHLRL9M80KVV7YUZ79XRW2YB7FDIQK2TOEGW99V7O538GN9F2F9KXWO2QXTDN7WFYHBKJYOHEVHB3CWN
LY4LCDEPRUC27I07K1BNJVMA9W0UVEOWQLYO4GWO6PBT9PTYTLL14QX8X8TQ02LKGQFZ1U8D37MJY4BP
S24FBA5UF0JR9KGDC260R8CYZXDAL58ZMAA1E6FCIZBKNHKYDVQ14NY1LSTLHSF9RSXZ71S5WUI4RM1S
3QPATLYRVTISQOZ4MMPOC23VCNRSGPWEPLJZC5W26Q5FTLHAJK0O6V0C6PYMO0B7CVDMBLTIW7GROQZG
2H6QAJG0JBOPR8Y2O6B5KUHAL5IQ017A4M6BBHNSNNNK604L4XWF7PKOPXDI5CT5GBS50MA91VSCZ1D6
HAL1YBI2O5WWMK4U1ZMZP768Q9BDF8D9V8QTRN9EXJLZLA8A69SCDHJEVPEU6SHF2DQDE1M56ISFFYPM
QB2TRH6X1TWF90G1DZ1V8GD6E1LG5IL8RE85MWP5SYC4OMK755D6406KRVNXAQEH5O9NKVI4YTZYWK4Z
VZO2L1GB0G5J8SA5TY2Q9NPQSEL45N66PZP29B33IFM2Y7L3AOGZKBEX3OAPRKHB0SMHK905SHRD94SA
168QB2ITMIZZKD599EFNSQDS7BR9RA5UO5GJ7QR9SEUZCP45E76OVWWPHU4TSCZOCYV58LYG716ZUJP5
LWXZZ789O6B7NMCRUZ8645JCFNCZVHY4M33P7VGSELC9F7VZS4UIFI1A8DO1WT2FN4DUATB8CSXV4U5A
0ETJZ75UQD01TUGHOY6HCER0EL2SEZYJ0ELL1PS2HTL8YVOQ87XET3IJFD77HA9W4LHESRZ9KNEBUH0O
TKD2FI90S23TFDL589ZCDN52GYOSFL35VE1EBTKQOKPR86N79RLCYJ52DW0S41YGY3QJVNOXIV6C4ROZ
IZF28862ESO10FXJXASP9BGX8G6BZVYQ8U82YAMTT1OGE6P4R83X78OH6XVRKB8DAHRNZI8ZN6PFY8J1
4J5EXPWPSRYE0NESU029TIELCBC2QW3XKXOP8GP3EP2TLFJ6EQP4ZC1EYDGW0583ORZJMJO8NR0V54W4
934R3ZU6ZMZNB6JMBHXVNCR2F3L6M2KWA0N0H683AMJGGENEP89EJ36UCCCTH6U17CMDZU9G6JBHMI0P
UXR980DM13EXZ43KXI6QL90OFA8JP0DZ6NNFA8YP3ID6C1MBBX4V7FRY0T0VX15CK809GNNVN0HMUCRL
ND75NWXQRRGEX09QA55QYXCLWQZ3OFWYITVRYU4LQOJ8IWCWRKPOHJ5EFKEZSQFZ1NKR5RHLCCE6K04I
CGZHM9QRIV6AWLAOF6HQ2OZW2TA0L8OBQKLWYO6DCSBE0CJ42TQ7B1TY4VIRQUMWDWBYGT3C3CE1LN59
3N46NOETZVK4BSOFAOHHUO2WEI64CODZ5KZCP6CJ9GJGJBBNRC08HB30JOK7XTL9Q5C1MX1COD1277J7
5DOD1FCT4OE2Q2OWZV84NGV40YJBBG9LKT2LCOZZFBH5AZQQRN8U0XUS3DDQFR9G5A022Q5IOK5NQZ4T
I7EMA9DJKO99VWXA37KE0ZZ6E02WSLB1GR89AAYP7OJ0KNZPUWG4OT6BDHDC9L8PRE0FIV3ILA6AD1QM
QIEAUVQPC9FJUL9SG7KER7MON6QE7B4P6JSK855LMWEWNEH9BMF28N8DNKKRG114FGTK0GQ3QJRODQH4
7PSFSLT13G4O0L2T38XBPMMIUPQBSB6K8K5BHYKECA5H1FFLRW0MNF5KLJG3AZLHGIIW1H2YU7YLZ5HC
SGZYYOBWP4A05IZQ2LCRQWR0BIA99UJ8OSMXFUCRICARZS5XRRH8BUOBHUOAC8ITVXB8J9PB2XSAQU6Y
8AZFFFWF1ZAYJET74RUH1TDZCVYE12GVB8X83PSLTZ4ZUUZZTNNUTY758A70UDGQ8P03V4CL3R6CUJ2Q
0QTHH2QY7QQGZHC6UBW189WTYGLLP6UTP5HOPZH3LLMP6PWMQ9OIA74JVW55RZCURPYUN7U1XES40L3F
8R0SDLSB7UVM5F5FSNCRMADJTAOZSSVGQ1NJUH2VEI5S5TWGZB4XBGKYOU91N4KGCKIF8HCOXO7K75YS
OILLQUOOBZDRWC5FKIDSB9P1FTNRGM8ISM7MR94J17I5XM1LPK1M40NR74JS3KJVIBZF3DK6RGA0F0K2
C47OAVOZLTUNFNZKI7NMTGKMGFK3URP64MQ3D1NH0J1QGY416M8X9ZGWV83EZ6KRRGA3YGQ2N37A0OXA
GBNS9ARIHKAPONM4D6C39TSTQKONTFZBHD29WBM0L6LPI18O6CNORX3U81QFW846C72IU2MDVO6ZX7YY
5IADC4PDA1HGE4EHTF74IJUYOOO1EHZQ2C7E7ZUD7QGKI1TUL47NJ0ZDDNXV7R4SLKC951N96253CEGB
L88VJH5CLT65PQOP614BGIS9RJEFC8EFXOQYAIA4CAKLN7H36C36BSAAQZBIPM4GIN95UTPGXZIXHSL8
SK5MRAEAIQ332SWMSO7O4OT74GTCL47LZU91V2NOG8U6F6OX03BW9OL0MSF22NDAPZU4F8YO829GXY4U
A74CJZNEOZTWZ5K875WX0BLD1CA2GSE13ZASYDB10SZ1IVEQY8ANP35Z834ZGR47RUWS8WQT2CJZUG2R
Z6H5KI8F34OQJDZF4C9VQLKJD77HXUDDNARBTGJ0BMQ51FQS12AKXHBEM5HWHTZJONTKZYV2H8I5UERH
FFTGE74U3DQ2T0IWL2YDI10V0LR7U7Y2NO0FI133YL74L2JZ6GSJB9SKUPX2RGE1CJSTV9H2S7LHLRUA
KMCHWZ4001510GAYZJ97CZOXWTV5HGHQ36KIQERB5OTPMVAEJSOOSVA8F198IX25PRFOUJZLOZQNMN7K
M0JUPKXAXF23ES78CIPT85SHRCJ573W6KA4PVM11LGXHU1I7HS8L4XJQMQNXIW0CVTARXRFQM5OTGCGA
MWCAT0OFMGZU84LZWRXCCYY4FY2IMHAYKSGKD49N4AX1MAH7GE99MDE5A3ZHE3CNRJIZ0V84R41BNXXK
HA4CK6CQ052PP7E4EXY11YCTWRR15VX4UQUVQXS6L36Y3PA8F0JVVYIOWAZ1IAXP27UNH7KVJLLDWODZ
SIMGOYIWWPIFIECBWWE1LYO9F6BJ98PK9Q1OM5S23G2F62H0SAJ83PTRAG91V1FI02U279ISD1XJCQZ1
F63UTAW8C3SL5MGVJ3HP8S3LZUIXODGI5T8H6B6NK6TPRW0KFPF6Y6C317JS5SON3FE41GVE0GPIUXWY
6OFPRPP08HVU156ZN8U9LBG3XLMQHV9DO24MI6Y72H9XUUENE5ATH7X7S84RSJ0ZSWCQSJ3FLRQI7CXB
WJG66LEH5L7PD0BCZQD9YRITI5D25UEF0W8PUGJ8AMXIQZO5GJ57O8QUYWJ80WSJOEW68JECUGI7TRUR
9NHVBQELES39PBVCUQCQ8W1H4PF6J37165FKYS87PX1YOSVDA2BIJWAP2Q9N480JJRVD4IUT4069WDH8
84T9A98ZKYCRT6K3Q8UF1L0MJY4H8AISDKGQX7Q1NYJIZWGOH5N36AHNCXY6CT921BGE8FGR9MU2NMC4
SM5GIJCYLZCGNZCF89VH3F3QVHLG05QCAV0XBKCCCV5J4GT4Z05AJ92HV4L84ZABU9RSUKCERQYDVQOR
FC6M0DFR7UV6SASDUVUOLT8NCK7QFXSGX6VIACDXO0QD3AL0AYT3DCUR10NFQWSDA9FXNMZZT5SFSVZU
6NZAEH8XVR2GSXOFF1QBSFSFNATIIK7358UAC1G9LVGJBAXXB9TXIV6QNYBJ4AF3HBATZPLI0MK3BZN6
T9M70VS66V4FRAAUURUQ7KBOK8EMVLDRCJMRQL1VURUC6DGONN640H28Q1ALKGR3CECEPSVBLB8KFVQG
JXTIF3AFLO6OPMMYQ1TNTHMBVHLZHOPVZ2PRERF2ZQ8FEXCV1G8CL2VL1UGQFH84KBMA7K1O4KC2DAA9
7M3EHOHBZYYJO03BG79KFNZ6UN304OTDM3KHSC5L3ZGF8LRBN6QIGL4PSU9W38M2XGW1EJRT62UA3FJH
N6F7J8TX1PTJBSA410VA7T8XP43SC94WLDFMK9VUEMJ2O387H5EJHFUJY9029GUL4T5WW5UXWYUS25QR
1MEJ5MVVDLTYF4FMRRI9Z4L9GPX0H5698H32P7V1YVKKNOUEE6KQ71ICW25K54N4ABXWWDP8AIY6FD5O
HU2OHHGJA0TJKE47LMA1KTB27YSHT2UVRV03ZBRYUGHJVYIQY8IEI21W2X8FJ1CDWLKMEW0LM6D5VNIR
SOMIJ6BQP75UJ97P1DITCHVY75RJDXHI29PGCGQTEKM0JOVG07GJ23R3S54HV9VE7RDUECSJ8UWMZ42S
5D6KNCL0X02RGJKFGZ7KFN81Y3J2NKSKGKNZ7INM4NTJC6K9CPJSMVK49TB9VAIS7Y811NEWKHW21ULA
KBYHDIM1ID2L50OYZRNIW7N6OPFBDXH2757O6R3HW1K3BXHZ03FUOUH3VKJGX40KZUZ8XR3788RSQPEO
CJG3FEVKIWCJU7SRGXSFLJ238NCAYCR9BN6LXIBQ8G4G053XTKZNJSBYH5AUWAV4OFZAVC9P3CYAXPW7
2M8PVB7OBOGP19AIF7XOXRLLC52560QLDRFYVNJZY8LXGCQY5SGSWBT3QHQA7DZX977QEPW2GZLL3KGV
J8476JHKS9NZVJXUOBYCFV5M6GA1Y3ZR2ZZ7A9DLKM1V380WP659JSTW5JN5KN9SCGXY67S4AK1G5B7B
254HT9R5B6FEEHUGBWQ17BWMN0D2JOMVLOROKFLC3PUB8AMS7PPE6ZBD8E7E5RJJYS192RVPR30QCMM5
BVFNAF0QZQIH29ZESO3IZQEF5JLETGH7Q75JYNI1CUDAASQ658D5YYZUR4F30HH6RZ266DX7X5Z7W01R
1JFYWSRKVK9OZ17UOIN5XN86DRQNAEVGILU8ARIH2YWHAMJRQX2DUD79ELUF401ZE9BG0MX07NXTE3IT
FQD7AXN09BNT0UJQYJ81P7VVW4H3DYFBFGO7R7UO8TJN0BOAWRH125KJC7AP8Q3R2A2XD4P8OBC307PG
BT53U6FZZPKMS8ZYX288VHR72LYHQLEXYM9CWCLPLZ6C17I52YGMCDQCV7ZRXGBDFNBL8DWLNNE1PA7G
UNAJYHVXML7QQMCBZUORKIYC14WP165EQNC5393P1NFFYIJ3ZWPVUE6XHMYQ9Q8G1RROHE7XIRFJFVC7
T05C9NCTT5KRXM7VY37JMNIZZAYGWNERHRDRUJUDLK73LTQ4PZ5HGMNXKOP2J1JGZM7VMK30IV2W885O
H6PY3QQW9JZIRJRBE9EVZNHI1CTVAOZ113IV11BW7TXM36F6G98OWIOMLAJ6GU2AARJ6EPXV71Y2VYFV
HVMIUUAQX10BTBGAMPKUPKESEWT5FVIESPSYRETW5692GVBTVP58INM6BRJOKO1E5HRQF0ULBIV1UPDP
R2WSV2DZ9QPTVZW5LHCLPWYM2E701S10F5NW4YNW3KSYS9CTIEI4H8GUQDBMVXPU70RZUIVB7RKJQECR
VY5QYEYBKCAQBR1MJNL5YNWQ5O15JY0OF54NI7S29DENI181CIJV23KATAANVVXIO33VX7F66L1KEWTP
RMAMSSU9A6N19715GS9QWBFX7S7ZGDTCBJZA5VYEDBL7IIIB87S1222IEIPQORZF7GDOUNOCH28VT5QC
NVUCHX1ZLCGG93QW5UWEQF7QXD54VW6WNF8T3CEQ35FJ9UILAGKO8S0ELC3Z5F8EEII6FIJNWDWJBZJ3
BQUO4ALMWJQY61GJDA84AJZEYCFG1AH0Q3Q3KDGP7AL7TVEG1MJFFI4FXD6GAEF31642ZOT36AGP3ON4
UTZAMNFN7SG6GR9QT28TF78DODQ8QP1ED4CUQR1X5JARQIMTHTE0GNAGI8JZPV20NBBRQ34BJGEQP4GE
QYY12B93NWF0XMLR5E1FLUW7TMODM9X6YG7M6YLBYUHG8HFXZEGN9CB2T9YDTM5M3QCSVT3DU2YB0Z8E
QC51BA3X1MO3VJ3X5GPLIBMTOZCFABAGXGHEFF9OAQI47HPLPU185RKFN4DOOCSQ85RVG7OMAU7Q5OX3
PCH2JA7ZGMUL7XZYCPL80V432DIDJXATNWF70YHKL9VQ5XA2OZ9CW3Z6DJ6C96TGJU4FTTDCIKY2IFE9
428EA7MB9EDY7XZ0FV9AXFJC0H6WNK0GD8OBCVHBB4RD8HGU5KNJRL8992IQRZM1GB8O4D2G9NG6VZMW
5O6RLBW3QWVIUQXLZLWSES8Q1ZB3K3IOM52CZQD6V8XL85M27DXFISRL1ZN1M9SNQ18AJ2H2RT0YDZ7B
WPK37KK3GKONMOKPLXEVY767IGE5V433UL7H603L9G7OQ4ARPQEDCMZGO1S3E2MWI1TZYSXRBRQUYGJB
5URICW63GOHAU3X2G870Y01MTD31L1QZNA0PSGQBXDRXSTVHRDJ9B1ZJPYXYVNKUCLSWWARMIKYEPP8L
L34XDB0HCQA5B50LH6LWURHD4QYAYRZ7XV6O1KU02C8ETEZX6W1KHFKDRF2D2PAUN3PG7HCY7PFBLGOP
3E05R252839IJZNB4IQTWHIW24YTQKPHMBKE7UG2MMJMLMNKRO7EPBLROBM4JMB60D0LH0W8VZLROPSG
HWVJ7HRQWXYHPX1D7FYVDYCYNHRLOFW1XL4YSZE31RH7AD4T6BATMLB7WANZRVFLRIOZZQNAZ8CTXZWA
3N4HLYP1WKF4HH7TBBWQLSZGTIJLV6733Z1LP544I20RIK6NHK0I8KBQP80JFS79KBV95BIFXS6EIEMQ
B7DYHZB46QRKS1GX4C891F65CYR0ONEUHML9FKN4MR3WAQ6E4Y1E6B6S859CC6MW4GS56Z6XVZ14U90U
A1ISWXL9Z330MG74ZMXPX4K1ZAB6VS7L18BWVR96F517YTBOUS1GGJ2SLQPEZDP72JNSXWYG7J7FSHZX
FTJA7MEBUS9WR6SCOMTE13VEU5SGY1U14ALIQQXXPIGDSFIFJ4GKZ30TY82B5VF1ZVLNZOEZ02JKXNJO
XWCKTERHKZHRTKNJ9VD0LNHCY084SIKNT7O9OR3VX40C7UMMDA5V1KBB8CIF5TTGXDC8Z76GPLGSUPBF
WO71GOXX8POEBD68I408N0R7BL5U2EG5THWF53H8HKQLD3K29IQU86RB1WAWJK49L8DQ9B6U11HXYGV7
OAP81G2QGWZ2ZEGA1LYNRS0XHUZXKBYK2QOF8DVI0DYVWHSETJ4UJ6ZS904ZJGLN6UXITZTR0NIO02FM
H8JYI0BRD3FILUUVQBCSFO5DW72HMD3IM7FFLVI4ELPWZ9KUQXNS1RZX6K2BT6L4UXAA48CXRBI4URIM
7P097LAMBBZ9MU38ZCM8346P5QDWMDYD73UMNZSVMJEJZ57FWZ2AUDEAL7HT7K2G3FS2MR0A5XZMP01K
19PH25CTITDZONRNDRGLFOKP18FS30V01SC45CZWDO99KNXTL7HSP35CZFLQM154I2CP6XIZPX0U8EL7
QD8DTKK6OPPBQJIBJFPVC7NKCW69QFUAKUPBPFSXFGEZPLK6SA8Q7KHMC2OXXVTHTLQI3BMN1NKBV1G9
Q1RCTTK8D75JEHK2VYW4HQ6ROY406V5EGN83P50H00X4A8H20JDBQLT3Y9O8LYR63RGKUAIGED9B9YYD
KHNFDTEXGTZLXXYR0EU1N2K9K4Y5D3BBU6L9SLC4I0KZWFZ2ZS3N2OUMMIS230IQCZCZUNTGKG7OGO3U
ARRBB6B6AJTKYD6T75TMAV5AVT030Z42PUCDJDPLGVJ5K7WWTX0F3DG5IY82DF8FGRTIOI6MVZMAM893
UNGD16ZQIY8K2PKF7551PZU0U1EQASYWK8CE21L7TUY2LV4N12GJW3SFCSYCR4MZRB7T0XEUGMPD6T61
V0Z6NTM39ONIYM30N0OYS2AXDS3MCMSGQBUXMA06Y9HDZ9TDRPAHITWEPPNPN3JURCETG6SX7351G3MM
LQZ9V2BQ3RWJ6HKLVTAWADDMGJ1OQAXS77ZRPTO3ZR59WET8ABCIUJBSL2Z83TIYEN6MP205UFCWA72Y
S06YGYXEBND0FNZV6NP5U15HI7TLY4P4NQ9C4A6L50S46TQIIWWWM7WLOCI6V3SLB2E220FYCEQKAM89
6N4J6JOEC0SYXNQ30VUJ08IMHJC5EN2I7KBU9V7BU2L83Z8SP7HON839IS8J7TZ96QAT7VPGSI6M1UKN
PUUZXVT7ZPH4VBDJACX6RILT4VLUN5319YYXTL0G1PEXA8LUO9O1S22WZAAETC1MWXLWD23PY3S7E4MZ
47989RMMBT7VPJLXC9G2UF6K192WNX56WD4FIKPJ6XTK7CYMBDUH3F6QDSQ2DNV3SSAE464G6H0O5CWF
Y07K9JZ067638DOFGBLKGVDT56PHZ3P7PCRS17M6V3NZ0RY9ZKRUS5Z5LQ3PZD9XJ6J6PMOS7MAVKBXO
3DEZUTZFCCZQ4CDDEK3YFXMK7P0Z1ODG8OZ3IMT70U54GDJ7BKW8AQWIALDZ1NM5LO0TTOW11NYYZKDB
TS2Z8F4R5WA53D1VZVT4NOJQZ6VH786V6M9R76BJ1KLQB99W3KCJQJY5UZMVJRHQOPZVEIKJ0CVSJTQE
9ABRNK8GBGLJ4WK0DRC3M8KAY7YBZCGR35MQ5BAMZF1EVJ4C6YB7WHSD0599AWU0FZA56IXG5DZAX78M
LEMW3WPLN13IVO8637D2NV8H33BEM2SH5GV74S3P29D8DVSZATSSZHYTM0ETIDPDSBBNRC852NQ85PSU
6N3IVUGL3SQ5JA5V6F2IUTC8ERZA2FQ8SDASGDPYMEZGAML6RS6SJZL6WMJJ9HYNZMN95URS57UCG74M
FT3ONS3B1QNCJJLO32RKSI8AM9LORCTP9TPHKY1KQKF6901G8G3TU1G7Y74OU68QN181WK9V0AE99XJ3
9X8IIBXSG52AOFNHU86V5W1FBVD85DGQZKKMM1ZJX86MR9172GLNJX8MY2TWZRNJASY2ZMU1X0TFK9JT
OR3UXMQZ2HN08LKWEURUVWNBL4G0N339YUBPELE04Z6G3T3MHHRBDTXYD5BVUI186HFBL3ANTFD2JMN7
P9993ZMGJEEFEKEPO30JE1FAS61UWKOW3JHADZWIR7X8E7VZOHIQDAM54C9IZVRU3URH6VLUR723LVD1
E5BDKYRRSFGYS3PO66S32SJMK4I7JFZ6S42KXASEE4R5N81I7Y12N1SR9SPNADTED9MHQS5582E2E3LO
YDV9NKRS194IR66T5LRGUY2P4ZGMNJ26ABP15SVF0ODCG9CA9QHQE4789WUPMW8UKNMHS8LCJWSED0L9
DBPNQY3FTMZK2D8B8BQACC26W47V7BYKCB5QJOQMNGL40F0UPJ3VHDP6U0U84ES4DUYDTQ3NB4MIY1GV
YJHQG4K3QSAI9HOMI939LI7CK7KU2R44NY1TP6I0VTR6II7Q6YWJI5OLJCFLSU8JAYHLF6SR0LLTTTV6
OL1JPWMOC58X3X4T9W483SM6ITEO5JBFMSRAKY0L77MDZNYPQCAMA99FK4V1EF1WZMGYI71PH8KJLFRN
15T6MJRWO2H3Q55QVTX8J9KQ1M2GGG5THVEE80VBHEFKLZLSXWA7093RVPHY1QM88S66KGSJHR4WUSZ9
GEDTHX66AMO3F49BDLQX4KJJRS7W0XXIKZFP3NMWU0DWOFC5DEBJKPVMRHER2U9MJWCY3FGU8225HWMX
PSB0RVURFXXJDYY43V4JC7GXRP556R0HD313ZLT72XLYASHB89ELYTDDSS1J1Y2Y6J1Q70SWZOX39OBK
SJBDO0V2C4BXHW5YQ0DEWD3K7EKIHEQ8ROOTHENHTOJW1TPZNRG5ER5OWLOBIB603GLJFN9DYG9PII9J
590IKLCM07RJ9S0GSGUZ3ASYRYF773N68O5XVH82SGH6SK5QWAYQCX9TSAZ9H2B3IF8BBWYC6NXX6IJ4
9Z30SLSAK38R04MNP9MWFSEQ8KFY2OUUY01YB10M8US0MPX78G74UL82Z3XD28OXIJ5LMTMURUL48DFB
32JZCSSC5DELKBHLGHOYSSXDNMCWYD74FP3BP95IMCXR8Z8LRHIDVCO17DMOO4W0T4X8R597VBWEYXD1
77H1UA6O82T8WSMJFSP5T3TCTLSZGNMAV1TL3A8Y55QTBZSUDIESP2ZUPWPJ8UK1H8ZJ0LWMLZGZW0YL
A0YXBY360FNUQH5RCGRI0FF0BD4DSWCQNDLBMD74Q4PEAQ64QVLWCCAYD9F4MYQU5A65RT6RAYUR6RJZ
S01GISSSSJS1YH7ES2X884B510NKZXQW6RXACM02NCFDE87CV0QQ74RG89KE3A075EC67IMLUF2QSDLP
94O4H26LJJ7JELI7F8WX8IH7MI6NP6IRAMGZ9L3AYA1ARJNMEG9SXKPD4N8U5UUU37808HQ8UGO702P5
130H751Q9CWKGQLZYYHGOC7AZY0TPLHG36PISCDP4255FRSCV2S24Y0KRNSJAOP0PUPGCUT82QQ9RNJF
HRE0IJ770CWOYL7TLRE47EERF5P4AN1B99R49RGLBF6UMI3E7PIFIG22HCRA9S4B3OR8X0AB879A2EF0
T5657FZIJJYV8EYTAZ7FGM6559I89BQ4KJZKXNEOOJGM33L2YXTU6GSNAWGQSWEZPOJ8IDBDZWJ3OTND
DX3PNKIH5RJST576M93X15KFFGN1FU1DXGG0YQ9IRAT1I1D8GTSASDM6OB8ALOHZJNXGUBIW6GHU7Z75
2F1J62AYX787X28BMFXJAEKFM62B6UC7VG0LMUF2JT5LZ7MBK2S9H7CBHS5WUBGPVG99CPBUYBT6VBSX
0LODVQ46OXT95IC5ZSVRPJM9FF9B20I4OUZ0XWIE3Z1M3CT3VHHW6L4T5PD9LUWMTU9ZCI572JPHJ34R
1NJLAX6SJVACQ3638JZ5E9G6VPFDMZYYOAT08YQM9P2F0I4E8DM5RJ9FOO6G4UYZJWYR67LT19RO6YFM
KB7M4QJMN0F5NB2XLTIXR1ECXHWCIM7OS4DTAF1LUNKV9Q03CN4M7LPRD7JX38A7PIYE8C2ZF6AYLQGJ
J0KPSJBJO13D9K44Y6L892MVAENWBRMLNMFNEYZNITRPSOJRXEVMC51A6GS6YR9CSEN6D135P4GZ9KB1
18FRZUNTNIWRYOROS6C2TUXIJID0EGIJXE152XUFS04MKD707G1IZCDI5EHLY7LWF2AJ7FETBJGRZSPR
DRDJABSHEDPXDHTSMHJ7OJTFYBE4MNCOZHXB6JTQ0ZPWMQJZWQQQL0B5GA3TG2K51DUMACL0C9Q55F4M
W3CUAFDTSN5PZ1FV6XUZBFHX15E2BEV4W24VXK95ULU79MXHB25A39GNIDH6VYA0AF03DM3VYII6UJZJ
5SNXP85TD3LMA0E2NXGFWGIQR5XWF1OORRSHMG4RO6G6IKEDS1D5YE94O1G49NJ72SGY3TPV0BVVFM2S
Q9XQQ2B48ZL21GKQLUB27671BMW1ZI4BPU14NXBD33JLQG0XWPICUV29NJBSM3DWWPK0J5KDRWEP7BY1
G0Y8K8A8CGTWWS6JLK0NVV32PB8MGAWNETLFMF9W20G05OKOV0H9EAWP1WSMKOGZPEVUJL6F2HQE64Q7
RSOV7YU5EHLX8DLWMDFPOZJMW6TY97K8V3YDVM6KBF617G08BDJYB72K9TJZFMOFA79YZDGFAJSVQRKX
RWIWPM1IPSSV8TAYSBCLKM123KKVFS5QTI92SA0174ZMTKE1R13BAP0Z2FAAKL55WQ6U9BCSGEQJWUZ3
DSJ4U56CVMHAEBUJIQQ1BGJ3OF8HG2G8884KPFC2ZDJUDQ00TX5X5SZ8V38JWG5T76A39OG8JYGRTKIB
OYALO7MWOXQ10I9B1A6JVO29USZ7QQ8QZB4P241J6XPBZ5TEUB4BA0GT5Q0TG1Y1AJ3B9S58SQR6U8KQ
CN233NUNGEUK3KK4V1YIJPY4WZNX4999X6EINW1XGWLWXF027QNX39XBNSQ40SQXWY3FAA115AKO6N4K
DC2PZ5DC96BKRIYEM2IHPBPFUE49A6P5FP31GS0WIBHB7AZGC5P3UM0EUKWSVJDBWG5KKQMX3CM3W32L
HMX20U00TG28MISIDPUCAG24LHNUBJATP8GGRKFKK8BVM94GQGDNQZM3E868AFDZFHKNJTRTDUZGJAQW
3VJFWCVUALXU8JP46SJE0YXZLDZGEVN98EH8UU8YD6H6IE390085B10RC6CARTJPZAIGB1ND921748BK
E4HFNFHRG33J6516Q30YZWSMEJWUKXT670KIE4G8ULA68K36IG6XVO3WM5LS5RC2EEIYRMZ15B5GRCJL
Q6OB4ZQT20XQA2NH3WDRDLNNOOVWDO5BN4FQBDSA26VLS64SC3NNIEGZIEJ7OG6P5HS9B9CHBDKK7XHR
KUWY9S7SLQ4MKW3B36L3YM5UHDI61KSZCUSJORW8NGUWCJ335XSO14WBGI0QEH2VUK5XMAEWRE1INKT1
7EU4NHPGH2WKND2QEB6MHC8AFXAQ0H04BKGE4JNACWXCFWBPT8RVNOJC2AYAKZMR2U1NFG4P7P065UVK
WNQHX0OKYR1G6KGS6C8N2RR8C7OYN6PE9WBZGW9N4OG1FH6OZAPV4E1DY30W12W9PPQTY39YQ3TCDGPP
AL2CIB9H292OFXUI2TQ5W3ESHV45JCBS15X6O4AX7OA6WDDQIAALC4ZP5O5GYABM4RUN3X7QG3U4P37T
KXPZ1HG8BBNZNYCYWAONZYM0HH4TN4YALJU4G38NS1RWSWKYBG01L914EDMJYY3X8E642HF9JQZFR0AC
4NWW561GWQZX6CTJ2O184PGWU5K8Q8UHOQCVN0I14QCPLXBGBBS6XGX3Z2JM1EVXF87BJQIC5QQD30WE
7G6BEBHWZV5UIWIOJ91VBQRFKK97ULV0EFPP862VTV8ARTDB81ONND96FGXHYEACRYZBEG1I1FQTODRR
QYF117AA56LRV44GNKZJV7YB6K93PH15WHC358SOYXO5CFX6TLZRU00H8QICI6A8GM5B8TFH9CDKYG9U
EKEKWWHRZYMEIGZHKNCROBSGIW70AH2C7PLGB5G59IN05Z5ZBBJLD8V7DIXD7RNYN62PTV1SLEZZ1XY0
ZBBK91U7VN8NYUTYSP67924GJW82B03BXKG0KXXI0OG3CUC2Z6DNTHD2Q7354HYTGDFDF2F9I801XUIT
ICUE8J6C3C6KR4KACAR6ADJ67348WSFH0J7S19WCAXAYU90AX18ZFFO1R9Q29M06XK1RQ2GMDIKR4NIH
VNEQ3VRXWH06OQI0DIQINRV3KG17PIHZQTMBF3LURWGTSMBVT8W0DSU3KXIDL90N5TNMMMTH86JS4QNT
MDRTIEKGOANU6C9HJXOPZJ3I6YGR8WHKQZ1FPKMAXL7ZCEFO2MTC9Y8TW4PTR4A0RRLPJ47M0HSHKXRY
OJZXP9JEXR2UU288N6ZV2OHKYW4SR4YYQK82KD9FYLCNGQKAN6GDP08XDH4NYYFT5MGE4444XO1QN4GM
6IB27T9SMRJ63D98PJ24G6VFFMUDHJ64H79UEIZGJ3CHT4PILSM7RT2YUCPCB7ZQ59X6CYUQCG57M20H
22RJ02H98RC7JNO5XQSKCF2VXONV7F8O5P21ZAKT2OWDNATZKOCTGIE87OLMFY8X46YLK82DE7DZJ2OT
U1J758TYZTN7SWGGFARZB95DBNUVY5JL42SB12UCORFWII49IYQDX0CYFWP62WNTKR5X5CECI4WD8L1W
HOHWSLAOYI1COAJC8YMU027JV9LCMQUDCZXAP68JW4MRJ57YORV7I03KZ6ASQD66HJKQGEKUSIQAR9EZ
XPVU12P18E6IRYKAFVPS3F0YIGYI29N4HXCAELXFJJSHJYQK39TLF7JQO660RRSH2Q06FTAT0NTQI5SX
IWDJCRCDU5X98B6S91U3RR7XYKBO1VFY5EL141HEPNLYJMJ124EGBXMFTU6AEAOVMJSPW1Q774OPUB4I
GL5GOWWWPUU9DZZ6W0KLJ744SJ9FH8U4322BTL4JVFO6WY5DU0R6N86LCFT4T1HDL86GSGBJ7DPX752M
3H8BKZ543BY3JI311VZKP2GEICIWQC0R78C6FJ18SXVWD0MQTDD3OGINMIY0DIMBQ7TC9R2VR81Z0SJN
4LZMIWX0UXK3N9GECMHQXXT9JNRDFWRU1RAORI9R6O0S6S94MQ0OTTZK0P9UG1IWERA7YUKH06BK75R8
49MC23YOEFHPRLHF7T0O89GVXIPONXTVHHJZ4BIG4N9UEQ1ZC83GJR3MPF438E84NJVZBTDLHYZ1VF4B
EVFN9AKELHJDHM4C5I9JZSCL9M383VIL44N5IPG3BLER2F3DTDXVK5MS6HAZ8C8VSJU1FATNNWGCVLXJ
0KCF50Q4F0B9JRF5RX8LCLAITH00NOBL5N0C9ZPHWYO87ZSKYO65LF2RRWNBML081HHNK4YTQZU3VP09
6ZFNHSHH2G781Q6J37BM5H757PFSH87NWRECQ3Q7W0QAENXHUHEUVHDDPD4NDIQ12B1R742YGSYVT7YS
9XJFVBWSJ3V2L33OSM6HALOSXK6QSC9FPP1G74DZ7G566WU5SIFZLZQF9L09IBTL16NCDIKHDEFWDMKX
8IWLSU0Z123LECBB3DIV9KTBXCRVLNU0FWQ252Z42BIE0X0OG5Z9ONNLT5JTRDXJ676PAB17ZCLJ37VX
EE6KKUM5FYBS0B9YY7JMHYUO2J75WCNBSO0FY6XC8IUP42SSBWSU8RJZIVF89WW3IU2C3YWCN686M4KH
G8LLDPJV5FX0UGDCXQALB16F6MO0QD91VCQCHMT2FLO8O1QKYD45HV01FXRJ8KERYBAAE9ETC01JIFSI
TJOTMHHOKKPD1IAWZHU0Q2A51B5UD8YEZDE27VAMSBWOD1HAD08BQ61PXMSVZPOGUYWBGK3KL8QT0659
ORGINBEZAA4INCIE1PJ0J6T719M7HTU5AZ5LQRY297N7VID8XYWV2HXP3B01STQPVDIAZUEEO6H9HI91
U975P70VAQTHUU0JB7OMX45E6P5U9JSHC0I4GREAP63YR8JXQMQJQRXGSCAYZI6U8PNJQCVHOR1HEGDB
1X0T2153H4P9A9SNZLKVDXQ3DR3WHA2CGRF2NIKSWDJSHXS18X3V9HJZCBZI6DVM4Y1C0R41BAX45981
7W86FHFM4WIHIAOMRLDX8FQZLPTRB7D6ZI9KRYLAW93NGGS7CW32CCCWIRHIARS6FXK7QGVYY9Z2DI4X
KH02TV9TWN6YVNQTCP8WUN2KASJATVWIW1TCBRUVZPH2YMJXZHKXM56RDGFE02V4UBWOTAU0MGS3MPRF
CMWF8FYNR4KL15RBCMQZG7JQZ4N12Q36591PAVOQSTRZNRVI0U0AURXRM0SD5QN6JPDPRPIQKJ5TYDBS
NLGXOJ5SDNDS9JBDWTIGNCH7W1H0LDJDX652ZNRT4EPWHM0HWVSX7307OCRVRERG2R4UII4P0NYQTM2R
4JZPPSKIO41J3ZIYBVP2AYW6H0IX4J4CNOIA5CW97TZ1DDRLWVU1UA1IR4L4KVDZNN2OBBN6C5SRN74Q
QMVO55DNRGSDMO53YMVT644F076F4ATIU94OHHJ4H0U5D6ZG0KD7DC3ACF98323NPX7CDVB91VKTSST1
ETAZPPAZPTYXHRXAIQDVWFHXD7JL9MRJVUT1F31JC5YAXDLWH8C500KW3GJA764M1GBHXNUVBWBJ6S23
SHXABWFF6DGVH8S628WEEAZKTQAJ58Q9Z4ZT3BBIW5SNNQ7EH5LFQ1UTSE6M3KDZQH9KCFNXTLQ5AWKF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121102/5e80819c/attachment-0003.html>
-------------- next part --------------
EMJ3FUBVIHJAEBXFWD9R0QZ4AOT4X8HYD0K8DI2J4YDHMQIVN9D6E6GB2MOL6AU94YF37N0PNI4KZYDV
JPQ3IS0WN0YCRE7TS68ZS2ZJE1BGRBTK91NL1C005870NYQMXLVBEE4CB3TSI24XKS3RB8AC51UTAS84
4BMYYPVJZBRVK6SME4HRYSSCBQ2AZ6ZAOVOMC6G33MEG7LZ3QOAT7A61X4WG2GTU09QI0Z4W728IRQFP
IG6HXN4IRIXUK47U0JWMRS2YUEV4NG0YWG07QF73A3NR45RWZJUQV0Q1EDQ9V34GF7IHHY8S1KZ7IYVP
LXBQE5KT90UTLAUMCBE5REJ08CB73LIHUTI37Q2G5140Q5BOTH9JAM7BR28J49RVKGGJ0BTC5T4PVONW
YOTSH861CZ7N6A5JVIBZQ3WNE9EQU7FM7TD9WUSJIQIYH27V6AA5F5I76IPTEZ4QUY67J43NE87DARUC
BUFVG8R4VRMHQN33F5NJHMYR2R3D4FZGKDQKQLIY3N0I3JZQHTARZ5E2OXF2MLKOX3L6110CDYCH2AG6
ETM6O28IX6RGG1HBC048WO5MQABZ4E61GOWGMMM8RN1DPMUJB8T70WE8LRI2Y0BJ9B7M5DRO0SH7YMYP
RBTA3A38PPDK435H48F0AH84R3EJ07OFI7XQB8JNT0MV81LXECIDZ1VF0TOJPKU0LL25AH0H2LZC90M0
JGM4PFALC6JCL0R8CQMNGETFOY2HZMDPNX55NZJ64I904BEAMZB909HDBKXS4SI9JAEUPTE5RV815RTX
JF8GVDOSP5AEX65TMNOIIUBW3N8QJ360FAPF431QDPRA9C8V7ZF8E002HAUXYF444RZPOUN0B8LY4BT7
DXIQE2RUIXYJ2BFOFJCPMUSAHHXG1VFL8ZYZWXUMU8RDFPIIKOGXFIR4J0JH3O3A844NE8BXX0BRMLY3
9XWXXXVPON1OL92RKT19B4XDJXDB0FB9ZGZFK6RMJHG7XL28PXV8RV21VIL11AXW07G99ID079YRR0Q6
LCNBWMW0QSE1XIP5XOJP69D5A19MI553VZEWYDAN02K6QQ8OAT1HDLJX94B7NTO9ON46BKXWPRNHV15T
EZJ6GB02HA6151NDGJML1S0H0APF9X3Y8M55T7Z5U68TWZK6Y3D1OL94GXDP5KW3BIUOPOOFCIBBM2IZ
ATGLWI1PP9NJJC0GLB9Y0T258ZCL7Q97ZHPZGU45Q12H5CV6T28IOB536GOTBYOP2YHWUC9UWBVCGY0F
VB2NIFO6SGHUE3L09AITPG7HT7V51I8AGILUWVW91UQG1LUVCFS3VFF19RT86DYGXN4GS2SF1IBYXR4W
QIMNXONGN0HPTV0ODIPB5ZIPER0XSSK1HCGJABSEBJZQ8BQX21C5PRD09D52WTC40PA4E5N5O4WVUZCI
FSEFJLNPMLISDYQFICPF9J2B19X2F2KV3J4SHFBPETTLL4QDSS5QST01MGN9D3ZYIR3U34VH97I5S0CX
YEBHP3DSDFQH4P7X664ARX8S1YHOOLK1GS2KZEZCOV9QWU4OAT06Y7D9WYADWJ5IW8HM8X3TUOBZP1XB
71Z5YXLCE7G7R986ZKQXM036PT5W50GMFEG4AHQKIEWOVBDNTFVKGZJYWDR0IGYCG0QCVZP61VZK12WR
QUFGXX2S4L5ENBJ3J8EW55WL3CS0AZ4RSY816ECIEGLIMS7I4KN6O3WOPMRLVKZIATSKQGISUPPJ9W9X
YBA4N4HTDNADRDYM1MQNAPLDM9EKC0OPCB14GQMGYWJZQFVEB329V4I6Q9Y7GELO19KW18IRWP4KXW7A
K7R1UMMIO2RDEUWG7S4F9VNEO7D03OX1QOQLC3V6QK1CV9QLOK6JL496K63OJKLZCPXIHC2FDXXQNAEJ
05QPCX05MMRLVWWAAL5D2BQOTU1EB7ECT51VBFC4G0UI6ACGJZ23GWUU4GMD187OF620RQO0TIP7TBNY
XYLXGYXDXHT8PR3WKWGYK3S2PN28NL5IVSHYQ2IGLE1ZNJNEJ666J7KHRO0RX8FU10SWNAPNWATP2EXB
RQ0SRYVYMH2SEGSQKV0M3LGZWNA8YCZI4NBZEKMFRTVCFMABA44VN1IBBO7A5SK7Y6ENK7B8AUMLPU9A
SKMGRKPRIUIHKM3VCDXVTOG2ZTWE8SJYP65J6N7M5WY4RUAQ8J77PH36Q7L623KLZCUOA57HK5INBTS5
AWHKFFEJSOXEXGHI8LM20ODRRY6XS3K8VT9UF8KT3128ANXEURCC68X7W7MW8L92BOX55LHLZNC60SZU
923FB1MJ5Y3VDBIA6IT54VB166WUO3VNQNHORKEQVTMFSJRNWJ0QCWE6VXWOCI6RVWHPOJH0PFF5GB9M
R9N7RKZ7SLZD5GWQI9UP2D2EORAM6E4LGUQS2ZBMKSL0QFBOZTXZUQ4PP7Q55N4I6HFIQ7DQS1RUX4FA
IW14JTTCAPWL6DVFGKYBC1CLNAUIQQPTFQ7HK2EMR7H34CBZLFK3UIT4YU0CJDVQV6Y0WLBKRJQCEF0E
9A40FX6AANZ3AUGB1C6784Z31WZUL722NKYIYVC72JGO6585FY068799WE4FE3MF2J24W8ERMELYJK4D
5O9T8BGKQ4JFD0ZMG058ESNLWDQKZTIJ3LJ92K6DRE49ULJRCA8R1H3FGPQLEZPLN91EIZ3L8JWB9AWR
1WAWSUHGGT4CZH2PAKCOYM3S3V8HW4WZVURT0D95VZMHICY456VBMNQ0DNUD90X814K8YX93H9J25U8C
F8BIC931BF8EPSL4XNP81F6R3OJKRJ6W3DITDYYYZ9QLIYZ5HVJSNAOR8HP6PEATNM3EC1WEODEZGD6T
19WXR4B4Q4BI7GRP1MMEIDNOVQPKPDA9HMXG6PFV172REPCQDEP8UG0L349K1PCQDJLC2PVRY61WJREN
UJMIBKNZ422CEZJXQX77TNU4XI6YEANRI8BN1POKTAD2LS1ENHR5I82W9JLDFE3LU91AW9E4FEGVB8OG
SJII1ZGJ0F8EKCQDCXPBO4SM2DC97DWMN12RFR6IDJJC8FZQOWRN7QA6Q3M37APUK07ATL55QSACXCKG
2890TF3U8FVOZSDLN1GISOT105W0M47HEMTHUUH2M71WJOL0D1VCUKPTIVY79MQN4LC0TV3RS3R8JI11
NPUXN1DH52FRG4BTKO83URNIMKRDE3OGHPL8QHBGVMQFETX4TKY8Z36J1IXNGMZL1N3CPE9QIEG4418D
NR85GAQNMDKH6J38M9NT6H8HT8715P406ZZYS4GQEOCYFDYKH7LPAMY93LQUUPFW8A3M1FDT7BWGZ6GO
GSPXI14DQKGGBKANY6QOAG5X3TJ9QZ295OROMPXGLFODSG299166NMIW3PRWBZ6GXPATH7YIWZVUI1Y8
4WXBY3BR8T1NYREGM9OMR82LML3COJL5Y770UJ4FK792WIQN7P69E667EJV2AAF11MCVC2UDYVGSEZLK
BOKHG7BGOECPFNH2FJUSB1YVXOJ1T4FO12LIM2M18YNPLOXEV430FO69HLZ31X37IV4EL826G16M7GBD
D1WO0V7WMM0NGFSWHI7R7LTZJVD1TJEAGXKRKGU7ZWP1CJOM7CPLIDO6K4U9KJT7LC833B6NESG9MED5
NVXC53YI5JNDI9KZQ0EW6CTAR48E9DEQELIS6FKY5J41OG2MO80SM96Q4OQGDCU3LV1DZSPNOFPTJ46H
BZF4X10TU2WHWZN6MM5UK2PQ8E47MDV1NXJ7JZQYCJ0RZ5A148YU7KYOP5ZCJNDOWQ0C4RV6TWEANMBH
3YMVJEKZXP18H3F5P2W7BT265EJA6FBKT6MRX26AW5MRFN57C9VQRNOPTKI4RS73NZR7NEAU2R1B6GML
GJE78DH6K4ZO9G0QKJ0YTXYX46Q3MI6TEY8MB9RT220V19GMF3UMB3NETCHAX9J085SSIH2XTUBF2VNU
EV0JBYYIUKDGWUQT32J23KY5411VQ087VOM4PJR6ZJB6DGEZAIPHEZV4RAOYI4M8906X0QJ6Y9UPMXTS
VMJZXV4Q9TKRXO9NXP0LNDVMPOEDPMNU1U4MUPQY5PKZBZPN4BSHCDGERSGK8J6DBEJ8P85EMWT47EGN
FCME51WW5AYD9EYKZNB2AQPAT9VWUNKUCBYDSIIECXC3J7BNI8M0QP7LJ7E7UYV1NZN7V7KNJ3DRRFKF
G69D61J0ALQM10PREHKG560MXAQCEDZXIQ9NFTGGSAYUTVBGHO0LC8LX5K5CA78AQ32B4NLBTB1TAESC
Z0JJB8F9DRZRUHRDD2JMSLOTSUWKVVEQ6Z5HON82BJGF4D1M6OIC2Z9V4SI4EGL6QM8B6PYBJFAHX69F
10D19XNCVKIGEAB2W7YSYT1OW30ZG6UYYJ5HUGJR667OS1245VFWWUTVNHL61XGPT38UP26HF04QA6ZW
CZQEEQRRT8ILNOL6XQQ0HXCUSSUTNAGKB14EKP8G1WTFP0ZX9J32KSE7A6NUX11QYC5DHLJ7MZ7JY7E0
74UW5CX8ASCCQJS57SQBIFGDUDFZRTAUV3K58TONZQ5DMILQT1HO5NJVID6IS9SJA9FEXFZ9Y36NFOHS
2MSSEZ0G5RFIVYL7FDYA2101HUSQB68J8JT65N5L29IT5Z618L5KF8OBZRBJD4Z6O3HJDTZXCZ9ZFW7H
28R6JYZJEE70C41OILUYT2SJUM7MHU6SMM9V5223ZCG3LVDCDBA7WILBRD1II96Q1Y5LWMYTNVAMUQW7
UQVT5QS5V7U3SOTQFZRWTIQI9VNQ2T2MNYIQ6R8AMJP4HGQ8GII22P2D6IOQ3PF45VAKQ9C02BUPJ2S2
EKTGYUHBWG8E9ZALCBTTS5AIVOIRTP8VRN0R08FDNN6E5P18UI2GU8NO5MJADO9XHL3ZD2S78YCP6BS9
BQHYV3PMTMKEP10UX3GAZMVAP9T14ZKVX6TFIVD75HDKS9ZRLEJEVEPEBAKAM8LWMLXP2UIHZJLQ3X5Q
YHABP25DGSELEX3P4OF5PQBTY83AP22Y6YFOTJ9OASXCXK5JH9H7MFMENEB8U14445DJ1FST2AKO9FO9
G6TSMTDUX2QLDEKLQWTU72D4NEE3XPKX81IUES0NIN6MWGJI5XYTNKVR5Z3J7BF6NQDLGQTHMQ745SJT
SB16FRUCDQSB3ZP90B87SNK9XATQMHKFRCGFN4G61PUJEBQ9MSOWCYFZDCODSEAQRX6DH5L0HDYY7EOI
7R0JU6IQ0B10ZGBNZS2QONW5TCUCP6T4FPYWSWCT201324B9OT4JWMOI4ZF85901ZG7INKSS2C2UUGZ4
VW03489XSQEW3JLSM56YF93Z2R07Y08P29YCPAFUZ9PNH5XTGLT8EBKK7EG9R2FWCOZHZV4CCJF65RS1
Y6LTUM3HPH2ZQF2GBL8SXBCY6C61CH56RADJE5E7Q28SBQPKJF96BJHKAQ62S0HHYXDD9809KW11ZMAW
07YIKS2Y0BUFAFANLJYH6GKEEOWDXN3M124S7VBTX8U7SJVR7XMENRGT8D05WOMFUWDFEBO5HY3AJKBL
RNCSZHT9CN3FU4AE7L8899SIRH5JR1K9XTWWRK2HXO4VXCFC3HPNL8VLJ6XITT67W30J56R2BYN3VN1G
K6D1AI6LU633N55VO4IRC11VJOBUT3CDD6405BKH0HOHD1AUUKXYAUVIQSG210W5G5TIGP4DJKRMDSPD
FRWQC3GKGCZTM4EIHSARRCPOGP2XCUGHS3WCR5KHZG7UZHOSGZIZPMENB7F3D4U4RF4TO1E6UZS8NCJG
6YUSGGHEP5LS9CPVF6N3D58ODVU8L16EJCWDZFTNKKNISEGKYO1Y7G87BHUP7WHWSQISD6BLTKVLWH1I
XD72ZT0PO8QCCNRI3JQ008NZ5FWYQ3RSRVRUSWTMEICI6DLPZ2WB47VK56NWYWDA8CUSOL239OR3WXDZ
J5WGC136KOMQXWHVVO0HDQTUC1FX9QL4APSZF1C39U59Z1XFZ3YVVFJ3C2U4O9AUEP9I96HKMWFHHECC
KD4ZQRAX1SGV3T53BQPCYVAE3FULN5SN4X9FP12TWSB5Q58JP1Z5PD2HANT5UE6XF46FUHGXZMU77N2O
BPZ381BJDWX70G8LOALA4HGQBZZ6UUAZRI99B3JJHN0SUVGYMEI7MIVGQ06GPO3JVN3RU9ORWTKVZB2H
QUDSZORNFB79I2I5CGVLG8LIQUOHZ27TYGD6IQEUXF2YCLY5CK31JXYTI4CQBD8KTLGR0V2YOQ2PTXQ2
3WAESYFJTDCW8LEN9TYP34BTS4F6GD2896ZCSG2R7JS34935FAZ7VZC0B11C98M9CL3HRKLI98OMTCG2
C8JJH3ADR345NRE3SK0P5L0A7SPG1H5F39WQ73T4MDFTJFSX0YTHHEDWMMGUSX6S2IDFXF7K4GLOZIZY
ZVTIE82RHSM7060OS112PB8MYUVA5F4JLSPQMHH6DXRQ0F7MBXSWIPJ9K9283HEC1PTMSGAJDPN6YIOK
HG24VOWYHLCFPCI1J7A0FOJHZ6KVHXCSDV46R3KAPXCQMFY9OA796IFPTEG08R4IYV30DE9IWKVBMCR7
J0IGLKNZ0EHGGLWNUPQMUPTGYL9TPSFYIYQNDS7BF46EHQQXHTUVH70Z0RKPEX5TVKCSYO953EQR4S72
R2J6RV4EW4S3MTD8FACEK0BIA8RE4U7A93KE90SE19HU5H9AQQMMTKG1ML50YVTGPQPEYOCEUYVBTGUX
RTB5K1HSL1MMMFGHPMN7B9SGNXJDL37SGR17N4NPZK2QDAELEONRSC0N6QO1Z99B8N4YB1UMJFP5AAKM
6B3R4OKYJPYUROKKK0BJBOBSGVMGASOIU8MP9DMF2TDKG3QKSJM63AZ5RZ4V561I8CL9ZI4TY6XAZNRL
JL4TKMTOIWX98PZZGMUSPXOA4OOR1IUTEDRZEKWG1EG4OLC7PVPJGKNAAC3C4X71T4HMKJHA4DWA6M1E
F7GN77UI6XYQWGKHI3E9PU2G3DKFHGBFM1ZVHRMCUTN9JLC1F9WJ6A6SG7IRT1VLUY8YF8WY5SATSSX8
JP9T3JHJUHEK52X777I0SE5BI4SSBA9I2YPUNBA51E6KTG8R9N9JA65KF0JG87IZA8WB540JUJPLCFS4
U1QV510XPPNPZCHHIC5KIT75P4QFIW3Q0BXFIYNF8CSQ25YQZ2OF386E559OR2EOO1ZM84DOK4K86E9J
JNHG4X4O9SYRV96QDKAQ2SMMYSWGMTXTWLY4FXNU7N8ZTKHUMA00KDVZWZX19D709QZ3LHDR8A902X4Q
77YPA8HMGOFCE6OQIV0CVFL90JONC5V40H4K8ATLT9N1MKAMUWVURQT3BF4EIRRCA6M05JS1FH753JJ6
J3Q0604C20TUYD0V7M2UAEDIVTYGE811ECIO8T7IEVZ1IR4Z13YTBQBAGUO7YS5T4XQDPO4A4J2SURHI
RNJAKGAPOMDLO7E8WUGURFO42JHGT3NTZTVXPDYPBT2FYLTCKYYHIOM634NSTGNOE9X3829S4Q6XOFBG
D2EXY7DG2RW0PFQRLNNI3E6AF2KHFO455V2D3ZTP12A5YS61JT4AF3CQIKZQ9II19CROZEPK6X0XN4QY
4IGAXDA6IHB8C1R60BWLNX4V77FZCLPE8YF1TTGWTD6KMC5SOEQIOCDLPOFV1IBM8R5IE9B6CDZO6LB6
TBGLX4TS1E2RH9NY4QCP19M326PFHHITVRLUFFB4N3TOQISB3YIV7ABV3MYYIZJ76TEBR29DRAN2O6BP
XTIWLJGQ5PVTGXW7IUYV8XS540ZKU8GA8WPKB31RBY71CUHC1Z7LKO3R41M6WRTWCSZ0WKJPNO8MDTTD
WUTYWUGP1X64RK86CW4DC2Y246UFRNR75GJINKIWI3YRI9N6YOVCYYVCL80R5U9FEEN9GWALNR27ZECI
1UCOQFFC2KN7ABRL9WTXBJ9L1DIYS8LM2UNNUE1232BKEWX4S5O73OTFCMIJLTNGS9FLXU7YRWT9WD2Q
GSCQRJ37NKGCNIVGJ62U8N3VVZU8YJ0H51FWR8T8ZAT88YYOYX7LNABMAS5JWOHOZ9MNDY18U5JJG8HK
EF6ODTPPQATDMWDB3AE6RPVHQ8390D2YNQ0RGGTZRAMOYIA9U9XXV730CGMYYT4SY4LZG462J1FZ5043
KMWDJRXB1QK9MT55LDGEEXOWDN7USWWLJWONU1EXI9EPVY0D1MDPAMUAHFYUGL2DLPFA45LAVOE9R0HT
0VNQ8KB25EM8P2ERRCDM84WRGPCRP52362MBS2240OJA9JQK2IEJ6S3T515FCFM04CFJ9FN3LO3WK0BI
Q099VP87KF2T52H5WHDDSWJJZY4S797BSFIADZU8JATS40HE35J7I2JQM40C6XK8F4MSAQV9TR99XOTT
2AUW7U0AJ3AS3MDQ2Y5SSU8X2TQWRQV0RQR4ICH2HBL6OH69P2G9NPAPL4UA35Z1QI1VI2WMJNLHQT45
Z07ZIM4OTHIQTRZJPIKY8BW2NKALRKTAK5N854S0NF22S066NUD6RIHHDJ4IHXZEDPU5H6VKMIP4CS9B
J58551DCY8HAGJEZF4KR6GRPQP8885KMOZKOVQUTK1EP25QWVOSHZ9R29QISQWMI0LT09LWZFKA1OL6Q
32G8IBE5W1J9S7QR9F42IXMIONLRSWKKM2B1I4DY0WTK9I68EXX6NUM4NUHFFWWDXGLYBAOAY4YYDL0C
1RJ4YD48SVTUU0MDCMVMKNIKH98Z4OU4394V9K6WTAZF0ZDFZIJLMR7M3NI1FA58483RRR8867XL5OA2
H3B9TWEDTB5KBY032BHBEO8B1RRXRUD9GWJAEVPNCMFCHM6LC2GHP32A1I705WDN6JKSD7GK352OIVRJ
XQYQ1B87B88I2ROI7WFB63IZ41IKFVBTCU1QIHSUQCZRVKMXEH0WA8LVNCFZQ9I1OFOZ2W4TWEG4O8LL
BMMA22HPT2BPY1XSRXCAMNRQB1DB6N6LIGJZXHMW6IRY7ZQFU8GSG25Y682JE5RIJYOIGDK8KKCNKAYF
513AFBKMUQ2JTK78GL43CIN1T357XVLB5JJDP3ZSHVKQ27VJY312MI9ZDKJVIMM2X3GRIRCDMRALKG9E
EGCZDXDXKQVDIDAVBREDH05WE89S4DEHSBYZ7Q1907J7WQV2GT7DFLNFHOC9H1TVR0ZVVXT5PFXDFYIL
D5T6FP4H2E5TWMX7XEBSNW7JC4BOLD8BPF2FFJWQ8D87SZPR9WBERG20H0UKUDBR1RYNGQ5IJ9QDHU8D
W7CHSUPRSNN8KRMW63F3JZ7KCK0YHQV6UE03DATBN4MBVSYY71TBXT94UC471MDX7R3X61F6V8YL5T7N
38PMSSMEA9T0RXMD2ZFUX95O095AK604R996R9JNDMM2X7CD4Y2G4HADJ3IJ01PDJ825V51477385YLT
X0UBCMALATGDC9KIY1FHJD978IHCNJHH6UDBI9EK07YA8HG2D5I6EAYTVUZSRXTU82Y5IPTI90NVWYFS
53B289FRMEOMV097Y7HKDXTZJM8BFFB3ZUXBDVPI2AF6EUBLFJGNL8ZOGGLZNMWEOBWQA0UYH9ZH10MA
GOJV5130JOZBDBWNWQ5GGETY77J2OCEQ5D2BM4O9G5O5V4FBMNE26VDFTFTOKOB2X3ETDT69GVP8DI6P
1TAUK7MOVFM0TBBFRG0LL0MWXCP0V8G881NU1868KPDC4IY7PM5A4ENEH2OMHT2J7KUQPGGI8TO7MAMW
Y2I7UB4X0CV322STOMYCAK0J1PO8R7NQRMMJ52UZWXTE5IOV0IE1LU0I1L6V9607MIFSVXXB7BSA4ZBG
QFEVNYIKJ3SJXQHS3FNDQL0LQLE0CNM73NSD5HZG6EFPO0PMCW9R0RH65AOSN9YXPB0UT0KR49GLWZDM
5UCIJLTAAEBWRFDW9DZ1SDDQBZ48WCVMQT51GBXGU27QCZ1DXBXWNA4A9G3UKTF0XTCP3VY1MUOCR6QY
CDOMZUC92CTKRNAVOQ400IT4V8VWATT5CCWRTLVZ68T8DZ49UE4VM6F5TSU5MQZFRJC5P5GB0MRDSFR1
4NQG0VZFPWUX8C0V90ZQH1W585KYCFJHFWGHL4XNA5YQSFFISS5SITUO2F78DV2AMXJNAU3RLJB9AG1O
5SQJ7JPA5DVZR1WSJB796JUV0VYVULGGNQ51NXZ0D3EYRJJRLHCT33Z6LANOKJNU33ELSV3V2KGMQ2PM
N878G8GQHTH8DJPRSXB8WFMQ5T14PHVEBO6VCQO75AW4VQ1Y9QA80OOBQIXUF4VO7R57AU5VFR8X2USZ
QASL8AO28BP19YBXP42WQDRC7VBNKGSEBZLOFENW3QSLMB3HT4054GR5R2WTQDL7ZNW3R8SYWCIJK0GT
3DCZJX5AZMJCJ5GMEL0A5CRNXCI8FVZYH77GNRWCO89A6JLL3J6XNJQGGON6SF2SYAWB10P2NHUQKBD0
AAJXB2JBVV9NXTNWZFCYR7NKCRUINBYM1RTJVHKWXEE9FUO687TXUIFVON9OET55MBQ4DX5WQ97HJU0O
PORPBT3QOUA76JUV6L8U3GY1D9IR0Z322HPV0I121KRYNI4LNDRZ8LU4VAV97CYK64WWYU4826QZHUDL
UUUVHN7RFBUG183VXZECS6SW1HE3AV9T94FBULPW3OJOCERHNSQ5H8B9ACI3MA0Y536VX2DHEWL4FDCP
D863060SXHDT43ABPAM4ON4D9ANNRZDMA4JW61N7UEQZ733CW6MOZ944UNPH87OUS32WU327ZBM21R7U
0WHRI8J7ADPGRPB6SW625OC8SG5PY22CC3P1NP8ZCETVK15RAW1TABLKQDJ385A3WLUVJMVVRRXYSN8Q
1IAQJ5L9REJRLPI6B2GBIBDXJ4RXWEI4WLDTGJOOPT73M1QEQ656ATLV84JEAM5OLRKY3QC6P84ZS4XB
OO9M1P32OK3PJCDYKPYU10O6JSP39R7H83XIVJV9K9ND4R4IV0IKXW7HU09V2IC8AEQHTRB6FP8H062Y
LKTW257AB8RBTULQF8FTHVV1GL2K9GQFI6GS4NCG8J0ZKBV7S5WBMQVOC9733ERDPZVJ6Q1QMD3FZH33
POE4XPBLEM7NEP2QYR0SX5KKHR1C0BGYLRPM7L2DN267MSS3WITXP7QA7CPNQG50OILR7PY4YJMPJ06Y
X564CYSQUN1P6M9VLOR3QUE9M22IZRLLA91IRVSA357L3EGLT3LBBZBP8HX9EVJ5AUKB0615J1ZYQMMR
H699OZFRHD9H7TBLFNZGTC5ZKFYS1KH9H23NTG56KH5KKIDHGTP57ITH178AEFBYWFZCXHJU6TDO02BX
2Y3FFXJDM5E2YCRDYC7QGZ2YB0POVAR8ZLERM93B1MM8HDER7SFRYZ38HQSFMJPOF0WZHR81XSA57YP1
VQXPQJB6PAWN7JEYJ6QNI9EQMVYG6589QBPFXBYLT83SKCAU209SME51XFPJ9Z1KF6TK2GWP3QYJIBO2
2NPL4O839YBK6R6LP58BKHNPBH73HY5U5AFEDONNEF5CR7VQBDFWNNKQBGF7TMTSYLX252HZN2HXPXJA
611M8W0NV66NHLDIGV0KS4NXOUZQVULRSIDKQ1LXEJK9EHO10N45RKZ10JQTZPPND5UBEFWBBAGCCTT2
5JA6FSN23KCRE9XXHBVT5YSZ574ULUWTCQEMGT3ARTQ0MJNTUABQSQLX1Y0UPIE0NZIQ0KFF204URL3G
VPAH5EAX5TXT1AS9XA9YN6Y27RHNLFJFFYVFG788FUU7WKULA9K6BFFTESZVAA79CK13MFAMIJR8Z8OS
Q2BMOHKBDWDV543J9HSCN7CQVV0R845GIDR2LMXLVVQZ9HOANUJAK1I141ZE2JW00511M2JP1UI4WVMR
E3FR58CV6YJANHWXIIAXNN7M45I3C88X1J4K343TL40BYDR8W4V4J0NR15UT5T8F160IZ3JG4TCSPC83
Z3XL9YIRPVU5GFOWJLQGXYBPLOAW9VOWK6UEX76BMSG9ONQYJ9XGI5OJXQONJO30XAI7C0828PJL8DCG
R5CTUAQJY56UUZ26C3TJOMZSI4YB4N7RY76LO9CATNAEGZ6V5KRBMY18EPOW134Q9COJOSN8UXQ9OKHM
MPUC98RXHQLOJGDRCASHAHN50FKVFC401OSDFSJD944PB0G96WVR3GLFQ8ZVMAYBG6KXGS1FL5Q3RTYV
1CIZSN1QO1XI0S7PCJ3WPMDM8T9UAH1OYL1S9TB9RX3UAB8UUH373GNWVGPZK5IC1CJC0C4IP6EL6RFM
091SG9HR9FYLRQ3MC2MSNYEAXODGOAEILVZ24M6WOK6RBUKUE8P1FXYAUS5OF7AJ6B616VVV3GMXNASR
WB931JDVW568GB21NL4T92JIQYGE96BNWLQEX5XC88XCPCSO0QHC7DLHZI8GQV8C8VY7N2U4LCHO81F5
XF4N2JA712H637YTXO72N7BQPRP5IM8EK9HN9KU7X7OM5R0G4JCQTQDLEIG61Q6DLNRGQVZ312KMBH5Q
W9Z027DIEBVKEGIYBV0HKJ8230OE1OJEW8EFF0FYY3MDZNC50IEZ44AGJB3MVWGOXT6J9ABTZNTZDGVQ
YEO714RYB9B95SAYU52Y34K3N5I52KS1YX0JGEOFCG4FC2FNSAV85WX78SNJI1JNURTIA1TKCNINT4OM
ZIUZ3LTT147HMJFR2MPC323CUSCB9WSSS8M5Y1HXB4LBT635E6BPW7FJ66VL2AN1V2NXCHQKS5OSGSDT
5G5MB3LNL7PV4SKFAV13P6XJPSQRBEPJGWEM3W7HBLDPYSU8OICEKX088LHPHRJ4ZFAJD4QT59P7UYX3
SCQQUX8CAI648O8JWNOPX6WB2AZXGEIF3KG20BX4IVO2D9N5YKBUFNJTJBV156DMMCYE1JORF9QC1T86
7RGWUJFH8D0RR7CAGJC6XMFXKVWGTQCYA6LDWM680P8GTKFSLPNI26JTZWU5GH1BGL23F3MNDA1YXG7Y
XZ9BTAYIKJAIXHXVGPI1A82B5SAUHN1CNBV47VB1OGRYQEUWYCIWT07AZKN7FGHKKW3LTA0WCF4VOOM3
D6GJHPGBEJBYZFEJS20MVB5CHPJHDZQ9HCA33NIYMWKZ80OZX5B137H2QD0DNE6LDN7SAKPJ5WK75Q80
HVGYD5PPTCEOH138OE3EBLKQU4NR2RMUQ91QQGMW9KPZHTXN1UZ53VIWD3803T5S79LJJOJSBZMQ5IQP
AC00DZQ4VCLHXG6THBX2JQ3INIQXSOT8C1O5FQ4RHCDXMX6QEJ0WC1KP3TH3GY3ZY2HJD3CTNDIH03F9
GQVVNOKGGZXC0N9P7G69NZQQRSYLXEGTEH0D9HUVDQF1GB5X1OVZ4IVBSZNRCP7EACEUR03C50U2JZBB
PLXJKAG1G8TU07JT871O9Z7H7G9O7UJKI2TOA42FJAEF25YRCX7RE20GIEQZWP580GCP9NE13Z6QXSPP
BOM62YDQ0QGU10NQ9X732CJTZUJ68CRLT15NQXRXTIJLXD8L5KC7VBW1FPHY1447FCT5WCL0DABX75LH
XG5BDXBYXP0FIXMWRPRX38I93380MIC31ZQP2A6R1LSLDIXYB7HFA5PGL2X53SBB0149M7LD1KLVJ1NB
W12TECGNSPMWHXZR7A44K4WUTS7WOOISPM42UNHK5B6P3Q2DFCOVVRLT4NTN6AYKPRKHHBRIG4V9Z07R
UJ15F6BUDRZDGUJ1UNRXXGOOE74EEWK8ZKREXARB4QSAC0P7FZMWNZ7LF9DV5OIE57H35J824FLR1RO2
JDJHBRZBNDT5CQBXTOTL6XOD4EJAAETK2OJYGRI56GOXPRR343D9TTX2NJKPSVH9JJ6P2TTRFR1E3IZO
SXTF8FZN230I8C9A8E72KOKEPXC6BMYE33W353FE2NJBV16IMR0D602W4IP3MOJSB93C4ZBTYJT7ZH8I
88V34JC4VX0SAI0LMHE77YX5UN356U75DC5N8P4B9PBX6ZVY5TLORRVVSMNPNY2W39A8QL269LV0U1WO
0OH39DO7E105MG56A3TIWKO3WUSFF4WSES47R1PDHVWH5VBU9CAPY9I7EFIL4MBLWHPS6Q759QMWNBKL
H2BA6WU8CU8GDO6NU2QQFO3ODXF6KQNDPU3TMFQA6SY3VELJCYAGTCWWN3QEHP5G12XW610NH6NYW6JX
SOP0XYS82AEUYPX7Y6I4ITWB8A2DYYWGRAJ9KYCG7N7U3LKD3OCR4P2KAKJWEFF2YLEOTCP50B75VGPV
QPCSJEWH8UDNQO8S482YQM1MHW9TOA7L6UPK8V6PTVCLIJ51TUZ6J8UB8RL4AVJV9C73QZTPMY6KTWWE
FN939X58LCN45VS2M1A8P01O8WH60BDQR7YB54Q6ZOJ4EQRSHZTFEQKCJL0X6PBWKVHQ8WVOWQ0W5VTI
54TWIHO3K4TSDS8RLO1F6DV3K7J5EJTUODZ5AXN6U9I0AHOE1RYXII0OR0LU7J4O9IHZD8YVR5M03ZXI
Z30UZFFK0VECV076YLOB7JPXA2E51TZ1TW0X84464YAYFAHD1VWETVX7TYDOBT4TGXINBP4RFYVV2IAC
GCGPF03CSKUGXX7MUPSWADJZOFARIENS4W92C0M29IFY6U8ABXYO1I7BU0WK2EVIV1GOCHX4VBSQ5MUP
3MEPUY9WAZDJF1XWCRSQJW9XBL5EKWKO2UHMW35AT65TGEFXB2K8GI9P6K75PIU7SHKKANGZILOSXX35
UJWBJAW1UKE55WCRCCIN1E5EWC5X0L4UZ87GH9F84D7ZRGSI1U8S1X4N4XDTRGRVUWP2UBI74O8C8TVP
N2WPKPKVVQS1AZI1RZX5BFBOYPLN08V23TMDGPMPZI8I6LB8WC6YAKV3IJI25B3XUXGYITD4V69UINCQ
30JUH20J2TKXEEKWMXLP2JTKGBMM4O203N9FI0PWAWL9ARUZ69XP5XG9IPUXJ7JFBH1Q5NSKPOU3F2L8
X7B45W92SSSL36DKD4W2XSQTR7OYGM4ZCRGNWDYNR7FEOBGAB1JHIGFX9CD2LD5OS2PAITMG6D0Y52QY
PUU5PBHWLA09KV36OXQ89J2Z5DCK6OE1TTYVTD62EX1N67A7G0Q0NZYZ2A5EYB5TA7XRM6Q5QO620ID5
U4MY37NKTJD03NWGOEEAMXXDVKWNBSHHBT3YJYGO3TD6TD2316WSLL9151YDBJ4EBA9PLCUMQ5560G1W
ONTLQBJ2Q1B0Q9CI6DAQMX269HT9GZET8CMAIF89JHZTBDG3VYJHW3SI4R6C9JH529LQITIM1EX41GHJ
SRN8PX5IZLODE2N0LVKTWZXT4CIGNTVOQWNWF4ZATWGT0UHCBJLS6IASV1MPF5LO0EB502BV16LO9N3E
U108UL0SO6IKQ09ZZVD5JLWYFYG2N6B06O9DS34AEG813OLAK7YRKYZMK2GI7UTSFDIBKQULI5JRCAV4
RYJD1GINYVJHKSAQ714O07L63UUP2NCGK93R3TINNHUABKXO8QGD8Z0OGS27Z6QIFK4XYJIW4EY92ZQ0
8SUXGWKZ35GE6MEIQ277PVFDUQX3XTEGP4GKDWJ1PU8V0UW1RDDCAPD7ORY66KN1R7NW27KWGXMI6FZY
NTFRP5HXUTZS0L68NGBM16X31Q8701OCMD79GW80RA5FLPRRXV0MNKL8O4DFO4AKGFQ5M0MSO45YMR1Z
DME8OCCWPYWUUMXDDLDP7N1GILC1WROIB8NE99FRSMRBV777UA28VDSWZ8HBJIGPOUYBLGC9AA41SPA4
J11G6BOQ2TGXJ1B97I86L0C2BK6AWVE8H8JYJN437ZV0ILDCM3OEYK9QOX0G3QBM6S8F7RMH54H9EU89
B129UP1VP10EFK7HJ4S77JEHRKIX8BLT6AA9EB9UWIGZBJPJVE9LR4V41SH2SA5L183713FMC32IM64O
Q3DQOD35XNZS9MYU77JUKHXGBBQXZ214L6RHGJK0ORFLFVB2ZAA5KZ8AUCRUIQH9AKZONU7ZIVFL3X13
3VUVHNXWG3ZYADUEOIYZW9WR5YKSWK10UD3PNHQSLLDR2RI2FZIZBF2VVE6Q90F05C4VMS5XZAOSIMV7
NNL2YA4BSKF1HPI4VSZGVVE9RHUWEROTUAJHLEOMDPO24Z12UCVMWJ4VLF8GN6HJQ4L53FZQAEG8ZTQZ
JGFG9SXW9GN8ON0SB33PRA81YAO1DQHUY8PW2CGL20U9N0EYAJRSG1ZI1045VMTKQ8E877G8RHFZUWCN
Y15SC5BGTIL2GK0A6SZN0VPBKJKMH86FAGUJ4SJLTC4S8FNZUGVOYFZ5GQRDQ9Q6AHQ38NVNT0N6AMJP
KW7G5ZVM6RCBKVAYL0AAN6ODNEWKO4N7OPD6SRY8K2F0YFFVYX34ZKT9CUGV4LIH4HVHD2WZD5691YJ8
STCMGD1EFFTHIH942MSY0L3EAYYHASTEHJDLY1WH8S0IXE2W5XSZO7KXYN9WTNEO6TOX08744UM1J62C
H0AYEGURD924OD91ITCKOY2RZN8MKTSBNSZ2OLHBH5K48J5VCK2RWK6A5LQG7K4TRD6KI0RR8U1847D4
XSOL5RTZHNCSLREPOLSJOQ272BOEKRZDTN17FZ0N8QYAXGMNSOCY1PHHH8ZSZDD2U4MB7ZEQTJRSAIEP
HUW9T9OA53IDHECHDVUHPP9JMRCF773MYND3UHA1HO4VQSIYAFTHZ2O9VR5YJY06MRKI7RBSU90CIZDV
329JPOGGQF1HJAKQY3JP5CNFDPSHTNOUDTQXTFC1OK159CMP2PRTLH7GUOHE4PXLEG1A29YNCLUJNC0H
1FJ4GP9BP05KSGUYGXG1FXZV12W2U93QTX5ZV5UVRH6FFLZL1IFV3TD963O4CYF5WOVBZCUH25GSY4NC
7D91NIAPH6IBBXFTMZ1HJRJ5CJ37E8W11TK18XHZPY52OIKNKRYTLIVCVKHBK6Y0JSWXK49S09C6ZLMV
3C61NAM15PIKD7AWZ8T48VO55RQ4LR5BG476ZSLU9M6O8RHOLZK7LK4Y0P0HXGYDA2MWOMG3IX9H5BA9
J62TUQ449UT4DXMNLRXIEH5JGTC2FELIK505U5X8BWWOHW43G8N1COAL5H30BE7FOXWDZYMMHBQCE4X1
VQ7GEZ8P369MBZQ5R5AT93SZUSTBERJQ6XUMVS26LC5RL0KTFA6HWBJ592KVODLECHFCBA1TJYN8FJKQ
R9UN0Y7U9HUI3WHKSZBZQ3G0X7J1THEO3SJNJB6XRGQS4Z82VYGLCFIJTDJ92CLIKT134YSB6UQL6G8K
G3ELE7A5TEXVYV1S78P3891UCSY9N752Y95AK27B7NMLPNMMC2T14N7XIQYXLE8GCDAT1IQDW4ZS5A9X
MVWTH0J7K173O42XQ8BWNH58Y75IGMJ7GI7GEXYJ2CE0DJQRMWXTVI8F697IGY1JPY3THRXV9TZL894L
S50MMO7HFG34N4ZSR9P2BIQZTU4PSAELQYD1T4R893KO519J5MJIAHY0IQG587ZC9Z7B6AL0H5OMQHJI
1LAXOUBR3FPWIFN2LWHK5LNZ14X8WYACH2AS0M9RY2MN90WK0BO86DZNYAHLOGCWS1XVKZHIWBADQYMN
MPCGDXCIWX59T2ZJ48J0AUVEGK5QGSYNZ5ORTZ3QWS8J8CD8EFR0FD99L0UI9URYYHAMB02V1HUK7FD3
ADN2V4JMJJG5D3O4RNXGGPRN8PS5JAETUN6IRTTWLIYWF0V9B2J6MHFS6ULW6D7QCVVSH59YSOQ4H6CT
KKRLB8EBWT69E38QAEUGUIOCDAG9AUWU0HQ4WA7118780AIEXY2C2Q0ZX66HJN9NC2OD8P18KVT6N0S0
LAFQLUD137QJGTGJYXFKAULICADQRTHFGLKTQQVYAWSO9UJ7DGZTRF44QCM4KAD2XOFPO9JD7OVR81QD
EBFBFTEXE41FSEI0P0VBK2GIOYS3MK6V3EG1HFHFCAX9JEAKT2I4A3ESL6Y97ATI4RSSGWIKSTA37VEJ
GZ0RQADHOLPMIUD940O1KWR0BIUPX5OAQYKX0K78G6GEOLYL9TM55D9WKNS8U7L7MEFAOIG37HFODEDJ
URYEGNF3ACQUM6IY109AZDSQAXE9CQ1G69CU3RXCB7FWPJG2WYMNSMCPNFB4PW7QPUD2O2OXGHVHLAOU
9EN5YVCE08V13KK6M2XGRB4PGVPOOFKR0TDZ2OIMHAXQQ69746OKQDLW1NDZRC4C9YJHKYE7UZAG01DO
B8C42XQDS4T8XEIOFEBND2VSC6PBOXONDS7PD2O16Y51GNY4FGDNNA96JTCGWQN6RL2UREYQD1GZT9CZ
POOUBAUKPO6TZNHT9ZXF7Y0W5JHW9ZJF99PZBRKM0VVGP0FLT4JFTRE0IMC5CGS7KF4CAMRQTAAR3C76
545BKGWZRTV4VPWEHGFFA83DZ8V5WVGDWYDB0SKI6HZZV4O8N4S8I7JL6X9K2O42RC56A1A64FT86ZT7
ITY8P48TXPJ4H216X0KLF3FZ32UCE8MBJ0RPFMK7OYL51HOJOMGOYAJS01FM6QIPQULB99THLP5ZIK6C
7M7XX3VUQBZUSWFK7ENBU9Q8ILRAAQ3U3K2K9HIJEF4JZCHGRC67A5R1SOKP1RELVML5W1Z1REVHRGRZ
26AEAMXJ40HJ9NFDDAD1Y333WVRGIEKQJ2G8A2WR3D8620ZF6LA271EQCBEKJCBGOM0CZYPFFSWSI3SE
KRSPYEMRLN3AXOEHBGWB1SWL904NZOZZZAZIM7BERAN4J0DUFDQ4I3D2QR0AQOTM68YPU6SXWUDR086K
PJK0T49C505G25I1TT17A59IXDV4UZHUF1IR0875RQ6H8JTSS8QHROP1JHJH4IGUFQKGS6K37HHAI0UJ
5SNQ8Z4E0HQR8ATDK9U7Y7MOWAV2HW9PQ6LJM7HLJ76UP84SOMSJAYYUZCWAH0P9AKOOIWE90F3Y1VWS
MJTFW8CUHFGTGWP3ENL0SSWDTIU7F1V6KCZ69QB8MA36G419FAUYJZSRGQLE617MGCQDBWVFQ8FF9E7T
SLSL0EH05G047S70Q85TT6U2A1UKAKNPYL885LQHSOVB6FWC4JY2B0JUEPH04L4059LWL66RAERM9EWO
BTFCM7U049ESLVPFSK6O80PXBSXDVOOQO06AEXHQ0GXHL8FTEZUQIMWIXL29SF0OSR1GVVR88U3D79VL
VE0HDV6YM90AMJ5PKDG66KZHX240JIT6K1VM43AJEMMEX15YUP221LA6P4V5II88L5LR80D7A15CSGQA
SCIDRN7WGNNGRZN04VPO5T4NWXM9KMI54OTHGZGEWM9SXI4KGCOEJ0OLS88U9V277SGD3C25EPYVTF1V
7HKWXIHC7KWA33CUEVY2VJ83Y3B8J0N6U27BQFH4HMMLNAPVN5PLKE8KD8T992Z95BNFT8HEB1UBRJDA
DC0B2HERUUCNKMJ9J0WR5BMZJ3XMIT9Q2R5BHZ4U6UVFVNMYXA0KZNF643WOXYD89F1KPAW38BVBIOH8
VR4P7IRDD243YRMDJ019SKHUR6SKL0WV0BUZPTP4TY721CS3DFERQ9WB7ZRQS9RQUXTWCH7237XAV3N2
GFWGLQPIYI3OO94DDXM57L3EI2984K2V9O8394R1Z3SM699HJMF5E0L0Q4TL2S45GWKNC23QLFSICV6T
JRTAXGQKYVA9VTZCEBD66GGQSD0X0A4TYRFPJXS9XNI2X42K5QWGAWOTR14EF2HGXLCL5B4G58N596F0
RAIIF7OG3W42X1VF7Z2P4EY8FP93SXCDGZWMUJN68NEZ1JP8NXX1LHYBCDXBE09Z046GUVSVMMO5N6TE
ES8JDNSUPSG02SFDDJW6I1K1ZKF1PABCZGASY53UGB494RHFEY818HQTUYNRJA85WLP249V2WYUGPFWE
VHTECJG7YHWDHTL4PBU4706AZ4DA5Z4TBQBVRV0DU942CDY9KXO8EZ0LD4BL8PDWAJPL8XQUA8SODN22
P9428VGOEETR6CHHEW1332QAX9VW09GD1HQDZJF5WDUSV1R9FPD9WVID9DR89DS23WTU46F7TO2MPO2O
KRYZZSNJ14628ZQQL1SFYQSNH7SQSCYF5ZMPIR7S4O5A54FPJAGPOS31IAKV9I87HN67AFOSQYJ60KER
6ZK6JA0RECIHKGSC43KRVJPAA5OTTP2COCXUJXROIAXC6MJ7YJBPSV14317WH4SRMHX1N32S5L8JQG9D
EVWVQBM7HBWH9HMIB0S9KF7J43X4ZW38BH58R93IYJVSRE6561Q3K76L3O53EJSZ0N4XAX39W3F07ZRV

From rail.shafigulin at gmail.com  Mon Nov  5 15:50:44 2012
From: rail.shafigulin at gmail.com (rail shafigulin)
Date: Mon, 5 Nov 2012 09:50:44 -0500
Subject: [docs] Inaccurate description of HtmlDiff.make_table,
	Python 3.1.5
In-Reply-To: <CAL3CFcW+v2Rto2L7bL+=zRwK3rKgdOxJrQNbx3tn329yC_pj2w@mail.gmail.com>
References: <CAFAaeRXf_Fq=Sev4H+eX6+gf4oSK0g0YE5zhZyMiQGtAptx_gQ@mail.gmail.com>
	<CAL3CFcWAdaAHfXv+qp6epTVN5cQMwRT7YSLv9et2ZEVgRkJMEw@mail.gmail.com>
	<CAFAaeRWwu0Rgn_PW3N242qx3bRyh243kSEUJM_ePxyztOamYRQ@mail.gmail.com>
	<CAL3CFcW+v2Rto2L7bL+=zRwK3rKgdOxJrQNbx3tn329yC_pj2w@mail.gmail.com>
Message-ID: <CAFAaeRXnOHJ_R8GmSP9=zN2zXug3PTY7pEB=-0O8QcmYNFpGXw@mail.gmail.com>

I tried running the code you have given using Python 3.1.5 and Python
3.3.0. The result is always the same and I don't see any highlighting. Here
is what I did on the Windows command line:

C:\Documents and Settings\shafigulinr>python -c "from difflib import *; s1
= ['bacon\n', 'eggs\n', 'ham\n', 'guido\n']; s2 = ['python\n', 'eggy\n',
'hamster\n', 'guido\n']; print(HtmlDiff().make_table(s1, s2))" > diff.html

I'm also attaching the result file.

I'm running Python 3.1.5/3.3.0 on a Windows XP Pro Version 2002, SP 3,
Google Chrome browser, Version 22.0.1229.94 m


On Fri, Nov 2, 2012 at 4:46 PM, Andrew Svetlov <andrew.svetlov at gmail.com>wrote:

> Perhaps we have some misunderstanding.
>
> I tried:
>
> >>> from difflib import *
> >>> s1 = ['bacon\n', 'eggs\n', 'ham\n', 'guido\n']
> >>> s2 = ['python\n', 'eggy\n', 'hamster\n', 'guido\n']
> >>> d.make_table(s1, s2)
> ... LONG ENOUGH OUTPUT
>
> when I've opened that output in browser the differences was definitely
> highlighted.
>
> I've tried it on 3.2, 3.1 is open for security bugs only for now BTW.
> Please inform me how to reproduce your problem.
> Also please keep in mind: 3.1 in security-only stage, if your issue has
> been fixed in 3.2 we'll do nothing to backport fix into 3.1
>
> Thanks.
>
>
> On Fri, Nov 2, 2012 at 8:47 PM, rail shafigulin <rail.shafigulin at gmail.com
> > wrote:
>
>> I can't see any highlighting. I'm attaching diff.html which I generated
>> using the script provided here,
>> http://docs.python.org/release/3.1.5/library/difflib.html#a-command-line-interface-to-difflib .
>> In the script I changed make_file to make_table to demonstrate the effect.
>> I'm also attaching two text files I used for diff generation.
>>
>> I'm running Python 3.1.5 on a Windows XP Pro Version 2002, SP 3.
>>
>> Thanks.
>>
>>
>> On Thu, Nov 1, 2012 at 6:34 AM, Andrew Svetlov <andrew.svetlov at gmail.com>wrote:
>>
>>> It works, at least from my understanding of ?highlighting?.
>>>
>>>
>>> On Tue, Oct 30, 2012 at 9:16 PM, rail shafigulin <
>>> rail.shafigulin at gmail.com> wrote:
>>>
>>>> The description of HtmlDiff.make_table is inaccurate,
>>>> http://docs.python.org/release/3.1.5/library/difflib.html#difflib.HtmlDiff.make_table It
>>>> says the following
>>>>
>>>> "Compares fromlines and tolines (lists of strings) and returns a string
>>>> which is a complete HTML table showing line by line differences with
>>>> inter-line and intra-line changes highlighted."
>>>>
>>>> However non of the rows in the tables are highlighted.
>>>>
>>>> There are two possible fixes for this.
>>>>
>>>> 1. The documentation is incorrect in describing what should happen when
>>>> this method is called. Instead of what is says right now it should say that
>>>> the table is generated without showing any differences.
>>>> 2. The code does not reflect the documentation, i.e. make_table should
>>>> generate the html string correctly.
>>>>
>>>> I'm running Python 3.1.5 on a Windows Xp Pro Version 2002, SP 3.
>>>>
>>>> _______________________________________________
>>>> docs mailing list
>>>> docs at python.org
>>>> http://mail.python.org/mailman/listinfo/docs
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Andrew Svetlov
>>>
>>
>>
>
>
> --
> Thanks,
> Andrew Svetlov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121105/628f3754/attachment-0002.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121105/628f3754/attachment-0003.html>

From rail.shafigulin at gmail.com  Mon Nov  5 16:17:26 2012
From: rail.shafigulin at gmail.com (rail shafigulin)
Date: Mon, 5 Nov 2012 10:17:26 -0500
Subject: [docs] Inaccurate description of HtmlDiff.make_table,
	Python 3.1.5
In-Reply-To: <CAL3CFcUPCVSXpJL7DosPSYifwbyBd6y1bEX11-W6Nv0SRNKe7w@mail.gmail.com>
References: <CAFAaeRXf_Fq=Sev4H+eX6+gf4oSK0g0YE5zhZyMiQGtAptx_gQ@mail.gmail.com>
	<CAL3CFcWAdaAHfXv+qp6epTVN5cQMwRT7YSLv9et2ZEVgRkJMEw@mail.gmail.com>
	<CAFAaeRWwu0Rgn_PW3N242qx3bRyh243kSEUJM_ePxyztOamYRQ@mail.gmail.com>
	<CAL3CFcW+v2Rto2L7bL+=zRwK3rKgdOxJrQNbx3tn329yC_pj2w@mail.gmail.com>
	<CAFAaeRXnOHJ_R8GmSP9=zN2zXug3PTY7pEB=-0O8QcmYNFpGXw@mail.gmail.com>
	<CAL3CFcUPCVSXpJL7DosPSYifwbyBd6y1bEX11-W6Nv0SRNKe7w@mail.gmail.com>
Message-ID: <CAFAaeRXZ=dsG9MK5ASnHU7GMCc+MObGpAuD6m7nRk+1phcR+=w@mail.gmail.com>

That's what I meant by inaccurate description. Documentation for make_table
says that the differences will be highlighted,
http://docs.python.org/release/3.1.5/library/difflib.html#difflib.HtmlDiff.make_table,
while the output shows that it isn't. Either documentation needs to be
fixed not to say that differences will be highlighted or the code needs to
be fixed to generate appropriate highlighting.

Thanks.


On Mon, Nov 5, 2012 at 10:04 AM, Andrew Svetlov <andrew.svetlov at gmail.com>wrote:

> Well, use HtmlDiff().make_file(s1, s2) method or provide css for
> make_table by yourself.
>
> On Mon, Nov 5, 2012 at 4:50 PM, rail shafigulin
> <rail.shafigulin at gmail.com> wrote:
> > I tried running the code you have given using Python 3.1.5 and Python
> 3.3.0.
> > The result is always the same and I don't see any highlighting. Here is
> what
> > I did on the Windows command line:
> >
> > C:\Documents and Settings\shafigulinr>python -c "from difflib import *;
> s1 =
> > ['bacon\n', 'eggs\n', 'ham\n', 'guido\n']; s2 = ['python\n', 'eggy\n',
> > 'hamster\n', 'guido\n']; print(HtmlDiff().make_table(s1, s2))" >
> diff.html
> >
> > I'm also attaching the result file.
> >
> > I'm running Python 3.1.5/3.3.0 on a Windows XP Pro Version 2002, SP 3,
> > Google Chrome browser, Version 22.0.1229.94 m
> >
> >
> > On Fri, Nov 2, 2012 at 4:46 PM, Andrew Svetlov <andrew.svetlov at gmail.com
> >
> > wrote:
> >>
> >> Perhaps we have some misunderstanding.
> >>
> >> I tried:
> >>
> >> >>> from difflib import *
> >> >>> s1 = ['bacon\n', 'eggs\n', 'ham\n', 'guido\n']
> >> >>> s2 = ['python\n', 'eggy\n', 'hamster\n', 'guido\n']
> >> >>> d.make_table(s1, s2)
> >> ... LONG ENOUGH OUTPUT
> >>
> >> when I've opened that output in browser the differences was definitely
> >> highlighted.
> >>
> >> I've tried it on 3.2, 3.1 is open for security bugs only for now BTW.
> >> Please inform me how to reproduce your problem.
> >> Also please keep in mind: 3.1 in security-only stage, if your issue has
> >> been fixed in 3.2 we'll do nothing to backport fix into 3.1
> >>
> >> Thanks.
> >>
> >>
> >> On Fri, Nov 2, 2012 at 8:47 PM, rail shafigulin
> >> <rail.shafigulin at gmail.com> wrote:
> >>>
> >>> I can't see any highlighting. I'm attaching diff.html which I generated
> >>> using the script provided here,
> >>>
> http://docs.python.org/release/3.1.5/library/difflib.html#a-command-line-interface-to-difflib
> >>> . In the script I changed make_file to make_table to demonstrate the
> effect.
> >>> I'm also attaching two text files I used for diff generation.
> >>>
> >>> I'm running Python 3.1.5 on a Windows XP Pro Version 2002, SP 3.
> >>>
> >>> Thanks.
> >>>
> >>>
> >>> On Thu, Nov 1, 2012 at 6:34 AM, Andrew Svetlov <
> andrew.svetlov at gmail.com>
> >>> wrote:
> >>>>
> >>>> It works, at least from my understanding of ?highlighting?.
> >>>>
> >>>>
> >>>> On Tue, Oct 30, 2012 at 9:16 PM, rail shafigulin
> >>>> <rail.shafigulin at gmail.com> wrote:
> >>>>>
> >>>>> The description of HtmlDiff.make_table is inaccurate,
> >>>>>
> http://docs.python.org/release/3.1.5/library/difflib.html#difflib.HtmlDiff.make_table
> >>>>> It says the following
> >>>>>
> >>>>> "Compares fromlines and tolines (lists of strings) and returns a
> string
> >>>>> which is a complete HTML table showing line by line differences with
> >>>>> inter-line and intra-line changes highlighted."
> >>>>>
> >>>>> However non of the rows in the tables are highlighted.
> >>>>>
> >>>>> There are two possible fixes for this.
> >>>>>
> >>>>> 1. The documentation is incorrect in describing what should happen
> when
> >>>>> this method is called. Instead of what is says right now it should
> say that
> >>>>> the table is generated without showing any differences.
> >>>>> 2. The code does not reflect the documentation, i.e. make_table
> should
> >>>>> generate the html string correctly.
> >>>>>
> >>>>> I'm running Python 3.1.5 on a Windows Xp Pro Version 2002, SP 3.
> >>>>>
> >>>>> _______________________________________________
> >>>>> docs mailing list
> >>>>> docs at python.org
> >>>>> http://mail.python.org/mailman/listinfo/docs
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Thanks,
> >>>> Andrew Svetlov
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Thanks,
> >> Andrew Svetlov
> >
> >
>
>
>
> --
> Thanks,
> Andrew Svetlov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121105/09fb777a/attachment-0001.html>

From sander at rotzorg.org  Thu Nov  1 14:06:21 2012
From: sander at rotzorg.org (Sander De Graaf)
Date: Thu, 01 Nov 2012 13:06:21 -0000
Subject: [docs] Wrong calculation in itertools documentation
In-Reply-To: <CAL3CFcWjJCK_3FX95N-NUaTKnh-j2JbjjS6u21ujBJJ032szKg@mail.gmail.com>
References: <404D6AF4-CB77-4C64-8DC6-AAD9F953C97F@rotzorg.org>
	<CAL3CFcWjJCK_3FX95N-NUaTKnh-j2JbjjS6u21ujBJJ032szKg@mail.gmail.com>
Message-ID: <980E10A6-6825-4C18-BFBA-2AF4C64DD596@rotzorg.org>

You are correct. I'm not sure where I failed, but I did :)

Thanks
Sander

On 31 okt. 2012, at 10:37, Andrew Svetlov <andrew.svetlov at gmail.com> wrote:

> Sure, the doc is correct. The count if permutations is n! / (n-r)!
> Try yourself, please.
> 
> On Sun, Oct 7, 2012 at 1:29 AM, Sander De Graaf <sander at rotzorg.org> wrote:
>> Hi,
>> 
>> I'm reading docs.python.org/library/itertools.html @ permutations().
>> 
>> It writes:
>> 
>>    The number of items returned is n! / (n-r)! ...
>> 
>> The number should be n! / r!
>> 
>> Thanks,
>> Sander De Graaf
>> 
>> _______________________________________________
>> docs mailing list
>> docs at python.org
>> http://mail.python.org/mailman/listinfo/docs
> 
> 
> 
> -- 
> Thanks,
> Andrew Svetlov

From seanmunkel at gmail.com  Thu Nov  8 20:08:55 2012
From: seanmunkel at gmail.com (Sean Munkel)
Date: Thu, 8 Nov 2012 14:08:55 -0500
Subject: [docs] datetime.time inconsistency
Message-ID: <CAKyAGk3i_+QRMfzbxwadoaTNP=PGWFOKiLpAJ6FK_gDuS4=fdA@mail.gmail.com>

In the 2.x (and 3.0) version of the python documentation, the arguments for
datetime.time are listed as follows:
datetime.time(hour[, minute[, second[, microsecond[, tzinfo]]]])

While the builtin python help() function says this:
time([hour[, minute[, second[, microsecond[, tzinfo]]]]])

The online documentation seems to suggest that "hour" is a required
argument, which isn't the case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121108/67e8bb3b/attachment.html>

From weppenaar at gmail.com  Thu Nov 15 15:25:13 2012
From: weppenaar at gmail.com (Nick Weppenaar)
Date: Thu, 15 Nov 2012 15:25:13 +0100
Subject: [docs] Possible bug in zipfile when opening zip file from external
	drive
Message-ID: <CAJwS_C=17nZ1D9bidXSMUu0X0wdvemBLyGN_Xw_FbwVypJAmAA@mail.gmail.com>

Hello.


I would like to report a possible bug. I'm using zipfile to extract files
from a zip repository. When I try to open the zip repository, I hit an
error message from lines 173-174 in zipfile.py:


if diskno != 0 or disks != 1:

    raise BadZipfile("zipfiles that span multiple disks are not supported")


The problem is that it's not a multi-disk zipfile. When I try to open it
with anything else (7-zip, windows), it works fine. I think the problem
could be that the zipfile was created on an external harddrive and hits a
snag on the first part of the check. I don't know exactly what diskno is,
but I guess that it relates to the order of the disk in the system. Anyway,
it I comment out those two lines, zipfile extracts the files without any
problems.


My suggestion is to separate out the two checks and make sure that zipfiles
created on external drives (if that's the cause of the problem) can be
extracted.


Thank you.


Nick Weppenaar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121115/2cf9a528/attachment.html>

From report at bugs.python.org  Sun Nov 18 11:21:01 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Nov 2012 10:21:01 +0000
Subject: [docs] [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <3Y48Mw4FrkzQNb@mail.python.org>


Roundup Robot added the comment:

New changeset 290f3b75480f by Mark Dickinson in branch '2.7':
Issue #12005: clarify behaviour of % and // for Decimal objects.
http://hg.python.org/cpython/rev/290f3b75480f

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

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

From report at bugs.python.org  Sun Nov 18 11:23:15 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Nov 2012 10:23:15 +0000
Subject: [docs] [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <3Y48QV6G2rzQQB@mail.python.org>


Roundup Robot added the comment:

New changeset 0ec314f26791 by Mark Dickinson in branch '3.2':
Issue #12005: clarify behaviour of % and // for Decimal objects.
http://hg.python.org/cpython/rev/0ec314f26791

New changeset f626c214cad0 by Mark Dickinson in branch '3.3':
Issue #12005: merge doc patch from 3.2
http://hg.python.org/cpython/rev/f626c214cad0

New changeset 0263d2ef9530 by Mark Dickinson in branch 'default':
Issue #12005: merge doc patch from 3.3
http://hg.python.org/cpython/rev/0263d2ef9530

----------

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

From report at bugs.python.org  Sun Nov 18 11:24:05 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 18 Nov 2012 10:24:05 +0000
Subject: [docs] [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1353234245.25.0.440773979151.issue12005@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Docs updated.

----------
assignee: rhettinger -> mark.dickinson
resolution:  -> fixed
status: open -> closed
versions: +Python 3.4

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

From report at bugs.python.org  Sun Nov 18 11:39:34 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 18 Nov 2012 10:39:34 +0000
Subject: [docs] [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1353235174.64.0.788241373236.issue12005@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Mark, there's a small typo in the patch: "preseve the usual identity"

----------
nosy: +skrah

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

From report at bugs.python.org  Sun Nov 18 11:40:04 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 18 Nov 2012 10:40:04 +0000
Subject: [docs] [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1353235204.05.0.638993512693.issue12005@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

D'oh!  Thanks.

----------

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

From report at bugs.python.org  Sun Nov 18 11:44:00 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 18 Nov 2012 10:44:00 +0000
Subject: [docs] [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1353235440.06.0.0649183247782.issue12005@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Typo now fixed.

----------

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

From report at bugs.python.org  Sun Nov 18 11:56:44 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Nov 2012 10:56:44 +0000
Subject: [docs] [issue16053] "strict" parameter is not documented in csv
	module
In-Reply-To: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za>
Message-ID: <3Y49975dfPzQSv@mail.python.org>


Roundup Robot added the comment:

New changeset 9b6797631490 by Ezio Melotti in branch '2.7':
#16053: document csv.Dialect.strict.  Patch by Kushal Das.
http://hg.python.org/cpython/rev/9b6797631490

New changeset faf6941ed5fd by Ezio Melotti in branch '3.2':
#16053: document csv.Dialect.strict.  Patch by Kushal Das.
http://hg.python.org/cpython/rev/faf6941ed5fd

New changeset 1956bc3edbb7 by Ezio Melotti in branch '3.3':
#16053: merge with 3.2.
http://hg.python.org/cpython/rev/1956bc3edbb7

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

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

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

From report at bugs.python.org  Sun Nov 18 11:57:50 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Nov 2012 10:57:50 +0000
Subject: [docs] [issue16053] "strict" parameter is not documented in csv
	module
In-Reply-To: <1348655757.15.0.984566805089.issue16053@psf.upfronthosting.co.za>
Message-ID: <1353236270.32.0.684817862731.issue16053@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: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Nov 18 12:38:27 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Nov 2012 11:38:27 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <50A83A62.5010607@gmx.net>
Message-ID: <1353238657.3364.0.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> On 11/18/2012 12:36 AM, Antoine Pitrou wrote:
> >
> > - the patch needs a test (and docs too)
> > - are you sure ignoring POSTed data is the right thing to do? Shouldn't we forbid it instead?
> 
> Btw.: The file:// protocol handler also just ignores posted data, so I think the data url handler 
> shouldn't deviate from that. Either both raise an error when data is posted or none.

Ah, fair enough, then. Thanks for the updated patch, I'll take a look
(unless someone beats me to it).

----------

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

From report at bugs.python.org  Sun Nov 18 16:23:41 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 18 Nov 2012 15:23:41 +0000
Subject: [docs] [issue16493] Document the 'optimize' argument to compile()
In-Reply-To: <1353167567.95.0.716171753234.issue16493@psf.upfronthosting.co.za>
Message-ID: <1353252221.02.0.309293055532.issue16493@psf.upfronthosting.co.za>


Brett Cannon added the comment:

No one else is working on it.

----------

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

From report at bugs.python.org  Sun Nov 18 16:37:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 18 Nov 2012 15:37:59 +0000
Subject: [docs] [issue16493] Document the 'optimize' argument to compile()
In-Reply-To: <1353167567.95.0.716171753234.issue16493@psf.upfronthosting.co.za>
Message-ID: <1353253079.25.0.2773027915.issue16493@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/issue16493>
_______________________________________

From zachary.ware+pydocs at gmail.com  Sun Nov 18 17:40:09 2012
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Sun, 18 Nov 2012 10:40:09 -0600
Subject: [docs] A Broken Link on Your Site About Geany and GTK
In-Reply-To: <3FPK73FB-7FA6-634G-8G8T-DPQX0QMHOL6E@gmail.com>
References: <3FPK73FB-7FA6-634G-8G8T-DPQX0QMHOL6E@gmail.com>
Message-ID: <CAKJDb-PzpHeRXsBXnHH+Gkf9eQJXq4ED0LStnJWU=AuYfdCf4g@mail.gmail.com>

Hi Michelle,

First off, pythonexperts.com does not appear to be affiliated with
python.org or the Python Software Foundation.  The most up-to-date
Python documentation will always be found at docs.python.org and I
would encourage you to use that site for the best information.

Secondly, the documentation on the page you linked to is for Python
2.6, which is by now in security fix only mode.  The issue you raised
is already fixed in 2.7, though: http://docs.python.org/2/using/unix

Thanks for the report, though!  We're more than happy to fix any other
bugs you find in current versions as found on docs.python.org

On Sun, Nov 11, 2012 at 10:44 PM, Michelle Barton
<michellebarton39 at gmail.com> wrote:
> Hi Administrator,
>
> I came across your website and wanted to notify you about a broken link on
> your page in case you weren't aware of it. The link on
> pythonexperts.com/_sources/using/unix.txt which links to
> http://geany.uvena.de/ is no longer working. I've included a link to a
> useful page on Geany and GTK that you could replace the broken link with if
> you're interested in updating your website. Thanks for providing a great
> resource!
>
> Link: http://www.onlinecomputersciencedegree.com/resources/geany-and-gtk/
>
> Best,
> Michelle Barton
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs

From zachary.ware+pydocs at gmail.com  Sun Nov 18 17:46:02 2012
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Sun, 18 Nov 2012 10:46:02 -0600
Subject: [docs] Hi all, I want to translate Python 2.7's doc to Chinese,
 what shall i do?
In-Reply-To: <CALMyDCm9=h+hD+jf--1TmbBj2yAoeGV8ue-WQTUgn1m+r5MJ7w@mail.gmail.com>
References: <CALMyDCm9=h+hD+jf--1TmbBj2yAoeGV8ue-WQTUgn1m+r5MJ7w@mail.gmail.com>
Message-ID: <CAKJDb-NbjZ--ry8w7GkNE1Fbqg=HsvE9Zbi=7uyGjcQricBipg@mail.gmail.com>

Hi Flair Yu,

You may want to check out pootle.python.org, the Python Translations
site.  I'm sorry I don't know much more about that site than that it
exists, but hopefully pointing you towards it helps you.

Good luck on translating, though; it is a worthy goal!

On Tue, Nov 13, 2012 at 9:50 AM, Flair Yu <flairyu at gmail.com> wrote:
> Hi all!
>
>  I like python, it's simple and easy to use.  I want to translate Python
> 2.7's documents to Chinese, so lots of Chinese can know it and learn. I
> wander what shall I do next? Is there somebody i should report for? thanks.
>
> flair yu.
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>

From zachary.ware+pydocs at gmail.com  Sun Nov 18 18:00:49 2012
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Sun, 18 Nov 2012 11:00:49 -0600
Subject: [docs] Python 2.7.2
In-Reply-To: <27E0026F-50E4-4C1C-BEED-9A4E59B50AF4@gmail.com>
References: <27E0026F-50E4-4C1C-BEED-9A4E59B50AF4@gmail.com>
Message-ID: <CAKJDb-NFr-PgJPWv9eeN=JnbB+BaCHDb9VbF5pF+5a=V_Y6p-A@mail.gmail.com>

On Tue, Nov 13, 2012 at 3:05 PM,  <gurleym at gmail.com> wrote:
> Greetings,
>
> I'm using Python 2.7.2 on windows 7.  From the tutorial page chapter 3.1.1,we start going into numbers and comments. In following the examples I type the code
>
> 8/5 # Fractions aren't lost when dividing integers <hit enter>
> 1
>
> Per the example on the web page I should get 1.6 not 1
>
> Am I doing something wrong?
>
> Also I purchased your app for iPad. I can't figure out where to do these tutorials on it. I understand the reference page and found the links but where/ how do I input the code in the app. Even just the simple math part.
>
>
> Thank you for your time
>
> -Matt

Hi Matt,

It would appear you're using the Python 3 tutorial with Python 2.7.
You can change the version of the page you're looking at with the
version switching dropdown at the top left of the page; or by changing
'3' to '2' in the address bar.

You've encountered one of the significant backward-incompatible
changes between Python 2 and Python 3; in 2.x the '/' operator is for
floor division while in 3.x '/' is for 'true' division and '//' is for
floor division.  You can enable this functionality in 2.7 by doing
"from __future__ import division", though.

As far as the iPad app, please contact its developer for questions.
It is not maintained by the Python Software Foundation or CPython
community.

From report at bugs.python.org  Sun Nov 18 18:33:29 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Nov 2012 17:33:29 +0000
Subject: [docs] [issue16502] PEP 305: eaten backslashes
Message-ID: <1353260009.13.0.210575226551.issue16502@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In PEP 305 '\r\n' rendered as 'rn' in one place.  The proposed patch should fix this.

----------
assignee: docs at python
components: Documentation
files: pep-0305_rn.patch
keywords: patch
messages: 175891
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: PEP 305: eaten backslashes
Added file: http://bugs.python.org/file28028/pep-0305_rn.patch

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

From report at bugs.python.org  Sun Nov 18 18:35:05 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Nov 2012 17:35:05 +0000
Subject: [docs] [issue16502] PEP 305: eaten backslashes
In-Reply-To: <1353260009.13.0.210575226551.issue16502@psf.upfronthosting.co.za>
Message-ID: <1353260104.97.0.964015754963.issue16502@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Hmm, I wonder if this is a ReST bug.

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

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

From report at bugs.python.org  Sun Nov 18 18:35:16 2012
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 18 Nov 2012 17:35:16 +0000
Subject: [docs] [issue16503] Unclear documentation regarding apply(),
	'extended call syntax'
Message-ID: <1353260116.84.0.175308282069.issue16503@psf.upfronthosting.co.za>


New submission from Zachary Ware:

(Reported by Kevin Leeds on docs at python.org)

The documentation for the apply() built-in function in 2.7 says that it is deprecated and to use "extended call syntax" instead.  There is no mention of "extended call syntax" anywhere else in the docs.  The simplest solution I can see is in the attached patch; it merely adds a link to the tutorial section about arbitrary argument lists within the deprecation warning.  I wonder though if the wording should be changed to something more findable.  What is the common wording of *args and **kwargs usage?

----------
assignee: docs at python
components: Documentation
files: arbitraryargs_2.7.patch
keywords: patch
messages: 175894
nosy: docs at python, zach.ware
priority: normal
severity: normal
status: open
title: Unclear documentation regarding apply(), 'extended call syntax'
versions: Python 2.7
Added file: http://bugs.python.org/file28029/arbitraryargs_2.7.patch

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

From zachary.ware+pydocs at gmail.com  Sun Nov 18 18:36:14 2012
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Sun, 18 Nov 2012 11:36:14 -0600
Subject: [docs] Bug: I can't find documentation for the "apply" function,
 and then I can't find documentation for "extended call syntax"
In-Reply-To: <CAJnwqek57v5AfzvpduY=U3Q1TzaD33RQ+uFTV1o8Di9GwhFQzA@mail.gmail.com>
References: <CAJnwqem37yWo+xBJRPHAogAs81=MzoUFmWY4qR8sdDzj3q95hQ@mail.gmail.com>
	<CAJnwqek57v5AfzvpduY=U3Q1TzaD33RQ+uFTV1o8Di9GwhFQzA@mail.gmail.com>
Message-ID: <CAKJDb-PKnJkwYH1N5d9KgniMws346fzVH_Hi-wXownXUYnbY2Q@mail.gmail.com>

On Wed, Nov 14, 2012 at 6:12 PM, Kevin Leeds <knleeds at gmail.com> wrote:
> P.S. I still can't find it when I read the Python Tutorial.
> There's a section on Defining Functions, then there's More About
> Defining Functions.
> However there's no section about calling functions.
>
>
> On Wed, Nov 14, 2012 at 5:40 PM, Kevin Leeds <knleeds at gmail.com> wrote:
>> Sorry! I am trying to figure out from the documentation a good way to
>> use "call" instead of "apply", and am finding myself frustrated by the
>> documentation site
>>
>> Apparently there's no way to search among functions names only, and
>> perhaps not for phrases either.
>>
>> On one page I found out the "apply" function is deprecated, and that I
>> should use the "extended call syntax".
>> At one point I'm informed that the description of "extended call
>> syntax" is described "above".
>>
>> There should be a hyperlink to the actual description.  It's not
>> possible to find the material being referenced without guessing
>> sections or reading the entire document perhaps.
>>
>> :) Thank you for your prompt attention to this important matter :)


Hi Kevin,

I think the section you're looking for is
http://docs.python.org/2.7/tutorial/controlflow.html#arbitrary-argument-lists
(or the Python 3 version thereof).

Could you give some more information about what version of Python
you're using, which pages you're looking at (and which versions),
etc.?  The more we know about your situation, the better able we are
to make the docs clearer for the next reader :).

In the meantime, I've filed an issue on the Python Bug Tracker to
track this issue: http://bugs.python.org/issue16503

Thanks for the report!

From report at bugs.python.org  Sun Nov 18 18:49:55 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Nov 2012 17:49:55 +0000
Subject: [docs] [issue16502] PEP 305: eaten backslashes
In-Reply-To: <1353260009.13.0.210575226551.issue16502@psf.upfronthosting.co.za>
Message-ID: <1353260995.21.0.772761617785.issue16502@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a markup bug. In all other cases \n escaped (\\n), or quoted (``\n``), or used in a code fragment.

----------

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

From report at bugs.python.org  Sun Nov 18 18:55:47 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Nov 2012 17:55:47 +0000
Subject: [docs] [issue16502] PEP 305: eaten backslashes
In-Reply-To: <1353260009.13.0.210575226551.issue16502@psf.upfronthosting.co.za>
Message-ID: <1353261347.86.0.181571561043.issue16502@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Nov 18 20:23:57 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Nov 2012 19:23:57 +0000
Subject: [docs] [issue16503] Unclear documentation regarding apply(),
	'extended call syntax'
In-Reply-To: <1353260116.84.0.175308282069.issue16503@psf.upfronthosting.co.za>
Message-ID: <3Y4NQN3Jx9zRN7@mail.python.org>


Roundup Robot added the comment:

New changeset 7efa0d66b1a0 by Ezio Melotti in branch '2.7':
#16503: clarify "apply" docs.
http://hg.python.org/cpython/rev/7efa0d66b1a0

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

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

From report at bugs.python.org  Sun Nov 18 20:24:59 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Nov 2012 19:24:59 +0000
Subject: [docs] [issue16503] Unclear documentation regarding apply(),
	'extended call syntax'
In-Reply-To: <1353260116.84.0.175308282069.issue16503@psf.upfronthosting.co.za>
Message-ID: <1353266699.38.0.94605676165.issue16503@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

It should be clearer now.

----------
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/issue16503>
_______________________________________

From report at bugs.python.org  Sun Nov 18 20:26:29 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Nov 2012 19:26:29 +0000
Subject: [docs] [issue16493] Document the 'optimize' argument to compile()
In-Reply-To: <1353167567.95.0.716171753234.issue16493@psf.upfronthosting.co.za>
Message-ID: <1353266789.32.0.567928687274.issue16493@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Nov 18 20:32:51 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Nov 2012 19:32:51 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1353267171.77.0.9089365221.issue8145@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Can someone review this patch?
(There is a typo: s/The/This/)

----------
keywords: +easy, needs review
nosy: +ezio.melotti
versions: +Python 3.3, Python 3.4 -Python 3.1

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

From zachary.ware+pydocs at gmail.com  Sun Nov 18 21:00:44 2012
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Sun, 18 Nov 2012 14:00:44 -0600
Subject: [docs] Bug: I can't find documentation for the "apply" function,
 and then I can't find documentation for "extended call syntax"
In-Reply-To: <CAJnwqen534Y0LcWbVHnRZ1mb9m8B2tVeyWGaTVPCtsu4m54c7w@mail.gmail.com>
References: <CAJnwqem37yWo+xBJRPHAogAs81=MzoUFmWY4qR8sdDzj3q95hQ@mail.gmail.com>
	<CAJnwqek57v5AfzvpduY=U3Q1TzaD33RQ+uFTV1o8Di9GwhFQzA@mail.gmail.com>
	<CAKJDb-PKnJkwYH1N5d9KgniMws346fzVH_Hi-wXownXUYnbY2Q@mail.gmail.com>
	<CAJnwqen534Y0LcWbVHnRZ1mb9m8B2tVeyWGaTVPCtsu4m54c7w@mail.gmail.com>
Message-ID: <CAKJDb-O=ZgjDakZ_7dtsWPkQdGuc3hjFgNATVmdgRU+eqeayxw@mail.gmail.com>

On Sun, Nov 18, 2012 at 11:44 AM, Kevin Leeds <knleeds at gmail.com> wrote:
> Thank you!
> I think I was deluded perhaps thinking "apply" was a Python function?

apply() is in fact a Python 2 function, as is everything else at
http://docs.python.org/2/library/functions.  However, as you've seen,
it is deprecated and was removed in Python 3.

> It turned out "map" is what I wanted at the time, actually.
> Still I find the function search capability or function index to be
> somewhat deficient in this area.  The documentation didn't seem to
> tell me definitively what "apply" or "map" is or isn't.

That should be covered by the "Built-in Functions" page I linked to
above.  Do you have any specific suggestions for how to improve it?

> I DO
> appreciate that the documentation is to be constructed to be readable
> by programmers who do not wish to be confronted by reams of hard
> technical categories, and mainly want to get something done fast.

True, but we also try to keep the documentation very newbie-friendly.
Anyone who has thoroughly read the tutorial should be able to
understand the reference docs, and if not (or at least if not after
having asked on python-list at python.org or tutor at python.org and gotten
an explanation), the docs should be clarified.

> The
> course I am in is at the level where the correct answer is to use a
> "for" loop.  The course is at too Beginner a level for me, so that is
> my situation.  MIT Open Courseware, Python for beginning programmers -
> but I'm not one of those, taking it anyway to see what chaos can
> ensue! - My version for that course is 2.7.

Another thing to be sure of is that you are in fact looking at the
right documentation.  The docs site was recently changed to redirect
"docs.python.org" to "docs.python.org/3/", the Python 3 doc site. You
can check (and change) which version you're using in the top left of
the page.

> Thank you very much for your helpful reply!

You're very welcome :)

-- Zachary Ware

> Just my 2 cents
> I see there is a Bug Report so I will go visit that right away. Thank
> you Zachary.
> Kevin Leeds
>
> On Sun, Nov 18, 2012 at 11:36 AM, Zachary Ware
> <zachary.ware+pydocs at gmail.com> wrote:
>> On Wed, Nov 14, 2012 at 6:12 PM, Kevin Leeds <knleeds at gmail.com> wrote:
>>> P.S. I still can't find it when I read the Python Tutorial.
>>> There's a section on Defining Functions, then there's More About
>>> Defining Functions.
>>> However there's no section about calling functions.
>>>
>>>
>>> On Wed, Nov 14, 2012 at 5:40 PM, Kevin Leeds <knleeds at gmail.com> wrote:
>>>> Sorry! I am trying to figure out from the documentation a good way to
>>>> use "call" instead of "apply", and am finding myself frustrated by the
>>>> documentation site
>>>>
>>>> Apparently there's no way to search among functions names only, and
>>>> perhaps not for phrases either.
>>>>
>>>> On one page I found out the "apply" function is deprecated, and that I
>>>> should use the "extended call syntax".
>>>> At one point I'm informed that the description of "extended call
>>>> syntax" is described "above".
>>>>
>>>> There should be a hyperlink to the actual description.  It's not
>>>> possible to find the material being referenced without guessing
>>>> sections or reading the entire document perhaps.
>>>>
>>>> :) Thank you for your prompt attention to this important matter :)
>>
>>
>> Hi Kevin,
>>
>> I think the section you're looking for is
>> http://docs.python.org/2.7/tutorial/controlflow.html#arbitrary-argument-lists
>> (or the Python 3 version thereof).
>>
>> Could you give some more information about what version of Python
>> you're using, which pages you're looking at (and which versions),
>> etc.?  The more we know about your situation, the better able we are
>> to make the docs clearer for the next reader :).
>>
>> In the meantime, I've filed an issue on the Python Bug Tracker to
>> track this issue: http://bugs.python.org/issue16503
>>
>> Thanks for the report!

From report at bugs.python.org  Sun Nov 18 21:03:54 2012
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 18 Nov 2012 20:03:54 +0000
Subject: [docs] [issue16503] Unclear documentation regarding apply(),
	'extended call syntax'
In-Reply-To: <1353260116.84.0.175308282069.issue16503@psf.upfronthosting.co.za>
Message-ID: <1353269034.93.0.524490689543.issue16503@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Looks good to me, thank you Ezio!

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

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

From report at bugs.python.org  Sun Nov 18 21:04:19 2012
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 18 Nov 2012 20:04:19 +0000
Subject: [docs] [issue16503] Unclear documentation regarding apply(),
	'extended call syntax'
In-Reply-To: <1353260116.84.0.175308282069.issue16503@psf.upfronthosting.co.za>
Message-ID: <1353269059.58.0.513625991461.issue16503@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


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

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

From report at bugs.python.org  Sun Nov 18 23:03:34 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Nov 2012 22:03:34 +0000
Subject: [docs] [issue13094] Need Programming FAQ entry for the behavior of
	closures
In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za>
Message-ID: <1353276214.77.0.354788448864.issue13094@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Mon Nov 19 01:14:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 19 Nov 2012 00:14:41 +0000
Subject: [docs] [issue16508] include the "object" type in the lists of
	documented	types
Message-ID: <1353284081.12.0.684350303879.issue16508@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add the "object" type to the list of types documented in the language reference's standard type hierarchy and the library reference's list of built-in types:

http://docs.python.org/dev/reference/datamodel.html#the-standard-type-hierarchy
http://docs.python.org/dev/library/stdtypes.html#other-built-in-types

The constructor is documented here:

http://docs.python.org/dev/library/functions.html#object

In the documentation, it might also be worth stating explicitly which of the special methods the object type defines:

http://docs.python.org/dev/reference/datamodel.html#special-method-names

For example, object.__str__ is defined, but object.__bytes__ is not.  By doing this, users will know which special methods user-defined classes will automatically inherit.

----------
assignee: docs at python
components: Documentation
messages: 175938
nosy: chris.jerdonek, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: include the "object" type in the lists of documented types
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Nov 19 08:40:52 2012
From: report at bugs.python.org (Daniel Micay)
Date: Mon, 19 Nov 2012 07:40:52 +0000
Subject: [docs] [issue16509] sqlite3 docs do not explain check_same_thread
Message-ID: <1353310851.97.0.745365364193.issue16509@psf.upfronthosting.co.za>


New submission from Daniel Micay:

The sqlite3 documentation now includes a Multithreading section explaining issues with older sqlite versions, but still doesn't directly cover disabling check_same_thread beyond listing it as a possible parameter.

As far as I can tell, reusing sqlite connections in different threads (such as from a pool) is safe, as long as no attempt is made to use them from multiple threads with no locking.

----------
assignee: docs at python
components: Documentation
messages: 175946
nosy: docs at python, strcat
priority: normal
severity: normal
status: open
title: sqlite3 docs do not explain check_same_thread
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 19 09:27:04 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 19 Nov 2012 08:27:04 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1353313623.91.0.803075037942.issue13538@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Updating patch after Ezio's review on Rietveld.

----------
Added file: http://bugs.python.org/file28040/issue-13538-6-default.patch

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

From chris.jerdonek at gmail.com  Mon Nov 19 09:36:41 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Mon, 19 Nov 2012 08:36:41 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121119083641.2636.56909@psf.upfronthosting.co.za>


http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1264
Doc/library/functions.rst:1264: :meth:`object.__str__()
<object.__str__>`, which is the "informal" or nicely
I am writing out "object.__str__()" explicitly because it is important
that the rendered version show the invocation of the method.  Strictly
speaking, while Sphinx will render :meth:`object.__str__` the same way,
I want to make it clear that the final rendering matters in this case.

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

From ezio.melotti at gmail.com  Mon Nov 19 10:08:13 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 19 Nov 2012 09:08:13 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121119090813.2636.68990@psf.upfronthosting.co.za>

I added one more comment.
There are also a couple of my previous comments that have not been
addressed.  Did you just miss them or do you think that the original
form was already OK?


http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1268
Doc/library/functions.rst:1268: representation :func:`repr` of *object*.
This sentence doesn't sound too well.  Maybe "If *object* does not have
an :meth:`object.__str__` method, then :func:`str` falls back on calling
:meth:`object.__repr__`"?

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

From report at bugs.python.org  Mon Nov 19 10:16:15 2012
From: report at bugs.python.org (Kushal Das)
Date: Mon, 19 Nov 2012 09:16:15 +0000
Subject: [docs] [issue16493] Document the 'optimize' argument to compile()
In-Reply-To: <1353167567.95.0.716171753234.issue16493@psf.upfronthosting.co.za>
Message-ID: <1353316575.24.0.0900954970793.issue16493@psf.upfronthosting.co.za>


Kushal Das added the comment:

I guess somebody already did the work http://docs.python.org/3.4/library/functions.html?highlight=compile#compile ?

----------

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

From chris.jerdonek at gmail.com  Mon Nov 19 10:27:26 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Mon, 19 Nov 2012 09:27:26 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121119092726.2636.66037@psf.upfronthosting.co.za>

On 2012/11/19 10:08:13, ezio.melotti wrote:
> There are also a couple of my previous comments that have not been
addressed. 
> Did you just miss them or do you think that the original form was
already OK?

I read and thought about each comment.  In the cases where I kept the
original or made a different type of change, I believe you had a
question mark -- suggesting that you didn't feel strongly or weren't
sure yourself.  I can discuss those comments further if you would like. 
Let me know.


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

From report at bugs.python.org  Mon Nov 19 10:27:42 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Nov 2012 09:27:42 +0000
Subject: [docs] [issue16493] Document the 'optimize' argument to compile()
In-Reply-To: <1353167567.95.0.716171753234.issue16493@psf.upfronthosting.co.za>
Message-ID: <1353317262.06.0.982256953193.issue16493@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Looks like Georg did: 713c6b6ca5ce.
The documentation is missing on 2.7, but AFAICT that's because the arg is only in 3.2+.
Brett, if you meant that this should be documented somewhere else, feel free to reopen the issue.

----------
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

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

From chris.jerdonek at gmail.com  Mon Nov 19 10:28:44 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Mon, 19 Nov 2012 09:28:44 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121119092844.2636.97188@psf.upfronthosting.co.za>


http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1268
Doc/library/functions.rst:1268: representation :func:`repr` of *object*.
On 2012/11/19 10:08:13, ezio.melotti wrote:
> This sentence doesn't sound too well.  Maybe "If *object* does not
have an
> :meth:`object.__str__` method, then :func:`str` falls back on calling
> :meth:`object.__repr__`"?

I prefer saying what the function "returns" rather than what it "calls,"
because it is more to the point.  I also wanted to parallel the first
sentence.  By the way, it calls repr() (PyObject_Repr) rather than
object.__repr__().  Given that, can you suggest other wording you would
prefer?

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

From ezio.melotti at gmail.com  Mon Nov 19 10:50:02 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 19 Nov 2012 09:50:02 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121119095002.27722.70186@psf.upfronthosting.co.za>

I expanded my questions marks :)


http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1268
Doc/library/functions.rst:1268: representation :func:`repr` of *object*.
On 2012/11/19 10:28:44, cjerdonek wrote:
> On 2012/11/19 10:08:13, ezio.melotti wrote:
> > This sentence doesn't sound too well.  Maybe "If *object* does not
have an
> > :meth:`object.__str__` method, then :func:`str` falls back on
calling
> > :meth:`object.__repr__`"?
> 
> I prefer saying what the function "returns" rather than what it
"calls," because
> it is more to the point.  I also wanted to parallel the first
sentence.  By the
> way, it calls repr() (PyObject_Repr) rather than object.__repr__(). 
Given that,
> can you suggest other wording you would prefer?

The problem I have with this sentence is that it's not clear if the
subject is "representation" or "repr", so it sounds wrong.
New suggestion:
"If *object* does not have an :meth:`object.__str__` method, then
:func:`str` falls back to returning :meth:`repr(object) <repr>`."
There's no need to explain here what the repr is.  Also this might be
slightly inaccurate, because IIRC str() might make some other changes
after calling PyObject_Repr (but I haven't looked at the code).

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1277
Doc/library/functions.rst:1277: :class:`bytes` (or :class:`bytearray`)
object in this case, then
It's not clear to me what "in this case" means here.
If it means "in the case where the object is a bytes object", then it's
redundant and should be removed (hence my suggestion).
If it means "in the case where at least encoding or errors is given",
then it's not clear, and since the sentence is already in this paragraph
it shouldn't be necessary to specify it again.

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1285
Doc/library/functions.rst:1285: or *errors* arguments uses the first
mode of returning the informal string
I suggested to replace "mode" with "b.__str__()" because the term "mode"
suggests to me something that can be specified with a flag or similar. 
I wouldn't call any combination of args/kwargs a different "mode".
Another disadvantage of referring to first and second mode is that the
user has to keep track of what the two modes are, and while this is
arguably a trivial task, it's IMHO better to be explicit.  (I could go
more in detail if you want, but it's probably easier if we move the
discussion on IRC.)

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

From chris.jerdonek at gmail.com  Mon Nov 19 11:32:39 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Mon, 19 Nov 2012 10:32:39 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121119103239.2673.83152@psf.upfronthosting.co.za>


http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1268
Doc/library/functions.rst:1268: representation :func:`repr` of *object*.
Your new suggestion is fine.  Thanks.  Also, the code is here:

http://hg.python.org/cpython/file/cf606c403f14/Objects/object.c#l397

It just returns what PyObject_Repr returns.

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1277
Doc/library/functions.rst:1277: :class:`bytes` (or :class:`bytearray`)
object in this case, then
The latter was intended.  This may be clearer if "In this case" is at
the beginning of the sentence.  Without the phrase, it has an ambiguous
feeling to me.  The second sentence could be interpreted to be an
additional implication rather than a refinement of the previous
implication.  For example, the first sentence says that *object* needs
to be a bytes object.  The second sentence could then be saying what
happens for bytes objects, but in all cases.  That also seems like a
natural way of explaining something.

I also feel the extra clarity is deserved here because this point about
bytes is a source of confusion -- so much so that we added an extra
paragraph and example to clarify.  I realize that if the reader reads
the next paragraph, it will dispel the ambiguity we're discussing here,
but I think it's worth having the paragraph be unambiguous when read
alone.

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1285
Doc/library/functions.rst:1285: or *errors* arguments uses the first
mode of returning the informal string
I don't especially like the word "mode" either. :)  I was just keeping
with what was originally used in the first sentence of the str() docs. 
Why didn't you object to it there? :)

Can you suggest a rephrasing of the first sentence ("... using one of
the following two modes.") that allows us to use parallel phrasing in
the subsequent paragraphs?  I like telling the reader in advance that
there are two of "something" and because it parallels the two
signatures.  Also, saying first or second helps because then the reader
knows whether to look in the first or second of the two paragraphs
(without having to interpret the text and then map it to the
corresponding paragraph themselves).  Both may be best (number and
description).

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

From ezio.melotti at gmail.com  Mon Nov 19 11:50:05 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 19 Nov 2012 10:50:05 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121119105005.2673.41256@psf.upfronthosting.co.za>


http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1277
Doc/library/functions.rst:1277: :class:`bytes` (or :class:`bytearray`)
object in this case, then
On 2012/11/19 11:32:39, cjerdonek wrote:
> The latter was intended.  This may be clearer if "In this case" is at
the
> beginning of the sentence.  Without the phrase, it has an ambiguous
feeling to
> me.  The second sentence could be interpreted to be an additional
implication
> rather than a refinement of the previous implication.  For example,
the first
> sentence says that *object* needs to be a bytes object.  The second
sentence
> could then be saying what happens for bytes objects, but in all cases.
 That
> also seems like a natural way of explaining something.
> 
> I also feel the extra clarity is deserved here because this point
about bytes is
> a source of confusion -- so much so that we added an extra paragraph
and example
> to clarify.  I realize that if the reader reads the next paragraph, it
will
> dispel the ambiguity we're discussing here, but I think it's worth
having the
> paragraph be unambiguous when read alone.

Putting it at the beginning of the sentence sounds better.

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1285
Doc/library/functions.rst:1285: or *errors* arguments uses the first
mode of returning the informal string
On 2012/11/19 11:32:39, cjerdonek wrote:
> I don't especially like the word "mode" either. :)  I was just keeping
with what
> was originally used in the first sentence of the str() docs.  Why
didn't you
> object to it there? :)
> 

I don't like it there either, but here it has the additional problem
that you have to go back to find which one is the first mode.

> Can you suggest a rephrasing of the first sentence ("... using one of
the
> following two modes.") that allows us to use parallel phrasing in the
subsequent
> paragraphs?  I like telling the reader in advance that there are two
of
> "something" and because it parallels the two signatures.  Also, saying
first or
> second helps because then the reader knows whether to look in the
first or
> second of the two paragraphs (without having to interpret the text and
then map
> it to the corresponding paragraph themselves).  Both may be best
(number and
> description).

Maybe something similar to
"""
The behavior of str() depends on whether the encoding and errors args
are provided::
 * if they are not provided ...
 * if they are provided ...
"""

Then you can use "in the first case" instead of "the first mode". 
Another option is to put this in the first case directly, and say
something like "This is also valid for bytes, however the behavior is
different if encoding and errors are passed.
* if they are provided ..."

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

From chris.jerdonek at gmail.com  Mon Nov 19 12:01:09 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Mon, 19 Nov 2012 11:01:09 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121119110109.27722.23975@psf.upfronthosting.co.za>

Thanks.  I will make these changes tomorrow.

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

From chris.jerdonek at gmail.com  Mon Nov 19 12:52:42 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Mon, 19 Nov 2012 11:52:42 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121119115242.27722.69703@psf.upfronthosting.co.za>


http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6626/Doc/library/functions.rst#newcode1268
Doc/library/functions.rst:1268: representation :func:`repr` of *object*.
Incidentally, after discovering recently that the object type defines a
default implementation of object.__str__(), it's not clear to me when
this case can even arise.  Do you know?

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

From andrew.svetlov at gmail.com  Mon Nov 19 16:56:20 2012
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Mon, 19 Nov 2012 17:56:20 +0200
Subject: [docs] minor error in Tutorial section 4.4
In-Reply-To: <475012176.604.1352816607482.JavaMail.open-xchange@cal.bgc-jena.mpg.de>
References: <475012176.604.1352816607482.JavaMail.open-xchange@cal.bgc-jena.mpg.de>
Message-ID: <CAL3CFcUEMsL_zqeyG-HQCuhRtxVgwTgJP-aVF4A+gb5PyXHhKQ@mail.gmail.com>

Please note: in python 2 `print` is statement, starting from 3.0 it is function.
So tutorial is completely correct: compare
http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops
and http://docs.python.org/3/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops

On Tue, Nov 13, 2012 at 4:23 PM, Julia Marshall
<marshall at bgc-jena.mpg.de> wrote:
> Hello,
>
> this is really a small thing, but there's an inconsistency between the input
> and output in the second example (showing the "continue" statement) in
> section 4.4 of the tutorial.  The example reads as follows:
>
>
>>>> for num in range(2, 10):
> ...     if num % 2 == 0:
> ...         print("Found an even number", num)
> ...         continue
> ...     print("Found a number", num)
> Found an even number 2
> Found a number 3
> Found an even number 4
> Found a number 5
> Found an even number 6
> Found a number 7
> Found an even number 8
> Found a number 9
>
> and it should read like this:
>
>
>>>> for num in range(2, 10):
> ...     if num % 2 == 0:
> ...         print "Found an even number", num
> ...         continue
> ...     print "Found a number", num
> ...
> Found an even number 2
> Found a number 3
> Found an even number 4
> Found a number 5
> Found an even number 6
> Found a number 7
> Found an even number 8
> Found a number 9
>
>
> Otherwise there are unsightly parentheses and quotation marks in the output.
> I know this is really nit-picking, but the documentation is really good, so
> I figured it might as well be perfect. ;)
>
> Cheers,
>
> -Julia
>
> -------------------------------------------------------
> Julia Marshall, Ph.D.
> Max-Planck-Institut f?r Biogeochemie
> Hans-Kn?ll-Str. 10
> 07745 Jena
> Germany
>
> Tel.: +49 (36 41) 57 6383
> Fax.: +49 (36 41) 57 7300
> mobile.: +49 (176) 6433 2265
> email: marshall at bgc-jena.mpg.de
> http://www.bgc-jena.mpg.de/~marshall
> -------------------------------------------------------
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



-- 
Thanks,
Andrew Svetlov

From report at bugs.python.org  Tue Nov 20 03:16:15 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 20 Nov 2012 02:16:15 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1353377774.6.0.760328537274.issue13538@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Attaching new patch to address Ezio's further comments (for the convenience of comparing in Rietveld).  I will be committing this.

----------
Added file: http://bugs.python.org/file28045/issue-13538-7-default.patch

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

From report at bugs.python.org  Tue Nov 20 05:13:17 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 20 Nov 2012 04:13:17 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1353384797.49.0.310734763645.issue13538@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I left a few remarks.  The patch is very nice, thanks!

----------

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

From report at bugs.python.org  Tue Nov 20 05:44:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 20 Nov 2012 04:44:36 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1353386676.81.0.594316194567.issue13538@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks, ?ric!  (And thanks also to Ezio who helped quite a bit with the improvements.)  I replied to your comments on Rietveld.

----------

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

From report at bugs.python.org  Tue Nov 20 08:39:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 20 Nov 2012 07:39:47 +0000
Subject: [docs] [issue16508] include the "object" type in the lists of
	documented	types
In-Reply-To: <1353284081.12.0.684350303879.issue16508@psf.upfronthosting.co.za>
Message-ID: <1353397187.31.0.892283565869.issue16508@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
assignee: docs at python -> chris.jerdonek

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

From andrew.svetlov at gmail.com  Tue Nov 20 15:14:27 2012
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Tue, 20 Nov 2012 16:14:27 +0200
Subject: [docs] docs bug
In-Reply-To: <CAAj=Cf-s7eUbz6jM9AB-pvK9Dxex+gUvO_XA3se-xE=jwWOVyg@mail.gmail.com>
References: <CAAj=Cf-s7eUbz6jM9AB-pvK9Dxex+gUvO_XA3se-xE=jwWOVyg@mail.gmail.com>
Message-ID: <CAL3CFcViv+8L_erVVDwGWArPDE9jCf4h6R=q9oeV_mFJY+oC8Q@mail.gmail.com>

Fixed, thanks.

On Sat, Nov 17, 2012 at 10:12 PM, Dmitry Tolstoy <ertymail at gmail.com> wrote:
> http://docs.python.org/3.3/library/multiprocessing.html
>
> if __name__ == '__main__':
>     with Pool(processes=4) as pool         # start 4 worker processes
>
>
> Must be:
>
> if __name__ == '__main__':
>     with Pool(processes=4) as pool:         # start 4 worker processes
>
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



-- 
Thanks,
Andrew Svetlov

From report at bugs.python.org  Wed Nov 21 02:56:13 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Nov 2012 01:56:13 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <3Y5n223lp5zPt0@mail.python.org>


Roundup Robot added the comment:

New changeset f32f1cb508ad by Chris Jerdonek in branch '3.2':
Improve str() and object.__str__() documentation (issue #13538).
http://hg.python.org/cpython/rev/f32f1cb508ad

New changeset 6630a1c42204 by Chris Jerdonek in branch '3.3':
Null merge from 3.2 (issue #13538).
http://hg.python.org/cpython/rev/6630a1c42204

New changeset 325f80d792b9 by Chris Jerdonek in branch '3.3':
Improve str() and object.__str__() documentation (issue #13538).
http://hg.python.org/cpython/rev/325f80d792b9

New changeset 59acd5cac8b5 by Chris Jerdonek in branch 'default':
Merge from 3.3: Improve str() and object.__str__() docs (issue #13538).
http://hg.python.org/cpython/rev/59acd5cac8b5

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

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

From report at bugs.python.org  Wed Nov 21 03:17:59 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 21 Nov 2012 02:17:59 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1353464279.85.0.288565234495.issue13538@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


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

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

From report at bugs.python.org  Wed Nov 21 07:03:27 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 21 Nov 2012 06:03:27 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
Message-ID: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add "buffer protocol" (or perhaps "buffer object") to the glossary.  The concept is currently described here:

http://docs.python.org/dev/c-api/buffer.html#buffer-protocol

?ric initially suggested doing this in the comments to issue 13538.

Such a glossary entry would be useful because the buffer protocol (or buffer object) should likely be cited, for example, wherever a function accepts a bytes object, bytearray object, or any object that supports the buffer protocol.  The str() constructor is one example where this is done:

http://hg.python.org/cpython/file/59acd5cac8b5/Doc/library/functions.rst#l1275

"Buffer object" might be the more useful term to add to the glossary because it would help to have a briefer way of saying "any object that supports the buffer protocol."  (I'm assuming this is what "buffer object" actually means.)

The patch for this issue should also do a comprehensive review of occurrences of buffer object/protocol throughout the docs and add or update links and index entries where appropriate.

----------
assignee: docs at python
components: Documentation
messages: 176042
nosy: chris.jerdonek, docs at python, eric.araujo, ezio.melotti, pitrou
priority: normal
severity: normal
status: open
title: add "buffer protocol" to glossary
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 21 13:49:06 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 21 Nov 2012 12:49:06 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1353502145.89.0.456188274253.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Here is a proposed patch just to get the ball rolling on this.

Note that I'm proposing that we let ourselves use the word "standard" in place of "positional-or-keyword" when talking about parameters.  This is partly inspired by PEP 362, which says, "Parameter.POSITIONAL_OR_KEYWORD ... this is the standard binding behaviour for functions implemented in Python."

This patch only takes an initial crack at the glossary entries.  Once these are fleshed out, we can add additional :term: links and index directives.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28061/issue-15990-1-default.patch

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

From report at bugs.python.org  Wed Nov 21 14:38:32 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Nov 2012 13:38:32 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <3Y64cR0jSqzRPk@mail.python.org>


Roundup Robot added the comment:

New changeset 5c39e3906ce9 by Chris Jerdonek in branch '3.2':
Fix label in docs (from issue #13538).
http://hg.python.org/cpython/rev/5c39e3906ce9

----------

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

From report at bugs.python.org  Wed Nov 21 16:16:06 2012
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Nov 2012 15:16:06 +0000
Subject: [docs] [issue16523] attrgetter and itemgetter signatures in docs
	need cleanup
Message-ID: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za>


New submission from R. David Murray:

It looks like the use of the 'args' formal parameter was cut and pasted from the methodcaller docs, when it is not appropriate for itemgetter and attrgetter.

     http://docs.python.org/3/library/operator.html#operator.attrgetter

----------
assignee: docs at python
components: Documentation
messages: 176060
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: attrgetter and itemgetter signatures in docs need cleanup
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 21 16:18:09 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 21 Nov 2012 15:18:09 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1353511089.03.0.786326520551.issue15990@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

On one hand it's good to have individual entries that can be referenced.
On the other hand I think it's important that people get the full picture, and having these definitions sparse in 4 or more distinct glossary entries doesn't help IMHO -- even if the reader follows all the cross-links.

I think it would be better to have a single entry somewhere (e.g. in the FAQs -- maybe it's too "advanced" for the tutorial), that:
  * explains the difference between arguments (what you pass) and parameters (what the function accepts);
  * lists the 5 kinds of parameters, providing an example for each;
  * lists the 2 kinds of arguments, providing an example for each;

I see 3 options here:
  1) we make this section and keep stub entries that link to it;
  2) we repeat the informations in both places (section and entries);
  3) we just keep the glossary entries;

If we pick 1 people might have to follow one more link.  Having a single "parameters and arguments" entry in the glossary might make this better by avoiding a redirect.
If we pick 2 there's duplication, and that's bad.
If we pick 3 I think we could at least explain the kinds of arguments in the "argument" entry and having stubs for "keyword args" and "positional args".  This will leave us with only two entries ("argument" and "parameter"), and with the initial problem that we don't know where to put the explanation of the difference between the two (in both? in a new entry? somewhere else? no parallel?).

----------

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

From report at bugs.python.org  Wed Nov 21 16:31:10 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Nov 2012 15:31:10 +0000
Subject: [docs] [issue16523] attrgetter and itemgetter signatures in docs
	need cleanup
In-Reply-To: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za>
Message-ID: <1353511870.31.0.522996881894.issue16523@psf.upfronthosting.co.za>


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


----------
keywords: +easy

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

From report at bugs.python.org  Thu Nov 22 03:08:18 2012
From: report at bugs.python.org (Kiet Tran)
Date: Thu, 22 Nov 2012 02:08:18 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1353550098.74.0.0399039219713.issue16438@psf.upfronthosting.co.za>


Kiet Tran added the comment:

I was trying to fix this, but I ran into a couple questions.

1) Once I put, say, "x + y" and "x - y" into the same table cell, what would a good format be? My preferred format is to have them on separate lines in the cell, but after a lot of googling on the syntax of reST (and trials and errors), I'm still unable to figure out how to do it. Using bullet points would mean I have to align elements in the "Notes" column with the ones in the "Operation" column somehow. Alternatively, I can separate them by comma, but the table would look a bit cluttered.

2) Should the functions abs, int, etc., belong in the same table that's meant to list operators by precedence?

----------
nosy: +ktt3ja

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

From report at bugs.python.org  Thu Nov 22 03:30:09 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 22 Nov 2012 02:30:09 +0000
Subject: [docs] [issue16528] 3.2 docs not updating on docs.python.org
Message-ID: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The 3.2 docs haven't updated since Oct 28, 2012:

http://docs.python.org/3.2/

The commits for the Doc folder around that time are as follows.  I observed that the top commit was not built, but I'm not sure about the ones previous:

$ hg log -b 3.2 Doc | more

changeset:   80018:40aedc7da30f
branch:      3.2
parent:      79798:16493102f9b1
user:        Andrew Svetlov <andrew.svetlov at gmail.com>
date:        Sun Oct 28 14:10:30 2012 +0200
summary:     Issue #14570: Document json sort_keys parameter properly.

changeset:   79996:e02d49db3f5b
branch:      3.2
parent:      79989:f6d04f5cff31
user:        Georg Brandl <georg at python.org>
date:        Sun Oct 28 07:59:42 2012 +0100
summary:     #8040: fix jQuery incompatibility

changeset:   79984:36a35b86e3b0
branch:      3.2
parent:      79980:740be7346c92
user:        Ezio Melotti <ezio.melotti at gmail.com>
date:        Sat Oct 27 23:12:48 2012 +0300
summary:     #8040: fix the version.

changeset:   79980:740be7346c92
branch:      3.2
parent:      79976:35a2a0e166d0
user:        Ezio Melotti <ezio.melotti at gmail.com>
date:        Sat Oct 27 22:28:48 2012 +0300
summary:     #8040: enable the versionswitcher for the autobuild-dev target.

changeset:   79976:35a2a0e166d0
branch:      3.2
parent:      79972:abbfb89055d3
user:        Ezio Melotti <ezio.melotti at gmail.com>
date:        Sat Oct 27 22:09:16 2012 +0300
summary:     #8040: add a version switcher to the documentation.  Patch by Yury Selivanov.

----------
assignee: docs at python
components: Documentation
messages: 176090
nosy: chris.jerdonek, docs at python, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: 3.2 docs not updating on docs.python.org
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov 22 03:49:23 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Nov 2012 02:49:23 +0000
Subject: [docs] [issue16528] 3.2 docs not updating on docs.python.org
In-Reply-To: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>
Message-ID: <1353552563.33.0.19025606757.issue16528@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is intentional.  Only 2.7, 3.3, and 3.4 auto-update now that 3.3 is out.  There will be a final rebuild of the 3.2 docs when 3.2 final is released.

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

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

From report at bugs.python.org  Thu Nov 22 03:50:58 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 22 Nov 2012 02:50:58 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1353552657.88.0.13288466691.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I like option (3).  I attached a new patch using this approach.

As suggested, I made the glossary entries for "keyword argument" and "positional argument" into stubs.  So now there are just two substantive entries: one for "argument" and one for "parameter."  I also included in the parameter entry an example for each of the five parameter types.

----------
Added file: http://bugs.python.org/file28069/issue-15990-2-default.patch

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

From report at bugs.python.org  Thu Nov 22 03:54:23 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 22 Nov 2012 02:54:23 +0000
Subject: [docs] [issue16528] 3.2 docs not updating on docs.python.org
In-Reply-To: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>
Message-ID: <1353552863.05.0.0902955033723.issue16528@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks for the info.  Is this information reflected somewhere online?

----------

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

From report at bugs.python.org  Thu Nov 22 05:58:29 2012
From: report at bugs.python.org (Todd Rovito)
Date: Thu, 22 Nov 2012 04:58:29 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1353560309.23.0.116800287919.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Attached is patch with the final formatting for the documentation updates. I fixed the :exc:`OSError` problems that I had before and used indents to denote Unix behavior VS Windows behavior. Please let me know if I can do anything else to help get this issue resolved.  Thanks!

----------
Added file: http://bugs.python.org/file28071/OSRenameDocs3point4.patch

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

From report at bugs.python.org  Thu Nov 22 06:00:35 2012
From: report at bugs.python.org (Todd Rovito)
Date: Thu, 22 Nov 2012 05:00:35 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1353560435.16.0.54130229234.issue16278@psf.upfronthosting.co.za>


Changes by Todd Rovito <rovitotv at gmail.com>:


Removed file: http://bugs.python.org/file27640/OSRenameTest3point4.patch

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

From report at bugs.python.org  Thu Nov 22 06:15:34 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Nov 2012 05:15:34 +0000
Subject: [docs] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s?=
 =?utf-8?q?_new_opener_argument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <3Y6TPd2Gf1zQ7y@mail.python.org>


Roundup Robot added the comment:

New changeset bf1bf3bf3fe2 by ?ric Araujo in branch '3.3':
Address reviews for open?s opener argument doc patch (#13424).
http://hg.python.org/cpython/rev/bf1bf3bf3fe2

New changeset 8ca6f4953c4b by ?ric Araujo in branch 'default':
Merge #13424 followup from 3.3
http://hg.python.org/cpython/rev/8ca6f4953c4b

----------

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

From report at bugs.python.org  Thu Nov 22 06:17:30 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 22 Nov 2012 05:17:30 +0000
Subject: [docs] =?utf-8?q?=5Bissue13424=5D_Add_examples_for_open=E2=80=99s?=
 =?utf-8?q?_new_opener_argument?=
In-Reply-To: <1321609933.89.0.531165464334.issue13424@psf.upfronthosting.co.za>
Message-ID: <1353561450.12.0.377658895395.issue13424@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks for all comments.  If you think of a better example to show the usage of the argument, feel free to change it.

----------
assignee: docs at python -> eric.araujo
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Nov 22 07:03:08 2012
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 22 Nov 2012 06:03:08 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1353564188.76.0.751117342755.issue16438@psf.upfronthosting.co.za>


Yongzhi Pan added the comment:

One possible solution:

We do not list priorities of the operations, instead link to the precedence table in the language reference.

----------

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

From report at bugs.python.org  Thu Nov 22 12:29:27 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Nov 2012 11:29:27 +0000
Subject: [docs] [issue16528] 3.2 docs not updating on docs.python.org
In-Reply-To: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>
Message-ID: <1353583767.51.0.916269092395.issue16528@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't know.  If it is would be in wherever "documenting Python" is these days.  The policy is that only the versions in active maintenance are automatically rebuilt.  3.2 is technically no longer in maintenance, it's just that there are reasons that we are delaying the final release. But I remember Georg answering this question on one forum or another, saying that the switch in which versions get built happens when the new version's pages move from default to release.  (So, it is always somewhat before the final release of the previous maintenance version.)

----------

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

From report at bugs.python.org  Thu Nov 22 16:21:46 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Nov 2012 15:21:46 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1353597706.55.0.997971498797.issue15990@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I modified the last patch to use bullet lists and include more examples, and also added a FAQ entry to explain the difference between args and parameters.
I'll leave further comments on rietveld.

----------
nosy: +eric.araujo
Added file: http://bugs.python.org/file28073/issue-15990-3-default.patch

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

From ezio.melotti at gmail.com  Thu Nov 22 16:38:14 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Thu, 22 Nov 2012 15:38:14 -0000
Subject: [docs] solidify argument/parameter terminology (issue 15990)
Message-ID: <20121122153814.28387.16777@psf.upfronthosting.co.za>


http://bugs.python.org/review/15990/diff/6650/Doc/faq/programming.rst
File Doc/faq/programming.rst (right):

http://bugs.python.org/review/15990/diff/6650/Doc/faq/programming.rst#newcode324
Doc/faq/programming.rst:324: we can say that *foo*, *bar* and *kwargs*
are :term:`parameter`\s of
If we use the plural forms for the glossary entries we won't need the
\s.

http://bugs.python.org/review/15990/diff/6650/Doc/faq/programming.rst#newcode336
Doc/faq/programming.rst:336: How do I write a function with output
parameters (call by reference)?
Not sure this should be called "parameters" :)

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode52
Doc/glossary.rst:52: * keyword arguments: values passed by keyword and
assigned to the local
Is "passed by keyword" an acceptable terminology?
Should I add "(e.g. ``keyword=value``) or is it clear from the other
example?

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode55
Doc/glossary.rst:55: A dictionary preceded by ``**`` can also be used to
pass a mapping of
IIRC there were some problems with arbitrary mappings, so I'm not sure
if here "dictionary" should be replaced with "mapping".

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode62
Doc/glossary.rst:62: variables.  Also see the :term:`parameter` glossary
entry and :pep:`362`.
This should link to the FAQ.

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode561
Doc/glossary.rst:561: function can accept.  There are five types of
paramters:
The first sentence is a bit confusing IMHO.
It talks about named entities and function signatures (reader might not
know what they are), and argument and collections of arguments (might
add confusion between parameters/arguments).
OTOH it's difficult to come up with a different wording.
One thing that can be improved is using "defines" instead of
"corresponds", but that would require to pluralize the term and use
something like:
parameters
  Named entities in a function (or method) signature that
  define what :term:`arguments` the function can accept.

Using the plural form might be better if :term:`parameters` is more
common than :term:`parameter`.

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode561
Doc/glossary.rst:561: function can accept.  There are five types of
paramters:
I made a typo: s/paramters/parameters/.
Also here I used "types", whereas in the "argument" entry I used
"kinds".  This should be fixed (I think I prefer "types").

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode579
Doc/glossary.rst:579: function signature (e.g. *args* in ``def
func(*args, **kwargs): ...``).
I was going to use *\*args*, but the actual parameter is only *args*,
same for kwargs/**kwargs in the next example.

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode583
Doc/glossary.rst:583: signature (e.g. *kwargs* in ``def func(*args,
**kwargs): ...``).
This definitions are adapted from the ones in PEP 362.

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode583
Doc/glossary.rst:583: signature (e.g. *kwargs* in ``def func(*args,
**kwargs): ...``).
Do we need an entry for function signature?

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode587
Doc/glossary.rst:587: :pep:`362`.
This should link to the FAQ.

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

From report at bugs.python.org  Thu Nov 22 17:28:58 2012
From: report at bugs.python.org (George Yoshida)
Date: Thu, 22 Nov 2012 16:28:58 +0000
Subject: [docs] [issue16530] documentation of os.wait3
Message-ID: <1353601738.51.0.504098475316.issue16530@psf.upfronthosting.co.za>


New submission from George Yoshida:

Documentation defines os.wait3 function as :
> os.wait3([options])
but, this argument is required(no default options are set), so
> os.wait3(options)
is the correct definition.

http://docs.python.org/3.3/library/os.html#os.wait3

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 176112
nosy: docs at python, quiver
priority: low
severity: normal
status: open
title: documentation of os.wait3
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov 22 18:04:11 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Nov 2012 17:04:11 +0000
Subject: [docs] [issue16528] 3.2 docs not updating on docs.python.org
In-Reply-To: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>
Message-ID: <1353603851.43.0.385234605758.issue16528@psf.upfronthosting.co.za>


Georg Brandl added the comment:

That's correct.  "Documenting Python" is in the devguide now; feel free to remark this somewhere.

----------

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

From report at bugs.python.org  Thu Nov 22 18:50:42 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 22 Nov 2012 17:50:42 +0000
Subject: [docs] [issue16528] 3.2 docs not updating on docs.python.org
In-Reply-To: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>
Message-ID: <1353606642.09.0.728193227791.issue16528@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> The policy is that only the versions in active maintenance are automatically rebuilt.  3.2 is technically no longer in maintenance, it's just that there are reasons that we are delaying the final release.

Okay, below the devguide says it is still in maintenance.  Should that be changed?

  "There are 6 open branches right now in the Mercurial repository:

   * the default branch holds the future 3.4 version and descends from 3.3
   * the 3.3 branch holds bug fixes for future 3.3.x maintenance releases and descends from 3.2
   * the 3.2 branch holds bug fixes for an upcoming final 3.2.4 maintenance release and then for future 3.2.x security releases
   * the 3.1 branch holds security fixes for future 3.1.x security releases
   ..."

(from http://docs.python.org/devguide/devcycle.html#summary )

Perhaps that was the source of confusion for me.  I was wondering if there was some other policy about when not to rebuild branches still in maintenance mode.  But given that it's not really in maintenance mode any longer, that answers my question.

----------

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

From report at bugs.python.org  Thu Nov 22 19:20:46 2012
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Nov 2012 18:20:46 +0000
Subject: [docs] [issue16528] 3.2 docs not updating on docs.python.org
In-Reply-To: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>
Message-ID: <1353608446.16.0.341551814325.issue16528@psf.upfronthosting.co.za>


Georg Brandl added the comment:

3.2 is still in maintenance, but the docs are not rebuilt daily for any past stable version, whether they are in maintenance or not.

Maybe it's not such a big deal at all?

----------

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

From report at bugs.python.org  Thu Nov 22 19:31:02 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 22 Nov 2012 18:31:02 +0000
Subject: [docs] [issue16528] 3.2 docs not updating on docs.python.org
In-Reply-To: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>
Message-ID: <1353609062.55.0.779049508756.issue16528@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

It's not.  Thanks for the clarification and info.

----------

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

From report at bugs.python.org  Thu Nov 22 19:44:51 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 22 Nov 2012 18:44:51 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1353609891.31.0.302702900469.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I have a number of comments but it is a holiday this weekend so I might not be able to get to it for a day or two.

----------

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

From report at bugs.python.org  Thu Nov 22 22:33:24 2012
From: report at bugs.python.org (Kiet Tran)
Date: Thu, 22 Nov 2012 21:33:24 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1353620004.71.0.0022671867447.issue16438@psf.upfronthosting.co.za>


Kiet Tran added the comment:

Good idea.

----------
keywords: +patch
Added file: http://bugs.python.org/file28075/16438.patch

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

From report at bugs.python.org  Fri Nov 23 00:06:48 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Nov 2012 23:06:48 +0000
Subject: [docs] [issue15474] Differentiate decorator and decorator factory
	in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1353625608.98.0.380458187768.issue15474@psf.upfronthosting.co.za>


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


----------
nosy: +chris.jerdonek

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

From report at bugs.python.org  Fri Nov 23 00:20:49 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Nov 2012 23:20:49 +0000
Subject: [docs] [issue15474] Differentiate decorator and decorator factory
	in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1353626448.98.0.91127425084.issue15474@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The tutorial doesn't seem to mention decorators, do you think this should be covered there?
FWIW while explaining decorators I usually use 3 examples:
 1) a simple decorator that accepts a function, does something, and returns the same function;
 2) a decorator that defines and returns an inner function;
 3) a decorator factory, that defines two nested inner functions

Not sure if it's necessary to include the first example though.

----------

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

From report at bugs.python.org  Fri Nov 23 03:52:13 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 23 Nov 2012 02:52:13 +0000
Subject: [docs] [issue15474] Differentiate decorator and decorator factory
	in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1353639133.75.0.503597468163.issue15474@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

No, using decorators needs to be in the tutorial, but writing your own is a metaprogramming task that's beyond the tutorial's scope.

A HOWTO guide would be appropriate, though.

----------

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

From report at bugs.python.org  Fri Nov 23 14:09:19 2012
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 23 Nov 2012 13:09:19 +0000
Subject: [docs] [issue16538] The docs doesn't describe MAKE_CLOSURE correctly
Message-ID: <1353676159.67.0.844924036734.issue16538@psf.upfronthosting.co.za>


New submission from Daniel Urban:

The documentation of the dis module describes the MAKE_CLOSURE opcode incorrectly. The description of MAKE_FUNCTION was updated in 242d3f8e8c50 (issue14349) to include the qualified name, but MAKE_CLOSURE wan't. A patch is attched.

----------
assignee: docs at python
components: Documentation
files: make_closure.patch
keywords: needs review, patch
messages: 176166
nosy: daniel.urban, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: The docs doesn't describe MAKE_CLOSURE correctly
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28086/make_closure.patch

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

From report at bugs.python.org  Fri Nov 23 14:29:59 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Nov 2012 13:29:59 +0000
Subject: [docs] [issue16538] The docs doesn't describe MAKE_CLOSURE correctly
In-Reply-To: <1353676159.67.0.844924036734.issue16538@psf.upfronthosting.co.za>
Message-ID: <3Y7JKf2brHzQNb@mail.python.org>


Roundup Robot added the comment:

New changeset 5d1e7912e23e by Andrew Svetlov in branch '3.3':
Issue #16538: correctly describe MAKE_CLOSURE in docs.
http://hg.python.org/cpython/rev/5d1e7912e23e

New changeset 8fff40a7c5b5 by Andrew Svetlov in branch 'default':
Merge issue #16538: correctly describe MAKE_CLOSURE in docs.
http://hg.python.org/cpython/rev/8fff40a7c5b5

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

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

From report at bugs.python.org  Fri Nov 23 14:30:36 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 23 Nov 2012 13:30:36 +0000
Subject: [docs] [issue16538] The docs doesn't describe MAKE_CLOSURE correctly
In-Reply-To: <1353676159.67.0.844924036734.issue16538@psf.upfronthosting.co.za>
Message-ID: <1353677436.43.0.62883683236.issue16538@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed. Thanks.

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

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

From report at bugs.python.org  Fri Nov 23 18:16:44 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Nov 2012 17:16:44 +0000
Subject: [docs] [issue16508] include the "object" type in the lists of
	documented	types
In-Reply-To: <1353284081.12.0.684350303879.issue16508@psf.upfronthosting.co.za>
Message-ID: <1353691004.04.0.697338493031.issue16508@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch

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

From report at bugs.python.org  Fri Nov 23 18:18:16 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Nov 2012 17:18:16 +0000
Subject: [docs] [issue16509] sqlite3 docs do not explain check_same_thread
In-Reply-To: <1353310851.97.0.745365364193.issue16509@psf.upfronthosting.co.za>
Message-ID: <1353691096.29.0.745841996124.issue16509@psf.upfronthosting.co.za>


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


----------
nosy: +ghaering
stage:  -> needs patch
versions: +Python 3.2, Python 3.4

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

From report at bugs.python.org  Fri Nov 23 18:19:13 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Nov 2012 17:19:13 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353691153.96.0.80940098362.issue16518@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch

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

From report at bugs.python.org  Fri Nov 23 18:41:39 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Nov 2012 17:41:39 +0000
Subject: [docs] [issue16523] attrgetter and itemgetter signatures in docs
	need cleanup
In-Reply-To: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za>
Message-ID: <1353692499.36.0.544413506591.issue16523@psf.upfronthosting.co.za>


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


----------
keywords: +patch
nosy: +chris.jerdonek
stage: needs patch -> patch review
versions: +Python 3.2
Added file: http://bugs.python.org/file28089/issue16523.diff

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

From report at bugs.python.org  Fri Nov 23 18:47:02 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Nov 2012 17:47:02 +0000
Subject: [docs] [issue16530] documentation of os.wait3
In-Reply-To: <1353601738.51.0.504098475316.issue16530@psf.upfronthosting.co.za>
Message-ID: <3Y7Q2F5yYwzRHt@mail.python.org>


Roundup Robot added the comment:

New changeset a2038edb51cd by Ezio Melotti in branch '2.7':
#16530: the "options" arg of os.wait3 is required.
http://hg.python.org/cpython/rev/a2038edb51cd

New changeset 1cf1194a443e by Ezio Melotti in branch '3.2':
#16530: the "options" arg of os.wait3 is required.
http://hg.python.org/cpython/rev/1cf1194a443e

New changeset 7359ade2ab0b by Ezio Melotti in branch '3.3':
#16530: merge with 3.2.
http://hg.python.org/cpython/rev/7359ade2ab0b

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

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

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

From report at bugs.python.org  Fri Nov 23 18:47:33 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Nov 2012 17:47:33 +0000
Subject: [docs] [issue16530] documentation of os.wait3
In-Reply-To: <1353601738.51.0.504098475316.issue16530@psf.upfronthosting.co.za>
Message-ID: <1353692852.99.0.747123580555.issue16530@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
versions:  -Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Nov 23 18:58:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 23 Nov 2012 17:58:20 +0000
Subject: [docs] [issue16523] attrgetter and itemgetter signatures in docs
	need cleanup
In-Reply-To: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za>
Message-ID: <1353693500.81.0.114462951814.issue16523@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

+.. function:: attrgetter(attr[, attr2, attr3, ...])

Why not reword to use the *attr notation?  It is even already being used below:

+   The function is equivalent to::
 
       def attrgetter(*items):
           if any(not isinstance(item, str) for item in items):

----------

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

From report at bugs.python.org  Fri Nov 23 19:05:01 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Nov 2012 18:05:01 +0000
Subject: [docs] [issue16523] attrgetter and itemgetter signatures in docs
	need cleanup
In-Reply-To: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za>
Message-ID: <1353693901.62.0.0385224325456.issue16523@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I thought about that, but wanted to make a distinction between the form that accepts only 1 arg and returns an item and the form that receives 2+ args and returns a tuple.

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

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

From report at bugs.python.org  Fri Nov 23 19:27:48 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 23 Nov 2012 18:27:48 +0000
Subject: [docs] [issue16523] attrgetter and itemgetter signatures in docs
	need cleanup
In-Reply-To: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za>
Message-ID: <1353695267.99.0.915531096709.issue16523@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

You can also make that distinction using *.  For example:

.. function:: attrgetter(attr, *attrs)

or

.. function:: attrgetter(attr)
              attrgetter(attr1, attr2, *attrs)

(cf. http://docs.python.org/dev/library/functions.html#max )

Elsewhere we started to prefer using two signature lines where two or more "behaviors" are possible, which might be good to do in any case.  With the "..." notation, this would look like:

.. function:: attrgetter(attr)
              attrgetter(attr1, attr2, ...)

----------

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

From report at bugs.python.org  Fri Nov 23 19:38:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Nov 2012 18:38:38 +0000
Subject: [docs] [issue16528] 3.2 docs not updating on docs.python.org
In-Reply-To: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>
Message-ID: <3Y7R9n1Wc4zRMj@mail.python.org>


Roundup Robot added the comment:

New changeset 31bb42754962 by Chris Jerdonek in branch 'default':
Clarify that only the latest maintenance branches are rebuilt (issue #16528).
http://hg.python.org/devguide/rev/31bb42754962

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

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

From report at bugs.python.org  Fri Nov 23 19:40:23 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 23 Nov 2012 18:40:23 +0000
Subject: [docs] [issue16528] 3.2 docs not updating on docs.python.org
In-Reply-To: <1353551409.71.0.725216455531.issue16528@psf.upfronthosting.co.za>
Message-ID: <1353696023.7.0.726477905666.issue16528@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
keywords: +easy
resolution: invalid -> fixed
type: behavior -> enhancement

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

From report at bugs.python.org  Fri Nov 23 21:11:17 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Nov 2012 20:11:17 +0000
Subject: [docs] [issue16508] include the "object" type in the lists of
	documented	types
In-Reply-To: <1353284081.12.0.684350303879.issue16508@psf.upfronthosting.co.za>
Message-ID: <1353701477.42.0.359773592617.issue16508@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

good idea

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

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

From report at bugs.python.org  Fri Nov 23 21:16:02 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Nov 2012 20:16:02 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353701762.08.0.395654564732.issue16518@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I would use the term that is currently used in some error messages.

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

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

From report at bugs.python.org  Fri Nov 23 21:20:32 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 23 Nov 2012 20:20:32 +0000
Subject: [docs] [issue16544] Add external link to ast docs
Message-ID: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

http://greentreesnakes.readthedocs.org/en/latest/index.html
is excellent and comprehensive documentation for ast tree structures.
It would be nice to incorporate that docs into stdlib documentation, but adding *see also* section is good enoigh as first step.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 176239
nosy: asvetlov, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Add external link to ast docs
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 23 21:23:46 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Nov 2012 20:23:46 +0000
Subject: [docs] [issue16544] Add external link to ast docs
In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za>
Message-ID: <1353702226.77.0.0892332470896.issue16544@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I would suggest to contact the author and ask him if he wants to contribute those docs to Python.  They could be then be merged to the current docs or included as a separate HOWTO.

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

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

From report at bugs.python.org  Fri Nov 23 21:26:14 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Nov 2012 20:26:14 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353702374.09.0.930065244331.issue16518@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

"Buffer protocol" is the right term. "Buffer object" doesn't mean anything in Python 3 and, furthermore, it might be mixed up with the Python 2 `buffer` type.

As for the error messages, they are generally very bad on this topic, so I would vote to change them :-)

----------

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

From report at bugs.python.org  Fri Nov 23 21:28:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 23 Nov 2012 20:28:29 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353702509.07.0.885628848998.issue16518@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Do we have a recommended (and preferably briefer) way of saying, "any object that supports the buffer protocol"?

----------

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

From report at bugs.python.org  Fri Nov 23 21:29:03 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 23 Nov 2012 20:29:03 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353702543.87.0.950105877324.issue16518@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

s/any//

----------

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

From report at bugs.python.org  Fri Nov 23 21:30:44 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Nov 2012 20:30:44 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353702644.92.0.989432698637.issue16518@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> "Buffer object" doesn't mean anything in Python 3 and, furthermore,
> it might be mixed up with the Python 2 `buffer` type.

Agreed.

> As for the error messages, they are generally very bad on this topic,
> so I would vote to change them :-)

I would say that they are verbose maybe, but not necessary bad.
Using "any object that supports the buffer protocol" without explicitly mentioning bytes (and bytearray) might end up being even more confusing (if that's what it's being proposed).

----------

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

From report at bugs.python.org  Fri Nov 23 21:32:34 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Nov 2012 20:32:34 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353702509.07.0.885628848998.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353702697.3343.2.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Do we have a recommended (and preferably briefer) way of saying, "any
> object that supports the buffer protocol"?

It depends where. There's no recommended way yet, but I would vote for
"bytes-like object" in error messages that are targetted at the average
developer.

The docs (glossary?) could explain that "bytes-like object" is the same
as "buffer-providing object" or "object implementing the buffer
protocol".

----------

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

From report at bugs.python.org  Fri Nov 23 21:33:42 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Nov 2012 20:33:42 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353702822.62.0.0795732948105.issue16518@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I would vote for "bytes-like object"

Sounds like a good compromise between brevity and clarity to me.

----------

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

From report at bugs.python.org  Fri Nov 23 21:36:54 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 23 Nov 2012 20:36:54 +0000
Subject: [docs] [issue16544] Add external link to ast docs
In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za>
Message-ID: <1353703014.15.0.936692211422.issue16544@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

I've done it just now sending him message via bitbucket.

----------

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

From report at bugs.python.org  Fri Nov 23 21:49:25 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 23 Nov 2012 20:49:25 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353703765.27.0.369159029402.issue16518@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I wouldn't use "bytes-like object". One can certainly argue that *memoryview*
should be bytes-like as a matter of preference, but the buffer protocol
specifies strongly (or even statically) typed multi-dimensional arrays.

PEP-3118 Py_buffer structs are essentially how NumPy works internally.

----------
nosy: +skrah

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

From report at bugs.python.org  Fri Nov 23 21:58:44 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Nov 2012 20:58:44 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353703765.27.0.369159029402.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353704267.3343.3.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> I wouldn't use "bytes-like object". One can certainly argue that *memoryview*
> should be bytes-like as a matter of preference, but the buffer protocol
> specifies strongly (or even statically) typed multi-dimensional arrays.

Ach :-(

> PEP-3118 Py_buffer structs are essentially how NumPy works internally.

Well, we should still write a Python documentation, not a NumPy
documentation (on this tracker anyway). Outside of NumPy, there's little
use for multi-dimensional objects.

----------

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

From report at bugs.python.org  Fri Nov 23 22:18:31 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 23 Nov 2012 21:18:31 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353705511.36.0.951211905467.issue16518@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> I wouldn't use "bytes-like object".

What about "buffer-like object"?

----------

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

From report at bugs.python.org  Fri Nov 23 22:21:06 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Nov 2012 21:21:06 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353705511.36.0.951211905467.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353705608.3343.5.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> > I wouldn't use "bytes-like object".
> 
> What about "buffer-like object"?

"buffer-like" means "like a buffer" which is wrong on two points:
- "buffer" is not defined at this point, so the user doesn't understand
what it means
- we are not talking about an object which is "like a buffer", but which
"provides a buffer"

----------

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

From report at bugs.python.org  Fri Nov 23 22:54:13 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 23 Nov 2012 21:54:13 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353704267.3343.3.camel@localhost.localdomain>
Message-ID: <20121123215415.GA3655@sleipnir.bytereef.org>


Stefan Krah added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> > PEP-3118 Py_buffer structs are essentially how NumPy works internally.
> 
> Well, we should still write a Python documentation, not a NumPy
> documentation (on this tracker anyway). Outside of NumPy, there's little
> use for multi-dimensional objects.

Ok, but people should not be surprised if their (Python) array.array() of
double or their array of ctypes structs is silently accepted by some byte
consuming function.

How about "object does not provide a byte buffer" for error messages
and "(byte) buffer provider" as a shorthand for "any buffer provider
that exposes its memory as a sequence of unsigned bytes in response
to a PyBUF_SIMPLE request"?

----------

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

From report at bugs.python.org  Fri Nov 23 22:57:42 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Nov 2012 21:57:42 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <20121123215415.GA3655@sleipnir.bytereef.org>
Message-ID: <1353707804.3343.9.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> > Well, we should still write a Python documentation, not a NumPy
> > documentation (on this tracker anyway). Outside of NumPy, there's little
> > use for multi-dimensional objects.
> 
> Ok, but people should not be surprised if their (Python) array.array() of
> double or their array of ctypes structs is silently accepted by some byte
> consuming function.

Probably. My own (humble :-)) opinion is that array.array() is a
historical artifact, and its use doesn't seem to be warranted in modern
Python code. ctypes is obviously a very special library, and not for the
faint of heart.

> How about "object does not provide a byte buffer" for error messages
> and "(byte) buffer provider" as a shorthand for "any buffer provider
> that exposes its memory as a sequence of unsigned bytes in response
> to a PyBUF_SIMPLE request"?

It's not too bad, I think. However, what I think is important is that
the average (non-expert) Python developer understand that the function
really accepts a bytes object, and other similar types (because, really,
bytes is the only bytes-like type most developers will ever face).
That's why I'm proposing "bytes-like object".

----------

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

From report at bugs.python.org  Sat Nov 24 00:18:03 2012
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 23 Nov 2012 23:18:03 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353707804.3343.9.camel@localhost.localdomain>
Message-ID: <20121123231804.GA4321@sleipnir.bytereef.org>


Stefan Krah added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> > How about "object does not provide a byte buffer" for error messages
> > and "(byte) buffer provider" as a shorthand for "any buffer provider
> > that exposes its memory as a sequence of unsigned bytes in response
> > to a PyBUF_SIMPLE request"?
> 
> It's not too bad, I think. However, what I think is important is that
> the average (non-expert) Python developer understand that the function
> really accepts a bytes object, and other similar types (because, really,
> bytes is the only bytes-like type most developers will ever face).
> That's why I'm proposing "bytes-like object".

If it is somehow possible to establish the term as a shorthand for the real
meaning, then I guess it's the most economical option for documenting Python
methods (I don't think it should be used in the C-API docs though).

help (b''.join) for example would sound better with "bytes-like object"
than with "(byte) buffer provider".

----------

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

From report at bugs.python.org  Sat Nov 24 02:33:27 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 24 Nov 2012 01:33:27 +0000
Subject: [docs] [issue16518] add "buffer protocol" to glossary
In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za>
Message-ID: <1353720806.63.0.678034913959.issue16518@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> > That's why I'm proposing "bytes-like object".
>
> If it is somehow possible to establish the term as a shorthand for the real
meaning,

This can be established via the glossary.  We can still use "buffer provider" for the general case, if we find that it is useful in certain circumstances.

----------

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

From sandro.tosi at gmail.com  Sat Nov 24 13:03:53 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 24 Nov 2012 13:03:53 +0100
Subject: [docs] Documentation bug in 2.7.3 version 4.4 section
In-Reply-To: <CAKs9=yMiuoC5ib6UBiOP+U352Wku76bwQbKNxD9wUcekVNXhkA@mail.gmail.com>
References: <CAKs9=yMiuoC5ib6UBiOP+U352Wku76bwQbKNxD9wUcekVNXhkA@mail.gmail.com>
Message-ID: <CAB4XWXzr9iq3EzOus7skKrc8-edCgXMAjrxgNuZOFh3ti0aOxA@mail.gmail.com>

Hello David,

On Mon, Nov 12, 2012 at 6:03 PM, David Ceresuela <davidzgz123 at gmail.com> wrote:
> Hello everyone!
>
> In the
> http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops
> there are two print statements that I think are not correct.
> These are:
> - print("Found an even number", num)
> - print("Found a number", num)

going to the link you posted, I can see these are:

print "Found an even number", num

so the problem might have been fixed in the meantime (I hadn't check)
or there was a problem when making 3.x doc the default for
docs.python.org

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 Nov 24 14:10:40 2012
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 24 Nov 2012 13:10:40 +0000
Subject: [docs] [issue16544] Add external link to ast docs
In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za>
Message-ID: <1353762640.84.0.218173973158.issue16544@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Thanks, I'm really glad to see that it's useful to others. I don't mind contributing it to Python, but I wonder if it's better to let it develop separately for a few months first - it's still very new, and I can improve it faster in a repository where I can commit to it myself. I'm open to other opinions on that, though.

In the meantime, let me know if there are any specific formats/styles/etc. that I should work towards, to make a later move into the official docs simpler. I have a couple of particular questions:
- The repository includes some utility code for exploring ASTs, as well as longer, runnable versions of the examples in the docs. What would be the best way to preserve these?
- There are some nodes (like AugLoad) that I've yet to find what they actually do, while I've only seen Param in Python 2. Is this an issue?

Of course, you're more than welcome to give a 'see also' link to GTS if we decide not to move it for now.

----------
nosy: +takluyver

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

From report at bugs.python.org  Sat Nov 24 15:46:33 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Nov 2012 14:46:33 +0000
Subject: [docs] [issue16413] Non cross-platform behavior of os.path.split
In-Reply-To: <1352114668.34.0.500502059895.issue16413@psf.upfronthosting.co.za>
Message-ID: <1353768393.52.0.787590949914.issue16413@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't think that Python should include documentation on all supported OSes, formats, protocols and algorithms. There are documentation outside Python. I think this is not Python issue.

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

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

From aahz at pythoncraft.com  Sat Nov 24 16:41:38 2012
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 24 Nov 2012 07:41:38 -0800
Subject: [docs] FWD: Re: I want to translate Python document into Chinese
Message-ID: <20121124154138.GA6612@panix.com>

Might be handy if the bug reporting page were updated to link to
information about translating the docs.

http://docs.python.org/3/bugs.html

----- Forwarded message from webmaster at python.org -----

> Date: Sat, 24 Nov 2012 07:40:23 -0800
> From: webmaster at python.org
> To: ?? <hi.leon.y at gmail.com>
> Cc: webmaster at python.org
> Subject: Re: I want to translate Python document into Chinese
> Organization: The Cat & Dragon
> 
> On Sat, Nov 24, 2012, ?? wrote:
>> 
>> I love Python. I have seen the advantage of Python.
>> I would like to translate Python document into Chinese, in order to
>> promote Python among Chinese programmers.
>> Concerning good experiences of programming and know C, C++, Java, I
>> believe I can translate the document well. The purpose of sending this
>> e-mail is that I hope my translation will be officially recognized. It
>> may be extremely impossible that I will be paid for this. I still
>> prefer to translate the document voluntarily.
> 
> Are you looking to translate the documentation or the website?  If the
> docs, you should contact the people who work on that:
> 
> docs at python.org
> -- 
> Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/
> 
> "LL YR VWL R BLNG T S"  -- www.nancybuttons.com

----- End forwarded message -----

-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"LL YR VWL R BLNG T S"  -- www.nancybuttons.com

From pitrou at free.fr  Sat Nov 24 17:51:04 2012
From: pitrou at free.fr (pitrou at free.fr)
Date: Sat, 24 Nov 2012 16:51:04 -0000
Subject: [docs] urllib data URL recipe (issue 16423)
Message-ID: <20121124165104.2673.97684@psf.upfronthosting.co.za>

Thanks for the updated patch. There are a couple of very minor issues,
but I can handle them myself.



http://bugs.python.org/review/16423/diff/6609/Doc/library/urllib.request.rst
File Doc/library/urllib.request.rst (right):

http://bugs.python.org/review/16423/diff/6609/Doc/library/urllib.request.rst#newcode349
Doc/library/urllib.request.rst:349: .. class:: DataHandler()
You need a `versionadded` tag below.

http://bugs.python.org/review/16423/diff/6609/Doc/library/urllib.request.rst#newcode1395
Doc/library/urllib.request.rst:1395: 1.0), FTP, local files, and data
URLs.
And here you probably need a `versionchanged` tag for the addition of
data URL support.

http://bugs.python.org/review/16423/diff/6609/Lib/urllib/request.py
File Lib/urllib/request.py (right):

http://bugs.python.org/review/16423/diff/6609/Lib/urllib/request.py#newcode1559
Lib/urllib/request.py:1559: scheme, data = url.split(":",1)
PEP8 nit: space after commas.

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

From report at bugs.python.org  Sat Nov 24 18:00:13 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Nov 2012 17:00:13 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <3Y80xm27jTzRRR@mail.python.org>


Roundup Robot added the comment:

New changeset a182367eac5a by Antoine Pitrou in branch 'default':
Issue #16423: urllib.request now has support for ``data:`` URLs.
http://hg.python.org/cpython/rev/a182367eac5a

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

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

From report at bugs.python.org  Sat Nov 24 18:03:24 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Nov 2012 17:03:24 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353776604.39.0.865287179123.issue16423@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've committed your patch after having made the few very minor changes mentioned in the review. Thank you very much!

----------
assignee: orsenthil -> 
resolution:  -> invalid
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Nov 24 18:23:55 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Sat, 24 Nov 2012 17:23:55 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353777835.16.0.594922571215.issue16423@psf.upfronthosting.co.za>


Mathias Panzenb?ck added the comment:

Great!

Feels awesome to have my first bit of code contributed to the Python project. :)

----------

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

From report at bugs.python.org  Sat Nov 24 18:49:19 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Nov 2012 17:49:19 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353779359.17.0.868425735888.issue16423@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

You're welcome! We're always happy to have new contributors.

I've forgotten something: could you sign a contributor agreement?
You'll find instructions at http://www.python.org/psf/contrib/

----------

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

From report at bugs.python.org  Sat Nov 24 18:55:01 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Sat, 24 Nov 2012 17:55:01 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353779701.25.0.266078274603.issue16423@psf.upfronthosting.co.za>


Mathias Panzenb?ck added the comment:

Will do (later today).

----------

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

From report at bugs.python.org  Sat Nov 24 19:30:05 2012
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Sat, 24 Nov 2012 18:30:05 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1352258882.3.0.769784982909.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353781805.42.0.836971230823.issue16423@psf.upfronthosting.co.za>


Mathias Panzenb?ck added the comment:

Hmm, which of the two initial licenses should I choose? Which one do you rather want me to choose?

----------

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

From report at bugs.python.org  Sat Nov 24 19:39:10 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 24 Nov 2012 18:39:10 +0000
Subject: [docs] [issue16423] urllib data URL
In-Reply-To: <1353781805.42.0.836971230823.issue16423@psf.upfronthosting.co.za>
Message-ID: <1353782290.3328.1.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Hmm, which of the two initial licenses should I choose? Which one do
> you rather want me to choose?

Whichever you prefer. They should be equivalent in their terms
(non-copyleft free licenses).

----------

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

From report at bugs.python.org  Sat Nov 24 21:46:12 2012
From: report at bugs.python.org (Todd Rovito)
Date: Sat, 24 Nov 2012 20:46:12 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1353789972.16.0.789687054633.issue5066@psf.upfronthosting.co.za>


Changes by Todd Rovito <rovitotv at gmail.com>:


----------
nosy: +Todd.Rovito

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

From report at bugs.python.org  Sat Nov 24 21:46:51 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Nov 2012 20:46:51 +0000
Subject: [docs] [issue16544] Add external link to ast docs
In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za>
Message-ID: <1353790011.76.0.160240764072.issue16544@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I don't mind contributing it to Python, but I wonder if it's better to 
> let it develop separately for a few months first - it's still very new, 
> and I can improve it faster in a repository where I can commit to it 
> myself.

That's fine, there's no hurry to merge this.

We should also decide on the approach, e.g.:
  1) we could extract bits from your work and use them to improve the current docs (you can also report problems that you might notice in the current docs);
  2) we could add your work to the current ast docs;
  3) we could add your work as a separate howto in Doc/howto/;

> In the meantime, let me know if there are any specific formats/styles/etc.

The general guidelines are explained here: http://docs.python.org/devguide/documenting.html
You can also look at the current docs to get an idea.

> What would be the best way to preserve these?

If they are not too long they could be kept in the rst files, otherwise they could be included in the Tools/ dir.

> Is this an issue?

Any improvement is welcomed -- it doesn't necessarily have to be comprehensive, but it should be correct.

----------

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

From report at bugs.python.org  Sun Nov 25 00:07:52 2012
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 24 Nov 2012 23:07:52 +0000
Subject: [docs] [issue16544] Add external link to ast docs
In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za>
Message-ID: <1353798472.62.0.64468798507.issue16544@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

I think that putting the full content of GTS into the ast module docs would make it awkwardly long. Perhaps the bulk of it could become a howto, and GTS could be maintained separately as a showcase of examples.

----------

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

From report at bugs.python.org  Sun Nov 25 02:09:00 2012
From: report at bugs.python.org (Todd Rovito)
Date: Sun, 25 Nov 2012 01:09:00 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1353805740.63.0.858012423649.issue5066@psf.upfronthosting.co.za>


Todd Rovito added the comment:

This is a good patch but it is rather out of date and won't apply.  I will patch the patch and maybe somebody can apply it this time.  Expect a new patch by 11/26/2012.

----------

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

From report at bugs.python.org  Sun Nov 25 03:58:51 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 25 Nov 2012 02:58:51 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1353812331.14.0.620661129612.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I'm attaching a patch that preserves the structure of the previous patch but that builds on the wording and formatting.  The patch also addresses many of the comments on Rietveld.  I will also publish some comment replies on Rietveld (to the previous patch) that will give background on some of the changes made by this patch.

----------
Added file: http://bugs.python.org/file28101/issue-15990-4-default.patch

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

From chris.jerdonek at gmail.com  Sun Nov 25 04:05:18 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Sun, 25 Nov 2012 03:05:18 -0000
Subject: [docs] solidify argument/parameter terminology (issue 15990)
Message-ID: <20121125030518.28387.10183@psf.upfronthosting.co.za>

Reviewers: ezio.melotti,


http://bugs.python.org/review/15990/diff/6650/Doc/faq/programming.rst
File Doc/faq/programming.rst (right):

http://bugs.python.org/review/15990/diff/6650/Doc/faq/programming.rst#newcode324
Doc/faq/programming.rst:324: we can say that *foo*, *bar* and *kwargs*
are :term:`parameter`\s of
I recommend using the "target" form in cases like this so that the "s"
does not look different from the rest of the word.

http://bugs.python.org/review/15990/diff/6650/Doc/faq/programming.rst#newcode333
Doc/faq/programming.rst:333: arguments are the actual values passed to a
function during a call.
I think it is usually better to start off by stating the difference, and
then following with an example, as opposed to the reverse.

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode46
Doc/glossary.rst:46: * positional arguments: values passed by position
(e.g. ``3`` and ``5``
The singular form should be used here to parallel the singular form
being used elsewhere.  Also, defining "positional" as "passed by
position" seems circular.

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode52
Doc/glossary.rst:52: * keyword arguments: values passed by keyword and
assigned to the local
On 2012/11/22 16:38:14, ezio.melotti wrote:
> Is "passed by keyword" an acceptable terminology?

Similar to above, defining keyword argument to mean "passed by keyword"
seems circular.

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode559
Doc/glossary.rst:559: A named entity in a :term:`function` (or method)
signature that
We can use "definition" in place of "signature," though signature may be
the better word for people who know what it means.  I originally chose
"entity" because "object" is already laden with other meanings in
Python.

Regarding the word "argument," I think it is helpful to reference
because it makes clear the dependency relationship between the two terms
(and the reader can then look up the other term).  Note also that the
entry for argument does not depend on "parameter" for its definition.

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode561
Doc/glossary.rst:561: function can accept.  There are five types of
paramters:
On 2012/11/22 16:38:14, ezio.melotti wrote:
>   Named entities in a function (or method) signature that
>   define what :term:`arguments` the function can accept.

We can still use a form like this without pluralizing.  For example,

   A named entity in a function (or method) definition that defines
   an argument (or arguments) that the function can accept.

> Using the plural form might be better if :term:`parameters` is more
common than
> :term:`parameter`.

I think the singular form should be used for nouns in the glossary.  The
only exception to this that I can think of is if the singular form is
never or rarely used (e.g. a word like data).  It looks like "universal
newlines" is the only entry that currently ends in "s."  In that case,
the word is used an adjective and so isn't really a counter example. 
Moreover, there we were deciding what term should be used in all cases
(e.g. "universal newline mode" versus "universal newlines mode").

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode577
Doc/glossary.rst:577: * var-positional: a tuple of positional arguments
that aren't bound to
This reads like a var-positional parameter is a tuple of positional
arguments, which isn't what we want to communicated.

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode581
Doc/glossary.rst:581: * var-keyword: a dict of keyword arguments that
aren't bound to any other
This reads like a var-keyword parameter is a dict of keyword arguments,
which isn't what we want to communicate.



Please review this at http://bugs.python.org/review/15990/

Affected files:
  Doc/faq/programming.rst
  Doc/glossary.rst



From report at bugs.python.org  Sun Nov 25 07:08:33 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 25 Nov 2012 06:08:33 +0000
Subject: [docs] [issue16209] add a "class str" entry to the docs
In-Reply-To: <1350032597.23.0.0536115574586.issue16209@psf.upfronthosting.co.za>
Message-ID: <1353823712.78.0.261768997682.issue16209@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Attaching patch.

Adding Nick to the nosy list because he did the work of originally breaking out the "Text Sequence Type" section for issue #4966, as well as Terry who created that issue.  I view the current issue and patch as a progression of some of the issues discussed in that issue.

----------
keywords: +patch
nosy: +ncoghlan, terry.reedy
stage:  -> patch review
Added file: http://bugs.python.org/file28102/issue-16209-1-default.patch

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

From report at bugs.python.org  Sun Nov 25 11:47:22 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Nov 2012 10:47:22 +0000
Subject: [docs] [issue16209] add a "class str" entry to the docs
In-Reply-To: <1350032597.23.0.0536115574586.issue16209@psf.upfronthosting.co.za>
Message-ID: <1353840442.45.0.713701045636.issue16209@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Right, aside from my recent revamp, much of the existing layout of the types section has been inherited from the pre-new style classes days when you *couldn't* inherit from types, and strings were the only one with a non-trivial number of methods.

Rearranging as Chris suggests makes sense to me - my work was certainly only intended to be the *start* of improvements to the builtin type docs.

The main thing to watch out for is ensuring we don't break any incoming deep links while rearranging things (perhaps by adding the appropriate explicit anchor targets). It's OK if some cases end up just linking to the page (e.g. that's what now happens to reference to the old monolithic sequence types section, as there's no obviously better destination), but in this case the old deep links should go to the new class docs.

----------

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

From report at bugs.python.org  Sun Nov 25 11:51:45 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 25 Nov 2012 10:51:45 +0000
Subject: [docs] [issue16209] add a "class str" entry to the docs
In-Reply-To: <1350032597.23.0.0536115574586.issue16209@psf.upfronthosting.co.za>
Message-ID: <1353840705.24.0.477690366558.issue16209@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The simpler approach Chris has taken here (i.e. just leaving the string methods separate from the class definition) also works.

Patch looks good to me - I'm definitely in favour of moving towards a more consistent approach of having the builtin function definitions reference to full class definitions (as shown by the changes I made to the docs for the other sequence types).

----------

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

From report at bugs.python.org  Sun Nov 25 12:06:31 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Nov 2012 11:06:31 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <1353841591.17.0.87120597309.issue16339@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Here's a patch for the documentation and tests.

----------
keywords: +patch
Added file: http://bugs.python.org/file28105/issue16339.patch

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

From report at bugs.python.org  Sun Nov 25 12:07:26 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Nov 2012 11:07:26 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <1353841646.39.0.721899380833.issue16339@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file28106/issue16339.patch

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

From report at bugs.python.org  Sun Nov 25 12:07:35 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Nov 2012 11:07:35 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <1353841655.14.0.494052881276.issue16339@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file28105/issue16339.patch

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

From report at bugs.python.org  Sun Nov 25 12:20:16 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Nov 2012 11:20:16 +0000
Subject: [docs] [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1353842416.17.0.224652248909.issue8824@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Should this be closed as a duplicate of issue #13557?

----------

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

From report at bugs.python.org  Sun Nov 25 12:23:38 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Nov 2012 11:23:38 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <1353842618.83.0.467291314572.issue16339@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Nov 25 12:59:22 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Nov 2012 11:59:22 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <1353844762.92.0.347736559544.issue16339@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Updated patch:  drops mention of backwards compatibility, since that's not so useful (thanks, Ezio!).  Adds note about resemblance to Python 3 code.

----------
Added file: http://bugs.python.org/file28108/issue16339_v2.patch

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

From report at bugs.python.org  Sun Nov 25 13:06:26 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Nov 2012 12:06:26 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <1353845186.1.0.116222397239.issue16339@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Rewording the sentence about Python 3.

----------
Added file: http://bugs.python.org/file28109/issue16339_v3.patch

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

From report at bugs.python.org  Sun Nov 25 14:26:06 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Nov 2012 13:26:06 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <3Y8X8F34tTzRWh@mail.python.org>


Roundup Robot added the comment:

New changeset fd9c9579050d by Mark Dickinson in branch '2.7':
Issue #16339: Document and test exec(stmt, globals, locals) form in Python 2.7.
http://hg.python.org/cpython/rev/fd9c9579050d

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

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

From report at bugs.python.org  Sun Nov 25 14:28:34 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Nov 2012 13:28:34 +0000
Subject: [docs] [issue16339] Document "exec(stmt, global_dict,
	local_dict)" form in Python 2?
In-Reply-To: <1351359067.41.0.359232821509.issue16339@psf.upfronthosting.co.za>
Message-ID: <1353850114.04.0.24333352266.issue16339@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Nov 25 18:22:02 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 25 Nov 2012 17:22:02 +0000
Subject: [docs] [issue16209] add a "class str" entry to the docs
In-Reply-To: <1350032597.23.0.0536115574586.issue16209@psf.upfronthosting.co.za>
Message-ID: <1353864122.65.0.31775494776.issue16209@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> The simpler approach Chris has taken here (i.e. just leaving the string methods separate from the class definition) also works.

Yes, though I mentioned nesting the string methods beneath the class entry in the original post for this issue, I figured we could start smaller and do this in more manageable steps.  We can do the bigger change (in the sense of being a bigger diff) of indenting as part of a second issue/patch.

----------

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

From report at bugs.python.org  Sun Nov 25 19:03:32 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Nov 2012 18:03:32 +0000
Subject: [docs] [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1353866612.85.0.386114303836.issue8824@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> exec of list comprehension fails on NameError

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

From report at bugs.python.org  Sun Nov 25 19:07:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 25 Nov 2012 18:07:56 +0000
Subject: [docs] [issue16209] add a "class str" entry to the docs
In-Reply-To: <1350032597.23.0.0536115574586.issue16209@psf.upfronthosting.co.za>
Message-ID: <1353866876.91.0.433712649315.issue16209@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Updating patch to fix up affected/related index entries.

----------
Added file: http://bugs.python.org/file28124/issue-16209-2-default.patch

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

From report at bugs.python.org  Sun Nov 25 19:50:36 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 25 Nov 2012 18:50:36 +0000
Subject: [docs] [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1353869436.68.0.229612515409.issue8824@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I suggested more change here than I committed in #13557. I would like to think about the extra a bit more. The issue about def in exec just came up again on python-list, but I do not really like the third sentence I suggested.

----------
assignee: docs at python -> terry.reedy

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

From report at bugs.python.org  Sun Nov 25 19:51:54 2012
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 25 Nov 2012 18:51:54 +0000
Subject: [docs] [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1353869514.52.0.18239744734.issue8824@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Okay;  sorry about that.  Reopening.

----------
resolution: duplicate -> 
status: closed -> open

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

From report at bugs.python.org  Sun Nov 25 20:47:03 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 25 Nov 2012 19:47:03 +0000
Subject: [docs] [issue16552] os.path.basename() docs should link to
	os.path.split()
Message-ID: <1353872823.17.0.910563008076.issue16552@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The docs for os.path.abspath(), os.path.basename(), and os.path.dirname():

http://docs.python.org/dev/library/os.path.html#os.path.abspath

should hyperlink to os.path.normpath() and os.path.split() as appropriate for easier navigability.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 176386
nosy: chris.jerdonek, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: os.path.basename() docs should link to os.path.split()
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov 25 23:15:40 2012
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 25 Nov 2012 22:15:40 +0000
Subject: [docs] [issue16554] The description of the argument of
	MAKE_FUNCTION and	MAKE_CLOSURE is incorrect
Message-ID: <1353881740.2.0.222803994959.issue16554@psf.upfronthosting.co.za>


New submission from Daniel Urban:

The description of the argument of the MAKE_FUNCTION and MAKE_CLOSURE opcodes in the documentation of the dis module is incorrect. Patch attached.

----------
assignee: docs at python
components: Documentation
files: make_function_closure.patch
keywords: needs review, patch
messages: 176390
nosy: daniel.urban, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: The description of the argument of MAKE_FUNCTION and MAKE_CLOSURE is incorrect
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28125/make_function_closure.patch

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

From report at bugs.python.org  Mon Nov 26 05:11:33 2012
From: report at bugs.python.org (Taavi Burns)
Date: Mon, 26 Nov 2012 04:11:33 +0000
Subject: [docs] [issue16556] Update string.Formatter.vformat documentation
	to say	"**kwargs"
Message-ID: <1353903093.51.0.301727912961.issue16556@psf.upfronthosting.co.za>


New submission from Taavi Burns:

The documentation says "**kwds" instead of "**kwargs", which is what the function signature uses.

I noticed some other (internally-consistent) occurrences in string.rst. Is there any interest in replacing "**kwds" generally with "**kwargs"? It looks like 327 vs 932 ratio in the docs, and closer to 1185 vs 2361 in the source tree as a whole.

Thanks!

----------
assignee: docs at python
components: Documentation
files: kwds_kwargs.diff
keywords: patch
messages: 176393
nosy: docs at python, taavi-burns
priority: normal
severity: normal
status: open
title: Update string.Formatter.vformat documentation to say "**kwargs"
type: enhancement
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file28127/kwds_kwargs.diff

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

From report at bugs.python.org  Mon Nov 26 05:45:09 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Nov 2012 04:45:09 +0000
Subject: [docs] [issue16552] os.path.basename() docs should link to
	os.path.split()
In-Reply-To: <1353872823.17.0.910563008076.issue16552@psf.upfronthosting.co.za>
Message-ID: <3Y8wXf4P41zQ7C@mail.python.org>


Roundup Robot added the comment:

New changeset 580ca5c587f6 by Chris Jerdonek in branch '2.7':
Add hyperlinks to the docs of some os.path functions (issue #16552).
http://hg.python.org/cpython/rev/580ca5c587f6

New changeset cde59c6acf98 by Chris Jerdonek in branch '3.2':
Add hyperlinks to the docs of some os.path functions (issue #16552).
http://hg.python.org/cpython/rev/cde59c6acf98

New changeset 3eec2d562df0 by Chris Jerdonek in branch '3.3':
Merge from 3.2: add hyperlinks to some os.path function docs (issue #16552).
http://hg.python.org/cpython/rev/3eec2d562df0

New changeset 25321e2172ad by Chris Jerdonek in branch 'default':
Merge from 3.3: add hyperlinks to some os.path function docs (issue #16552).
http://hg.python.org/cpython/rev/25321e2172ad

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

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

From report at bugs.python.org  Mon Nov 26 05:47:27 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 26 Nov 2012 04:47:27 +0000
Subject: [docs] [issue16552] os.path.basename() docs should link to
	os.path.split()
In-Reply-To: <1353872823.17.0.910563008076.issue16552@psf.upfronthosting.co.za>
Message-ID: <1353905247.13.0.896783745981.issue16552@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


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

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

From report at bugs.python.org  Mon Nov 26 06:00:38 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 26 Nov 2012 05:00:38 +0000
Subject: [docs] [issue16556] Update string.Formatter.vformat documentation
	to say	"**kwargs"
In-Reply-To: <1353903093.51.0.301727912961.issue16556@psf.upfronthosting.co.za>
Message-ID: <1353906038.09.0.329827668819.issue16556@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Hello Taavi!  It seems to me there is little value in changing all docs to use ?**kwargs? instead of ?**kwds?, given that this cannot cause actual problems.  The interesting thing is that the function takes keyword args.

For string.Formatter.vformat, I see no harm in changing it, but also no value.  Core developers tend to resist to aesthetic/cleanup/perfectionism-only changes for the sake of minimizing diff churn, avoiding divergences between versions and not taking unneeded risks (less so for doc changes, but a real concern for code cleanups).  Ezio, what do you think?

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

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

From report at bugs.python.org  Mon Nov 26 06:09:28 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 26 Nov 2012 05:09:28 +0000
Subject: [docs] [issue12217] Cross-link docs for faulthandler,
	traceback and pdb
In-Reply-To: <1306770313.4.0.799430970978.issue12217@psf.upfronthosting.co.za>
Message-ID: <1353906568.23.0.831979052455.issue12217@psf.upfronthosting.co.za>


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


----------
nosy: +chris.jerdonek

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

From report at bugs.python.org  Mon Nov 26 06:14:31 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 26 Nov 2012 05:14:31 +0000
Subject: [docs] [issue15472] Itertools doc summary table misdocuments some
	arguments
In-Reply-To: <1343413434.71.0.36910737273.issue15472@psf.upfronthosting.co.za>
Message-ID: <1353906871.86.0.547294906448.issue15472@psf.upfronthosting.co.za>


?ric Araujo added the comment:

cycle was a bad example, but there are other: ifilter, islice, takewhile.  "it" (like what tee uses) instead of "seq" would work.

----------

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

From report at bugs.python.org  Mon Nov 26 07:40:53 2012
From: report at bugs.python.org (Taavi Burns)
Date: Mon, 26 Nov 2012 06:40:53 +0000
Subject: [docs] [issue16556] Update string.Formatter.vformat documentation
	to say	"**kwargs"
In-Reply-To: <1353903093.51.0.301727912961.issue16556@psf.upfronthosting.co.za>
Message-ID: <1353912052.97.0.0480000742288.issue16556@psf.upfronthosting.co.za>


Taavi Burns added the comment:

The issue of churn is totally fair.

I'd still advocate for the attached patch, as it's tiny and fixes an inconsistency between the function signature and the docs that are referring to that signature.

Thanks!

----------

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

From report at bugs.python.org  Mon Nov 26 13:07:18 2012
From: report at bugs.python.org (Masami HIRATA)
Date: Mon, 26 Nov 2012 12:07:18 +0000
Subject: [docs] [issue16557] PEP 380 isn't reflected in the Functional
	Programming	HOWTO
Message-ID: <1353931638.82.0.313274646017.issue16557@psf.upfronthosting.co.za>


New submission from Masami HIRATA:

Although PEP 380 says:
> 2. In a generator, the statement ::
> 
>     return value
> 
> is semantically equivalent to ::
> 
>     raise StopIteration(value)

Functional Programming HOWTO (Doc/howto/functional.rst) says:
> ``return`` with a value, such as ``return 5``, is a syntax error inside a generator function.

----------
assignee: docs at python
components: Documentation
messages: 176407
nosy: docs at python, msmhrt
priority: normal
severity: normal
status: open
title: PEP 380 isn't reflected in the Functional Programming HOWTO
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 26 14:43:19 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 26 Nov 2012 13:43:19 +0000
Subject: [docs] [issue16554] The description of the argument of
	MAKE_FUNCTION and	MAKE_CLOSURE is incorrect
In-Reply-To: <1353881740.2.0.222803994959.issue16554@psf.upfronthosting.co.za>
Message-ID: <1353937399.34.0.995870206421.issue16554@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

The patch is better than current doc.
Would you like to replace textual description of stack layout with some kind of ascii-art or table? I think it can be more readable.

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

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

From report at bugs.python.org  Mon Nov 26 17:01:25 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Nov 2012 16:01:25 +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: <1353945684.45.0.213912003167.issue14097@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I started working on this.  Attached there's a work in progress patch with changes done on the first half of the tutorial.
The changes are not definitive, and I'm trying to get some early feedback on rietveld before moving on the second half.

----------
Added file: http://bugs.python.org/file28130/issue14097-1.diff

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

From ezio.melotti at gmail.com  Mon Nov 26 17:32:40 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 26 Nov 2012 16:32:40 -0000
Subject: [docs] Improve the "introduction" page of the tutorial (issue 14097)
Message-ID: <20121126163240.31756.47104@psf.upfronthosting.co.za>

Reviewers: ,


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

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#oldcode54
Doc/tutorial/introduction.rst:54: >>> 2+2  # and a comment on the same
line as code
Removed redundant comment examples and cleaned up whitespace.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#oldcode65
Doc/tutorial/introduction.rst:65: representations.
Removed outdated note.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#oldcode92
Doc/tutorial/introduction.rst:92: 0
This can be done and works with immutable values, but might have
surprising side effects with mutable values and about the evaluation
order (see recent python-dev thread).
I think it's better to remove this altogether, since it's rarely needed
anyway.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#oldcode151
Doc/tutorial/introduction.rst:151: 5.0
All this might be moved somewhere else.
For now I just added a mention about complex number at the end of the
section.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#oldcode193
Doc/tutorial/introduction.rst:193: are typed for input: inside quotes,
and with quotes and other funny characters
Not entirely true, since the quotes might change.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#oldcode201
Doc/tutorial/introduction.rst:201: next line is a logical continuation
of the line::
This is not the best way to do it IMHO, so I only kept the example with
triple quotes.

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

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode27
Doc/tutorial/introduction.rst:27: string = "# This is not a comment
because it's inside quotes."
UPPERCASE is rarely used, so I removed it.
I also explained why this is not a comment.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode61
Doc/tutorial/introduction.rst:61: :class:``float``.  We will see more
about numberic types later in the tutorial.
Added short introduction about int and float.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode63
Doc/tutorial/introduction.rst:63: Classic division (``/``) always return
a float.  To do integer division and get
s/return/returns/.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode65
Doc/tutorial/introduction.rst:65: operator, and to calculate the
remainder you can use ``%``::
This sentence can be improved a bit.
I think it's important to introduce the modulo operator together with
the integer division.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode120
Doc/tutorial/introduction.rst:120: :class:`~fractions.Fraction`.
Here I mentioned other numberic types without going into details.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode130
Doc/tutorial/introduction.rst:130: double quotes (``"..."``) with the
same result.  ``\`` can be used to escape
In other languages '...' and "..." have different meanings, so I added
"with the same result", not sure if this should be more explicit.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode157
Doc/tutorial/introduction.rst:157: >>> s = 'First line.\nSecond line.' 
# \n means newline
Added an example with special characters.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode164
Doc/tutorial/introduction.rst:164: If you don't want to use special
characters, you can use *raw strings* by adding
Is there a glossary entry for this?

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode171
Doc/tutorial/introduction.rst:171: C:\some\name
And explain how to use raw strings to avoid unwanted effects.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode193
Doc/tutorial/introduction.rst:193: repeated with ``*``::
This could be moved before the section about """...""", so that
multiline strings created with implicit literal concatenation inside
parentheses can be presented as another alternative.
E.g.:
foo = ("I don't care about the "
       "newlines here.)

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode197
Doc/tutorial/introduction.rst:197: >>> 'na '*10 + hero + '!'!
s/!$//

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode198
Doc/tutorial/introduction.rst:198: 'na na na na na na na na na na
batman!'
I'm not sure if batman fits in the tutorial.

The HelpAHelpAHelpA example didn't make sense to me (am I missing some
reference?), so I was looking for something word with a repeated
sillable, like banana or ananas, but that only had 2 repetitions.

Since the repeated syllabe was 'na' in both of the cases, I thought
about the popular batman song and used it in the example.  Batman is
also good for 'bat' + 'man' example, and it can be reused in the slicing
section (you can use slices to go from batman to catman to catwoman, or
to extract bat or man, or similar things).
Not sure if that's too much batman for a single page though.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode211
Doc/tutorial/introduction.rst:211: ^
I forgot to show animal + 'man' here.
I changed the previous example because (string) methods have not been
introduced yet.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode225
Doc/tutorial/introduction.rst:225: 'lp'
Here it keeps using the "meaningless" example, so I would change these
too.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode262
Doc/tutorial/introduction.rst:262: Degenerate slice indices are handled
gracefully: an index that is too large is
This should be rephrased, as suggested in the index.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode301
Doc/tutorial/introduction.rst:301: *between* characters, with the left
edge of the first character numbered 0.
For indexes is easier to thing of the indices as pointing *to*
characters though.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode389
Doc/tutorial/introduction.rst:389: b'\xc3\x84pfel'
This section about Unicode should be trimmed down or removed IMHO.  Some
vague reference about Unicode could be done in the string section. 
Encoding/decoding should wait until the bytes type is presented.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode399
Doc/tutorial/introduction.rst:399: have the same type. ::
But usually they do (and should).

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode405
Doc/tutorial/introduction.rst:405: Like string indices, list indices
start at 0, and lists can be sliced,
Like string and all other sequences.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode422
Doc/tutorial/introduction.rst:422: means that the following slice
returns a shallow copy of the list *a*::
shallow is not explained.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode432
Doc/tutorial/introduction.rst:432: >>> a[2] = a[2] + 23
I would show a "regular" replacement here, e.g. a[2] = 123

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode480
Doc/tutorial/introduction.rst:480: >>> p[1].append('xtra')
Here methods are introduced, without any word about the difference
between methods and functions, and in a somewhat complex example.
Some methods should be introduced already while talking about strings.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode502
Doc/tutorial/introduction.rst:502: >>> while b < 10:
"if" and "for" should be introduced first.
This could be moved to the next page.



Please review this at http://bugs.python.org/review/14097/

Affected files:
  Doc/tutorial/introduction.rst



From report at bugs.python.org  Mon Nov 26 18:11:24 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Nov 2012 17:11:24 +0000
Subject: [docs] [issue16493] Document the 'optimize' argument to compile()
In-Reply-To: <1353167567.95.0.716171753234.issue16493@psf.upfronthosting.co.za>
Message-ID: <1353949884.76.0.0430656407033.issue16493@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Mon Nov 26 18:16:16 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 26 Nov 2012 17:16:16 +0000
Subject: [docs] [issue16538] The docs doesn't describe MAKE_CLOSURE correctly
In-Reply-To: <1353676159.67.0.844924036734.issue16538@psf.upfronthosting.co.za>
Message-ID: <1353950176.12.0.305107481077.issue16538@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From chris.jerdonek at gmail.com  Mon Nov 26 19:58:19 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Mon, 26 Nov 2012 18:58:19 -0000
Subject: [docs] Improve the "introduction" page of the tutorial (issue
	14097)
Message-ID: <20121126185819.31755.74297@psf.upfronthosting.co.za>

Some random comments (not comprehensive review).


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

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode8
Doc/tutorial/introduction.rst:8: absence of prompts (``>>>`` and
``...``): to repeat the example, you must type
Are you planning to link to glossary entries?  Both ">>>" and "..."
actually appear in the glossary.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode27
Doc/tutorial/introduction.rst:27: string = "# This is not a comment
because it's inside quotes."
I would use a variable name other than "string" so as not to encourage
its use.

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode52
Doc/tutorial/introduction.rst:52: >>> 50 - 5*6
Need spaces: 5 * 6 (as well as below)

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode146
Doc/tutorial/introduction.rst:146: By default, the interpreter output
the strings inside quotes and keeps other
I would do something like: "By default, the interpreter encloses the
string output in quotes and escapes special characters with
backslashes."  The meaning of the current word ordering is a little
ambiguous: does it output the strings that are inside quotes, or does it
put the strings inside quotes after outputting?  Similarly, does it keep
as is the characters that are escaped by backslashes, or does it escape
with backslashes the funny characters?

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode157
Doc/tutorial/introduction.rst:157: >>> s = 'First line.\nSecond line.' 
# \n means newline
On 2012/11/26 17:32:41, ezio.melotti wrote:
> Added an example with special characters.

I would use PEP-8 style for comments, for example by capitalizing the
first letter and ending with a period if the phrase is a sentence
(though the latter is optional for short comments).

http://bugs.python.org/review/14097/diff/6689/Doc/tutorial/introduction.rst#newcode197
Doc/tutorial/introduction.rst:197: >>> 'na '*10 + hero + '!'!
On 2012/11/26 17:32:41, ezio.melotti wrote:
> s/!$//

I would do "10 * 'na '" (add spaces and lead with the number -- as is
customary with polynomials, for example)

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

From report at bugs.python.org  Mon Nov 26 20:11:53 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Nov 2012 19:11:53 +0000
Subject: [docs] [issue15472] Itertools doc summary table misdocuments some
	arguments
In-Reply-To: <1343413434.71.0.36910737273.issue15472@psf.upfronthosting.co.za>
Message-ID: <1353957113.14.0.58150452452.issue15472@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I would like to stick with "seq" because another other variant is less readable or understandable IMO.

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

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

From report at bugs.python.org  Mon Nov 26 20:14:59 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Nov 2012 19:14:59 +0000
Subject: [docs] [issue15472] Itertools doc summary table misdocuments some
	arguments
In-Reply-To: <1343413434.71.0.36910737273.issue15472@psf.upfronthosting.co.za>
Message-ID: <1353957299.39.0.746297610466.issue15472@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Also note that the "seq[0], seq[1], ..." notation only makes sense for objects that are indexable.   It is very slightly misleading but does a good job of communicating what the itertools do.

----------
priority: normal -> low

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

From report at bugs.python.org  Mon Nov 26 21:41:33 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Nov 2012 20:41:33 +0000
Subject: [docs] [issue15472] Itertools doc summary table misdocuments some
	arguments
In-Reply-To: <1343413434.71.0.36910737273.issue15472@psf.upfronthosting.co.za>
Message-ID: <1353962493.86.0.262542877407.issue15472@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The line before the second table says "sequence". That could be changed to "iterable".  Specifying "it" in parentheses just after "iterable" and use it consistently in the examples could make it clearer.
I agree that using [0] and [1] is OK even if not 100% correct though.

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

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

From ezio.melotti at gmail.com  Mon Nov 26 22:04:35 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 26 Nov 2012 21:04:35 -0000
Subject: [docs] solidify argument/parameter terminology (issue 15990)
Message-ID: <20121126210435.31755.69479@psf.upfronthosting.co.za>


http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode47
Doc/glossary.rst:47: ``name=``) in the calling syntax or passed as a
value in a dictionary
s/in the calling syntax/in a function call/?
For consistency with the next definition you should use "and/or" here
too.

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode68
Doc/glossary.rst:68: See also the :term:`parameter` glossary entry and
:pep:`362`.
This should link to the FAQ

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode571
Doc/glossary.rst:571: :term:`keyword argument`.  This is the default
kind of parameter, for
I wouldn't link to positional/keyowrd arguments now that they are dummy.
 If linking to argument is too "vague" you /could/ add references before
the two definitions of argument.

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode583
Doc/glossary.rst:583: bare ``*`` before them in the parameter list of
the function
This might lead the reader to think that every keyword-only arg requires
its own *.  The example could specify kw-only args.

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode605
Doc/glossary.rst:605: :ref:`function` section, and :pep:`362`.
It occurred to me that there's another distinction that can be made:
required vs optional.  Should we add this too?

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

From ezio.melotti at gmail.com  Mon Nov 26 22:07:50 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 26 Nov 2012 21:07:50 -0000
Subject: [docs] solidify argument/parameter terminology (issue 15990)
Message-ID: <20121126210750.31756.247@psf.upfronthosting.co.za>


http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/15990/diff/6650/Doc/glossary.rst#newcode577
Doc/glossary.rst:577: * var-positional: a tuple of positional arguments
that aren't bound to
On 2012/11/25 04:05:18, cjerdonek wrote:
> This reads like a var-positional parameter is a tuple of positional
arguments,
> which isn't what we want to communicated.

Note that I took this from the pep.  The pep could get the same
clarification (unless I made it more confusing than it was).

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

From report at bugs.python.org  Tue Nov 27 06:11:41 2012
From: report at bugs.python.org (Todd Rovito)
Date: Tue, 27 Nov 2012 05:11:41 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1353993101.13.0.382194295321.issue5066@psf.upfronthosting.co.za>


Todd Rovito added the comment:

This patch is an extensive refactoring of help.txt and idle.rst. The first thing I did was merge issue5066.patch from jesstess into the current idle.rst file, because the original patch from jesstess was so old it had to be merged by hand into the 3.4 source code.  Then I compared what the merge document said with the actual menus of IDLE and made several corrections because of missing menu options.  Finally I refactored the help.txt based on idle.rst and created the resulting patch. Several capitalization's were fixed along with many inconsistencies between the two files.  

I have not tested on 2.7 only 3.4.  My plan is to test with 2.7 and create another patch by end of the week 12/2/2012.

----------
versions: +Python 3.4 -Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file28138/5066IDLEocumentationforUnixObsoleteIncorrect.patch

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

From report at bugs.python.org  Tue Nov 27 06:27:31 2012
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 27 Nov 2012 05:27:31 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1353994051.31.0.208266386595.issue5066@psf.upfronthosting.co.za>


Roger Serwy added the comment:

The original help.txt and the patched version still mixes tabs and spaces. This is a minor point, but perhaps all the tabs should be expanded.

Also, the section on running IDLE without a subprocess should not be removed until version 3.5. See #16123.

----------
nosy: +serwy

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

From ezio.melotti at gmail.com  Tue Nov 27 18:04:38 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Tue, 27 Nov 2012 17:04:38 -0000
Subject: [docs] add a "class str" entry to the docs (issue 16209)
Message-ID: <20121127170438.31755.76185@psf.upfronthosting.co.za>


http://bugs.python.org/review/16209/diff/6684/Doc/extending/newtypes.rst
File Doc/extending/newtypes.rst (right):

http://bugs.python.org/review/16209/diff/6684/Doc/extending/newtypes.rst#newcode986
Doc/extending/newtypes.rst:986: single: string; object presentation
representation?

http://bugs.python.org/review/16209/diff/6684/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/16209/diff/6684/Doc/library/functions.rst#newcode1246
Doc/library/functions.rst:1246: See the :class:`str` type for
documentation of ``str()``.
This sounds a bit confusing and redundant to me.
There are two links to textseq with two different texts, two to
:class:`str` (I think that's somewhere near textseq), and ``str`` is
used 4 more times.

I think all this (including the following line) can be summarized to:
Return a :class:`str` version of *object*.
See also the documentation of the :class:`str` type and :ref:`textseq`
for more information about strings.

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

From report at bugs.python.org  Tue Nov 27 18:19:14 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Nov 2012 17:19:14 +0000
Subject: [docs] [issue16556] Update string.Formatter.vformat documentation
	to say	"**kwargs"
In-Reply-To: <1353903093.51.0.301727912961.issue16556@psf.upfronthosting.co.za>
Message-ID: <3Y9sDK359rzRQX@mail.python.org>


Roundup Robot added the comment:

New changeset d805982336a0 by Ezio Melotti in branch '2.7':
#16556: Fix inconsistency between kwds and kwargs.  Patch by Taavi Burns.
http://hg.python.org/cpython/rev/d805982336a0

New changeset 565c3bbed7d3 by Ezio Melotti in branch '3.2':
#16556: Fix inconsistency between kwds and kwargs.  Patch by Taavi Burns.
http://hg.python.org/cpython/rev/565c3bbed7d3

New changeset ae19d86b71c8 by Ezio Melotti in branch '3.3':
#16556: merge with 3.2.
http://hg.python.org/cpython/rev/ae19d86b71c8

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

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

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

From report at bugs.python.org  Tue Nov 27 18:22:29 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 27 Nov 2012 17:22:29 +0000
Subject: [docs] [issue16556] Update string.Formatter.vformat documentation
	to say	"**kwargs"
In-Reply-To: <1353903093.51.0.301727912961.issue16556@psf.upfronthosting.co.za>
Message-ID: <1354036949.74.0.356872911186.issue16556@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The patch looked OK, so I committed it.
Regarding similar cleanups I think it's OK to do them only if the inconsistency is in the same function.  If different functions use kwds or kwargs in different places but they do it consistently, then it doesn't matter.

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

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

From report at bugs.python.org  Tue Nov 27 18:30:18 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 27 Nov 2012 17:30:18 +0000
Subject: [docs] [issue16556] Update string.Formatter.vformat documentation
	to say	"**kwargs"
In-Reply-To: <1353903093.51.0.301727912961.issue16556@psf.upfronthosting.co.za>
Message-ID: <1354037418.86.0.752211306155.issue16556@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Oh, I had totally missed that the mismatch was between the function signature in the docs and another part of the doc (I thought it was between the real function signature and the doc).  Good catch!

----------

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

From andrew.svetlov at gmail.com  Tue Nov 27 18:41:44 2012
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Tue, 27 Nov 2012 19:41:44 +0200
Subject: [docs] http://docs.python.org/2/library/hashlib.html
In-Reply-To: <CAOw2TN_vksS4n87amKDs4vxUbu+Gdng2daHPjHpX_3iO=91sBw@mail.gmail.com>
References: <CAOw2TN_vksS4n87amKDs4vxUbu+Gdng2daHPjHpX_3iO=91sBw@mail.gmail.com>
Message-ID: <CAL3CFcU2JL2ff-fJ1A6qVKoc+k4YiEDUzQNrN5tumKp5=n6A5w@mail.gmail.com>

The doc is correct.
For python2 `.update` method of hash objects accept str.
Python3 requires bytes, doc changed to something like

>>> import hashlib
>>> m = hashlib.md5()
>>> m.update(b"Nobody inspects")

On Thu, Nov 8, 2012 at 2:57 PM, Hugh Parker <hcp at pobox.com> wrote:
> http://docs.python.org/2/library/hashlib.html has an error:
>
> m.update("Blah") doesn't work.  It gives a type error.  To work, it needs to
> be m.update("Blah".encode('utf-8'))
>
> I'm using Python 3.3.
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



--
Thanks,
Andrew Svetlov

From report at bugs.python.org  Tue Nov 27 23:41:58 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 27 Nov 2012 22:41:58 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1354056118.53.0.495069004644.issue16438@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I'm still unable to figure out how to do it

You could look at Doc/library/unittest.rst, there are some tables that span multiple lines.  If you want a newline in the output too I think you have to add a blank line in the cell.

----------

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

From report at bugs.python.org  Wed Nov 28 02:05:43 2012
From: report at bugs.python.org (Kiet Tran)
Date: Wed, 28 Nov 2012 01:05:43 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1354064743.55.0.333728471361.issue16438@psf.upfronthosting.co.za>


Kiet Tran added the comment:

That document actually doesn't have any table that spans multiple lines. Here's the html page: http://docs.python.org/dev/library/unittest.html

Actually, I already know how to make a table span multiple lines from this stackoverflow page: http://stackoverflow.com/questions/13504595/multi-line-table-cell-in-restructuredtext

However, the problem is having the items in different columns match, as it depends on the width of the table, which is not fixed. For example, notice how the table is formatted nicely here: http://imgur.com/y1hLg
But if I shrink the width, the formatting just goes wrong: http://imgur.com/Oct9m

This is particularly problematic because some elements in the table have long lines.

----------

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

From report at bugs.python.org  Wed Nov 28 02:15:14 2012
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 28 Nov 2012 01:15:14 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1354065301.33.0.333211156744.issue5066@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Version 2 of the patch change include:
-help.txt removed all tabs and replaced with spaces, as suggested by Roger
-help.txt re-inserted the section on running IDLE without a subprocess as suggested by Roger
-Added a note on line 162 (idle.rst) about how the Python Community standard is to use spaces and not tabs as suggested by ezio
-Line 340 (idle.rst) where the Emacs bindings are rendered seemed to work fine on my computer without the spaces but I think ezio is correct spaces should be present so I added them
-Line 354 (idle.rst): are restricted to four spaces due to TCL/Tk issues.)s/issues/limitations/ so I replaced issues with limitations

Thanks for the feedback Roger and ezio!

----------
Added file: http://bugs.python.org/file28141/5066IDLEocumentationforUnixObsoleteIncorrectVersion2.patch

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

From report at bugs.python.org  Wed Nov 28 02:19:29 2012
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 28 Nov 2012 01:19:29 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1354065551.85.0.579638667748.issue5066@psf.upfronthosting.co.za>


Todd Rovito added the comment:

For version 2 of the patch 
-Line 340 (idle.rst) where the Emacs bindings are rendered seemed to work fine on my computer without the spaces but I think ezio is correct spaces should be present so I added them

******SHOULD BE******
-Line 340 (idle.rst) where the Emacs bindings are rendered seemed to work fine on my computer without the empty line between entries but I think ezio is correct empty lines should be present so I added empty lines just to be safe

----------

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

From report at bugs.python.org  Wed Nov 28 03:17:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 02:17:35 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354069055.35.0.884892975716.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Attaching new patch to address Ezio's suggestions on Rietveld.  I will also respond to those comments on Rietveld shortly.

----------
Added file: http://bugs.python.org/file28142/issue-15990-5-default.patch

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

From chris.jerdonek at gmail.com  Wed Nov 28 03:25:03 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Wed, 28 Nov 2012 02:25:03 -0000
Subject: [docs] solidify argument/parameter terminology (issue 15990)
Message-ID: <20121128022503.31755.17205@psf.upfronthosting.co.za>


http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode47
Doc/glossary.rst:47: ``name=``) in the calling syntax or passed as a
value in a dictionary
On 2012/11/26 22:04:35, ezio.melotti wrote:
> s/in the calling syntax/in a function call/?
> For consistency with the next definition you should use "and/or" here
too.

"and/or" doesn't fit here because "argument" is singular.  You would
never have an argument that is both preceded by an identifier and
occurring as a value.  The situation is different below because it
discusses multiple positional arguments -- some of which can appear at
the beginning and others in the iterable.  I used plural arguments below
because I did not want to give the impression that a positional argument
can occur only at the very beginning.  Multiple positional arguments can
appear at the beginning of the argument list.

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode571
Doc/glossary.rst:571: :term:`keyword argument`.  This is the default
kind of parameter, for
On 2012/11/26 22:04:35, ezio.melotti wrote:
> I wouldn't link to positional/keyowrd arguments now that they are
dummy.  If
> linking to argument is too "vague" you /could/ add references before
the two
> definitions of argument.

I will just link them to "argument" so the reader can still know they
are separately defined.

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode605
Doc/glossary.rst:605: :ref:`function` section, and :pep:`362`.
On 2012/11/26 22:04:35, ezio.melotti wrote:
> It occurred to me that there's another distinction that can be made:
required vs
> optional.  Should we add this too?

I mentioned them but do not feel more detail should be added here. 
Perhaps a question could be added to the FAQ on how to specify that
arguments be optional vs. required.  But that should be done as part of
a different issue.

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

From report at bugs.python.org  Wed Nov 28 03:42:55 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 02:42:55 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354070575.51.0.984187998795.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

For some reason, Rietveld is erroring out every time I try to reply to one of the comments.  So I am pasting the reply below:

[Issue in the Rietveld tracker here:
 http://code.google.com/p/rietveld/issues/detail?id=394 ]

On 2012/11/26 22:07:50, ezio.melotti wrote:
> 
> Note that I took this from the pep.  The pep could get the same clarification
> (unless I made it more confusing than it was).

>From what I have observed, PEPs tend to be left alone after they are accepted.  But that could simply be a misperception on my part.  What is the process for updating PEPs and whose approval is needed, etc?  In any case, that could be done as part of a separate issue.

----------

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

From report at bugs.python.org  Wed Nov 28 05:53:58 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 04:53:58 +0000
Subject: [docs] [issue16209] add a "class str" entry to the docs
In-Reply-To: <1350032597.23.0.0536115574586.issue16209@psf.upfronthosting.co.za>
Message-ID: <1354078438.72.0.933013939131.issue16209@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Attaching new patch to address Ezio's suggestions on Rietveld.

----------
Added file: http://bugs.python.org/file28143/issue-16209-3-default.patch

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

From ezio.melotti at gmail.com  Wed Nov 28 06:04:09 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Wed, 28 Nov 2012 05:04:09 -0000
Subject: [docs] add a "class str" entry to the docs (issue 16209)
Message-ID: <20121128050409.19424.7998@psf.upfronthosting.co.za>


http://bugs.python.org/review/16209/diff/6699/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/16209/diff/6699/Doc/library/functions.rst#newcode1244
Doc/library/functions.rst:1244: Return a :class:`str` version of
*object*.  See :func:`str` for details.
Wouldn't :func:`str` link to this entry?  Or would it just link to
:class:`str` but add the () at the end?

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

From chris.jerdonek at gmail.com  Wed Nov 28 06:06:05 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Wed, 28 Nov 2012 05:06:05 -0000
Subject: [docs] add a "class str" entry to the docs (issue 16209)
Message-ID: <20121128050605.31756.10564@psf.upfronthosting.co.za>

Reviewers: ezio.melotti,


http://bugs.python.org/review/16209/diff/6684/Doc/extending/newtypes.rst
File Doc/extending/newtypes.rst (right):

http://bugs.python.org/review/16209/diff/6684/Doc/extending/newtypes.rst#newcode986
Doc/extending/newtypes.rst:986: single: string; object presentation
On 2012/11/27 18:04:38, ezio.melotti wrote:
> representation?

I changed this.  If you think this should be changed, the section title
should probably be changed as well.  Note that an argument could be made
that "presentation" is better than "representation".  The latter
connotes the internal representation of an object, whereas presentation
connotes how something should be presented to others (which is what
str/repr do).

http://bugs.python.org/review/16209/diff/6684/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/16209/diff/6684/Doc/library/functions.rst#newcode1246
Doc/library/functions.rst:1246: See the :class:`str` type for
documentation of ``str()``.
On 2012/11/27 18:04:38, ezio.melotti wrote:
> This sounds a bit confusing and redundant to me.
> There are two links to textseq with two different texts, two to
:class:`str` (I
> think that's somewhere near textseq), and ``str`` is used 4 more
times.
> 
> I think all this (including the following line) can be summarized to:
> Return a :class:`str` version of *object*.
> See also the documentation of the :class:`str` type and :ref:`textseq`
for more
> information about strings.

I simplified the wording.  Note that I think it is important to state
explicitly rather than implicitly that str is a type since readers are
going to the entry expecting a function, so this should be made
unambiguously clear.

Regarding occurrences of "str", one of those occurrences was because I
wanted to avoid referring to the entry as "this function" or "the [str]
constructor."  In an earlier, similar issue you commented against using
either term for built-in functions that correspond to types.



Please review this at http://bugs.python.org/review/16209/

Affected files:
  Doc/c-api/object.rst
  Doc/extending/newtypes.rst
  Doc/library/functions.rst
  Doc/library/stdtypes.rst
  Doc/reference/datamodel.rst



From chris.jerdonek at gmail.com  Wed Nov 28 06:13:22 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Wed, 28 Nov 2012 05:13:22 -0000
Subject: [docs] add a "class str" entry to the docs (issue 16209)
Message-ID: <20121128051322.31756.24568@psf.upfronthosting.co.za>


http://bugs.python.org/review/16209/diff/6699/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/16209/diff/6699/Doc/library/functions.rst#newcode1244
Doc/library/functions.rst:1244: Return a :class:`str` version of
*object*.  See :func:`str` for details.
On 2012/11/28 06:04:09, ezio.melotti wrote:
> Wouldn't :func:`str` link to this entry?  Or would it just link to
:class:`str`
> but add the () at the end?

They link to the same thing: the full definition on the other page.  I
checked.  Only the link at the top of the Built-in Functions page links
to the stub entry.

(I know there are old comments on a related issue suggesting that they
can link to separate things, but as far as I could tell through
experimentation it is a Sphinx constraint that they link to the same
thing.)

And yes, "func" adds the parentheses and "class" leaves them off.  I
choose which to use based on whether I want to emphasize/refer to the
type or the constructor/function aspect.

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

From ezio.melotti at gmail.com  Wed Nov 28 06:14:27 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Wed, 28 Nov 2012 05:14:27 -0000
Subject: [docs] solidify argument/parameter terminology (issue 15990)
Message-ID: <20121128051427.19424.71034@psf.upfronthosting.co.za>


http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode47
Doc/glossary.rst:47: ``name=``) in the calling syntax or passed as a
value in a dictionary
On 2012/11/28 03:25:03, cjerdonek wrote:
> On 2012/11/26 22:04:35, ezio.melotti wrote:
> > s/in the calling syntax/in a function call/?
> > For consistency with the next definition you should use "and/or"
here too.
> 
> "and/or" doesn't fit here because "argument" is singular.  You would
never have
> an argument that is both preceded by an identifier and occurring as a
value. 
> The situation is different below because it discusses multiple
positional
> arguments -- some of which can appear at the beginning and others in
the
> iterable.  I used plural arguments below because I did not want to
give the
> impression that a positional argument can occur only at the very
beginning. 
> Multiple positional arguments can appear at the beginning of the
argument list.

OK

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode571
Doc/glossary.rst:571: :term:`keyword argument`.  This is the default
kind of parameter, for
On 2012/11/28 03:25:03, cjerdonek wrote:
> On 2012/11/26 22:04:35, ezio.melotti wrote:
> > I wouldn't link to positional/keyowrd arguments now that they are
dummy.  If
> > linking to argument is too "vague" you /could/ add references before
the two
> > definitions of argument.
> 
> I will just link them to "argument" so the reader can still know they
are
> separately defined.

OK

http://bugs.python.org/review/15990/diff/6665/Doc/glossary.rst#newcode605
Doc/glossary.rst:605: :ref:`function` section, and :pep:`362`.
On 2012/11/28 03:25:03, cjerdonek wrote:
> On 2012/11/26 22:04:35, ezio.melotti wrote:
> > It occurred to me that there's another distinction that can be made:
required
> vs
> > optional.  Should we add this too?
> 
> I mentioned them but do not feel more detail should be added here. 
Perhaps a
> question could be added to the FAQ on how to specify that arguments be
optional
> vs. required.  But that should be done as part of a different issue.

Adding a separate FAQ just after the one about args vs params SGTM.  If
you think details shouldn't be added here it's OK, but there should be
at least a link to this FAQ too.
Feel free to address this in a separate issue.

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

From report at bugs.python.org  Wed Nov 28 10:03:32 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 09:03:32 +0000
Subject: [docs] [issue16568] allow constructors to be documented separately
	from class
Message-ID: <1354093412.82.0.692042663136.issue16568@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to settle on and provide a way to document the constructor of a class separately from the overall summary/description of a class.

This is something that Ezio, Nick, and I discussed briefly on IRC a few hours ago.  We all see the value in it.

Currently, Sphinx's "class" directive is used in many places to document the constructor of a class.  One drawback of this approach is that linking to the class using the :class: role links to the constructor as opposed to the class summary.  As a result, in many cases the class description needs to be added before the class directive, and a second link needs to be created and used for the overall description.

One way to address this would be to create a new "constructor" directive similar to directives like method, classmethod, and staticmethod.  The constructor documentation could then be hyperlinked to using a new :constructor: role (or perhaps :ctor: to go with the pattern of 4-letter roles).  The class summary could then go immediately after the class directive, with the constructor directive following, as follows:

.. class:: Foo

   Description of Foo.

   .. constructor:: Foo(bar=1)
   
      Return a Foo.

This could render as--

class **Foo**

   Description of Foo.
   
   *constructor* **Foo**(bar=1)

      Return a Foo.

It is possible that something similar could be achieved by abusing the method directive for constructors and linking to them using :meth:`~Foo.Foo`, but that wouldn't be ideal in a few respects.

Nick also raised a related issue for base classes, etc.  I will let him speak to that issue, which might be best as part of another new issue.

----------
assignee: docs at python
components: Documentation
messages: 176524
nosy: chris.jerdonek, docs at python, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: allow constructors to be documented separately from class
type: enhancement

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

From report at bugs.python.org  Wed Nov 28 10:46:22 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Nov 2012 09:46:22 +0000
Subject: [docs] [issue16209] add a "class str" entry to the docs
In-Reply-To: <1350032597.23.0.0536115574586.issue16209@psf.upfronthosting.co.za>
Message-ID: <3YBH7K1Sl6zRdB@mail.python.org>


Roundup Robot added the comment:

New changeset 0097379df2e1 by Chris Jerdonek in branch '3.3':
Add a str class entry to the "Text Sequence Type" section (issue #16209).
http://hg.python.org/cpython/rev/0097379df2e1

New changeset 81ac75c64780 by Chris Jerdonek in branch 'default':
Merge from 3.3: Add a str class entry to the string section (issue #16209).
http://hg.python.org/cpython/rev/81ac75c64780

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

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

From report at bugs.python.org  Wed Nov 28 10:50:51 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 09:50:51 +0000
Subject: [docs] [issue16209] add a "class str" entry to the docs
In-Reply-To: <1350032597.23.0.0536115574586.issue16209@psf.upfronthosting.co.za>
Message-ID: <1354096251.41.0.621435425329.issue16209@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


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

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

From report at bugs.python.org  Wed Nov 28 11:03:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 10:03:18 +0000
Subject: [docs] [issue16205] update :class:`str` references to link to the
	str type	section
In-Reply-To: <1350008126.16.0.898285675428.issue16205@psf.upfronthosting.co.za>
Message-ID: <1354096998.42.0.884581188091.issue16205@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

This was addressed by issue #16209 since with that change :class:`str` and :func:`str` now both go to the new str class entry in the string type section.  See also the new issue #16568.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> add a "class str" entry to the docs

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

From report at bugs.python.org  Wed Nov 28 11:34:39 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Nov 2012 10:34:39 +0000
Subject: [docs] [issue16323] Wrong C API documentation for locale encoding
In-Reply-To: <1351173455.0.0.737976146006.issue16323@psf.upfronthosting.co.za>
Message-ID: <3YBJC22MHSzRGj@mail.python.org>


Roundup Robot added the comment:

New changeset 11629c14ce1f by Andrew Svetlov in branch '3.3':
Issue #16323: Fix wrong C API documentation for locale encoding.
http://hg.python.org/cpython/rev/11629c14ce1f

New changeset 6f3d3003acf3 by Andrew Svetlov in branch 'default':
Merge issue #16323: Fix wrong C API documentation for locale encoding.
http://hg.python.org/cpython/rev/6f3d3003acf3

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

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

From report at bugs.python.org  Wed Nov 28 11:35:05 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 28 Nov 2012 10:35:05 +0000
Subject: [docs] [issue16323] Wrong C API documentation for locale encoding
In-Reply-To: <1351173455.0.0.737976146006.issue16323@psf.upfronthosting.co.za>
Message-ID: <1354098905.51.0.555998536333.issue16323@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed. Thanks.

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

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

From report at bugs.python.org  Wed Nov 28 11:52:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Nov 2012 10:52:56 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <3YBJc8102gzRSG@mail.python.org>


Roundup Robot added the comment:

New changeset 69d5d834c5cb by Chris Jerdonek in branch '3.2':
Improve argument/parameter documentation (issue #15990).
http://hg.python.org/cpython/rev/69d5d834c5cb

New changeset 40fd26a4206b by Chris Jerdonek in branch '3.3':
Merge from 3.2: improve argument/parameter documentation (issue #15990).
http://hg.python.org/cpython/rev/40fd26a4206b

New changeset 74d8a2a20c52 by Chris Jerdonek in branch 'default':
Merge from 3.3: improve argument/parameter documentation (issue #15990).
http://hg.python.org/cpython/rev/74d8a2a20c52

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

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

From report at bugs.python.org  Wed Nov 28 12:03:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 11:03:39 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354100619.88.0.138256086503.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I realize now that this would also be good for 2.7.  I will try to do that tomorrow.

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

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

From report at bugs.python.org  Wed Nov 28 13:22:39 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Nov 2012 12:22:39 +0000
Subject: [docs] [issue16323] Wrong C API documentation for locale encoding
In-Reply-To: <1351173455.0.0.737976146006.issue16323@psf.upfronthosting.co.za>
Message-ID: <1354105359.0.0.856076310771.issue16323@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think the sentence "If a byte sequence can be decoded as a surrogate character and *errors* is not ``"strict"``, then the byte sequence is escaped using the ``"surrogateescape"`` error handler instead of being decoded." is redundant.

----------

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

From report at bugs.python.org  Wed Nov 28 13:23:03 2012
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 28 Nov 2012 12:23:03 +0000
Subject: [docs] [issue16554] The description of the argument of
	MAKE_FUNCTION and	MAKE_CLOSURE is incorrect
In-Reply-To: <1353881740.2.0.222803994959.issue16554@psf.upfronthosting.co.za>
Message-ID: <1354105383.25.0.936942981427.issue16554@psf.upfronthosting.co.za>


Daniel Urban added the comment:

Sorry, I won't have time for that in the following weeks.

----------

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

From report at bugs.python.org  Wed Nov 28 13:37:30 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 28 Nov 2012 12:37:30 +0000
Subject: [docs] [issue16323] Wrong C API documentation for locale encoding
In-Reply-To: <1351173455.0.0.737976146006.issue16323@psf.upfronthosting.co.za>
Message-ID: <1354106250.75.0.290416956392.issue16323@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Really I don't know what's better. Victor, what do you think?

----------

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

From report at bugs.python.org  Wed Nov 28 15:35:20 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 28 Nov 2012 14:35:20 +0000
Subject: [docs] [issue16557] PEP 380 isn't reflected in the Functional
	Programming	HOWTO
In-Reply-To: <1353931638.82.0.313274646017.issue16557@psf.upfronthosting.co.za>
Message-ID: <1354113320.22.0.631205092938.issue16557@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Wed Nov 28 16:00:07 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Nov 2012 15:00:07 +0000
Subject: [docs] [issue16323] Wrong C API documentation for locale encoding
In-Reply-To: <1354106250.75.0.290416956392.issue16323@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaSScO+TWOrit20SJQ_i86zeM03Z+LKDNtNskDS+5T7Sw@mail.gmail.com>


STINNER Victor added the comment:

"If a byte sequence can be decoded as a surrogate character and
*errors* is not ``"strict"``, then the byte sequence is escaped using
the ``"surrogateescape"`` error handler instead of being decoded."

I don't understand this sentence but it sounds to be wrong. The
"surrogateescape" is only used if errors="surrogateescape"...

If errors is set and is different to "strict" and "surrogateescape",
an error is raised.

2012/11/28 Andrew Svetlov <report at bugs.python.org>:
>
> Andrew Svetlov added the comment:
>
> Really I don't know what's better. Victor, what do you think?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16323>
> _______________________________________

----------

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

From report at bugs.python.org  Wed Nov 28 18:06:06 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 28 Nov 2012 17:06:06 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354122366.2.0.0714881676982.issue15990@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum, python-dev

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

From report at bugs.python.org  Wed Nov 28 18:18:36 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Nov 2012 17:18:36 +0000
Subject: [docs] [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <3YBT9712cNzQJt@mail.python.org>


Roundup Robot added the comment:

New changeset bbecbcff0ce4 by Andrew Svetlov in branch '3.2':
Issue #11076: document the way to convert argparse.Namespace to a dict.
http://hg.python.org/cpython/rev/bbecbcff0ce4

New changeset ee4e31845977 by Andrew Svetlov in branch '3.3':
Merge issue #11076: document the way to convert argparse.Namespace to a dict.
http://hg.python.org/cpython/rev/ee4e31845977

New changeset 63ff2d421d1a by Andrew Svetlov in branch 'default':
Merge issue #11076: document the way to convert argparse.Namespace to a dict.
http://hg.python.org/cpython/rev/63ff2d421d1a

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

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

From report at bugs.python.org  Wed Nov 28 18:26:42 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 28 Nov 2012 17:26:42 +0000
Subject: [docs] [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1354123602.86.0.696246439801.issue11076@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Sorry, looks like it work already was done. Reverting: c008f070f88a 814403d824a5 ddcf09a348ca

----------
nosy: +asvetlov
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Nov 28 19:34:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 18:34:11 +0000
Subject: [docs] [issue11076] Iterable argparse Namespace
In-Reply-To: <1296461103.49.0.397676179483.issue11076@psf.upfronthosting.co.za>
Message-ID: <1354127651.72.0.345437580613.issue11076@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Following up Andrew's last comment, for the record, it looks like this was done as part of issue 8982.

----------
nosy: +chris.jerdonek
superseder:  -> argparse docs cross reference Namespace as a class but the Namespace class is not documented

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

From report at bugs.python.org  Wed Nov 28 19:44:49 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Nov 2012 18:44:49 +0000
Subject: [docs] [issue16568] allow constructors to be documented separately
	from class
In-Reply-To: <1354093412.82.0.692042663136.issue16568@psf.upfronthosting.co.za>
Message-ID: <1354128289.3.0.119194389793.issue16568@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I was wondering if this should be called initializer instead of constructor.  Another idea is to keep using the "method" directive and use :initializer: to differentiate it from the others.  This might be easier to implement, but OTOH is not consistent with the staticmethod and classmethod directives though.

----------

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

From report at bugs.python.org  Wed Nov 28 19:49:04 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Nov 2012 18:49:04 +0000
Subject: [docs] [issue16568] allow constructors to be documented separately
	from class
In-Reply-To: <1354093412.82.0.692042663136.issue16568@psf.upfronthosting.co.za>
Message-ID: <1354128544.08.0.715742907734.issue16568@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Nov 28 22:18:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 21:18:39 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354137519.15.0.979607944722.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Note that I took this from the pep.  The pep could get the same clarification
> (unless I made it more confusing than it was).

Reading the following, it seems that PEPs aren't generally clarified after becoming Final (as is PEP 362):

"In general, Standards track PEPs are no longer modified after they have reached the Final state."

(from http://www.python.org/dev/peps/pep-0001/#pep-maintenance )

----------

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

From report at bugs.python.org  Wed Nov 28 23:01:34 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 28 Nov 2012 22:01:34 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354140093.13.0.354767124233.issue15990@psf.upfronthosting.co.za>


?ric Araujo added the comment:

PEP 1 doesn?t reflect current practice then.

----------

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

From report at bugs.python.org  Wed Nov 28 23:04:03 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Nov 2012 22:04:03 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354140243.44.0.164294209587.issue15990@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The PEPs don't undergo major changes, but AFAIU typo fixes and minor clarifications/rephrasing are allowed.

----------

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

From report at bugs.python.org  Thu Nov 29 00:53:40 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 28 Nov 2012 23:53:40 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354146820.75.0.472593438669.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks for the clarification.  I will create an issue to clarify that part of PEP 1.  It should also say who is allowed to make such changes and whether/from whom approval is necessary, etc.

----------

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

From report at bugs.python.org  Thu Nov 29 01:56:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 29 Nov 2012 00:56:56 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
Message-ID: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to clarify the policy in PEP 1 regarding non-substantive changes to PEPs in the Final state (minor clarifications, rephrasings, etc).

Currently, PEP 1 says, "In general, Standards track PEPs are no longer modified after they have reached the Final state."

(from http://www.python.org/dev/peps/pep-0001/#pep-maintenance )

However, others have pointed out that minor clarifications and rephrasings are in fact allowed:

http://bugs.python.org/issue15990#msg176575

The updated wording should also state the policy or process regarding such changes (who is allowed to make them and whether and from whom approval is needed to make such changes, etc).

----------
assignee: docs at python
components: Documentation
messages: 176598
nosy: barry, chris.jerdonek, docs at python, eric.araujo, ezio.melotti, goodger, ncoghlan
priority: normal
severity: normal
status: open
title: clarify policy on updates to final peps
type: enhancement

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

From report at bugs.python.org  Thu Nov 29 01:57:44 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 29 Nov 2012 00:57:44 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354150663.84.0.542596667625.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I just created issue 16574 to clarify PEP 1 with regard to the above.

----------

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

From report at bugs.python.org  Thu Nov 29 02:49:19 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 29 Nov 2012 01:49:19 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354153759.15.0.953277251507.issue16574@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I don't think this needs clarification. The status quo is fine.

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

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

From report at bugs.python.org  Thu Nov 29 03:00:54 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 29 Nov 2012 02:00:54 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354154454.28.0.847723930068.issue16574@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Are you saying that PEP 1 is correct and that Final PEPs should not be modified, or that the PEP isn't correct but that it shouldn't be modified?

If the latter, for someone new it's not clear whether minor clarifications are permitted and if so, how to go about making one.

----------

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

From report at bugs.python.org  Thu Nov 29 03:08:12 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 29 Nov 2012 02:08:12 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354154892.54.0.367739099352.issue16574@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I think Brett edited PEP 302 a decade after its acceptance.

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

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

From report at bugs.python.org  Thu Nov 29 03:37:48 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Nov 2012 02:37:48 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <20121128213744.2992f7e3@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Nov 29, 2012, at 12:56 AM, Chris Jerdonek wrote:

>
>Currently, PEP 1 says, "In general, Standards track PEPs are no longer
>modified after they have reached the Final state."

I agree w/mvl.  This is still true, and it doesn't mean PEPs can't be modified
after reaching Final state.

----------

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

From report at bugs.python.org  Thu Nov 29 03:39:46 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 29 Nov 2012 02:39:46 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354156786.91.0.386123800354.issue16574@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Right, ?in general? is good enough to capture what we do.  Chris, closing?

----------

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

From report at bugs.python.org  Thu Nov 29 03:46:21 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 29 Nov 2012 02:46:21 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354157181.08.0.872921468818.issue16574@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Okay, so in a comment to issue 15990, Ezio suggested that some clarifying changes to PEP 362 might be worth making.  How would I (or someone else) go about doing that?  Where would they begin?

I think this recent e-mail from Nick applies:

http://mail.python.org/pipermail/python-dev/2012-November/122525.html

----------

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

From report at bugs.python.org  Thu Nov 29 03:53:08 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 29 Nov 2012 02:53:08 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354157588.1.0.837645576537.issue16574@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

By the way, I don't especially care if the clarification goes in the PEP itself or not.  What's more important is that it be documented *somewhere* (which could also be the devguide, for example).  My interest in knowing the process is genuine.

----------

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

From report at bugs.python.org  Thu Nov 29 04:19:49 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Nov 2012 03:19:49 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354159189.41.0.552761379706.issue16574@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Once PEPs reach their final status, I view them basically done if there is more official docs. For instance, I updated PEP 302 because the import and importlib docs were not as thorough as they are now thanks to Barry. But now that we have proper docs I don't plan to muck with PEP 302 anymore. That being said, I wouldn't object if someone chose to put the effort into updating PEP 302 in the future, I just won't.

----------

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

From report at bugs.python.org  Thu Nov 29 04:28:13 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Nov 2012 03:28:13 +0000
Subject: [docs] [issue16568] allow constructors to be documented separately
	from class
In-Reply-To: <1354093412.82.0.692042663136.issue16568@psf.upfronthosting.co.za>
Message-ID: <1354159693.08.0.396350844767.issue16568@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Nov 29 04:42:14 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 29 Nov 2012 03:42:14 +0000
Subject: [docs] [issue16568] allow constructors to be documented separately
	from class
In-Reply-To: <1354093412.82.0.692042663136.issue16568@psf.upfronthosting.co.za>
Message-ID: <1354160534.45.0.570200548261.issue16568@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I?m interested in an explanation of the value of doing this.

In the threading docs for example, the classes (i.e. initializers) are documented in one section, with awkward links to ?Thread objects?, ?Lock objects?, etc.  This felt much more cumbersome to me than more modern class/attribute/method combos.  Isn?t it the simplest thing to document one class, usage, constructors and all attributes, in one place?

On the other hand, I don?t have the view of an outsider anymore, so I can?t say what makes sense / reads better for the doc?s audience (as opposed to doc editors).

----------

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

From report at bugs.python.org  Thu Nov 29 04:45:47 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 29 Nov 2012 03:45:47 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354160747.51.0.213051769928.issue16574@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I think the gist here is that ?in general? is good enough, given that there is unwritten consensus about what edits are possible in the developers? heads.  Most of the time unwritten knowledge is not good, but (if I get what Martin and Barry mean correctly) for PEP rules this is fine.  We don?t want an over-detailed or inflexible process.

About the mail from Nick: it was talking about writing a new informational PEP, so I don?t see the link with final standards track PEPs.

----------

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

From report at bugs.python.org  Thu Nov 29 04:53:24 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Nov 2012 03:53:24 +0000
Subject: [docs] [issue16568] allow constructors to be documented separately
	from class
In-Reply-To: <1354093412.82.0.692042663136.issue16568@psf.upfronthosting.co.za>
Message-ID: <1354161204.05.0.478252415033.issue16568@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This came up while documenting the str type in datamodel.rst (IIRC), and linking to it from functions.rst.

On one hand you want to say what the str type is, on the other hand you want to document the constructor and explain how can you use str() to obtain str objects.
Putting both under the constructor doesn't work too well, especially when there's a lot of text.  Putting the str type description in a plain paragraph before the "class" directive doesn't work too well either, because :class:`str` will link to the constructor documentation.

The idea is to keep the two separate but still provide an easy way to link to the class without missing the general description.

----------

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

From report at bugs.python.org  Thu Nov 29 05:06:11 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Nov 2012 04:06:11 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354161971.58.0.461351526145.issue16574@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

FTR the reason I suggested to modify PEP 362 is that we are linking to it from the docs.  This means that people will go and read the PEP looking for clarifications, so the PEP should be clear.  In this regard I see the PEP (or at least the relevant section) as documentation, and given that it's about an aspect of Python that is not going to change any time soon, it makes sense to get it right and keep referencing the PEP.
This doesn't normally apply to most of the other PEPs, especially if what they proposed is now documented on docs.python.org.

(On a side note, I now noticed that the parameter kinds are also documented in http://docs.python.org/dev/library/inspect.html#inspect.Parameter.kind, so we could link to that instead of linking to the PEP.)

----------

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

From report at bugs.python.org  Thu Nov 29 05:07:36 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 29 Nov 2012 04:07:36 +0000
Subject: [docs] [issue16568] allow constructors to be documented separately
	from class
In-Reply-To: <1354093412.82.0.692042663136.issue16568@psf.upfronthosting.co.za>
Message-ID: <1354162056.54.0.730207470873.issue16568@psf.upfronthosting.co.za>


?ric Araujo added the comment:

For all the built-in types, I see the value now.

Thinking aloud: Separating the namespaces used by the str and func roles would probably require too many changes in Sphinx.

The current way is to use the function directive to document the class/constructor usage in one place, and use ref to link to the section describing the class.  You can also have the cool class/method combo if you configure the class directive with the noindex option.  Is that not good enough?

----------

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

From report at bugs.python.org  Thu Nov 29 05:18:10 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Nov 2012 04:18:10 +0000
Subject: [docs] [issue16568] allow constructors to be documented separately
	from class
In-Reply-To: <1354093412.82.0.692042663136.issue16568@psf.upfronthosting.co.za>
Message-ID: <1354162690.41.0.569458932361.issue16568@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> For all the built-in types, I see the value now.

The same applies for non built-in types too though (e.g. http://docs.python.org/3.4/library/collections.html).  The only difference is that the built-in ones have entries in functions.rst and use more links.

> Is that not good enough?

Not really, and creating additional links and suppressing others with :noindex: feels wrong.  The idea is that :class:`str` should just work and link to the right place.

----------

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

From report at bugs.python.org  Thu Nov 29 05:22:21 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 29 Nov 2012 04:22:21 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354162941.61.0.486926707138.issue16574@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> I think the gist here is that ?in general? is good enough, given that there is unwritten consensus about what edits are possible in the developers? heads.

As I said, I'm okay with keeping the PEP as is (with "in general," etc) provided a clarification is documented elsewhere like in the devguide.  What I want to avoid are, as you say, there being "unwritten" rules about changing PEPs in the Final state.  (It was the general remarks about unwritten rules in Nick's e-mail that I felt were applicable.)

The written rules need not be overly-detailed or inflexible so long as they give newcomers without that common understanding a leg up on what to do.  It could be something as simple as "non-substantive changes to PEPs in the Final state should be treated like any other changes to the documentation" (or whatever the general process/criteria should be for such changes).

----------

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

From report at bugs.python.org  Thu Nov 29 05:22:30 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Nov 2012 04:22:30 +0000
Subject: [docs] [issue13094] Need Programming FAQ entry for the behavior of
	closures
In-Reply-To: <1317652797.3.0.357677492942.issue13094@psf.upfronthosting.co.za>
Message-ID: <1354162950.74.0.130257862452.issue13094@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ezio.melotti

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

From report at bugs.python.org  Thu Nov 29 06:49:02 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Nov 2012 05:49:02 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354168142.11.0.326883937368.issue16574@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yeah, I agree the "in general" in PEP 1 is enough of a caveat.

The unwritten rules in this particular case are that if something in a PEP is important enough to be permanently referenced, then it's important enough to be part of the language spec (either the main language reference or the stdlib reference), or else it should be a versioned informational PEP that gets replaced when updated (e.g. the WSGI spec, DB-API, packaging metadata etc).

There have been a few PEPs, most notably the import PEPs, where that wasn't possible because such docs didn't exist, and documenting the existing system would have taken so many caveats that nobody was ever willing to do it. So PEP 302 became the de facto documentation for the modular part of the import system. Now that we have real docs in the language reference for 3.3+, PEP 302 will finally be able fade into irrelevance as a normative document.

Now that the import case is resolved, I can't think of any Final PEPs where we're likely to break the rules any more, unless it's just to update them with a link to the normative docs.

----------
components: +Devguide -Documentation

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

From report at bugs.python.org  Thu Nov 29 13:16:37 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 29 Nov 2012 12:16:37 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354191396.74.0.566795475288.issue16574@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

1. I think that the PEP author has the final say as to what specific text goes into the PEP. Contributors shouldn't modify other people's PEP without consent from the author(s).

2. This holds for all stages, including the Final stage. If the PEP author wants to clarify/elaborate, they may; if they don't feel like it, they don't need to (even if the implementation later deviates from the PEP).

3. We should avoid to refer to PEPs for specification in the documentation. If there is a documentation issue proposing to update the PEP because it's referenced from the documentation, the right action should be to stop referencing it, and to incorporate the PEP text into the documentation (as needed).

4. Even without the "In general" cop-out, I think the PEP is fine as written. It doesn't say (as Chris suggested in msg176603) that Final PEPs *should not* be modified, but that they *are not* modified. PEP 1 describes an ideal process, nobody should be surprised that the real world does not always follow the ideal. My biggest complaint about PEP 1 not being followed is the "PEP authors are responsible for collecting community feedback" requirement. Editing Final PEPs is absolutely no concern to me, since the PEP has already achieved what it was written for. So even if this rule was regularly ignored, I'd still continue to be a happy contributor to Python.

----------

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

From report at bugs.python.org  Thu Nov 29 13:27:05 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 29 Nov 2012 12:27:05 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354191396.74.0.566795475288.issue16574@psf.upfronthosting.co.za>
Message-ID: <20121129072702.16a2e874@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Nov 29, 2012, at 12:16 PM, Martin v. L?wis wrote:

>1. I think that the PEP author has the final say as to what specific text
>goes into the PEP. Contributors shouldn't modify other people's PEP without
>consent from the author(s).
>
>2. This holds for all stages, including the Final stage. If the PEP author
>wants to clarify/elaborate, they may; if they don't feel like it, they don't
>need to (even if the implementation later deviates from the PEP).
>
>3. We should avoid to refer to PEPs for specification in the
>documentation. If there is a documentation issue proposing to update the PEP
>because it's referenced from the documentation, the right action should be to
>stop referencing it, and to incorporate the PEP text into the documentation
>(as needed).
>
>4. Even without the "In general" cop-out, I think the PEP is fine as
>written. It doesn't say (as Chris suggested in msg176603) that Final PEPs
>*should not* be modified, but that they *are not* modified. PEP 1 describes
>an ideal process, nobody should be surprised that the real world does not
>always follow the ideal. My biggest complaint about PEP 1 not being followed
>is the "PEP authors are responsible for collecting community feedback"
>requirement. Editing Final PEPs is absolutely no concern to me, since the PEP
>has already achieved what it was written for. So even if this rule was
>regularly ignored, I'd still continue to be a happy contributor to Python.

I agree with all of this.  Occasionally PEPs themselves may leave open the
possibility for future additions or changes.  Release schedule PEPs are one
example.  PEP 425 is another example, where the PEP seems like the logical
choice for registering future tags.

All this is fine IMHO, and doesn't need any further clarification in PEP 1.

----------

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

From report at bugs.python.org  Thu Nov 29 14:23:56 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Nov 2012 13:23:56 +0000
Subject: [docs] [issue16323] Wrong C API documentation for locale encoding
In-Reply-To: <1351173455.0.0.737976146006.issue16323@psf.upfronthosting.co.za>
Message-ID: <3YBzvv1k7TzQcQ@mail.python.org>


Roundup Robot added the comment:

New changeset af45e9ec35f0 by Andrew Svetlov in branch '3.3':
Remove redundant sentence from c-api docs (issue #16323)
http://hg.python.org/cpython/rev/af45e9ec35f0

New changeset efedd0f62a7e by Andrew Svetlov in branch 'default':
Merge: remove redundant sentence from c-api docs (issue #16323)
http://hg.python.org/cpython/rev/efedd0f62a7e

----------

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

From report at bugs.python.org  Thu Nov 29 14:25:08 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 29 Nov 2012 13:25:08 +0000
Subject: [docs] [issue16323] Wrong C API documentation for locale encoding
In-Reply-To: <1351173455.0.0.737976146006.issue16323@psf.upfronthosting.co.za>
Message-ID: <1354195508.81.0.783219452278.issue16323@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Removed bad sentence.

----------

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

From report at bugs.python.org  Thu Nov 29 15:32:29 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 29 Nov 2012 14:32:29 +0000
Subject: [docs] [issue16194] imp.load_dynamic imports wrong module when
	called	several times on a multi-module .so
In-Reply-To: <1349953870.22.0.50760531633.issue16194@psf.upfronthosting.co.za>
Message-ID: <1354199548.91.0.037154996728.issue16194@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

I think it should not be fixed in 2.7, so I guess to close the issue as wontfix.

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

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

From report at bugs.python.org  Thu Nov 29 16:08:52 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Nov 2012 15:08:52 +0000
Subject: [docs] [issue16194] imp.load_dynamic imports wrong module when
	called	several times on a multi-module .so
In-Reply-To: <1349953870.22.0.50760531633.issue16194@psf.upfronthosting.co.za>
Message-ID: <1354201732.21.0.85005329657.issue16194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The behaviour won't change in 2.7, but the docs at http://docs.python.org/2/library/imp.html#imp.load_dynamic still need to be clarified.

e.g. add a note like:

Note: the import internals identify extension modules by filename, so doing ``foo = load_dynamic("foo", "mod.so")`` and ``bar = load_dynamic("bar", "mod.so")`` will result in both foo and bar referring to the same module, regardless of whether or not ``mod.so`` exports an ``initbar`` function. On systems which support them, symlinks can be used to import multiple modules from the same shared library, as each reference to the module will use a different file name.

(probably flagged as a CPython implementation detail, since it's really an accident of the implementation rather than a deliberately considered language feature)

----------

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

From report at bugs.python.org  Thu Nov 29 16:15:26 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Nov 2012 15:15:26 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1354202126.49.0.752407171448.issue16421@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

One nice feature of this is the potential to simplify single-file distribution - pack your application into a zip file, and only need to extract a single shared library for *all* your extension modules, which could be handled via a utility function called in __main__.py rather than needing to be built into the interpreter.

----------

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

From report at bugs.python.org  Thu Nov 29 16:27:21 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 29 Nov 2012 15:27:21 +0000
Subject: [docs] [issue16194] imp.load_dynamic imports wrong module when
	called	several times on a multi-module .so
In-Reply-To: <1349953870.22.0.50760531633.issue16194@psf.upfronthosting.co.za>
Message-ID: <1354202841.41.0.951741947285.issue16194@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Pushed doc patch.
Nick, is it good for you?

----------
Added file: http://bugs.python.org/file28159/issue16194.diff

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

From report at bugs.python.org  Thu Nov 29 17:55:23 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Nov 2012 16:55:23 +0000
Subject: [docs] [issue16421] importlib.machinery.ExtensionFileLoader cannot
	load	several modules from the same shared object
In-Reply-To: <1352212973.28.0.0255386645646.issue16421@psf.upfronthosting.co.za>
Message-ID: <1354208123.59.0.000505733020453.issue16421@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Are you still planning on committing this, Andrew?

----------

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

From report at bugs.python.org  Thu Nov 29 17:56:34 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 29 Nov 2012 16:56:34 +0000
Subject: [docs] [issue16194] imp.load_dynamic imports wrong module when
	called	several times on a multi-module .so
In-Reply-To: <1349953870.22.0.50760531633.issue16194@psf.upfronthosting.co.za>
Message-ID: <1354208194.07.0.599535751032.issue16194@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The doc patch LGTM.

----------

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

From report at bugs.python.org  Thu Nov 29 18:52:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Nov 2012 17:52:31 +0000
Subject: [docs] [issue16194] imp.load_dynamic imports wrong module when
	called	several times on a multi-module .so
In-Reply-To: <1349953870.22.0.50760531633.issue16194@psf.upfronthosting.co.za>
Message-ID: <3YC5sq15bzzQgg@mail.python.org>


Roundup Robot added the comment:

New changeset 94de77bd0b4b by Andrew Svetlov in branch '2.7':
Issue #16194: document imp.load_dynamic problems
http://hg.python.org/cpython/rev/94de77bd0b4b

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

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

From report at bugs.python.org  Thu Nov 29 18:54:11 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 29 Nov 2012 17:54:11 +0000
Subject: [docs] [issue16194] imp.load_dynamic imports wrong module when
	called	several times on a multi-module .so
In-Reply-To: <1349953870.22.0.50760531633.issue16194@psf.upfronthosting.co.za>
Message-ID: <1354211651.27.0.881081047011.issue16194@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Documentation is fixed, behavior cannot be changed.
Close the issue

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

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

From report at bugs.python.org  Thu Nov 29 20:25:09 2012
From: report at bugs.python.org (Paddy McCarthy)
Date: Thu, 29 Nov 2012 19:25:09 +0000
Subject: [docs] [issue16580] Add examples to int.to_bytres and int.from_bytes
Message-ID: <1354217109.61.0.534443148437.issue16580@psf.upfronthosting.co.za>


New submission from Paddy McCarthy:

http://docs.python.org/3.3/library/stdtypes.html?highlight=to_bytes#int.to_bytes and http://docs.python.org/3.3/library/stdtypes.html?highlight=to_bytes#int.to_bytes would benefit from an example showing what they do based on simpler coding.

I have such an example that I wrote here: http://paddy3118.blogspot.co.uk/2012/11/some-identities-for-python-inttobytes.html that you can use.

I.e.

>>> n = 2491969579123783355964723219455906992268673266682165637887
>>> length = 25
>>> n2bytesbig    = n.to_bytes(length, 'big')
>>> n2byteslittle = n.to_bytes(length, 'little')
>>> assert n2bytesbig    == bytes( (n >> i*8) & 0xff for i in reversed(range(length)))
>>> assert n2byteslittle == bytes( (n >> i*8) & 0xff for i in range(length))
>>> assert n == sum( n2bytesbig[::-1][i] << i*8 for i in range(length) )
>>> assert n == sum( n2byteslittle[i]    << i*8 for i in range(length) )
>>> assert n == int.from_bytes(n2bytesbig,    byteorder='big')
>>> assert n == int.from_bytes(n2byteslittle, byteorder='little')
>>>

----------
assignee: docs at python
components: Documentation
messages: 176671
nosy: docs at python, paddy3118
priority: normal
severity: normal
status: open
title: Add examples to int.to_bytres and int.from_bytes
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov 29 20:44:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 29 Nov 2012 19:44:38 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354218278.1.0.194182269953.issue15990@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Attaching a 2.7 version of the patch for this issue.

>From the patch committed to Python 3, I removed mention of keyword-only parameters, inspect.Parameter, and PEP 362 (because all are specific to Python 3).

----------
Added file: http://bugs.python.org/file28161/issue-15990-5-2.7.patch

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

From report at bugs.python.org  Thu Nov 29 23:57:05 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 29 Nov 2012 22:57:05 +0000
Subject: [docs] [issue16574] clarify policy on updates to final peps
In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za>
Message-ID: <1354229825.02.0.204780926599.issue16574@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks for the feedback.  I will post here a devguide patch to include some of this information in the devguide.

----------

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

From report at bugs.python.org  Fri Nov 30 03:00:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 30 Nov 2012 02:00:10 +0000
Subject: [docs] [issue16581] define "PEP editor" in PEP 1
Message-ID: <1354240810.61.0.280116049987.issue16581@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to define "PEP editor" (or "PEP editors") in PEP 1 before it is used in the document and to provide certain clarifying information.

In particular, PEP 1 should say whether editorship is an invitation-only status and/or how one becomes a PEP editor.  It would also be good if it said (for transparency) how to go about seeing the current list of editors.

There is also inconsistent singular/plural usage that I think would be good to clear up.  Currently, in many places PEP 1 says "the PEP editor" (singular), so it's not clear if each PEP has its own editor, if there is a single PEP editor for all PEPs at any one time, or if it simply means "the PEP editor that happens to reply to an e-mail to peps at python.org".

PEP 0 also has this issue because its introduction says, "[This] PEP contains the index of all Python Enhancement Proposals, known as PEPs.  PEP numbers are assigned by the PEP Editor, and once assigned are never changed."

----------
assignee: docs at python
components: Documentation
messages: 176678
nosy: Jeremy.Hylton, barry, chris.jerdonek, docs at python, goodger, ncoghlan
priority: normal
severity: normal
status: open
title: define "PEP editor" in PEP 1
type: enhancement

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

From report at bugs.python.org  Fri Nov 30 04:04:34 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Nov 2012 03:04:34 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <3YCL6m5xN7zNGR@mail.python.org>


Roundup Robot added the comment:

New changeset f44b8d69e5fc by Chris Jerdonek in branch '2.7':
Backport from 3.2: improve argument/parameter documentation (issue #15990).
http://hg.python.org/cpython/rev/f44b8d69e5fc

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

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

From report at bugs.python.org  Fri Nov 30 04:05:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 30 Nov 2012 03:05:47 +0000
Subject: [docs] [issue15990] solidify argument/parameter terminology
In-Reply-To: <1348169057.62.0.370171802379.issue15990@psf.upfronthosting.co.za>
Message-ID: <1354244747.15.0.85768452241.issue15990@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


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

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

From zachary.ware at gmail.com  Sun Nov 18 17:06:35 2012
From: zachary.ware at gmail.com (Zachary Ware)
Date: Sun, 18 Nov 2012 10:06:35 -0600
Subject: [docs] Documentation bug in 2.7.3 version 4.4 section / minor error
 in Tutorial section 4.4
Message-ID: <CAKJDb-NwjG0xvAtudPRE1wMXyD=1piymijJHZvwSNvzjTA+7BQ@mail.gmail.com>

Thanks for the reports, David and Julia.  This issue has been fixed
(see http://hg.python.org/cpython/rev/121872879e91).

On Mon, Nov 12, 2012 at 11:03 AM, David Ceresuela <davidzgz123 at gmail.com> wrote:
> Hello everyone!
>
> In the
> http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops
> there are two print statements that I think are not correct.
> These are:
> - print("Found an even number", num)
> - print("Found a number", num)
>
> The output should be:
>>>> Found an even number 2
>>>> Found a number 3
>
> But instead I get:
>>>> ('Found an even number', 2)
>>>> ('Found a number', 3)
>
>
> Proposed solution is to delete the parentheses:
> Change
> print("Found an even number", num)
> to
> print "Found an even number", num
>
> That way the output I get matches the expected output
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>

From zachary.ware at gmail.com  Sun Nov 18 17:22:00 2012
From: zachary.ware at gmail.com (Zachary Ware)
Date: Sun, 18 Nov 2012 10:22:00 -0600
Subject: [docs] http://docs.python.org/2/library/hashlib.html
In-Reply-To: <CAOw2TN_vksS4n87amKDs4vxUbu+Gdng2daHPjHpX_3iO=91sBw@mail.gmail.com>
References: <CAOw2TN_vksS4n87amKDs4vxUbu+Gdng2daHPjHpX_3iO=91sBw@mail.gmail.com>
Message-ID: <CAKJDb-OdQW9q1yAGdnKRLHbOHxg8mAas-V1A=NddAPd0K95rGA@mail.gmail.com>

On Thu, Nov 8, 2012 at 6:57 AM, Hugh Parker <hcp at pobox.com> wrote:
> http://docs.python.org/2/library/hashlib.html has an error:
>
> m.update("Blah") doesn't work.  It gives a type error.  To work, it needs to
> be m.update("Blah".encode('utf-8'))
>
> I'm using Python 3.3.
>

Hi Hugh,

Please note that while the majority of things are the same between
Python versions, several major changes happened between Python 2 and
Python 3.  The page you linked to is the Python 2.7 version of the
docs, which don't necessarily apply to Python 3.3.  In this case, the
page you referred to is correct for 2.7, and the 3.3 version of the
page is correct for that version.  You can change which version you
are looking at with the version switching dropdown at the top left of
the page.  If you have javascript disabled, you can change the version
by changing the '2' in your link to a '3'.

From byron at base2.cc  Mon Nov 19 12:56:31 2012
From: byron at base2.cc (Byron Foster)
Date: Mon, 19 Nov 2012 04:56:31 -0700
Subject: [docs] Bug in sqlite package doc
Message-ID: <B8B411E6-B4A1-4EF0-B575-C24F1253885E@base2.cc>

On the following page:

11.13. sqlite3 ? DB-API 2.0 interface for SQLite databases ? Python v2.7.3 documentation

Search for  "fetchone"

the first match will take you to the following code:

# Do this instead
t = ('RHAT',)
c.execute('SELECT * FROM stocks WHERE symbol=?', t)
print c.fetchone()
c however is a connection object, it does not contain 'fetchone'

I believe the author meant something like the following:

# Do this instead
t = ('RHAT',)
cur = c.execute('SELECT * FROM stocks WHERE symbol=?', t)
print cur.fetchone()
Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121119/62cc1f68/attachment-0001.html>

From michellebarton39 at gmail.com  Mon Nov 19 15:58:27 2012
From: michellebarton39 at gmail.com (Michelle Barton)
Date: Mon, 19 Nov 2012 22:58:27 +0800
Subject: [docs] A Broken Link on Your Site About Geany and GTK
In-Reply-To: <CAKJDb-PzpHeRXsBXnHH+Gkf9eQJXq4ED0LStnJWU=AuYfdCf4g@mail.gmail.com>
References: <3FPK73FB-7FA6-634G-8G8T-DPQX0QMHOL6E@gmail.com>
	<CAKJDb-PzpHeRXsBXnHH+Gkf9eQJXq4ED0LStnJWU=AuYfdCf4g@mail.gmail.com>
Message-ID: <CAMVSUGobba=Bk2R=TgT=ecUm9p6wtrzpcyW=idf=rVQSfi0KgA@mail.gmail.com>

Hi Zachary,

Thanks for letting me know. Have a great day!

Best Regards,

Michelle









On Mon, Nov 19, 2012 at 12:40 AM, Zachary Ware <
zachary.ware+pydocs at gmail.com> wrote:

> Hi Michelle,
>
> First off, pythonexperts.com does not appear to be affiliated with
> python.org or the Python Software Foundation.  The most up-to-date
> Python documentation will always be found at docs.python.org and I
> would encourage you to use that site for the best information.
>
> Secondly, the documentation on the page you linked to is for Python
> 2.6, which is by now in security fix only mode.  The issue you raised
> is already fixed in 2.7, though: http://docs.python.org/2/using/unix
>
> Thanks for the report, though!  We're more than happy to fix any other
> bugs you find in current versions as found on docs.python.org
>
> On Sun, Nov 11, 2012 at 10:44 PM, Michelle Barton
> <michellebarton39 at gmail.com> wrote:
> > Hi Administrator,
> >
> > I came across your website and wanted to notify you about a broken link
> on
> > your page in case you weren't aware of it. The link on
> > pythonexperts.com/_sources/using/unix.txt which links to
> > http://geany.uvena.de/ is no longer working. I've included a link to a
> > useful page on Geany and GTK that you could replace the broken link with
> if
> > you're interested in updating your website. Thanks for providing a great
> > resource!
> >
> > Link:
> http://www.onlinecomputersciencedegree.com/resources/geany-and-gtk/
> >
> > Best,
> > Michelle Barton
> >
> > _______________________________________________
> > docs mailing list
> > docs at python.org
> > http://mail.python.org/mailman/listinfo/docs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121119/a0ca96fb/attachment-0001.html>

From altfga at gmail.com  Mon Nov 19 16:02:06 2012
From: altfga at gmail.com (Amanda)
Date: Mon, 19 Nov 2012 13:02:06 -0200
Subject: [docs] wrong function name
Message-ID: <CABsE+2cXvqc-woFGqK_YUnyDBTCcQZmrf9NWzbtT41BYsKJoxw@mail.gmail.com>

AT http://docs.python.org/2/howto/doanddont.html#except
2 occurences

opne("file")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121119/0864c6de/attachment-0001.html>

From merwok at netwok.org  Tue Nov 20 05:12:34 2012
From: merwok at netwok.org (merwok at netwok.org)
Date: Tue, 20 Nov 2012 04:12:34 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121120041234.2636.71227@psf.upfronthosting.co.za>

Good work!

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

From chris.jerdonek at gmail.com  Tue Nov 20 05:41:17 2012
From: chris.jerdonek at gmail.com (chris.jerdonek at gmail.com)
Date: Tue, 20 Nov 2012 04:41:17 -0000
Subject: [docs] Improve doc for str(bytesobject) (issue 13538)
Message-ID: <20121120044117.27722.43581@psf.upfronthosting.co.za>

Thanks for the positive feedback, ?ric! :)  The patch has gone through
several iterations and Ezio deserves a fair bit of credit, too.



http://bugs.python.org/review/13538/diff/6630/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/13538/diff/6630/Doc/library/functions.rst#newcode537
Doc/library/functions.rst:537: effect as calling :func:`str(value)
<str>`.
On 2012/11/20 05:12:21, eric.araujo wrote:
> FYI: In a recent-ish discussion, Georg indicated his distaste for
mixing func
> and code markup like this.  For this instance it looks okay, if there
are no
> other links to str in the surrounding text.

In this case, including the code is important because it specifies which
form of the str() invocation takes effect.  In any case, I would be
curious to learn more about Georg's opinions and rationale on that.

http://bugs.python.org/review/13538/diff/6630/Doc/library/functions.rst#newcode1258
Doc/library/functions.rst:1258: str(object=b'', encoding='utf-8',
errors='strict')
On 2012/11/20 05:12:21, eric.araujo wrote:
> Shouldn?t the default value be '' here?

No, because that would throw a TypeError:

 >>> str('', encoding='utf-8')
 Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
 TypeError: decoding str is not supported

The default value in the second signature is a good visual cue that the
second form of the invocation requires a bytes/bytearray/etc object.

http://bugs.python.org/review/13538/diff/6630/Doc/library/functions.rst#newcode1258
Doc/library/functions.rst:1258: str(object=b'', encoding='utf-8',
errors='strict')
On 2012/11/20 05:12:21, eric.araujo wrote:
> I think the doc should say whether keyword args are supported.

I will add this.

http://bugs.python.org/review/13538/diff/6630/Doc/library/functions.rst#newcode1267
Doc/library/functions.rst:1267: the string itself.  If *object* does not
have an :meth:`object.__str__`
On 2012/11/20 05:12:21, eric.araujo wrote:
> People are going to comment on ?a __str__ method? vs. ?an __str__
method?,
> depending on whether and how you pronounce the underscores :)

Indeed.  I remember this python-dev thread quite clearly :)

http://mail.python.org/pipermail/python-dev/2012-August/121214.html

Personally, I think of it yet another way: "an object dot str method."
:)

http://bugs.python.org/review/13538/diff/6630/Doc/library/stdtypes.rst
File Doc/library/stdtypes.rst (right):

http://bugs.python.org/review/13538/diff/6630/Doc/library/stdtypes.rst#newcode2085
Doc/library/stdtypes.rst:2085: the :ref:`buffer protocol
<bufferobjects>` to access the memory of other
On 2012/11/20 05:12:21, eric.araujo wrote:
> Do you think a glossary entry would help?

I do!  But I know other core developers feel strongly about limiting
what words we add.  Perhaps we can create a new issue for this?  From
what I observed, I also know "buffer protocol" could use some more
internal linking, indexing, etc.

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

From jocjo at mail.dk  Sat Nov 17 09:41:40 2012
From: jocjo at mail.dk (Hans Larsen)
Date: Sat, 17 Nov 2012 09:41:40 +0100
Subject: [docs] try-except-raise-bug
Message-ID: <95AA10126C7348B1880966C925C6827C@HansPc>

Med venlig hilsen:
Hans Larsen
Galgebakken S?nder 4-11A
DK-2620 Albertslund
Danmark/Danio

I found a bug in Python3.3!
See the attached file:
Where is ?.. During handling of the above exception, another exception occured: ...??
I use Windows 7 Home Premium 64bit, and installed Python 3.3.0 final 64bit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121117/e5f2b59f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Hans.vcf
Type: text/x-vcard
Size: 71 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20121117/e5f2b59f/attachment-0001.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: try-execpt-raise-bug.rtf
Type: application/rtf
Size: 1131 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20121117/e5f2b59f/attachment-0001.rtf>

From tyrope at tyrope.nl  Tue Nov 20 23:30:12 2012
From: tyrope at tyrope.nl (Dimitri Molenaars)
Date: Tue, 20 Nov 2012 23:30:12 +0100
Subject: [docs] Typo in Python 2.7 docs for random.random
Message-ID: <50AC0474.3030504@tyrope.nl>

Greetings,
http://docs.python.org/2.7/library/random.html?highlight=random.random#random.random

This:
Return the next random floating point number in the range [0.0, 1.0).

should be:
Return the next random floating point number in the range (0.0, 1.0).
or
Return the next random floating point number in the range [0.0, 1.0].

-- 
Signed,
Dimitri 'Tyrope' Molenaars


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4453 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/docs/attachments/20121120/7bc77de1/attachment-0001.bin>

From fn681 at ncf.ca  Tue Nov 20 23:55:22 2012
From: fn681 at ncf.ca (Colin J. Williams)
Date: Tue, 20 Nov 2012 17:55:22 -0500
Subject: [docs] Python 2.7.3 Section 7.1.3 Format String
Message-ID: <50AC0A5A.2040508@ncf.ca>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121120/3a3f7b3f/attachment.html>

From fn681 at ncf.ca  Wed Nov 21 13:40:31 2012
From: fn681 at ncf.ca (Colin J. Williams)
Date: Wed, 21 Nov 2012 07:40:31 -0500
Subject: [docs] Python 2.7.3 Section 7.1.3 Format String
Message-ID: <50ACCBBF.5000406@ncf.ca>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121121/de5c3817/attachment.html>

From jokoswt at gmail.com  Fri Nov 23 18:10:02 2012
From: jokoswt at gmail.com (jokoswt at gmail.com)
Date: Sat, 24 Nov 2012 00:10:02 +0700
Subject: [docs] Re.document python
Message-ID: <qWSnDxLlYRpz.D1KLrxsx@smtp.gmail.com>

Thank you


From hi.leon.y at gmail.com  Sat Nov 24 22:30:19 2012
From: hi.leon.y at gmail.com (=?UTF-8?B?5p2o5YWJ?=)
Date: Sat, 24 Nov 2012 21:30:19 +0000
Subject: [docs] Translate Python document into Chinese
Message-ID: <CAHYymqEHBo9j0r1i5hv+RGdhc6PZxM=EuoSfQcG+ATx3EVu+JA@mail.gmail.com>

Dear Sir/Madam,

I love Python. I have seen the advantages of Python.
I would like to translate Python document into Chinese, in order to
promote Python among Chinese programmers. Concerning good experiences
of programming and know C, C++, Java, I
believe I can translate the document well. The purpose of sending this
e-mail is that I hope my translation will be officially recognized. It
may be extremely impossible that I will be paid for this. I still
prefer to translate the document voluntarily.

Thank you,
Yours faithfully,
Guang Yang

From ezio.melotti at gmail.com  Tue Nov 27 21:59:58 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Tue, 27 Nov 2012 20:59:58 -0000
Subject: [docs] IDLE documentation for Unix obsolete/incorrect (issue
	5066)
Message-ID: <20121127205958.19424.90924@psf.upfronthosting.co.za>

I left a few comments.
I haven't reviewed the patch throughly though.


http://bugs.python.org/review/5066/diff/6694/Doc/library/idle.rst
File Doc/library/idle.rst (right):

http://bugs.python.org/review/5066/diff/6694/Doc/library/idle.rst#newcode162
Doc/library/idle.rst:162: Open a dialog to switch between indenting with
spaces and tabs
Shouldn't the note about using spaces instead of tabs be here?

http://bugs.python.org/review/5066/diff/6694/Doc/library/idle.rst#newcode340
Doc/library/idle.rst:340: * :kbd:`C-d` delete next character
Are these rendered correctly?  Isn't an empty line required between
entries?

http://bugs.python.org/review/5066/diff/6694/Doc/library/idle.rst#newcode354
Doc/library/idle.rst:354: are restricted to four spaces due to TCL/Tk
issues.)
s/issues/limitations/?

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

From lewin at post.harvard.edu  Thu Nov 29 01:03:35 2012
From: lewin at post.harvard.edu (Alex Lewin)
Date: Wed, 28 Nov 2012 16:03:35 -0800
Subject: [docs] doc bug in http://docs.python.org/2/library/re.html
Message-ID: <CAF04pKZacuNrupkAP7n2nhoFT3unDx1As9q+34u_XZHQBO67Kw@mail.gmail.com>

In http://docs.python.org/2/library/re.html , I believe "groupindex" should
be "groupdict"

-- 
book events:
   http://RealFoodFermentation.com/events
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121128/7aac4b33/attachment.html>

From lewin at post.harvard.edu  Thu Nov 29 01:02:32 2012
From: lewin at post.harvard.edu (Alex Lewin)
Date: Wed, 28 Nov 2012 16:02:32 -0800
Subject: [docs] doc bug in http://docs.python.org/2/library/re.html
Message-ID: <CAF04pKbJzD7cmc+UX_bo2FzEFXzg2OZgwJAG=g+xQG6_6yz=eQ@mail.gmail.com>

In http://docs.python.org/2/library/re.html , I believe "groupindex" should
be "groupdict"

-- 
book events:
   http://RealFoodFermentation.com/events
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121128/b1568d58/attachment.html>

From andrew.svetlov at gmail.com  Fri Nov 30 12:19:51 2012
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Fri, 30 Nov 2012 13:19:51 +0200
Subject: [docs] wrong function name
In-Reply-To: <CABsE+2cXvqc-woFGqK_YUnyDBTCcQZmrf9NWzbtT41BYsKJoxw@mail.gmail.com>
References: <CABsE+2cXvqc-woFGqK_YUnyDBTCcQZmrf9NWzbtT41BYsKJoxw@mail.gmail.com>
Message-ID: <CAL3CFcW4Vp2D1jViWGMqrKDpWX4iZga0KCGtMC9N4L28A99Yzw@mail.gmail.com>

Examples use deliberately misspelled name to throw NameError.
It is not mistake.

On Mon, Nov 19, 2012 at 5:02 PM, Amanda <altfga at gmail.com> wrote:
> AT http://docs.python.org/2/howto/doanddont.html#except
> 2 occurences
>
> opne("file")
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



-- 
Thanks,
Andrew Svetlov

From andrew.svetlov at gmail.com  Fri Nov 30 14:18:06 2012
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Fri, 30 Nov 2012 15:18:06 +0200
Subject: [docs] doc bug in http://docs.python.org/2/library/re.html
In-Reply-To: <CAF04pKZacuNrupkAP7n2nhoFT3unDx1As9q+34u_XZHQBO67Kw@mail.gmail.com>
References: <CAF04pKZacuNrupkAP7n2nhoFT3unDx1As9q+34u_XZHQBO67Kw@mail.gmail.com>
Message-ID: <CAL3CFcUW2majZj_p+71Yp2EBw3XXeYui_h5noncDJW5NFnkCCA@mail.gmail.com>

RegexObject has groupindex, MatchObject has groupdict
The doc is correct from my perspective.

On Thu, Nov 29, 2012 at 2:03 AM, Alex Lewin <lewin at post.harvard.edu> wrote:
> In http://docs.python.org/2/library/re.html , I believe "groupindex" should
> be "groupdict"
>
> --
> book events:
>    http://RealFoodFermentation.com/events
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



-- 
Thanks,
Andrew Svetlov

From report at bugs.python.org  Fri Nov 30 15:49:49 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Nov 2012 14:49:49 +0000
Subject: [docs] [issue10259] Entry text not set if all of 'Font',
	'Foreground' and 'Justify' are set
In-Reply-To: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>
Message-ID: <1354286989.06.0.981549786717.issue10259@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I confirm this. The bug appears sporadically on 3.x.

When the entry displays text, self.entry1['textvariable'] is 'PY_VAR0'. When it does not, self.entry1['textvariable'] is '0' (actually the value of "text" parameter).

The bug is due to the fact that option "text" is applied after the option "textvariable". Due to string hash randomization it occurs in 50% on 3.3+ (and always or never on default 2.7, depending on other options used in this call). For work around this bug you should not use both "text" and "textvariable" keyword or dict parameters in one call. Probably it is worth to mention in the documentation (unfortunately the Tkinter documentation is almost non-existent).

----------
assignee:  -> docs at python
components: +Documentation -Tkinter
nosy: +docs at python, serhiy.storchaka
stage:  -> needs patch
type: behavior -> enhancement

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

From report at bugs.python.org  Fri Nov 30 15:50:15 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Nov 2012 14:50:15 +0000
Subject: [docs] [issue10259] Entry text not set if all of 'Font',
	'Foreground' and 'Justify' are set
In-Reply-To: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>
Message-ID: <1354287015.2.0.0845052532568.issue10259@psf.upfronthosting.co.za>


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


----------
components: +Tkinter

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

From report at bugs.python.org  Fri Nov 30 17:01:01 2012
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 30 Nov 2012 16:01:01 +0000
Subject: [docs] [issue10259] Entry text not set if all of 'Font',
	'Foreground' and 'Justify' are set
In-Reply-To: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>
Message-ID: <1354291260.99.0.332693381868.issue10259@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

Calm down for a moment. This is just incorrect usage of Entry. There is no "text" parameter documented for this class (see its docstring, for a quick reference on that). Also, there is a lot of Tkinter documentation, the official one at can be found at  http://docs.python.org/2/library/tkinter.html, which includes links for further documentation.

This is actually unrelated to string hash randomization, it is only barely related to the unordered nature of the hash implementation. What actually happens is that the tk lib usually accepts abbreviations of parameter names. So specifying "text" and "textvariable" is the same for tk.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Nov 30 17:26:45 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 30 Nov 2012 16:26:45 +0000
Subject: [docs] [issue10589] I/O ABC docs should specify which methods
	have	implementations
In-Reply-To: <1291143953.85.0.0204032538698.issue10589@psf.upfronthosting.co.za>
Message-ID: <1354292805.44.0.269432039034.issue10589@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Updated the patch. Is it ok now?

----------
nosy: +asvetlov
Added file: http://bugs.python.org/file28166/issue10589.diff

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

From andrew.svetlov at gmail.com  Fri Nov 30 17:34:26 2012
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Fri, 30 Nov 2012 18:34:26 +0200
Subject: [docs] Bug in sqlite package doc
In-Reply-To: <B8B411E6-B4A1-4EF0-B575-C24F1253885E@base2.cc>
References: <B8B411E6-B4A1-4EF0-B575-C24F1253885E@base2.cc>
Message-ID: <CAL3CFcUdNGG6cqg_Gyd2f+OBAPumaDT41RO8Ahe+6p1CDDPVyA@mail.gmail.com>

`c` is the cursor instance. Connection instance named `conn` in example.

On Mon, Nov 19, 2012 at 1:56 PM, Byron Foster <byron at base2.cc> wrote:
> On the following page:
>
> 11.13. sqlite3 ? DB-API 2.0 interface for SQLite databases ? Python v2.7.3
> documentation
>
> Search for  "fetchone"
>
> the first match will take you to the following code:
>
> # Do this instead
> t = ('RHAT',)
> c.execute('SELECT * FROM stocks WHERE symbol=?', t)
> print c.fetchone()
>
> c however is a connection object, it does not contain 'fetchone'
>
> I believe the author meant something like the following:
>
> # Do this instead
> t = ('RHAT',)
> cur = c.execute('SELECT * FROM stocks WHERE symbol=?', t)
> print cur.fetchone()
>
> Thank you!
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



-- 
Thanks,
Andrew Svetlov

From report at bugs.python.org  Fri Nov 30 19:15:41 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Nov 2012 18:15:41 +0000
Subject: [docs] [issue10259] Entry text not set if all of 'Font',
	'Foreground' and 'Justify' are set
In-Reply-To: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>
Message-ID: <1354299341.54.0.163308510086.issue10259@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> So specifying "text" and "textvariable" is the same for tk.

Thanks for clarifying.

----------

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

From report at bugs.python.org  Fri Nov 30 20:16:14 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 30 Nov 2012 19:16:14 +0000
Subject: [docs] [issue16581] define "PEP editor" in PEP 1
In-Reply-To: <1354240810.61.0.280116049987.issue16581@psf.upfronthosting.co.za>
Message-ID: <1354302974.07.0.437418478942.issue16581@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +anthony_baxter

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

From report at bugs.python.org  Fri Nov 30 20:17:48 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 30 Nov 2012 19:17:48 +0000
Subject: [docs] [issue16581] define "PEP editor" in PEP 1
In-Reply-To: <1354240810.61.0.280116049987.issue16581@psf.upfronthosting.co.za>
Message-ID: <20121130141742.78397170@resist.wooz.org>


Barry A. Warsaw added the comment:

On Nov 30, 2012, at 02:00 AM, Chris Jerdonek wrote:

>In particular, PEP 1 should say whether editorship is an invitation-only
>status and/or how one becomes a PEP editor.  It would also be good if it said
>(for transparency) how to go about seeing the current list of editors.

IMO, becoming a PEP editor is by invitation-only, as decided by consensus of
the current set of PEP editors.  The current list of editors is exactly
equivalent to the members of the peps@ mailing list, currently:

Anthony Baxter
Barry Warsaw
Brett Cannon
Georg Brandl
David Goodger
Guido van Rossum
Jesse Noller

If there are editors who are not members of this mailing list, they should be!
If there are editors who want to retire and be removed from the list, please
let me know.

>There is also inconsistent singular/plural usage that I think would be good
>to clear up.  Currently, in many places PEP 1 says "the PEP editor"
>(singular), so it's not clear if each PEP has its own editor, if there is a
>single PEP editor for all PEPs at any one time, or if it simply means "the
>PEP editor that happens to reply to an e-mail to peps at python.org".

The latter, and it should be plural everywhere.

>PEP 0 also has this issue because its introduction says, "[This] PEP contains
>the index of all Python Enhancement Proposals, known as PEPs.  PEP numbers
>are assigned by the PEP Editor, and once assigned are never changed."

Plural.

----------

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

From report at bugs.python.org  Fri Nov 30 20:51:19 2012
From: report at bugs.python.org (Bruno Dupuis)
Date: Fri, 30 Nov 2012 19:51:19 +0000
Subject: [docs] [issue10259] Entry text not set if all of 'Font',
	'Foreground' and 'Justify' are set
In-Reply-To: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>
Message-ID: <1354305079.91.0.52471819476.issue10259@psf.upfronthosting.co.za>


Bruno Dupuis added the comment:

Thank you for the review, Guilherme.

----------

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

From report at bugs.python.org  Fri Nov 30 20:55:05 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 30 Nov 2012 19:55:05 +0000
Subject: [docs] [issue16581] define "PEP editor" in PEP 1
In-Reply-To: <1354240810.61.0.280116049987.issue16581@psf.upfronthosting.co.za>
Message-ID: <1354305305.49.0.39434312872.issue16581@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks for providing the info.  To clarify, is membership in peps@ restricted to editors?

----------

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

From report at bugs.python.org  Fri Nov 30 21:20:44 2012
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 30 Nov 2012 20:20:44 +0000
Subject: [docs] [issue16581] define "PEP editor" in PEP 1
In-Reply-To: <1354305305.49.0.39434312872.issue16581@psf.upfronthosting.co.za>
Message-ID: <20121130152040.3b61a295@resist.wooz.org>


Barry A. Warsaw added the comment:

On Nov 30, 2012, at 07:55 PM, Chris Jerdonek wrote:

>Thanks for providing the info.  To clarify, is membership in peps@ restricted
>to editors?

Yes.  It may not be a perfect overlap, but that's the best we have, and should
be the intent, IMHO.

----------

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

From report at bugs.python.org  Fri Nov 30 22:29:14 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Nov 2012 21:29:14 +0000
Subject: [docs] [issue16585] surrogateescape broken w/ multibytecodecs'
	encode
In-Reply-To: <1354306822.13.0.130768178209.issue16585@psf.upfronthosting.co.za>
Message-ID: <1354310954.16.0.331565096924.issue16585@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov 30 22:38:30 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Nov 2012 21:38:30 +0000
Subject: [docs] [issue16568] allow constructors to be documented separately
	from class
In-Reply-To: <1354093412.82.0.692042663136.issue16568@psf.upfronthosting.co.za>
Message-ID: <1354311510.81.0.788121556966.issue16568@psf.upfronthosting.co.za>


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


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

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

From dincel at live.com  Fri Nov 30 11:17:58 2012
From: dincel at live.com (=?windows-1254?B?RGlu52VsIFRh/nD9bmFy?=)
Date: Fri, 30 Nov 2012 10:17:58 -0000
Subject: [docs] Cover alternative for the tutorial
Message-ID: <BLU002-W33598566DF695AF25146F8AA430@phx.gbl>

Hi all,I've attached my version of the tutorial cover page. I'm not sure if you like it. By the way, Python is a life saver for newbie programmers like me. I'll always be grateful to Guido.
Din?el Ta?p?nar
[BS-CS] UoPeople 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121130/eaa26a22/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tutorial_cover.pdf
Type: application/pdf
Size: 103103 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20121130/eaa26a22/attachment-0001.pdf>

From static.vortex at gmx.com  Fri Nov 30 16:39:05 2012
From: static.vortex at gmx.com (gt)
Date: Fri, 30 Nov 2012 15:39:05 -0000
Subject: [docs] Small issue with documentation
Message-ID: <20121130153326.GA1336@localhost.localdomain>

Hi, on the following page:

http://docs.python.org/3/faq/installed.html

Under the "Can I delete Python?" section, I find that the statement:

"Reinstalling the whole system would then be required to fix things
again."

is a bit misleading. Wouldn't reinstalling python fix the problem with
the system? If the system isn't booting, then using a live environment
(Live CD, etc.) can be used to reinstall python.

I propose that it should be changed to:

"Reinstalling Python would be required to fix things."

From lewin at post.harvard.edu  Fri Nov 30 20:08:15 2012
From: lewin at post.harvard.edu (Alex Lewin)
Date: Fri, 30 Nov 2012 19:08:15 -0000
Subject: [docs] doc bug in http://docs.python.org/2/library/re.html
In-Reply-To: <CAL3CFcUW2majZj_p+71Yp2EBw3XXeYui_h5noncDJW5NFnkCCA@mail.gmail.com>
References: <CAF04pKZacuNrupkAP7n2nhoFT3unDx1As9q+34u_XZHQBO67Kw@mail.gmail.com>
	<CAL3CFcUW2majZj_p+71Yp2EBw3XXeYui_h5noncDJW5NFnkCCA@mail.gmail.com>
Message-ID: <CAF04pKaniS7_6HLhHEuzv+g=u3CWWYvaKWq95TV==pcJBGwh6Q@mail.gmail.com>

Agreed! Sorry, my mistake.

Alex

On Fri, Nov 30, 2012 at 5:18 AM, Andrew Svetlov <andrew.svetlov at gmail.com>wrote:

> RegexObject has groupindex, MatchObject has groupdict
> The doc is correct from my perspective.
>
> On Thu, Nov 29, 2012 at 2:03 AM, Alex Lewin <lewin at post.harvard.edu>
> wrote:
> > In http://docs.python.org/2/library/re.html , I believe "groupindex"
> should
> > be "groupdict"
> >
> > --
> > book events:
> >    http://RealFoodFermentation.com/events
> >
> > _______________________________________________
> > docs mailing list
> > docs at python.org
> > http://mail.python.org/mailman/listinfo/docs
> >
>
>
>
> --
> Thanks,
> Andrew Svetlov
>



-- 
book events:
   http://RealFoodFermentation.com/events
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121130/3474267e/attachment-0001.html>

From pwashington85 at gmail.com  Fri Nov 30 23:58:49 2012
From: pwashington85 at gmail.com (P. Washington)
Date: Fri, 30 Nov 2012 22:58:49 -0000
Subject: [docs] Search doesn't work
Message-ID: <CACT4uZgjhr1VF8bqaXzYT1Jtx6u=HRsMR1yr9S=hBmsmRWnK7A@mail.gmail.com>

Hi, I'm new to Python and one of the first things I've noticed is that the
search is extremely poor, bordering on useless.

Example:
I search for "sort" and receive a bunch of complicated stuff, while when I
go here: http://docs.python.org/2/tutorial/datastructures.html I see the
sort() method, clearly.
Yet this isn't displayed in the search results.

Example:
I search for "sort()" and receive nothing.

Please run your own searches, you will see what I mean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20121130/639af3c4/attachment-0001.html>