From eliben at gmail.com  Tue Jan  1 01:28:01 2013
From: eliben at gmail.com (Eli Bendersky)
Date: Mon, 31 Dec 2012 16:28:01 -0800
Subject: [docs] pickle docs - what can be pickled
Message-ID: <CAF-Rda_irsBtMeLokNia1jjrJWguUh7eguf6TDZONRp4tynD=g@mail.gmail.com>

In the pickle docs of 3.3, section 12.4.1 says:

"instances of such classes whose __dict__ or __setstate__() is picklable"

Does it actually mean __setstate__ or __getstate__ ?

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

From report at bugs.python.org  Tue Jan  1 06:01:16 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 01 Jan 2013 05:01:16 +0000
Subject: [docs] [issue16831] Better docs for ABCMeta.__subclasshook__
In-Reply-To: <1357010497.63.0.917650591234.issue16831@psf.upfronthosting.co.za>
Message-ID: <1357016476.1.0.435029794048.issue16831@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  1 15:56:30 2013
From: report at bugs.python.org (Yuval Weinbaum)
Date: Tue, 01 Jan 2013 14:56:30 +0000
Subject: [docs] [issue16834] ioctl mutate_flag behavior in regard to the
	buffer size	limit
Message-ID: <1357052189.92.0.352175087043.issue16834@psf.upfronthosting.co.za>


New submission from Yuval Weinbaum:

In fcntl module, the documentation states the following regarding the mutate_flag in ioctl method:

***
If it is false, the buffer?s mutability is ignored and behaviour is as for a read-only buffer, except that the 1024 byte limit mentioned above is avoided ? so long as the buffer you pass is as least as long as what the operating system wants to put there, things should work.
***

However, looking at the code (fcntlmodule.c) it seems that the 1024 bytes limitation is avoided when the mutate_flag is set to True (the opposite of what is stated in the doc).

----------
assignee: docs at python
components: Documentation
messages: 178732
nosy: Yuval.Weinbaum, docs at python
priority: normal
severity: normal
status: open
title: ioctl mutate_flag behavior in regard to the buffer size limit
versions: Python 2.6

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

From georg at python.org  Tue Jan  1 16:09:58 2013
From: georg at python.org (Georg Brandl)
Date: Tue, 01 Jan 2013 16:09:58 +0100
Subject: [docs] pickle docs - what can be pickled
In-Reply-To: <CAF-Rda_irsBtMeLokNia1jjrJWguUh7eguf6TDZONRp4tynD=g@mail.gmail.com>
References: <CAF-Rda_irsBtMeLokNia1jjrJWguUh7eguf6TDZONRp4tynD=g@mail.gmail.com>
Message-ID: <50E2FC46.5030105@python.org>

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

On 01/01/2013 01:28 AM, Eli Bendersky wrote:
> In the pickle docs of 3.3, section 12.4.1 says:
> 
> "instances of such classes whose __dict__ or __setstate__() is picklable"
> 
> Does it actually mean __setstate__ or __getstate__ ?

ISTM __setstate__ is correct, since that's the method that has to be
looked up at unpickling time.  (__getstate__ is called at pickling time.)

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

iEYEARECAAYFAlDi/EYACgkQN9GcIYhpnLBGEQCeOU8jsEDj0nKLNxcc/Z0LQRNM
k5QAnikcfb72aQ8LjEno0njjhh5JuPuO
=BXY+
-----END PGP SIGNATURE-----

From eliben at gmail.com  Tue Jan  1 16:37:07 2013
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 1 Jan 2013 07:37:07 -0800
Subject: [docs] pickle docs - what can be pickled
In-Reply-To: <50E2FC46.5030105@python.org>
References: <CAF-Rda_irsBtMeLokNia1jjrJWguUh7eguf6TDZONRp4tynD=g@mail.gmail.com>
	<50E2FC46.5030105@python.org>
Message-ID: <CAF-Rda-9ssa6-fPRV760EZwF7v2nYmEed2CpZ05=Z8whHJBdFg@mail.gmail.com>

On Tue, Jan 1, 2013 at 7:09 AM, Georg Brandl <georg at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/01/2013 01:28 AM, Eli Bendersky wrote:
> > In the pickle docs of 3.3, section 12.4.1 says:
> >
> > "instances of such classes whose __dict__ or __setstate__() is picklable"
> >
> > Does it actually mean __setstate__ or __getstate__ ?
>
> ISTM __setstate__ is correct, since that's the method that has to be
> looked up at unpickling time.  (__getstate__ is called at pickling time.)
>

Yes, __getstate__ is called at pickling time, which is precisely why it
should replace __setstate__ in the quoted statement, IMHO. Note that the
doc of __getstate__ says:

"Classes can further influence how their instances are pickled; if the
class defines the method
__getstate__()<http://docs.python.org/dev/library/pickle.html?highlight=pickle#pickle.object.__getstate__>,
it is called and the returned object is pickled as the contents for the
instance, instead of the contents of the instance?s dictionary. If the
__getstate__()<http://docs.python.org/dev/library/pickle.html?highlight=pickle#pickle.object.__getstate__>method
is absent, the instance?s
__dict__ <http://docs.python.org/dev/library/stdtypes.html#object.__dict__>is
pickled as usual."

Which further suggest that __getstate__ and __dict__ are, in a sense,
interchangeable.

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

From georg at python.org  Tue Jan  1 16:54:02 2013
From: georg at python.org (Georg Brandl)
Date: Tue, 01 Jan 2013 16:54:02 +0100
Subject: [docs] pickle docs - what can be pickled
In-Reply-To: <CAF-Rda-9ssa6-fPRV760EZwF7v2nYmEed2CpZ05=Z8whHJBdFg@mail.gmail.com>
References: <CAF-Rda_irsBtMeLokNia1jjrJWguUh7eguf6TDZONRp4tynD=g@mail.gmail.com>
	<50E2FC46.5030105@python.org>
	<CAF-Rda-9ssa6-fPRV760EZwF7v2nYmEed2CpZ05=Z8whHJBdFg@mail.gmail.com>
Message-ID: <50E3069A.7040907@python.org>

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

On 01/01/2013 04:37 PM, Eli Bendersky wrote:
> 
> 
> 
> On Tue, Jan 1, 2013 at 7:09 AM, Georg Brandl <georg at python.org 
> <mailto:georg at python.org>> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> 
> On 01/01/2013 01:28 AM, Eli Bendersky wrote:
>> In the pickle docs of 3.3, section 12.4.1 says:
>> 
>> "instances of such classes whose __dict__ or __setstate__() is
>> picklable"
>> 
>> Does it actually mean __setstate__ or __getstate__ ?
> 
> ISTM __setstate__ is correct, since that's the method that has to be looked
> up at unpickling time.  (__getstate__ is called at pickling time.)
> 
> 
> Yes, __getstate__ is called at pickling time, which is precisely why it
> should replace __setstate__ in the quoted statement, IMHO. Note that the
> doc of __getstate__ says:

You're right.  To be clear, the docs should talk about "whose __dict__ or the
result of calling __getstate__() can be pickled".

Georg

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

iEYEARECAAYFAlDjBpkACgkQN9GcIYhpnLDIBwCdFN3gQAkSQVi2a2UxYpgslq5V
378AoI/mcpAQxvkCiR3CdGBbRBVXAOPQ
=2PyJ
-----END PGP SIGNATURE-----

From report at bugs.python.org  Tue Jan  1 20:40:52 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 01 Jan 2013 19:40:52 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <1357069252.03.0.467900913857.issue16747@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Hello Zachary, What'wrong with referencing :class:`file` for iterable? I find it as OK. Also if it needs to be corrected, the reference could be made for :ref:`bltin-file-objects`

Re grammatical fixes, you could point out which were made as with the reflow of the text, it is difficult to spot the fix.

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

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

From report at bugs.python.org  Tue Jan  1 20:48:58 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 01 Jan 2013 19:48:58 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <1357069738.89.0.681650280911.issue16747@psf.upfronthosting.co.za>


R. David Murray added the comment:

senthil: the file type doesn't exist any more in python3.

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

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

From report at bugs.python.org  Tue Jan  1 21:55:24 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 01 Jan 2013 20:55:24 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1357069738.89.0.681650280911.issue16747@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOSwRJiDSHRjtZphyfV95Lpf7iLumaG=pg2xy_H=jx5qYQ@mail.gmail.com>


Senthil Kumaran added the comment:

Oh Okay, Thanks! I was checking it against 2.7!

On Tue, Jan 1, 2013 at 11:48 AM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray added the comment:
>
> senthil: the file type doesn't exist any more in python3.
>
> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16747>
> _______________________________________
>

----------

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

From report at bugs.python.org  Wed Jan  2 00:00:36 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 01 Jan 2013 23:00:36 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <1357081236.73.0.334263157887.issue16747@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Hi folks,

Sorry it's taken me so long to get back to this, it's been a busy month :)

Here's the non-reflowed diff.  In retrospect, I should have just specifically mentioned the grammatical changes I made in the first place; they were merely to change 'and' between 'dict' and 'file object' to a comma, and add a comma after 'file object'.

----------
Added file: http://bugs.python.org/file28520/iterable_glossary_no-reflow.diff

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

From report at bugs.python.org  Wed Jan  2 00:07:11 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Jan 2013 23:07:11 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <1357081631.48.0.584406437123.issue16747@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Yes, that would have been better.
I actually prefer reflowing text, but pointing out the changes makes reviewing the patch easier.

----------
assignee: docs at python -> ezio.melotti
stage:  -> commit review
type:  -> enhancement

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

From report at bugs.python.org  Wed Jan  2 00:29:31 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 01 Jan 2013 23:29:31 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <1357082971.3.0.0525054932008.issue16747@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Changed lines should still be reflowed to respect the column limit.  I was just referring to the unchanged lines before and afterwards that shouldn't be reflowed.

Not reflowing makes it easier for people viewing diffs on python-checkins and hg.python.org, using hg annotate, etc. to see what has changed.

----------

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

From report at bugs.python.org  Wed Jan  2 04:46:40 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jan 2013 03:46:40 +0000
Subject: [docs] [issue14393] Incorporate Guide to Magic Methods?
In-Reply-To: <1332493295.71.0.816804721304.issue14393@psf.upfronthosting.co.za>
Message-ID: <1357098400.35.0.489583887115.issue14393@psf.upfronthosting.co.za>


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


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

From report at bugs.python.org  Wed Jan  2 05:20:45 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 02 Jan 2013 04:20:45 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <1357100445.69.0.427707003514.issue16747@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file28525/issue16747.diff

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

From report at bugs.python.org  Wed Jan  2 05:20:56 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 02 Jan 2013 04:20:56 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <1357100456.07.0.970683810901.issue16747@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file28520/iterable_glossary_no-reflow.diff

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

From report at bugs.python.org  Wed Jan  2 05:21:04 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 02 Jan 2013 04:21:04 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <1357100464.39.0.776887446727.issue16747@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file28392/iterable_glossary.diff

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

From report at bugs.python.org  Wed Jan  2 05:26:35 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 02 Jan 2013 04:26:35 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1357100464.35.0.665718998358.issue16747@psf.upfronthosting.co.za>
Message-ID: <CAPOVWORrx141Eeo9vXDcdOKcJDB9rHLPDj8xBC-Cg4e-0ynrhA@mail.gmail.com>


Senthil Kumaran added the comment:

I reviewed the patch. Changes LGTM.

----------

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

From report at bugs.python.org  Wed Jan  2 19:23:42 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jan 2013 18:23:42 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1357151022.34.0.420235507114.issue16701@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jan  2 21:04:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jan 2013 20:04:18 +0000
Subject: [docs] [issue16827] Remove the relatively advanced content from
	section 2 in	tutorial
In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za>
Message-ID: <1357157057.98.0.945872725965.issue16827@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Those section could be moved to an appendix or somewhere near http://docs.python.org/3/tutorial/interactive.html.  Note that this page and the one about float issues could be appendices too.

----------

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

From report at bugs.python.org  Wed Jan  2 21:30:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Jan 2013 20:30:10 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <3Yc3m12BTHzS49@mail.python.org>


Roundup Robot added the comment:

New changeset 2afc0997e440 by Ezio Melotti in branch '3.2':
#16747: fix link to file objects in the glossary.
http://hg.python.org/cpython/rev/2afc0997e440

New changeset 6e4fc5e2acf8 by Ezio Melotti in branch '3.3':
#16747: merge with 3.2.
http://hg.python.org/cpython/rev/6e4fc5e2acf8

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

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

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

From report at bugs.python.org  Wed Jan  2 21:31:01 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jan 2013 20:31:01 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <1357158661.06.0.395151196164.issue16747@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

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

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

From report at bugs.python.org  Thu Jan  3 02:16:39 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Jan 2013 01:16:39 +0000
Subject: [docs] [issue14393] Incorporate Guide to Magic Methods?
In-Reply-To: <1332493295.71.0.816804721304.issue14393@psf.upfronthosting.co.za>
Message-ID: <1357175759.33.0.54633083977.issue14393@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Much of that article is taken directly from the official docs and adds very little in the way of explanation.  I think we need our own write-up with better explanations and examples.

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

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

From report at bugs.python.org  Thu Jan  3 02:42:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Jan 2013 01:42:10 +0000
Subject: [docs] [issue8952] Doc/c-api/arg.rst: fix documentation of number
	formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1357177326.65.0.213645491026.issue8952@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Three years later, nobody looks to be interested to work on this part of the documentation, so I'm closing the issue. => read the code, luke! (not the doc...)

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

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

From report at bugs.python.org  Thu Jan  3 02:44:27 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Jan 2013 01:44:27 +0000
Subject: [docs] [issue11726] linecache becomes specific to Python scripts in
	Python 3
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1357177466.96.0.55168979952.issue11726@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Well, my initial message doesn't convince me anymore today (especially after reading Terry's message), so I prefer to close the issue as rejected. I don't think that it's really a problem :-)

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

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

From report at bugs.python.org  Thu Jan  3 03:52:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Jan 2013 02:52:18 +0000
Subject: [docs] [issue13256] Document and test new socket options
In-Reply-To: <1319456775.82.0.463656498781.issue13256@psf.upfronthosting.co.za>
Message-ID: <1357181538.37.0.296826278273.issue13256@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I created this issue for myself (as a reminder), but sorry I'm not really motivated to work on the documentation, nor test. Document socket options is not trivial because the exact definition depends on the platform.

I close the issue.

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

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

From report at bugs.python.org  Thu Jan  3 08:05:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 03 Jan 2013 07:05:29 +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: <1357196729.51.0.784233521419.issue13094@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I'm having some problem at deciding what the title of the FAQ should be, and what the actual problem is.  ISTM that OP's problem is the same as:
>>> x = 1
>>> def foo(): return x
... 
>>> x = 2
>>> foo()
2

except that he has 3 lambdas in a loop that get attached to an instance rather than a simple function -- but the problem is that in both cases the function references a global variable whose value is retrieved at calling time rather that being set at definition time.
IOW the solution should be clear, but the code is complex enough that it's not easy to recognize the analogy with the simpler case.
I'm not even sure this has anything to do with closures, unless you consider the global scope a closure.

Maybe the "What are the rules for local and global variables in Python?" FAQ could be expanded with a few examples to cover this case too.

----------
assignee: ezio.melotti -> 
nosy: +chris.jerdonek

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

From report at bugs.python.org  Thu Jan  3 09:00:46 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 03 Jan 2013 08:00:46 +0000
Subject: [docs] [issue8952] Doc/c-api/arg.rst: fix documentation of number
	formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1357200046.35.0.97938509785.issue8952@psf.upfronthosting.co.za>


Georg Brandl added the comment:

It's still a valid bug.

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

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

From report at bugs.python.org  Thu Jan  3 13:30:39 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jan 2013 12:30:39 +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: <1357216239.54.0.00481985352528.issue13094@psf.upfronthosting.co.za>


R. David Murray added the comment:

The FAQ (as in, this question gets asked again and again) is something like "why do the lambdas I define in a loop all return the same result when the input value was different when each one was defined?"

The same applies to regular functions, but people almost never do that in a loop, so in that case they are more likely to think of the scoping issue.

----------

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

From report at bugs.python.org  Thu Jan  3 15:55:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Jan 2013 14:55:38 +0000
Subject: [docs] [issue8952] Doc/c-api/arg.rst: fix documentation of number
	formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1357224938.34.0.0408468079718.issue8952@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy:  -haypo

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

From report at bugs.python.org  Thu Jan  3 16:23:49 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 03 Jan 2013 15:23:49 +0000
Subject: [docs] [issue15067] Clean up the sqlite3 docs
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1357226629.75.0.0791438654451.issue15067@psf.upfronthosting.co.za>


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


Removed 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 Jan  3 16:23:55 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 03 Jan 2013 15:23:55 +0000
Subject: [docs] [issue15067] Clean up the sqlite3 docs
In-Reply-To: <1339687148.5.0.0456329910944.issue15067@psf.upfronthosting.co.za>
Message-ID: <1357226635.44.0.635096035668.issue15067@psf.upfronthosting.co.za>


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


Removed 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 Jan  3 16:33:43 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Jan 2013 15:33:43 +0000
Subject: [docs] [issue12103] Document how to use open with os.O_CLOEXEC
In-Reply-To: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za>
Message-ID: <1357227223.63.0.929012376696.issue12103@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> x      Open the file exclusively (like the O_EXCL flag of open(2)).
>  If the  file  already exists, fopen() fails, and sets errno to EEXIST.
> This flag is ignored for fdopen().

Python 3.3 adds support for this mode: see issue #12760.

> e (since glibc 2.7)
>       Open  the  file  with  the O_CLOEXEC flag.  See open(2) for more information.

I created the issue #16850 for this mode.

--

Other modes seem to be very specific to some platforms. I don't think that it would be possible to expose them in a portable way using the open() function directly.

Can we close this issue? I prefer to work on #16850 for the close-on-exec mode.

----------

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

From report at bugs.python.org  Thu Jan  3 17:28:01 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 03 Jan 2013 16:28:01 +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: <1357230481.78.0.623152360394.issue13094@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> "why do the lambdas I define in a loop all return the same result when
> the input value was different when each one was defined?"

I thought about that, but that sounds a bit too long/specific.  It also has the problem that the issue is not strictly related to lambdas or loops (even if this combination might be more common), and doesn't say where the "result" come from.

----------

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

From report at bugs.python.org  Thu Jan  3 17:31:48 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 03 Jan 2013 16:31:48 +0000
Subject: [docs] [issue12103] Document how to use open with os.O_CLOEXEC
In-Reply-To: <1305716485.42.0.643130250278.issue12103@psf.upfronthosting.co.za>
Message-ID: <1357230708.01.0.603064297717.issue12103@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Sounds good to me.

----------
nosy: +christian.heimes
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Thu Jan  3 17:56:23 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 03 Jan 2013 16:56:23 +0000
Subject: [docs] [issue16851] ismethod and isfunction methods error
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1357232183.0.0.614786408485.issue16851@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think that's expected and by design.  In Python 3 there are no unbound methods, but simply functions:
>>> class X:
...   def add(a, b): return a+b
... 
>>> add = X.add
>>> add
<function add at 0xb740d26c>
>>> add(3, 4)
7
>>> def add(a, b): return a+b
... 
>>> add
<function add at 0xb740d22c>
>>> add(3, 4)
7

As you can see there's no real difference between the two "add".

It's different though with bound methods (obtained from an instance rather than a class):

>>> add = X().add
>>> add
<bound method X.add of <__main__.X object at 0xb740e0ec>>

The documentation is also clear that ismethod() "Return true if the object is a bound method written in Python.".  Maybe an additional note can be added to state that "unbound methods" are not included, and that are instead recognized by isfunction().

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +easy
nosy: +docs at python, ezio.melotti
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan  3 18:23:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jan 2013 17:23:06 +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: <1357233785.96.0.284797276109.issue13094@psf.upfronthosting.co.za>


R. David Murray added the comment:

The point is, it is a FAQ.  We are talking about updating the FAQ document.  It doesn't matter if the text is "too specific", if it is in fact a FAQ.  And it is.

----------

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

From report at bugs.python.org  Thu Jan  3 20:22:00 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 03 Jan 2013 19:22:00 +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: <1357240920.49.0.225786500471.issue13094@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Here's a patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file28550/issue13094.diff

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

From report at bugs.python.org  Thu Jan  3 22:18:36 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 03 Jan 2013 21:18:36 +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: <1357247916.5.0.462118956523.issue13094@psf.upfronthosting.co.za>


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


----------
assignee:  -> ezio.melotti

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

From report at bugs.python.org  Fri Jan  4 01:49:23 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 04 Jan 2013 00:49:23 +0000
Subject: [docs] [issue10529] Write argparse i18n howto
In-Reply-To: <1290688089.28.0.749623528369.issue10529@psf.upfronthosting.co.za>
Message-ID: <1357260563.39.0.765211186244.issue10529@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan  4 01:56:59 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 04 Jan 2013 00:56:59 +0000
Subject: [docs] [issue16857] replace email address on howto with my home page
Message-ID: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

I would rather not get the 'thanks' I have been getting since this was published. Rather let that be my website.

----------
assignee: docs at python
components: Documentation
files: no-mail.diff
keywords: patch
messages: 179000
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: replace email address on howto with my home page
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28554/no-mail.diff

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

From report at bugs.python.org  Fri Jan  4 01:57:42 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 04 Jan 2013 00:57:42 +0000
Subject: [docs] [issue16857] replace my email address on argparse howto with
	my	website
In-Reply-To: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za>
Message-ID: <1357261062.62.0.996386281888.issue16857@psf.upfronthosting.co.za>


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


----------
title: replace email address on howto with my home page -> replace my email address on argparse howto with my website

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

From report at bugs.python.org  Fri Jan  4 05:35:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Jan 2013 04:35:25 +0000
Subject: [docs] [issue16857] replace my email address on argparse howto with
	my	website
In-Reply-To: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za>
Message-ID: <3YctTR6NK6zS8b@mail.python.org>


Roundup Robot added the comment:

New changeset c7ae3772b4d4 by Benjamin Peterson in branch '3.2':
drop email (closes #16857)
http://hg.python.org/cpython/rev/c7ae3772b4d4

New changeset c8e885ecbc89 by Benjamin Peterson in branch '2.7':
drop email (closes #16857)
http://hg.python.org/cpython/rev/c8e885ecbc89

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

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

From report at bugs.python.org  Fri Jan  4 05:36:17 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 04 Jan 2013 04:36:17 +0000
Subject: [docs] [issue16857] replace my email address on argparse howto with
	my	website
In-Reply-To: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za>
Message-ID: <1357274177.47.0.952574665696.issue16857@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I hope that works for you.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Fri Jan  4 13:46:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Jan 2013 12:46:35 +0000
Subject: [docs] [issue16747] Remove 'file' type reference from 'iterable'
	glossary	entry
In-Reply-To: <1356134813.58.0.26000957124.issue16747@psf.upfronthosting.co.za>
Message-ID: <3Yd5NC0R5JzS9q@mail.python.org>


Roundup Robot added the comment:

New changeset dea89ee34402 by Chris Jerdonek in branch '2.7':
Issue #16747: Reflow iterable glossary entry to match 3.x change e19ed347523e.
http://hg.python.org/cpython/rev/dea89ee34402

----------

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

From report at bugs.python.org  Fri Jan  4 15:31:09 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 04 Jan 2013 14:31:09 +0000
Subject: [docs] [issue16857] replace my email address on argparse howto with
	my	website
In-Reply-To: <1357261018.26.0.114123625931.issue16857@psf.upfronthosting.co.za>
Message-ID: <1357309869.42.0.658104665794.issue16857@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe added the comment:

thanks

----------

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

From report at bugs.python.org  Fri Jan  4 16:41:28 2013
From: report at bugs.python.org (Todd Rovito)
Date: Fri, 04 Jan 2013 15:41:28 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357314087.97.0.221996791992.issue5066@psf.upfronthosting.co.za>


Todd Rovito added the comment:

A "ping" on this bug since it has not had any forward movement.  Can somebody please review and or commit?  Thanks.

----------

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

From report at bugs.python.org  Fri Jan  4 16:54:25 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 04 Jan 2013 15:54:25 +0000
Subject: [docs] [issue16861] Portion of code example not highlighted in
	collections	doc
Message-ID: <1357314865.26.0.887283345978.issue16861@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

In http://docs.python.org/2/library/collections.html#namedtuple-factory-function-for-tuples-with-named-fields , a portion of the code example is not highlighted.
---
Happy, new, melodious, joyful, etc, boring new year.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 2.7

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

From report at bugs.python.org  Fri Jan  4 17:13:47 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 04 Jan 2013 16:13:47 +0000
Subject: [docs] [issue16862] FAQ has outdated information about Stackless
Message-ID: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

The FAQ says "It?s [Stackless] still experimental but looks very promising." AFAIK, Stackless is mature.

----------
assignee: docs at python
components: Documentation
messages: 179038
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: FAQ has outdated information about Stackless

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

From report at bugs.python.org  Fri Jan  4 17:14:10 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 04 Jan 2013 16:14:10 +0000
Subject: [docs] [issue16862] FAQ has outdated information about Stackless
In-Reply-To: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za>
Message-ID: <1357316050.05.0.790907004449.issue16862@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Sorry, link here, http://docs.python.org/3/faq/design.html#can-t-you-emulate-threads-in-the-interpreter-instead-of-relying-on-an-os-specific-thread-implementation .

----------

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

From report at bugs.python.org  Fri Jan  4 17:37:44 2013
From: report at bugs.python.org (Charlie Dimino)
Date: Fri, 04 Jan 2013 16:37:44 +0000
Subject: [docs] [issue16863] Argparse tutorial outdated
Message-ID: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za>


New submission from Charlie Dimino:

http://docs.python.org/2/howto/argparse.html

Error message in the first example is outdated, may indicate further out of date information on page.

Example:

The tutorial says:
prog.py: error: the following arguments are required: echo

When the actual error received is:
prog.py: error: too few arguments

----------
assignee: docs at python
components: Documentation
messages: 179041
nosy: Charlie.Dimino, docs at python
priority: normal
severity: normal
status: open
title: Argparse tutorial outdated
versions: Python 2.7

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

From report at bugs.python.org  Fri Jan  4 17:56:50 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jan 2013 16:56:50 +0000
Subject: [docs] [issue16863] Argparse tutorial outdated
In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za>
Message-ID: <1357318610.49.0.773390383503.issue16863@psf.upfronthosting.co.za>


R. David Murray added the comment:

Actually it looks like it is future-dated.  The documented error message is the one you get from 3.3.  I guess someone backported a doc change for a feature change.

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

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

From report at bugs.python.org  Fri Jan  4 17:59:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jan 2013 16:59:21 +0000
Subject: [docs] [issue16863] Argparse tutorial outdated
In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za>
Message-ID: <1357318761.1.0.604089354006.issue16863@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, the whole tutorial is newish.  So this is a bug just in the 2.7 version of the tutorial (it doesn't match the 2.7 code), and yes, there may be other issues as well.

----------

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

From report at bugs.python.org  Fri Jan  4 18:01:49 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jan 2013 17:01:49 +0000
Subject: [docs] [issue16863] Argparse tutorial outdated
In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za>
Message-ID: <1357318909.45.0.129727668514.issue16863@psf.upfronthosting.co.za>


R. David Murray added the comment:

See issue 14034.  Ezio apparently left the error messages unchanged on purpose...I'm not sure why.

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

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

From report at bugs.python.org  Fri Jan  4 18:21:29 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 04 Jan 2013 17:21:29 +0000
Subject: [docs] [issue16862] FAQ has outdated information about Stackless
In-Reply-To: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za>
Message-ID: <1357320089.46.0.278207714998.issue16862@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan  4 18:24:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 04 Jan 2013 17:24:20 +0000
Subject: [docs] [issue16863] Argparse tutorial outdated
In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za>
Message-ID: <1357320260.25.0.928312856504.issue16863@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

When I backported the patch I probably didn't want to try all the examples to see what the py2 error was.  In addition the py3 error is more clear even if it doesn't match what you actually get.
I think this can be closed as won't fix, unless someone wants to propose a patch.

----------
type:  -> enhancement

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

From report at bugs.python.org  Fri Jan  4 18:25:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 04 Jan 2013 17:25:58 +0000
Subject: [docs] [issue16861] Portion of code example not highlighted in
	collections	doc
In-Reply-To: <1357314865.26.0.887283345978.issue16861@psf.upfronthosting.co.za>
Message-ID: <1357320358.65.0.0791734840509.issue16861@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The part that is not highlighted is not part of the code, but the output of the function.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

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

From report at bugs.python.org  Fri Jan  4 18:31:18 2013
From: report at bugs.python.org (Charlie Dimino)
Date: Fri, 04 Jan 2013 17:31:18 +0000
Subject: [docs] [issue16863] Argparse tutorial outdated
In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za>
Message-ID: <1357320678.37.0.909671618554.issue16863@psf.upfronthosting.co.za>


Charlie Dimino added the comment:

If it's okay, don't close this just yet. I'm new to this system but I'll submit a patch with any fixes to the tutorial I find.

----------

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

From report at bugs.python.org  Fri Jan  4 19:07:45 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 04 Jan 2013 18:07:45 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357322865.27.0.614112346889.issue5066@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Hi Todd, I can't commit, but I have a review in the works for you.

----------
nosy: +zach.ware

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

From rdmurray at bitdance.com  Fri Jan  4 19:08:50 2013
From: rdmurray at bitdance.com (rdmurray at bitdance.com)
Date: Fri, 04 Jan 2013 18:08:50 -0000
Subject: [docs] Need Programming FAQ entry for the behavior of closures
	(issue 13094)
Message-ID: <20130104180850.13662.8057@psf.upfronthosting.co.za>

Thanks for writing this.  Overall it looks good, but I did some copy
editing.  Only two substantive comments.


http://bugs.python.org/review/13094/diff/6975/Doc/faq/programming.rst
File Doc/faq/programming.rst (right):

http://bugs.python.org/review/13094/diff/6975/Doc/faq/programming.rst#newcode219
Doc/faq/programming.rst:219: This gives you a list that contains 5
lambdas that calculate ``x**2``, and you
...``x**2``.  You...

http://bugs.python.org/review/13094/diff/6975/Doc/faq/programming.rst#newcode220
Doc/faq/programming.rst:220: might expect that, when called, they would
return respectively ``0``, ``1``,
commas around respectively (IMO)

http://bugs.python.org/review/13094/diff/6975/Doc/faq/programming.rst#newcode221
Doc/faq/programming.rst:221: ``4``, ``9``, and ``16``.  However, when
you actually try, you will see that
I think the comma after try is unnecessary and a bit distracting (though
not technically wrong).

http://bugs.python.org/review/13094/diff/6975/Doc/faq/programming.rst#newcode229
Doc/faq/programming.rst:229: This happens because ``x`` is not local to
the lambdas, but it's defined in
is instead of "it's".

http://bugs.python.org/review/13094/diff/6975/Doc/faq/programming.rst#newcode230
Doc/faq/programming.rst:230: the global scope, and it's accessed when
the lambda is called --- not when it's
How about you just say "outer scope" here, which will cover the case of
referencing a local inside a function.

http://bugs.python.org/review/13094/diff/6975/Doc/faq/programming.rst#newcode230
Doc/faq/programming.rst:230: the global scope, and it's accessed when
the lambda is called --- not when it's
I would prefer spelling out 'it is' here.

http://bugs.python.org/review/13094/diff/6975/Doc/faq/programming.rst#newcode233
Doc/faq/programming.rst:233: changing the value of ``x`` and see how the
result of the lambdas changes::
changes should be change.  Probably result should be results.

http://bugs.python.org/review/13094/diff/6975/Doc/faq/programming.rst#newcode246
Doc/faq/programming.rst:246: Here, ``n=x`` creates a new variable ``n``
local to the lambda, with the
Rather than say "local to the lambda", I think it would be more correct
to say "whose value is computed when the lambda is defined", which is
what is really going on here.

http://bugs.python.org/review/13094/diff/6975/Doc/faq/programming.rst#newcode256
Doc/faq/programming.rst:256: Note that this is not a particular
behaviour of lambdas, but it applies to
"this behavior is not peculiar to lambdas, but applies..."

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

From report at bugs.python.org  Fri Jan  4 19:26:14 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 04 Jan 2013 18:26:14 +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: <1357323974.72.0.90329822392.issue13094@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Attached a new patch.

----------
Added file: http://bugs.python.org/file28563/issue13094-2.diff

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

From report at bugs.python.org  Fri Jan  4 19:52:13 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 04 Jan 2013 18:52:13 +0000
Subject: [docs] [issue16863] Python 2 error in Argparse tutorial
In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za>
Message-ID: <1357325533.86.0.508090827728.issue16863@psf.upfronthosting.co.za>


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


----------
title: Argparse tutorial outdated -> Python 2 error in Argparse tutorial

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

From report at bugs.python.org  Fri Jan  4 20:19:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jan 2013 19:19:05 +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: <1357327145.1.0.989453205002.issue13094@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks good to me.

----------

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

From report at bugs.python.org  Fri Jan  4 20:36:31 2013
From: report at bugs.python.org (Todd Rovito)
Date: Fri, 04 Jan 2013 19:36:31 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1357322865.27.0.614112346889.issue5066@psf.upfronthosting.co.za>
Message-ID: <C44877CA-E4F2-462A-A3C5-92A5284C0355@gmail.com>


Todd Rovito added the comment:

Thanks much appreciated!

Sent from my iPhone

On Jan 4, 2013, at 1:07 PM, Zachary Ware <report at bugs.python.org> wrote:

> 
> Zachary Ware added the comment:
> 
> Hi Todd, I can't commit, but I have a review in the works for you.
> 
> ----------
> nosy: +zach.ware
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5066>
> _______________________________________

----------

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

From report at bugs.python.org  Fri Jan  4 22:33:24 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 04 Jan 2013 21:33:24 +0000
Subject: [docs] [issue14187] add "function annotation" entry to Glossary
In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za>
Message-ID: <1357335204.33.0.308521874811.issue14187@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/issue14187>
_______________________________________

From report at bugs.python.org  Fri Jan  4 23:51:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Jan 2013 22:51:56 +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: <3YdLpg5xNyzSCM@mail.python.org>


Roundup Robot added the comment:

New changeset fdc894d44d82 by Ezio Melotti in branch '2.7':
#13094: add Programming FAQ entry about the behavior of closures.
http://hg.python.org/cpython/rev/fdc894d44d82

New changeset 02933454b7ce by Ezio Melotti in branch '3.2':
#13094: add Programming FAQ entry about the behavior of closures.
http://hg.python.org/cpython/rev/02933454b7ce

New changeset 827ddaaa45e4 by Ezio Melotti in branch '3.3':
#13094: merge with 3.2.
http://hg.python.org/cpython/rev/827ddaaa45e4

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

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

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

From report at bugs.python.org  Fri Jan  4 23:52:45 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 04 Jan 2013 22:52:45 +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: <1357339965.42.0.594612080146.issue13094@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the review!

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

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

From report at bugs.python.org  Sat Jan  5 03:40:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jan 2013 02:40:20 +0000
Subject: [docs] [issue16823] Python crashes on running tkinter code with
	threads
In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za>
Message-ID: <1357353620.53.0.734078556438.issue16823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

What you are doing appears to be unsupported (invalid). From
http://www.astro.washington.edu/users/rowen/TkinterSummary.html
"all Tkinter access must be from the main thread (or more precisely,
from the thread that calls the mainloop). Violating this is likely to
cause nasty and mysterious symptoms such as freezes and core dumps."

There have been at multiple posts on python-list and stack overflow from other users that have run into this limitation. I cannot find it in our tkinter docs, but I think perhaps it should be (even though not-thread-safe is the default for any python structure).

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, gpolo, serwy, terry.reedy
resolution:  -> invalid
status: open -> closed
type: crash -> behavior
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Jan  5 05:14:26 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jan 2013 04:14:26 +0000
Subject: [docs] [issue16862] FAQ has outdated information about Stackless
In-Reply-To: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za>
Message-ID: <1357359266.59.0.976914318226.issue16862@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think answer 2 should just say "An alternative is Stackless Python." and let interested people click the link. The entire second sentence should go, and I am not sure how much of the rest of the first is still correct, as Stackless has changed from when it was written.

----------
keywords: +patch
nosy: +terry.reedy
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/issue16862>
_______________________________________

From report at bugs.python.org  Sat Jan  5 05:17:21 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jan 2013 04:17:21 +0000
Subject: [docs] [issue16863] Python 2 error in Argparse tutorial
In-Reply-To: <1357317464.45.0.840404790237.issue16863@psf.upfronthosting.co.za>
Message-ID: <1357359441.38.0.155245636254.issue16863@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A quick patch would be 'This tutorial was written for argparse in Python 3. A few details are different in 2.x.' But feel free to do better.

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

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

From report at bugs.python.org  Sat Jan  5 05:21:06 2013
From: report at bugs.python.org (Todd Rovito)
Date: Sat, 05 Jan 2013 04:21:06 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
Message-ID: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>


New submission from Todd Rovito:

The Python Developer Guide in section 3.3 about the life cycle of a patch/review process makes no mention that a bug should be "pinged" first before posting to the python-dev at python.org email list requesting a review.  

For more information see this thread on the Python-Dev email list: http://mail.python.org/pipermail/python-dev/2013-January/123453.html

----------
assignee: docs at python
components: Documentation
messages: 179109
nosy: Todd.Rovito, docs at python
priority: normal
severity: normal
status: open
title: Python Developer Guide: Include a reminder to "ping" bug report if not reviewed in timely manner
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jan  5 05:21:55 2013
From: report at bugs.python.org (Todd Rovito)
Date: Sat, 05 Jan 2013 04:21:55 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357359715.47.0.881405406849.issue16868@psf.upfronthosting.co.za>


Changes by Todd Rovito <rovitotv at gmail.com>:


----------
components: +Devguide -Documentation
nosy: +ezio.melotti

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

From report at bugs.python.org  Sat Jan  5 05:46:30 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jan 2013 04:46:30 +0000
Subject: [docs] [issue16823] Python crashes on running tkinter code with
	threads
In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za>
Message-ID: <1357361190.61.0.316857546912.issue16823@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan  5 06:29:44 2013
From: report at bugs.python.org (Todd Rovito)
Date: Sat, 05 Jan 2013 05:29:44 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357363784.35.0.87729711199.issue16868@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Here is a suggested patch with help from R. David Murray:
"To begin with, please be patient! There are many more people submitting patches than there are people capable of reviewing your patch. Getting your patch reviewed requires a reviewer to have the spare time and motivation to look at your patch (we cannot force anyone to review patches). If your patch has not received any notice from reviewers (i.e., no comment made) after a substantial amount of time first ?ping? the issue on the issue tracker to remind the nosy list that the patch needs a review. It is possible that the nosy committers have just forgotten about the issue. After the issue has been ?pinged? and if you don?t get a response after a few days then you may email python-dev at python.org asking for someone to review your patch."

----------
keywords: +patch
Added file: http://bugs.python.org/file28573/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-dev.patch

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

From report at bugs.python.org  Sat Jan  5 07:54:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Jan 2013 06:54:20 +0000
Subject: [docs] [issue16862] FAQ has outdated information about Stackless
In-Reply-To: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za>
Message-ID: <3YdYWH1DBvzS7X@mail.python.org>


Roundup Robot added the comment:

New changeset d2867c430333 by Ezio Melotti in branch '3.2':
#16862: remove outdated statements about Stackless.
http://hg.python.org/cpython/rev/d2867c430333

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

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

New changeset 0f24c65fb7e5 by Ezio Melotti in branch '2.7':
#16862: remove outdated statements about Stackless.
http://hg.python.org/cpython/rev/0f24c65fb7e5

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

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

From report at bugs.python.org  Sat Jan  5 07:56:05 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 05 Jan 2013 06:56:05 +0000
Subject: [docs] [issue16862] FAQ has outdated information about Stackless
In-Reply-To: <1357316027.38.0.0293877261012.issue16862@psf.upfronthosting.co.za>
Message-ID: <1357368964.96.0.0519544891532.issue16862@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: needs patch -> committed/rejected
status: open -> closed
type:  -> enhancement

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

From report at bugs.python.org  Sat Jan  5 09:16:07 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 05 Jan 2013 08:16:07 +0000
Subject: [docs] [issue16863] Python 2 error in Argparse tutorial
In-Reply-To: <1357359441.38.0.155245636254.issue16863@psf.upfronthosting.co.za>
Message-ID: <CAA77j2ALkomWwBy2s0wcZbX=GTDM7ouwFuB6R5WX5JxD4GwEsQ@mail.gmail.com>


Tshepang Lekhonkhobe added the comment:

> A quick patch would be 'This tutorial was written for argparse in Python 3. A few details are different in 2.x.' But feel free to do better.

That really sounds great, especially since it avoids resorting to
things as ugly as "...and this is Python 2 output".

----------

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

From report at bugs.python.org  Sat Jan  5 22:38:18 2013
From: report at bugs.python.org (Meador Inge)
Date: Sat, 05 Jan 2013 21:38:18 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357421898.75.0.0671037445056.issue16868@psf.upfronthosting.co.za>


Meador Inge added the comment:

This seems like a reasonable addition to me.  Although, I don't like the "substantial amount of time" part (yes I know it was already there).  That should probably be replaced with something more concrete, e.g. one week.

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

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

From report at bugs.python.org  Sat Jan  5 22:48:22 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 05 Jan 2013 21:48:22 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357422502.44.0.156005001741.issue16868@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I would also take out the sentence about forgetting about the issue, because that's just one of several possible reasons and I don't think usually the main reason.

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

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

From report at bugs.python.org  Sun Jan  6 00:55:16 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 05 Jan 2013 23:55:16 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357430116.56.0.895253546978.issue16868@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I agree with Chris.

+substantial amount of time first "ping" the issue on the `issue tracker`_

I would add a comma after 'time'.

> I don't like the "substantial amount of time" part (yes I know it
> was already there).  That should probably be replaced with something
> more concrete, e.g. one week.

That really depends on the situation.  I think the point of that sentence is to make clear that some time might pass before someone can look at the issue, and I'm not sure it's necessary to quantify this.

----------

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

From report at bugs.python.org  Sun Jan  6 01:41:54 2013
From: report at bugs.python.org (Meador Inge)
Date: Sun, 06 Jan 2013 00:41:54 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357430116.56.0.895253546978.issue16868@psf.upfronthosting.co.za>
Message-ID: <CAK1Qoootobw-Xvg-ygs3JX4s6U1U2Dx1=5-Krk2dRUfjg=vunA@mail.gmail.com>


Meador Inge added the comment:

On Sat, Jan 5, 2013 at 5:55 PM, Ezio Melotti <report at bugs.python.org> wrote:

> That really depends on the situation.  I think the point of that sentence is to make clear that some time might
> pass before someone can look at the issue, and I'm not sure it's necessary to quantify this.

It currently says:

"""
 If your patch has not received any notice from reviewers (i.e., no
comment made) after a substantial amount of time then you may email
python-dev at python.org asking for someone to take a look at your patch.
"""

That doesn't seem very useful to me because a newcomer is going to
wonder how much time is "substantial".  If you quantify it, then they
don't really have to think about it as much which makes contributing
easier.

----------

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

From report at bugs.python.org  Sun Jan  6 06:27:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jan 2013 05:27:15 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1357450035.59.0.845410484197.issue15204@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan  6 06:29:26 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jan 2013 05:29:26 +0000
Subject: [docs] [issue11346] Generator object should be mentioned in gc
	module	document
In-Reply-To: <1298818993.14.0.492098392223.issue11346@psf.upfronthosting.co.za>
Message-ID: <1357450166.47.0.465525497866.issue11346@psf.upfronthosting.co.za>


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


----------
nosy: +pitrou
stage:  -> needs patch
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/issue11346>
_______________________________________

From report at bugs.python.org  Sun Jan  6 16:48:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Jan 2013 15:48:26 +0000
Subject: [docs] [issue15204] Deprecate the 'U' open mode
In-Reply-To: <1340792991.22.0.497199331706.issue15204@psf.upfronthosting.co.za>
Message-ID: <1357487306.59.0.948792607871.issue15204@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Would the deprecation need to be moved up to 3.4 though now?

Yes, I think so.

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

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

From report at bugs.python.org  Sun Jan  6 17:42:40 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jan 2013 16:42:40 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357490560.31.0.289660945472.issue16868@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan  6 23:12:29 2013
From: report at bugs.python.org (Todd Rovito)
Date: Sun, 06 Jan 2013 22:12:29 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357510349.79.0.639382007607.issue16868@psf.upfronthosting.co.za>


Todd Rovito added the comment:

I agree with Meador it should be a specific amount of time.  As a beginner at contributing to Python I thought "substantial amount of time" meant one month but it depends on interpretation.  I think making it very specific makes the documentation more clear.  Included in the new patch are the other suggestions made by Mr. Jerdonek.  Thanks for the feedback!

----------
Added file: http://bugs.python.org/file28603/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-devV2.patch

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

From report at bugs.python.org  Mon Jan  7 06:47:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Jan 2013 05:47:58 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357537678.03.0.870414496305.issue16868@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

A month sounds good to me.

----------

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

From report at bugs.python.org  Mon Jan  7 07:09:28 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Jan 2013 06:09:28 +0000
Subject: [docs] [issue13899] re pattern r"[\A]" should work like "A" but
	matches	nothing. Ditto B and Z.
In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za>
Message-ID: <1357538968.29.0.347436371887.issue13899@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan  7 07:24:34 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Jan 2013 06:24:34 +0000
Subject: [docs] [issue16154] Some minor doc fixes in Doc/library
In-Reply-To: <1349562325.82.0.0767622542031.issue16154@psf.upfronthosting.co.za>
Message-ID: <1357539874.69.0.843024074366.issue16154@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/issue16154>
_______________________________________

From ezio.melotti at gmail.com  Mon Jan  7 07:27:55 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 07 Jan 2013 06:27:55 -0000
Subject: [docs] Some minor doc fixes in Doc/library (issue 16154)
Message-ID: <20130107062755.2642.74740@psf.upfronthosting.co.za>


http://bugs.python.org/review/16154/diff/6333/Doc/library/colorsys.rst
File Doc/library/colorsys.rst (right):

http://bugs.python.org/review/16154/diff/6333/Doc/library/colorsys.rst#newcode64
Doc/library/colorsys.rst:64: (0.30000000000000004, 0.4, 0.2)
I would replace the value with something with a better repr.

http://bugs.python.org/review/16154/diff/6333/Doc/library/fractions.rst
File Doc/library/fractions.rst (left):

http://bugs.python.org/review/16154/diff/6333/Doc/library/fractions.rst#oldcode59
Doc/library/fractions.rst:59: [40794 refs]
IIRC I already fixed this.

http://bugs.python.org/review/16154/diff/6333/Doc/library/string.rst
File Doc/library/string.rst (right):

http://bugs.python.org/review/16154/diff/6333/Doc/library/string.rst#newcode615
Doc/library/string.rst:615: ...        
print('{0:{width}{base}}'.format(num, base=base, width=width), end='' if
base == 'b' else ' ')
I'm -1 on this. NORMALIZE_WHITESPACE is OK though.

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

From report at bugs.python.org  Mon Jan  7 12:34:53 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 07 Jan 2013 11:34:53 +0000
Subject: [docs] [issue16884] logging handler automatically added starting in
	3.2+
Message-ID: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Starting in 3.2, the logging module no longer outputs the following message when logging and no handlers are configured for the root logger:

    log = logging.getLogger()
    log.error('test')

'No handlers could be found for logger "root"'

However, I can't seem to find any version-changed about this in the docs.  The code change may be from this commit: c86dc2bd3ae8

Incidentally, I also noticed that three logging paragraphs begin with "PLEASE NOTE:"  Those should probably be changed to ".. note::" etc.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 179257
nosy: chris.jerdonek, docs at python, vinay.sajip
priority: normal
severity: normal
status: open
title: logging handler automatically added starting in 3.2+
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan  7 14:21:58 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 07 Jan 2013 13:21:58 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357564918.22.0.89874492606.issue16868@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Ok I changed the time to one month...now the patch reads:
"To begin with, please be patient! There are many more people submitting patches than there are people capable of reviewing your patch. Getting your patch reviewed requires a reviewer to have the spare time and motivation to look at your patch (we cannot force anyone to review patches). If your patch has not received any notice from reviewers (i.e., no comment made) after one month, first ?ping? the issue on the issue tracker to remind the nosy list that the patch needs a review. After the issue has been ?pinged? and if you don?t get a response after a few days then you may email python-dev at python.org asking for someone to review your patch."

----------
Added file: http://bugs.python.org/file28611/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-devV3.patch

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

From report at bugs.python.org  Mon Jan  7 14:22:13 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 07 Jan 2013 13:22:13 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357564933.91.0.518416205117.issue16868@psf.upfronthosting.co.za>


Changes by Todd Rovito <rovitotv at gmail.com>:


Removed file: http://bugs.python.org/file28573/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-dev.patch

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

From report at bugs.python.org  Mon Jan  7 14:22:21 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 07 Jan 2013 13:22:21 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357564941.72.0.457187324572.issue16868@psf.upfronthosting.co.za>


Changes by Todd Rovito <rovitotv at gmail.com>:


Removed file: http://bugs.python.org/file28603/16868PythonDeveloperGuidePingIssueBeforeEmailingPython-devV2.patch

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

From report at bugs.python.org  Mon Jan  7 14:42:40 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 07 Jan 2013 13:42:40 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357566160.05.0.0533987439416.issue16868@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Wording LGTM

----------
stage:  -> commit review

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

From report at bugs.python.org  Mon Jan  7 15:15:46 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 07 Jan 2013 14:15:46 +0000
Subject: [docs] [issue16884] logging handler automatically added starting in
	3.2+
In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za>
Message-ID: <1357568146.62.0.306138951004.issue16884@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Although there is no versionadded directive, the HOWTO documentation does state that the behaviour relates to Python 3.2 and later, and how to obtain the earlier behaviour.

I will add documentation (including a versionadded) to the reference docs and also update the "PLEASE NOTE:" occurrences to use ".. note::" directives instead.

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

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

From report at bugs.python.org  Mon Jan  7 15:19:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Jan 2013 14:19:28 +0000
Subject: [docs] [issue16884] logging handler automatically added starting in
	3.2+
In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za>
Message-ID: <3YfzHz6Rs4zS1s@mail.python.org>


Roundup Robot added the comment:

New changeset 95a4ff8c540b by Vinay Sajip in branch '3.2':
Issue #16884: updated logging documentation to include lastResort and use 'note' directives where appropriate.
http://hg.python.org/cpython/rev/95a4ff8c540b

New changeset 3b5c4190e256 by Vinay Sajip in branch '3.3':
Issue #16884: Merged logging documentation fixes from 3.2.
http://hg.python.org/cpython/rev/3b5c4190e256

New changeset 9009178e08d9 by Vinay Sajip in branch 'default':
Closes #16884: Merged logging documentation fixes from 3.3.
http://hg.python.org/cpython/rev/9009178e08d9

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

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

From report at bugs.python.org  Mon Jan  7 15:41:54 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 07 Jan 2013 14:41:54 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357569714.34.0.760088945831.issue5066@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I wonder, is there any really good reason to keep a separate Lib/idlelib/help.txt, or can Doc/library/idle.rst be used for its purpose (with or without a small amount of processing to, for instance, remove comments and extra backslashes)?  Both have most of the same information, and reST is designed to be readable anyway, so I don't see much point in keeping them separate.

----------

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

From report at bugs.python.org  Mon Jan  7 17:10:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Jan 2013 16:10:40 +0000
Subject: [docs] [issue13790] In str.format an incorrect error message for
	list, tuple, dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1357575040.27.0.648779158543.issue13790@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan  7 18:20:45 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 07 Jan 2013 17:20:45 +0000
Subject: [docs] [issue16884] logging handler automatically added starting in
	3.2+
In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za>
Message-ID: <1357579245.03.0.832919502163.issue16884@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks a lot, Vinay.  By the way, I noticed that the "PLEASE NOTE" reformatting can also be applied to 2.7.

----------

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

From report at bugs.python.org  Mon Jan  7 19:05:23 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 07 Jan 2013 18:05:23 +0000
Subject: [docs] [issue13899] re pattern r"[\A]" should work like "A" but
	matches	nothing. Ditto B and Z.
In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za>
Message-ID: <1357581923.34.0.19590593471.issue13899@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

I've attached a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file28614/issue13899.patch

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

From report at bugs.python.org  Mon Jan  7 19:39:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Jan 2013 18:39:23 +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: <1357583963.22.0.291292151881.issue16404@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka

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

From report at bugs.python.org  Mon Jan  7 21:03:09 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 07 Jan 2013 20:03:09 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357588989.39.0.810104724067.issue5066@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Zachary,
   I like your idea about joining idle.rst with help.txt but I think that should be covered under a separate bug issue.  The way I see it this bug is about fixing the current documentation.  So I suggest you open up a new issue and get people's take on it.  I think a parser could be run at installation to convert idle.rst to help.txt or maybe IDLE could be modified to simply render idle.rst correctly.  I am not sure what the best approach will be.

PS Thanks for the review I should have your suggested changes integrating into a new patch today.

----------

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

From report at bugs.python.org  Mon Jan  7 21:20:07 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 07 Jan 2013 20:20:07 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357590007.19.0.402089022243.issue5066@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Right you are, Todd; I'll get another issue opened for that soon.

----------

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

From report at bugs.python.org  Tue Jan  8 06:06:55 2013
From: report at bugs.python.org (Todd Rovito)
Date: Tue, 08 Jan 2013 05:06:55 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357621613.36.0.319783437001.issue5066@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Zachary,
   Thanks for your excellent review!!!!  Your feedback was very helpful for making the patch even better.

----------
Added file: http://bugs.python.org/file28626/5066IDLEocumentationforUnixObsoleteIncorrectVersion3.patch

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

From report at bugs.python.org  Tue Jan  8 06:08:50 2013
From: report at bugs.python.org (Todd Rovito)
Date: Tue, 08 Jan 2013 05:08:50 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357621730.82.0.881511489853.issue5066@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Based on Zachary's comments I have uploaded a new version of the patch which is version 3.

----------

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

From report at bugs.python.org  Tue Jan  8 09:14:31 2013
From: report at bugs.python.org (Dmitry Mugtasimov)
Date: Tue, 08 Jan 2013 08:14:31 +0000
Subject: [docs] [issue16891] Fix docs about module search order
Message-ID: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za>


New submission from Dmitry Mugtasimov:

http://docs.python.org/2/tutorial/modules.html should be rewritten.
AS IS
6.1.2. The Module Search Path

When a module named spam is imported, the interpreter first searches for a built-in module with that name. If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations:

TO BE
6.1.2. The Module Search Path

When a module named spam is imported, the interpreter first searches for a built-in module with that name. If not found, it looks in the containing package (the package of which the current module is a submodule). If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations:

------
Note that now "6.1.2. The Module Search Path" and "6.4.2. Intra-package References" are contradictary since in 6.4.2 it is said: "In fact, such references are so common that the import statement first looks in the containing package before looking in the standard module search path.", but this is not reflected in 6.1.2.

------
EXAMPLE (for more information see  http://stackoverflow.com/questions/14183541/why-python-finds-module-instead-of-package-if-they-have-the-same-name#comment19687166_14183541 ):
/home/dmugtasimov/tmp/name-res3/xyz
    __init__.py
    a.py
    b.py
    t.py
    xyz.py

Files init.py, b.py and xyz.py are empty
File a.py:

import os, sys
ROOT_DIRECTORY = os.path.abspath(os.path.join(os.path.dirname(__file__), '..'))
if not sys.path or ROOT_DIRECTORY not in sys.path:
    print 'sys.path is modified in a.py'
    sys.path.insert(0, ROOT_DIRECTORY)
else:
    print 'sys.path is NOT modified in a.py'

print 'sys.path:', sys.path
print 'BEFORE import xyz.b'
import xyz.b
print 'AFTER import xyz.b'

File t.py:

import os, sys
ROOT_DIRECTORY = os.path.abspath(os.path.join(os.path.dirname(__file__), '..'))
if not sys.path or ROOT_DIRECTORY not in sys.path:
    print 'sys.path is modified in t.py'
    sys.path.insert(0, ROOT_DIRECTORY)
else:
    print 'sys.path is NOT modified in t.py'

import xyz.a

Run:

python a.py

Output:

    sys.path is modified in a.py
    sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz',
     '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg',
     '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7',
     '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk',
     '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload',
     '/usr/local/lib/python2.7/dist-packages',
     '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info',
     '/usr/lib/python2.7/dist-packages',
     '/usr/lib/python2.7/dist-packages/PIL',
     '/usr/lib/python2.7/dist-packages/gst-0.10',
     '/usr/lib/python2.7/dist-packages/gtk-2.0',
     '/usr/lib/python2.7/dist-packages/ubuntu-sso-client']
    BEFORE import xyz.b
    AFTER import xyz.b

Run:

python -vv a.py

Output:

    import xyz # directory /home/dmugtasimov/tmp/name-res3/xyz
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__module.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    # /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    import xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/b.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/bmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/b.py
    # /home/dmugtasimov/tmp/name-res3/xyz/b.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/b.py
    import xyz.b # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/b.pyc

Run:

python t.py

Output:

    sys.path is modified in t.py
    sys.path is NOT modified in a.py
    sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz',
     '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg',
     '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7',
     '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk',
     '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload',
     '/usr/local/lib/python2.7/dist-packages',
     '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info',
     '/usr/lib/python2.7/dist-packages',
     '/usr/lib/python2.7/dist-packages/PIL',
     '/usr/lib/python2.7/dist-packages/gst-0.10',
     '/usr/lib/python2.7/dist-packages/gtk-2.0',
     '/usr/lib/python2.7/dist-packages/ubuntu-sso-client']
    BEFORE import xyz.b
    Traceback (most recent call last):
      File "t.py", line 9, in <module>
        import xyz.a
      File "/home/dmugtasimov/tmp/name-res3/xyz/a.py", line 11, in <module>
        import xyz.b
    ImportError: No module named b

Run:

python -vv t.py

Output:

    import xyz # directory /home/dmugtasimov/tmp/name-res3/xyz
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__module.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    # /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    import xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/a.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/amodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/a.py
    # /home/dmugtasimov/tmp/name-res3/xyz/a.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/a.py
    import xyz.a # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/a.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/os.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/osmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/os.py
    # trying /home/dmugtasimov/tmp/name-res3/xyz/os.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/sys.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/sysmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/sys.py
    # trying /home/dmugtasimov/tmp/name-res3/xyz/sys.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyzmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.py
    # /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/xyz.py
    import xyz.xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc
    #   clear[2] __file__
    #   clear[2] __package__
    #   clear[2] sys
    #   clear[2] ROOT_DIRECTORY
    #   clear[2] __name__
    #   clear[2] os
    sys.path is modified in t.py
    sys.path is NOT modified in a.py
    sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz',
     '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg',
     '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7',
     '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk',
     '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload',
     '/usr/local/lib/python2.7/dist-packages',
     '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info',
     '/usr/lib/python2.7/dist-packages',
     '/usr/lib/python2.7/dist-packages/PIL',
     '/usr/lib/python2.7/dist-packages/gst-0.10',
     '/usr/lib/python2.7/dist-packages/gtk-2.0',
     '/usr/lib/python2.7/dist-packages/ubuntu-sso-client']
    BEFORE import xyz.b
    Traceback (most recent call last):
      File "t.py", line 9, in <module>
        import xyz.a
      File "/home/dmugtasimov/tmp/name-res3/xyz/a.py", line 11, in <module>
        import xyz.b
    ImportError: No module named b

As you see sys.path is the same for both cases:

sys.path: ['/home/dmugtasimov/tmp/name-res3', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/local/lib/python2.7/dist-packages/tornado-2.3-py2.7.egg', '/home/dmugtasimov/tmp/name-res3/xyz', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/local/lib/python2.7/dist-packages/setuptools-0.6c11-py2.7.egg-info', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/python2.7/dist-packages/ubuntu-sso-client']

But the behaviour is different. For a.py python searches for package xyz first, and them for module b in it:

    import xyz # directory /home/dmugtasimov/tmp/name-res3/xyz
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__module.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    # /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/__init__.py
    import xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/__init__.pyc
    # trying /home/dmugtasimov/tmp/name-res3/xyz/b.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/bmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/b.py
    # /home/dmugtasimov/tmp/name-res3/xyz/b.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/b.py
    import xyz.b # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/b.pyc

In other words:

    Search PACKAGE xyz in directory sys.path[0] -> FOUND
    Search module b in PACKAGE xyz -> FOUND
    Continue execution

For t.py it searches for moduel xyz in the same directory as a.py itself and then fails to find module b in module xyz:

    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyzmodule.so
    # trying /home/dmugtasimov/tmp/name-res3/xyz/xyz.py
    # /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc matches /home/dmugtasimov/tmp/name-res3/xyz/xyz.py
    import xyz.xyz # precompiled from /home/dmugtasimov/tmp/name-res3/xyz/xyz.pyc

In other words:

    Search MODULE xyz in directory in the same directory as a.py (or sys.path[1] ?) -> FOUND
    Search MODULE b in MODULE xyz -> NOT FOUND
    ImportError

So it looks like if "import xyz.b" bahaves different depending on how a.py was initially loaded as a script or imported from another module.

----------
assignee: docs at python
components: Documentation
messages: 179321
nosy: dmugtasimov, docs at python
priority: normal
severity: normal
status: open
title: Fix docs about module search order
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan  8 09:17:13 2013
From: report at bugs.python.org (Dmitry Mugtasimov)
Date: Tue, 08 Jan 2013 08:17:13 +0000
Subject: [docs] [issue16891] Fix docs about module search order
In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za>
Message-ID: <1357633033.1.0.702859092983.issue16891@psf.upfronthosting.co.za>


Dmitry Mugtasimov added the comment:

UPDATE:
CHANGE
http://stackoverflow.com/questions/14183541/why-python-finds-module-instead-of-package-if-they-have-the-same-name#comment19687166_14183541

TO
http://stackoverflow.com/questions/14183541/why-python-finds-module-instead-of-package-if-they-have-the-same-name

Because the whole question and replies are important.

----------

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

From report at bugs.python.org  Tue Jan  8 11:06:48 2013
From: report at bugs.python.org (Federico Reghenzani)
Date: Tue, 08 Jan 2013 10:06:48 +0000
Subject: [docs] [issue16851] ismethod and isfunction methods error
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1357639608.83.0.561962984378.issue16851@psf.upfronthosting.co.za>


Changes by Federico Reghenzani <federico.dev at reghe.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file28630/inspect.patch

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

From report at bugs.python.org  Tue Jan  8 12:20:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Jan 2013 11:20:22 +0000
Subject: [docs] [issue16884] logging handler automatically added starting in
	3.2+
In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za>
Message-ID: <3YgWGs28drzRmP@mail.python.org>


Roundup Robot added the comment:

New changeset 51138680b968 by Vinay Sajip in branch '2.7':
Issue #16884: Updated docs to use 'note' directives.
http://hg.python.org/cpython/rev/51138680b968

----------

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

From report at bugs.python.org  Tue Jan  8 12:27:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Jan 2013 11:27:30 +0000
Subject: [docs] [issue16884] logging handler automatically added starting in
	3.2+
In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za>
Message-ID: <3YgWR60LhtzPMy@mail.python.org>


Roundup Robot added the comment:

New changeset 50af862d0625 by Vinay Sajip in branch '3.2':
Issue #16884: Updated docs to use 'note' directives in a couple of places missed earlier.
http://hg.python.org/cpython/rev/50af862d0625

New changeset b00c4a095b00 by Vinay Sajip in branch '3.3':
Issue #16884: Merged doc fix from 3.2.
http://hg.python.org/cpython/rev/b00c4a095b00

New changeset 4617b7ac302a by Vinay Sajip in branch 'default':
Issue #16884: Merged doc fix from 3.3.
http://hg.python.org/cpython/rev/4617b7ac302a

----------

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

From report at bugs.python.org  Tue Jan  8 12:32:53 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 08 Jan 2013 11:32:53 +0000
Subject: [docs] [issue16884] logging handler automatically added starting in
	3.2+
In-Reply-To: <1357558493.08.0.0121878103652.issue16884@psf.upfronthosting.co.za>
Message-ID: <1357644773.07.0.0781163544363.issue16884@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks!

----------

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

From report at bugs.python.org  Tue Jan  8 13:30:35 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Jan 2013 12:30:35 +0000
Subject: [docs] [issue16805] when building docs on Debian 7 --> ERROR: Error
	in	"note" directive
In-Reply-To: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za>
Message-ID: <1357648235.71.0.296210570201.issue16805@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/issue16805>
_______________________________________

From report at bugs.python.org  Tue Jan  8 13:57:22 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Jan 2013 12:57:22 +0000
Subject: [docs] [issue16851] ismethod and isfunction methods error
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1357649842.22.0.701636480975.issue16851@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/issue16851>
_______________________________________

From report at bugs.python.org  Tue Jan  8 13:57:52 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Jan 2013 12:57:52 +0000
Subject: [docs] [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1357649872.69.0.349488835009.issue16851@psf.upfronthosting.co.za>


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


----------
title: ismethod and isfunction methods error -> Hint about correct ismethod and isfunction usage

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

From report at bugs.python.org  Tue Jan  8 13:58:35 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Jan 2013 12:58:35 +0000
Subject: [docs] [issue16891] Fix docs about module search order
In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za>
Message-ID: <1357649915.47.0.758412255239.issue16891@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon, ncoghlan

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

From report at bugs.python.org  Tue Jan  8 14:03:59 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 08 Jan 2013 13:03:59 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357650239.41.0.870883420235.issue5066@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Idle needs to find its text help files at runtime, so they are installed as data alongside with the code.  The rst doc files however can be installed anywhere or not installed at all, so we can?t change Idle to look for them.

An alternate idea to avoid duplication could be to copy the rst file to the code directory at build time.

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

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

From report at bugs.python.org  Tue Jan  8 14:32:20 2013
From: report at bugs.python.org (Federico Reghenzani)
Date: Tue, 08 Jan 2013 13:32:20 +0000
Subject: [docs] [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1357651940.02.0.989642294452.issue16851@psf.upfronthosting.co.za>


Changes by Federico Reghenzani <federico.dev at reghe.net>:


----------
nosy: +federico.reghenzani

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

From report at bugs.python.org  Tue Jan  8 15:12:43 2013
From: report at bugs.python.org (Dmitry Mugtasimov)
Date: Tue, 08 Jan 2013 14:12:43 +0000
Subject: [docs] [issue16891] Fix docs about module search order
In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za>
Message-ID: <1357654363.9.0.534817595782.issue16891@psf.upfronthosting.co.za>


Dmitry Mugtasimov added the comment:

As I investigate it a little closer it seems to me that it is not a documentation issue, but an implementation issue.

http://docs.python.org/2/reference/simple_stmts.html#import
"A package can contain other packages and modules while modules cannot contain other modules or packages."

The only why to import name from module is
from xyz import b
where "b" is name defined inside xyz module.

Issuing
import xyz.b
means that "b" is module or package.

Therefore xyz cannot be a module, since "...modules cannot contain other modules or packages." This means that xyz is package.

The problem is that it is considered as module for case:
python t.py

----------

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

From report at bugs.python.org  Tue Jan  8 15:43:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 08 Jan 2013 14:43:17 +0000
Subject: [docs] [issue16891] Fix docs about module search order
In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za>
Message-ID: <1357656197.18.0.951392426646.issue16891@psf.upfronthosting.co.za>


R. David Murray added the comment:

> So it looks like if "import xyz.b" bahaves different depending on how 
> a.py was initially loaded as a script or imported from another module.

There are several differences between importing a module and running a script, one of which is what is on sys.path.  You constructed your example to mask the path difference.

You are getting hit by the difference between absolute and relative imports.  How implicit relative imports behave are one of the other things that are different between running a file as a script and importing it.  This kind of confusion is one of the reasons implicit relative imports were dropped in Python3.  

If you add

  from __future__ import absolute_import

to the top of your a and t files, t will no longer produce an import error.

It could be that the documentation could be improved, but I'm not sure it is worth the effort for 2.7.  If there are statements in the 3.x docs that are incorrect now that implicit relative imports are gone, those would definitely be worth fixing.

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

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

From report at bugs.python.org  Tue Jan  8 16:04:16 2013
From: report at bugs.python.org (Dmitry Mugtasimov)
Date: Tue, 08 Jan 2013 15:04:16 +0000
Subject: [docs] [issue16891] Fix docs about module search order
In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za>
Message-ID: <1357657456.34.0.665470191827.issue16891@psf.upfronthosting.co.za>


Dmitry Mugtasimov added the comment:

A lot of people are still using python 2.7, even 2.6. For me it would be a nice fix in docs since I spent a plenty of time, trying to figure out what is going on.

In my previous comment I also pointed out that implementation probably should be fixed too, since interpreter tries to import module from module, which should not be possible according to docs. It may be an issue for Python 3 too, but I did not check.

----------

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

From report at bugs.python.org  Tue Jan  8 16:51:20 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 08 Jan 2013 15:51:20 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357660280.53.0.277314259144.issue5066@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Regardless of the topic of merge, the suggested improvements for both idle.rst and help.txt are great! Thanks for working the patch, Todd.
I am +1 with the changes. If no else has any comments, I can go ahead with committing this.

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

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

From report at bugs.python.org  Tue Jan  8 17:12:23 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Jan 2013 16:12:23 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357661543.72.0.976796230983.issue5066@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I'd like to see ?ric, Ezio, and my comments on v3 in Rietveld addressed, but after that I'm good with it :)

----------

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

From report at bugs.python.org  Tue Jan  8 17:45:12 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Jan 2013 16:45:12 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
Message-ID: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Lib/idlelib/help.txt and Doc/library/idle.rst contain almost exactly the same information, only formatted a bit differently.  This issue is to suggest the merger of the two files, by way of creating help.txt from idle.rst as a part of the build or install process.

This could be as simple as merely copying the one to the other, but that of course leaves in place all reST directives that mean nothing to a simple text document.  Thus, idle.rst should be processed to create help.txt.  This could be done with sphinx/docutils, but to avoid having the CPython build process (not just the doc build process) depend on those tools, I think a very simple dedicated script could be created to do the processing without much trouble.

As far as I can tell, this new script would only have to do a few simple steps:

- Remove comments (including index markers, etc.)
- Remove reST roles (replace ":role:`" with "`", possibly remove "`" as well)
- Remove backslash escapes
- Remove (or undouble) double colons
- Replace "#." with "1.", etc.

Thoughts?

----------
assignee: docs at python
components: Documentation, IDLE
messages: 179362
nosy: Todd.Rovito, docs at python, eric.araujo, zach.ware
priority: normal
severity: normal
status: open
title: Create IDLE help.txt from Doc/library/idle.rst
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  8 17:45:35 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 08 Jan 2013 16:45:35 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357663535.19.0.18600143266.issue5066@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Issue 16893 has been filed to deal with the idea of merging the files.

----------

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

From report at bugs.python.org  Wed Jan  9 00:12:09 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Tue, 08 Jan 2013 23:12:09 +0000
Subject: [docs] [issue1660009] continuing problem with httplib multiple
	set-cookie	headers
Message-ID: <1357686728.99.0.509642082074.issue1660009@psf.upfronthosting.co.za>


Piotr Dobrogost added the comment:

@jjlee

What you said re commas in 2007 was wrong and still is. Joining (with commas) multiple header field values having the same field name unconditionally (without knowing it's safe) was not allowed by RFC 2616 and still is not allowed by the upcoming new RFC. See my comment at http://bugs.python.org/issue4773#msg179377

This was fixed in Python 3 - see http://bugs.python.org/issue4773#msg154781 As this is backward incompatible change (and I guess weather this is private api or not does not matter here) and there's working alternative (although it's private api) nothing will be done here.

----------

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

From report at bugs.python.org  Wed Jan  9 00:40:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Jan 2013 23:40:02 +0000
Subject: [docs] [issue16891] Fix docs about module search order
In-Reply-To: <1357657456.34.0.665470191827.issue16891@psf.upfronthosting.co.za>
Message-ID: <CADiSq7d2LQgA06gNez-_XEeJBGZ9+JW6qR6ZUT3-RXGgF_47rQ@mail.gmail.com>


Nick Coghlan added the comment:

The docs sometimes try to draw a sharp distinction between modules and
packages, but it's essentially a lie - a package is really just a module
with a __path__ attribute, and if you know what you are doing, you make
even an ordinary module behave like a package (e.g. os.path)

Until 3.3, the import system had too many internal inconsistencies for sane
documentation. That's fixed in 3.3, but no comprehensive docs will be
happening for earlier versions.

----------

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

From report at bugs.python.org  Wed Jan  9 01:59:03 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Jan 2013 00:59:03 +0000
Subject: [docs] [issue16891] Fix docs about module search order
In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za>
Message-ID: <1357693143.38.0.107908594805.issue16891@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

That said, the originally proposed docs change looks like a solid improvement to me.

It's still a lie, but an appropriate one for the tutorial.

----------

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

From report at bugs.python.org  Wed Jan  9 03:30:51 2013
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 09 Jan 2013 02:30:51 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357698650.88.0.369370940549.issue5066@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Thanks Senthil but I don't deserve all the credit this issue is a team effort with lots of help from Zach, ?ric, and Ezio.  All of which have improved the patch's quality a great deal.  Hopefully we can address the issues then let you make the commit soon.

----------

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

From report at bugs.python.org  Wed Jan  9 06:29:20 2013
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 09 Jan 2013 05:29:20 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357709359.9.0.27263907082.issue5066@psf.upfronthosting.co.za>


Todd Rovito added the comment:

I took all the comments and created a new patch version 4 which should address all the issues.  Thanks for the excellent review and support from everybody.  I think this patch is a much higher quality now.

----------
Added file: http://bugs.python.org/file28643/5066IDLEocumentationforUnixObsoleteIncorrectVersion4.patch

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

From report at bugs.python.org  Wed Jan  9 07:03:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 09 Jan 2013 06:03:20 +0000
Subject: [docs] [issue13899] re pattern r"[\A]" should work like "A" but
	matches	nothing. Ditto B and Z.
In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za>
Message-ID: <1357711400.19.0.627738542163.issue13899@psf.upfronthosting.co.za>


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


----------
assignee:  -> ezio.melotti
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Jan  9 07:06:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 09 Jan 2013 06:06:55 +0000
Subject: [docs] [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1357711615.97.0.400393891744.issue16851@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ezio.melotti
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Jan  9 08:35:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 09 Jan 2013 07:35:25 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <3Yh2Dr46G2zRxC@mail.python.org>


Roundup Robot added the comment:

New changeset 3f2637a6fbfa by Ezio Melotti in branch 'default':
#16868: mention that you can "ping" issues before writing to python-dev.
http://hg.python.org/devguide/rev/3f2637a6fbfa

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

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

From report at bugs.python.org  Wed Jan  9 08:39:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 09 Jan 2013 07:39:18 +0000
Subject: [docs] [issue16868] Python Developer Guide: Include a reminder to
	"ping" bug	report if not reviewed in timely manner
In-Reply-To: <1357359666.56.0.215016911077.issue16868@psf.upfronthosting.co.za>
Message-ID: <1357717158.5.0.235250073406.issue16868@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed with a slightly different wording (thanks Chris for the suggestion).
Thanks Todd for the report and the initial patch!

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

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

From report at bugs.python.org  Wed Jan  9 08:55:45 2013
From: report at bugs.python.org (Dmitry Mugtasimov)
Date: Wed, 09 Jan 2013 07:55:45 +0000
Subject: [docs] [issue16891] Fix docs about module search order
In-Reply-To: <1357632871.49.0.196561776247.issue16891@psf.upfronthosting.co.za>
Message-ID: <1357718145.67.0.756708715287.issue16891@psf.upfronthosting.co.za>


Dmitry Mugtasimov added the comment:

Further investigation led me to the conclusion that "TO BE" should look like this:

6.1.2. The Module Search Path

When a module named spam is imported, the interpreter first searches in the containing package (the package of which the current module is a submodule) if applicable (a module is not required to be a submodule of a package). If not found or module is not a part of any package it searches for a built-in module with that name. If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations:

----------

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

From report at bugs.python.org  Wed Jan  9 15:45:16 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Jan 2013 14:45:16 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1357742716.88.0.18400141987.issue5066@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Version 4 looks good to me!

----------

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

From report at bugs.python.org  Wed Jan  9 22:04:26 2013
From: report at bugs.python.org (Ronnie Ghose)
Date: Wed, 09 Jan 2013 21:04:26 +0000
Subject: [docs] [issue16911] Socket Documentation Error
Message-ID: <1357765466.06.0.116052267024.issue16911@psf.upfronthosting.co.za>


New submission from Ronnie Ghose:

Running the example given in the docs gives the following:


In [8]: socket.getaddrinfo('www.python.org',80)
Out[8]:
[(2, 1, 6, '', ('82.94.164.162', 80)),
 (2, 2, 17, '', ('82.94.164.162', 80)),
 (2, 3, 0, '', ('82.94.164.162', 80)),
 (10, 1, 6, '', ('2001:888:2000:d::a2', 80, 0, 0)),
 (10, 2, 17, '', ('2001:888:2000:d::a2', 80, 0, 0)),
 (10, 3, 0, '', ('2001:888:2000:d::a2', 80, 0, 0))]

In [9]: socket.getaddrinfo('www.python.org',80,socket.SOL_TCP)
---------------------------------------------------------------------------
gaierror                                  Traceback (most recent call last)
/home/sghose/ADAPT/dns/<ipython-input-9-faa58a2f7926> in <module>()
----> 1 socket.getaddrinfo('www.python.org',80,socket.SOL_TCP)

gaierror: [Errno -6] ai_family not supported

----------
assignee: docs at python
components: Documentation
messages: 179487
nosy: docs at python, sghose
priority: normal
severity: normal
status: open
title: Socket Documentation Error
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan  9 22:11:43 2013
From: report at bugs.python.org (Ronnie Ghose)
Date: Wed, 09 Jan 2013 21:11:43 +0000
Subject: [docs] [issue16911] Socket Documentation Error
In-Reply-To: <1357765466.06.0.116052267024.issue16911@psf.upfronthosting.co.za>
Message-ID: <1357765903.89.0.198675266859.issue16911@psf.upfronthosting.co.za>


Changes by Ronnie Ghose <ronnie.ghose at gmail.com>:


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

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

From report at bugs.python.org  Wed Jan  9 22:11:59 2013
From: report at bugs.python.org (Ronnie Ghose)
Date: Wed, 09 Jan 2013 21:11:59 +0000
Subject: [docs] [issue16911] Socket Documentation Error
In-Reply-To: <1357765466.06.0.116052267024.issue16911@psf.upfronthosting.co.za>
Message-ID: <1357765919.12.0.365854849363.issue16911@psf.upfronthosting.co.za>


Ronnie Ghose added the comment:

sorry  - my error. accidentally omitted somethings

----------

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

From report at bugs.python.org  Thu Jan 10 16:20:31 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Jan 2013 15:20:31 +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: <1357831231.92.0.585715447218.issue16509@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jan 10 19:46:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Jan 2013 18:46:11 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1357843571.84.0.680013854295.issue8145@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 11 03:16:37 2013
From: report at bugs.python.org (Todd Rovito)
Date: Fri, 11 Jan 2013 02:16:37 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1357870597.24.0.267164923813.issue16893@psf.upfronthosting.co.za>


Todd Rovito added the comment:

I think getting this issue fixed makes sense, it would save time and remove duplication.

----------

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

From report at bugs.python.org  Fri Jan 11 05:42:03 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Jan 2013 04:42:03 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1357879323.89.0.885602509093.issue8840@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 11 06:07:28 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Jan 2013 05:07:28 +0000
Subject: [docs] [issue12901] Nest class/methods directives in documentation
In-Reply-To: <1315241119.9.0.996780726209.issue12901@psf.upfronthosting.co.za>
Message-ID: <1357880848.13.0.48814935028.issue12901@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/issue12901>
_______________________________________

From report at bugs.python.org  Fri Jan 11 06:54:24 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 11 Jan 2013 05:54:24 +0000
Subject: [docs] [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1357883664.03.0.527000954713.issue16851@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/issue16851>
_______________________________________

From ezio.melotti at gmail.com  Fri Jan 11 07:01:24 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Fri, 11 Jan 2013 06:01:24 -0000
Subject: [docs] Some minor doc fixes in Doc/library (issue 16154)
Message-ID: <20130111060124.2596.63757@psf.upfronthosting.co.za>


http://bugs.python.org/review/16154/diff/6333/Doc/library/colorsys.rst
File Doc/library/colorsys.rst (right):

http://bugs.python.org/review/16154/diff/6333/Doc/library/colorsys.rst#newcode64
Doc/library/colorsys.rst:64: (0.30000000000000004, 0.4, 0.2)
On 2013/01/07 07:27:55, ezio.melotti wrote:
> I would replace the value with something with a better repr.

FTR I tried to find a better value but apparently with all the
combinations there's some loss of precision that results in a long repr.
 This is probably caused by http://bugs.python.org/issue14323

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

From report at bugs.python.org  Fri Jan 11 07:44:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Jan 2013 06:44:49 +0000
Subject: [docs] [issue13899] re pattern r"[\A]" should work like "A" but
	matches	nothing. Ditto B and Z.
In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za>
Message-ID: <3YjF1W1f7dzS0T@mail.python.org>


Roundup Robot added the comment:

New changeset 2bc04449fd8c by Ezio Melotti in branch '2.7':
#13899: \A, \Z, and \B now correctly match the A, Z, and B literals when used inside character classes (e.g. [A]).  Patch by Matthew Barnett.
http://hg.python.org/cpython/rev/2bc04449fd8c

New changeset 081db241ccda by Ezio Melotti in branch '3.2':
#13899: \A, \Z, and \B now correctly match the A, Z, and B literals when used inside character classes (e.g. [A]).  Patch by Matthew Barnett.
http://hg.python.org/cpython/rev/081db241ccda

New changeset 17b1eb4a8144 by Ezio Melotti in branch '3.3':
#13899: merge with 3.2.
http://hg.python.org/cpython/rev/17b1eb4a8144

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

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

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

From report at bugs.python.org  Fri Jan 11 07:46:43 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Jan 2013 06:46:43 +0000
Subject: [docs] [issue13899] re pattern r"[\A]" should work like "A" but
	matches	nothing. Ditto B and Z.
In-Reply-To: <1327789733.95.0.48339527102.issue13899@psf.upfronthosting.co.za>
Message-ID: <1357886803.68.0.907746967665.issue13899@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report John, and for the patch Matthew!

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

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

From report at bugs.python.org  Fri Jan 11 08:13:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Jan 2013 07:13:10 +0000
Subject: [docs] [issue16154] Some minor doc fixes in Doc/library
In-Reply-To: <1349562325.82.0.0767622542031.issue16154@psf.upfronthosting.co.za>
Message-ID: <3YjFfF3ZfBzQpP@mail.python.org>


Roundup Robot added the comment:

New changeset 9b3d0bdb9256 by Ezio Melotti in branch '2.7':
#16154: fix some doctests in Doc/library.  Patch by Ravi Sinha.
http://hg.python.org/cpython/rev/9b3d0bdb9256

New changeset 5b405df8518d by Ezio Melotti in branch '3.2':
#16154: fix some doctests in Doc/library.  Patch by Ravi Sinha.
http://hg.python.org/cpython/rev/5b405df8518d

New changeset 3e884b3804b3 by Ezio Melotti in branch '3.3':
#16154: merge with 3.2.
http://hg.python.org/cpython/rev/3e884b3804b3

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

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

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

From report at bugs.python.org  Fri Jan 11 08:14:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Jan 2013 07:14:38 +0000
Subject: [docs] [issue16154] Some minor doc fixes in Doc/library
In-Reply-To: <1349562325.82.0.0767622542031.issue16154@psf.upfronthosting.co.za>
Message-ID: <1357888478.09.0.106186144185.issue16154@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

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

From report at bugs.python.org  Fri Jan 11 08:45:16 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 11 Jan 2013 07:45:16 +0000
Subject: [docs] [issue16928] spurious Cron Daemon e-mails to
	docs@dinsdale.python.org
Message-ID: <1357890316.54.0.914803734426.issue16928@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Some spurious e-mails are sent to python-checkins, e.g.

Subject: [Python-checkins] Cron <docs at dinsdale> /home/docs/build-devguide
From: Cron Daemon root at python.org 
To:  docs at dinsdale.python.org

/home/docs/devguide/documenting.rst:766: WARNING: term not in glossary: bytecode

(from http://mail.python.org/pipermail/python-checkins/2013-January/118934.html )

The e-mail is spurious in part because "bytecode" links correctly on the actual online version.

----------
assignee: docs at python
components: Devguide, Documentation
messages: 179643
nosy: chris.jerdonek, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: spurious Cron Daemon e-mails to docs at dinsdale.python.org

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

From report at bugs.python.org  Fri Jan 11 09:37:17 2013
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 11 Jan 2013 08:37:17 +0000
Subject: [docs] [issue16928] spurious Cron Daemon e-mails to
	docs@dinsdale.python.org
In-Reply-To: <1357890316.54.0.914803734426.issue16928@psf.upfronthosting.co.za>
Message-ID: <1357893437.28.0.435399071353.issue16928@psf.upfronthosting.co.za>


Georg Brandl added the comment:

This is a known issue in older Sphinx versions.  I've updated the version used to build the devguide now; this should fix it.

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

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

From report at bugs.python.org  Fri Jan 11 09:37:52 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 11 Jan 2013 08:37:52 +0000
Subject: [docs] [issue16928] spurious Cron Daemon e-mails to
	docs@dinsdale.python.org
In-Reply-To: <1357890316.54.0.914803734426.issue16928@psf.upfronthosting.co.za>
Message-ID: <1357893472.5.0.438723166192.issue16928@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Great, thank you! :)

----------

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

From xancorreu at gmail.com  Tue Jan  1 16:00:59 2013
From: xancorreu at gmail.com (xancorreu)
Date: Tue, 01 Jan 2013 16:00:59 +0100
Subject: [docs] possible bug in urllib.parse
Message-ID: <50E2FA2B.4090803@gmail.com>

Hi,

I found that:
urllib.parse.urlparse('localhost:8080/a')
ParseResult(scheme='localhost', netloc='', path='8080/a', params='', 
query='', fragment='')

is it a doc bug or software bug? Really, in 'localhost:8080/a' the 
scheme=None, netloc='localhost:8080' and path='/a'. So I suspect it's 
really a software bug. In that case, can someone report that. Otherwise, 
please forgive me ;-)

Regards,
Xan

From randall.baker at sbcglobal.net  Wed Jan  2 00:53:55 2013
From: randall.baker at sbcglobal.net (Randall Baker)
Date: Tue, 1 Jan 2013 15:53:55 -0800
Subject: [docs] Python glossary bug
Message-ID: <1B943F49-4B74-489B-8970-0E69201A2515@sbcglobal.net>

Using an iPad, can't scroll through glossary without page jumping back to top of page.


-Randy


 iPad

From zachary.ware at gmail.com  Sat Jan  5 07:59:45 2013
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Sat, 05 Jan 2013 06:59:45 -0000
Subject: [docs] IDLE documentation for Unix obsolete/incorrect (issue
	5066)
Message-ID: <20130105065945.26760.38510@psf.upfronthosting.co.za>

Several nitpicks and a few vague ramblings (on my part) that I hope
convey some of my thoughts on improving the overall quality of the
patch.

Overall, though, this looks like a solid update to the IDLE docs :)


http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst
File Doc/library/idle.rst (right):

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode19
Doc/library/idle.rst:19: * cross-platform: works on Windows, Unix, and
OS X
"Mac OS X" is what's most used elsewhere in the Python docs.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode22
Doc/library/idle.rst:22: features, e.g. smart indent and call tips
End this with "... and many other features".  The two features tacked on
to the end can be moved to the left side of that phrase and drop the
'e.g.'

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode32
Doc/library/idle.rst:32: IDLE has two window types the Shell window and
the Editor window. It is
There should be a colon or a comma after 'types'.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode139
Doc/library/idle.rst:139: Format menu (only in Editor window)
I think each case of '(only in (Editor|Shell) window)' would look better
as '((Editor|Shell) window only)'.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode159
Doc/library/idle.rst:159: Turn *all* tabs into the right number of
spaces
'right' should probably be changed to 'correct'.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode166
Doc/library/idle.rst:166: Open a dialog to switch between indenting with
spaces and tabs. The
Is this right? 'New Indent Width' opens the same dialog as 'Toggle
tabs'?

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode188
Doc/library/idle.rst:188: Checks the syntax of the current module which
is the code loaded in the
Perhaps 'Check the syntax of the module currently open in the Editor
window.'?

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode194
Doc/library/idle.rst:194: clean then executes the current file in the
__main__ namespace.
Wrong tense, I believe.  Better would be "Restart the shell to clean the
environment, then execute the currently open module."  Also, consistent
use of 'module' or 'file' would be good (between 'Check module' and 'Run
module', for instance).  And doesn't 'Run module' prompt for a save as
well?

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode200
Doc/library/idle.rst:200: Scrolls the shell window to the last Shell
restart
Change the tense: 'Scroll', not 'Scrolls'

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode203
Doc/library/idle.rst:203: Restarts the Python interpreter with a fresh
environment
See above comment.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode213
Doc/library/idle.rst:213: Debugger (toggle) (not complete consider it
experimental)
The 'not complete' note would be better in the description.  Better
still, the debugger's usage (and limitations) could be documented in its
own section.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode220
Doc/library/idle.rst:220: Toggle automatically opening the stack viewer
on a traceback
If I'm not mistaking the purpose of the feature, perhaps 'a traceback'
should be 'unhandled exception'?

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode237
Doc/library/idle.rst:237: is not present in the Shell window only the
Editor window.
Only need one note about which window has this option; I'm not too picky
about where it is other than to be consistent with other cases like
this.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode270
Doc/library/idle.rst:270: * Right-click in Editor window (Control-click
on OS X)
I'm not sure whether this line is still necessary.  Don't the majority
of people know what a context menu is these days?

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode323
Doc/library/idle.rst:323: * :kbd:`C-LeftArrow` and :kbd:`C-RightArrow`
moves by words in a strange but
'strange but useful' isn't very descriptive...

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode330
Doc/library/idle.rst:330: * Some useful :program:`Emacs` bindings are
inherited from TCL/Tk:
Tcl isn't all caps.  There's another instance of this a bit further
down.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode351
Doc/library/idle.rst:351: Standard Window's bindings (like :kbd:`C-c` to
copy and :kbd:`C-v` to paste)
Why the apostrophe in Windows?  And I may be wrong, but aren't these
pretty standard everywhere these days?  Maybe make it just 'Standard
keybindings (like...' instead?

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode377
Doc/library/idle.rst:377: the ACW will open immediately if a possible
continuation is found.
This paragraph switches between second and third person ("you type", "is
typed").  There are a couple other instances of second person
perspective.  I'm not sure if it's official policy, but it seems to me
that the library reference is best kept in third person and stick with
only the facts of what the code does.  Second person would be more
suited to a HOWTO. In fact, a good portion of this section would do well
as part of a separate "Using and customizing IDLE" HOWTO.

On the other hand, IDLE is pretty unique in the standard library. 
Ideally, IDLE should be documented separately (as a HOWTO, for example)
and idlelib documented within the library reference.  But that's an
entirely different issue.  Since this page is really more of a 'How to
use IDLE' page anyway, we may have more leeway with the style.  The real
point here is to pick a style and stick with it throughout the page,
whichever it be.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode400
Doc/library/idle.rst:400: Completions and the 'Expand Word' facility can
save a lot of typing!
This one is an example of not sticking to just laying out what the code
does, as mentioned in the previous comment.

http://bugs.python.org/review/5066/diff/6697/Lib/idlelib/help.txt
File Lib/idlelib/help.txt (right):

http://bugs.python.org/review/5066/diff/6697/Lib/idlelib/help.txt#newcode11
Lib/idlelib/help.txt:11: -debugger (not complete, but yes can set
breakpoints, view and step)
s/yes/you/

http://bugs.python.org/review/5066/diff/6697/Lib/idlelib/help.txt#newcode177
Lib/idlelib/help.txt:177: Go to file/line  -- Same as in Debug menu
Everything above this point should pretty much be lifted verbatim from
Doc/library/idle.rst.  As such, any comments on it apply here.

http://bugs.python.org/review/5066/diff/6697/Lib/idlelib/help.txt#newcode191
Lib/idlelib/help.txt:191: browse for its path on your machine using the
Browse button.
Is this paragraph still current?

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

From itshuchong at 126.com  Mon Jan  7 14:41:54 2013
From: itshuchong at 126.com (itshuchong at 126.com)
Date: Mon, 7 Jan 2013 21:41:54 +0800
Subject: [docs] maybe bugs of the Python Tutorial in 3.3.0 Documentation
Message-ID: <2013010721415410069811@126.com>

In the chm format help file ,Title
"3.2. First Steps Towards Programming" maybe should change to  "3.2. First Step Towards Programming".

word step shouldn't have an 's'

best wishes!




itshuchong at 126.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130107/fb3cee90/attachment-0001.html>

From k.langer at arkadin.com  Mon Jan  7 22:39:31 2013
From: k.langer at arkadin.com (Ken Langer)
Date: Mon, 7 Jan 2013 16:39:31 -0500
Subject: [docs] MOBI version of Python Docs
Message-ID: <D46D28DE7F71C346B708DCED59FDE64F0667EE82@uscolms01.arkadin.lan>

Docs Team:

 

Would it be possible to get a MOBI version of the docs to go along with
EPUB?  This will help Kindle owners along with other common e-readers.
This consideration would be appreciated.

 

Thank you.

 

Ken Langer

Engineer IV

Direct: (+1) (614)635-5305

Mobile: (+1) (614)547-3577

 

ARKADIN GLOBAL COLLABORATION SERVICES

150 East Campus View Blvd., Suite 220 * 43235 Columbus * United States 

arkadin.com <http://www.arkadin.com>   
<https://www.facebook.com/pages/Arkadin-Collaboration-Services/115628518
485203>    <http://www.linkedin.com/company/arkadin>  
<https://twitter.com/arkadinservices> 

  <https://twitter.com/arkadinservices> 

  <http://www.arkadin.com> 

Reduce travel costs, save time and contribute to a greener world using
remote collaboration solutions. <http://www.arkadin.com> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130107/4767fef4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 827 bytes
Desc: image001.jpg
URL: <http://mail.python.org/pipermail/docs/attachments/20130107/4767fef4/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 842 bytes
Desc: image002.jpg
URL: <http://mail.python.org/pipermail/docs/attachments/20130107/4767fef4/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 825 bytes
Desc: image003.jpg
URL: <http://mail.python.org/pipermail/docs/attachments/20130107/4767fef4/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 22567 bytes
Desc: image004.jpg
URL: <http://mail.python.org/pipermail/docs/attachments/20130107/4767fef4/attachment-0007.jpg>

From jeremy at gravitymarketing.com.au  Tue Jan  8 06:17:14 2013
From: jeremy at gravitymarketing.com.au (Jeremy Orchard)
Date: Tue, 8 Jan 2013 16:17:14 +1100
Subject: [docs] quick note on ftplib for python
Message-ID: <002d01cded5f$6d1fa980$475efc80$@gravitymarketing.com.au>

Hello,

 

Quick note, ftplib gives example host ftp.cwi.nl

 

In its documentation which is a url which is no longer active. when you try
the dummy example, ftplib doesn't really output a clear error so it might be
worth updating the host, (though most programmers should assume this
quickly),

 

Python 2.7 > documentation for ftplib which introduced the feature FTP_TLS
gives the examplehost ftp.python.org which is possibly the ideal candidate
for the change.

 

Not really a bug, thought id save you the trouble by reporting just incase,
it was something worth changing.

 

Cheers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130108/6ed92264/attachment-0001.html>

From ezio.melotti at gmail.com  Tue Jan  8 08:46:49 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Tue, 08 Jan 2013 07:46:49 -0000
Subject: [docs] IDLE documentation for Unix obsolete/incorrect (issue
	5066)
Message-ID: <20130108074649.2596.28458@psf.upfronthosting.co.za>


http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst
File Doc/library/idle.rst (right):

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode213
Doc/library/idle.rst:213: Not complete consider this menu option
experimental.  Run commands in the
This sentence has some problem.  Maybe "This feature is not complete and
considered experimental."?
(What does "not complete" mean?)

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode360
Doc/library/idle.rst:360: to 4 spaces if they are there. :kbd:`tab`
inserts spaces (in the Python
The other keys use capital letters, why this has been changed to
lowercase?

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode395
Doc/library/idle.rst:395: 'Hidden' attributes can be accessed by typing
the beginning of hidden
This should probably be "Hidden".

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode396
Doc/library/idle.rst:396: name after a '.'. e.g. '_'. This allows access
to modules with
'.',

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode397
Doc/library/idle.rst:397: '__all__' set, or to class-private attributes.
``__all__``

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode402
Doc/library/idle.rst:402: an Editor window which are not via __main__ or
sys.modules will not be
``__main__`` and :data:`sys.modules`

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

From anonyme.couard at gmail.com  Tue Jan  8 15:29:27 2013
From: anonyme.couard at gmail.com (anonyme couard)
Date: Tue, 08 Jan 2013 15:29:27 +0100
Subject: [docs] zlib.compressobj doesn't accept memlevel argument
Message-ID: <50EC2D47.105@gmail.com>

when trying to use 
http://docs.python.org/3/library/zlib.html#zlib.compressobj


with the folowwing code

import zlib
page1= b"page1"
page2 = b"page2"
c = 
zlib.compressobj(level=9,zdict=page1,method=zlib.DEFLATED,wbits=15,strategy=zlib.Z_DEFAULT_STRATEGY,memlevel=9)
print(len(c.compress(page2)+c.flush()))

I have the following traceback


Original exception was:
Traceback (most recent call last):
   File "test.py", line 4, in <module>
     c = 
zlib.compressobj(level=9,zdict=page1,method=zlib.DEFLATED,wbits=15,strategy=zlib.Z_DEFAULT_STRATEGY,memlevel=9)
TypeError: 'memlevel' is an invalid keyword argument for this function

I think that memlevel was replaced by wbits at a point and was not 
replaced in the documentation

my suggestion: remove memlevel



From rodarq at gmail.com  Wed Jan  9 02:44:00 2013
From: rodarq at gmail.com (Rodrigo Costa)
Date: Tue, 8 Jan 2013 23:44:00 -0200
Subject: [docs] Bits
Message-ID: <43061D2C-0034-44C0-8F92-C5667CBF1E6F@gmail.com>

I'm writing to report a bug in Python 3.4 for iOS that occurs when i'm writing a text in a split screen mode. The program shut down after i enter a second character.

I would like to know what is wrong. 
Thanks

Rodrigo

Enviado via iPad

From rovitotv at gmail.com  Wed Jan  9 05:10:09 2013
From: rovitotv at gmail.com (rovitotv at gmail.com)
Date: Wed, 09 Jan 2013 04:10:09 -0000
Subject: [docs] IDLE documentation for Unix obsolete/incorrect (issue
	5066)
Message-ID: <20130109041009.13696.18428@psf.upfronthosting.co.za>

Sorry I forgot to publish my comments last night.  I will work on
version 3 next.


http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst
File Doc/library/idle.rst (right):

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode19
Doc/library/idle.rst:19: * cross-platform: works on Windows, Unix, and
OS X
On 2013/01/05 07:59:45, zach.ware wrote:
> "Mac OS X" is what's most used elsewhere in the Python docs.

corrected

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode22
Doc/library/idle.rst:22: features, e.g. smart indent and call tips
On 2013/01/05 07:59:45, zach.ware wrote:
> End this with "... and many other features".  The two features tacked
on to the
> end can be moved to the left side of that phrase and drop the 'e.g.'
Corrected....

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode32
Doc/library/idle.rst:32: IDLE has two window types the Shell window and
the Editor window. It is
On 2013/01/05 07:59:45, zach.ware wrote:
> There should be a colon or a comma after 'types'.
Corrected....good catch.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode139
Doc/library/idle.rst:139: Format menu (only in Editor window)
On 2013/01/05 07:59:45, zach.ware wrote:
> I think each case of '(only in (Editor|Shell) window)' would look
better as
> '((Editor|Shell) window only)'.
I agree so I changed it in idle.rst

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode159
Doc/library/idle.rst:159: Turn *all* tabs into the right number of
spaces
On 2013/01/05 07:59:45, zach.ware wrote:
> 'right' should probably be changed to 'correct'.
Corrected...very good suggestion.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode166
Doc/library/idle.rst:166: Open a dialog to switch between indenting with
spaces and tabs. The
On 2013/01/05 07:59:45, zach.ware wrote:
> Is this right? 'New Indent Width' opens the same dialog as 'Toggle
tabs'?

No this is wrong some how I must of copied and paste wrong.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode188
Doc/library/idle.rst:188: Checks the syntax of the current module which
is the code loaded in the
On 2013/01/05 07:59:45, zach.ware wrote:
> Perhaps 'Check the syntax of the module currently open in the Editor
window.'?
Yes much better wording...thank you!

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode194
Doc/library/idle.rst:194: clean then executes the current file in the
__main__ namespace.
On 2013/01/05 07:59:45, zach.ware wrote:
> Wrong tense, I believe.  Better would be "Restart the shell to clean
the
> environment, then execute the currently open module."  Also,
consistent use of
> 'module' or 'file' would be good (between 'Check module' and 'Run
module', for
> instance).  And doesn't 'Run module' prompt for a save as well?

Corrected...thanks!

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode200
Doc/library/idle.rst:200: Scrolls the shell window to the last Shell
restart
On 2013/01/05 07:59:45, zach.ware wrote:
> Change the tense: 'Scroll', not 'Scrolls'
Again very good catch....thank you.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode203
Doc/library/idle.rst:203: Restarts the Python interpreter with a fresh
environment
On 2013/01/05 07:59:45, zach.ware wrote:
> See above comment.
I went with "Restart the shell to clean the environment"

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode213
Doc/library/idle.rst:213: Debugger (toggle) (not complete consider it
experimental)
On 2013/01/05 07:59:45, zach.ware wrote:
> The 'not complete' note would be better in the description.  Better
still, the
> debugger's usage (and limitations) could be documented in its own
section.
I went with:
"Not complete consider this menu option experimental.  Run commands in
the shell under the debugger"

I do agree with your statement somebody needs to either fix the debugger
in IDLE or remove it.  The current state is not good because it can
easily confuse the user.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode220
Doc/library/idle.rst:220: Toggle automatically opening the stack viewer
on a traceback
On 2013/01/05 07:59:45, zach.ware wrote:
> If I'm not mistaking the purpose of the feature, perhaps 'a traceback'
should be
> 'unhandled exception'?
Yes you are correct....I always think traceback = unhandled exception
but they are two different things.  Excellent feedback thanks!

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode237
Doc/library/idle.rst:237: is not present in the Shell window only the
Editor window.
On 2013/01/05 07:59:45, zach.ware wrote:
> Only need one note about which window has this option; I'm not too
picky about
> where it is other than to be consistent with other cases like this.
Good point thanks!!!!!

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode270
Doc/library/idle.rst:270: * Right-click in Editor window (Control-click
on OS X)
On 2013/01/05 07:59:45, zach.ware wrote:
> I'm not sure whether this line is still necessary.  Don't the majority
of people
> know what a context menu is these days?
I agree most people should know what a context menu is but what about
the other set of people that don't know?  Just to be safe I think we
should leave it in the patch.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode323
Doc/library/idle.rst:323: * :kbd:`C-LeftArrow` and :kbd:`C-RightArrow`
moves by words in a strange but
On 2013/01/05 07:59:45, zach.ware wrote:
> 'strange but useful' isn't very descriptive...
I didn't write this part....it has been a part of the Python
documentation for some time.  I actually like it even though I think you
are correct it is not very descriptive.  When a user reads that line
hopefully they will become curious and try the feature out.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode330
Doc/library/idle.rst:330: * Some useful :program:`Emacs` bindings are
inherited from TCL/Tk:
On 2013/01/05 07:59:45, zach.ware wrote:
> Tcl isn't all caps.  There's another instance of this a bit further
down.
I can't believe I missed that one....I must of been sleepy when I was
working on this patch.  I corrected the earlier instance of this as
well. Thanks.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode351
Doc/library/idle.rst:351: Standard Window's bindings (like :kbd:`C-c` to
copy and :kbd:`C-v` to paste)
On 2013/01/05 07:59:45, zach.ware wrote:
> Why the apostrophe in Windows?  And I may be wrong, but aren't these
pretty
> standard everywhere these days?  Maybe make it just 'Standard
keybindings
> (like...' instead?
This part of the documentation existed before I got it but I think the
apostrophe is a standard feature of rst files.  I will check into this
more and see what I find.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode377
Doc/library/idle.rst:377: the ACW will open immediately if a possible
continuation is found.
On 2013/01/05 07:59:45, zach.ware wrote:
> This paragraph switches between second and third person ("you type",
"is
> typed").  There are a couple other instances of second person
perspective.  I'm
> not sure if it's official policy, but it seems to me that the library
reference
> is best kept in third person and stick with only the facts of what the
code
> does.  Second person would be more suited to a HOWTO. In fact, a good
portion of
> this section would do well as part of a separate "Using and
customizing IDLE"
> HOWTO.
> 
> On the other hand, IDLE is pretty unique in the standard library. 
Ideally, IDLE
> should be documented separately (as a HOWTO, for example) and idlelib
documented
> within the library reference.  But that's an entirely different issue.
 Since
> this page is really more of a 'How to use IDLE' page anyway, we may
have more
> leeway with the style.  The real point here is to pick a style and
stick with it
> throughout the page, whichever it be.
Interesting idea a HOWTO on IDLE.....

I agree the person perspective should be the same.  I changed "you type"
to "is typed". It reads much better.

http://bugs.python.org/review/5066/diff/6697/Doc/library/idle.rst#newcode400
Doc/library/idle.rst:400: Completions and the 'Expand Word' facility can
save a lot of typing!
On 2013/01/05 07:59:45, zach.ware wrote:
> This one is an example of not sticking to just laying out what the
code does, as
> mentioned in the previous comment.

I agree we should create a HOWTO and move all this stuff over.

http://bugs.python.org/review/5066/diff/6697/Lib/idlelib/help.txt
File Lib/idlelib/help.txt (right):

http://bugs.python.org/review/5066/diff/6697/Lib/idlelib/help.txt#newcode191
Lib/idlelib/help.txt:191: browse for its path on your machine using the
Browse button.
On 2013/01/05 07:59:45, zach.ware wrote:
> Is this paragraph still current?
I am not sure so I left it.  I am not a big windows user in fact I try
to avoid it.

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

From rovitotv at gmail.com  Wed Jan  9 06:13:29 2013
From: rovitotv at gmail.com (rovitotv at gmail.com)
Date: Wed, 09 Jan 2013 05:13:29 -0000
Subject: [docs] IDLE documentation for Unix obsolete/incorrect (issue
	5066)
Message-ID: <20130109051329.2642.81960@psf.upfronthosting.co.za>

Made several comments based on people's inputs in idle.rst.  A version 4
should be added to issue tracker soon.  Thanks!


http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst
File Doc/library/idle.rst (right):

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode21
Doc/library/idle.rst:21: * multi-window text editor with multiple undo,
Python colorizing
On 2013/01/08 14:14:18, eric.araujo wrote:
> Missing comma at end of this line.
Yes I did correct in V4...Thanks!

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode22
Doc/library/idle.rst:22: smart indent, call tips, and many other
features.
On 2013/01/08 15:45:26, zach.ware wrote:
> Lose the period at the end of this line; it's not a sentence and the
other
> bullet points don't have periods either.
Dang you are right thanks!

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode213
Doc/library/idle.rst:213: Not complete consider this menu option
experimental.  Run commands in the
On 2013/01/08 08:46:49, ezio.melotti wrote:
> This sentence has some problem.  Maybe "This feature is not complete
and
> considered experimental."?
> (What does "not complete" mean?)
Good question about what does "not complete" mean.  I am only using that
phrase because that is what existed in the documentation before this
patch.  Recently I did test the debugger and it does need some work on
it but that is perhaps another issue.  I do like how you phrased that
sentence and have corrected.

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode220
Doc/library/idle.rst:220: Toggle automatically opening the stack viewer
on a unhandled exception
On 2013/01/08 15:45:26, zach.ware wrote:
> We can lose the 'a' in 'on a unhandled'.
Corrected in V4

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode234
Doc/library/idle.rst:234: Code Context (toggle)(only in Editor Window)
On 2013/01/08 15:45:26, zach.ware wrote:
> Here's another '(only in Editor Window)' to become '(Editor window
only)'.
Corrected in V4

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode322
Doc/library/idle.rst:322: * :kbd:`C-LeftArrow` and :kbd:`C-RightArrow`
moves by words in a strange but
On 2013/01/08 15:45:26, zach.ware wrote:
> I still don't know what 'strange but useful' means. If it's basically
the same
> as the behavior you can get out of MS Notepad with the same
keybindings, we can
> just leave off the 'strange but useful' part.
Removed the "strange but useful" even though I thought the wording was
interesting but you bring up a valid point what does that mean?

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode329
Doc/library/idle.rst:329: * Some useful :program:`Emacs` bindings are
inherited from Tcl/Tk:
On 2013/01/08 14:14:19, eric.araujo wrote:
> FWIW, the program markup here is wholly useless.
Good catch....I corrected and removed the markup around Emacs in V4.

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode350
Doc/library/idle.rst:350: Standard Window's bindings (like :kbd:`C-c` to
copy and :kbd:`C-v` to paste)
On 2013/01/08 15:45:26, zach.ware wrote:
> See comment in last review.
Zach wrote in the last review:
"Why the apostrophe in Windows?  And I may be wrong, but aren't these
pretty
standard everywhere these days?  Maybe make it just 'Standard
keybindings
(like...' instead?"

This part of the documentation existed before I got it but you are right
Windows should not have an apostrophe. ?IDLE is very strange because you
can actually select which key bindings you want to use so I can use
Window's key bindings on my Mac.  Normally on a Mac copy would be
command-c not control-c.  I like your suggestion so I modified the
wording in V4. My comments from patch 3 might not make sense so you can
ignore those.  Thanks!

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode360
Doc/library/idle.rst:360: to 4 spaces if they are there. :kbd:`tab`
inserts spaces (in the Python
On 2013/01/08 08:46:49, ezio.melotti wrote:
> The other keys use capital letters, why this has been changed to
lowercase?
Yes you are correct...thanks!

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode361
Doc/library/idle.rst:361: Shell window one tab), number depends on
Indent width. (N.B. Currently tabs
On 2013/01/08 14:14:19, eric.araujo wrote:
> I don?t know if the abbreviation ?NB? exists in English.  Anyhow,
saying ?Note:
> X? or ?Note that X? is often not really helpful: we can just write
?X?.
Thanks Eric!!! I was wondering what the heck NB meant....

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode395
Doc/library/idle.rst:395: 'Hidden' attributes can be accessed by typing
the beginning of hidden
On 2013/01/08 08:46:49, ezio.melotti wrote:
> This should probably be "Hidden".
Corrected in V4.

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode396
Doc/library/idle.rst:396: name after a '.'. e.g. '_'. This allows access
to modules with
On 2013/01/08 08:46:49, ezio.melotti wrote:
> '.',
Excellent catch....corrected!

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode397
Doc/library/idle.rst:397: '__all__' set, or to class-private attributes.
On 2013/01/08 08:46:49, ezio.melotti wrote:
> ``__all__``
Ok I corrected in V4.

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode402
Doc/library/idle.rst:402: an Editor window which are not via __main__ or
sys.modules will not be
On 2013/01/08 08:46:49, ezio.melotti wrote:
> ``__main__`` and :data:`sys.modules`
Ok I corrected in V4.

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode516
Doc/library/idle.rst:516: available at docs.python.org.  Selected URLs
can be added or removed from
On 2013/01/08 14:14:19, eric.araujo wrote:
> I don?t really understand the first sentence.  Readers already know
that they
> can access the Python doc, because they are reading a page from these
docs. 
> Maybe by ?access? you mean that there is a menu entry in IDLE that
opens the
> docs?  If so, I think you could start by saying that.
Ok I tried to correct as you suggested in version 4.  Thanks.

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

From rovitotv at gmail.com  Wed Jan  9 06:24:39 2013
From: rovitotv at gmail.com (rovitotv at gmail.com)
Date: Wed, 09 Jan 2013 05:24:39 -0000
Subject: [docs] IDLE documentation for Unix obsolete/incorrect (issue
	5066)
Message-ID: <20130109052439.13696.94965@psf.upfronthosting.co.za>

comments on help.txt


http://bugs.python.org/review/5066/diff/7039/Lib/idlelib/help.txt
File Lib/idlelib/help.txt (right):

http://bugs.python.org/review/5066/diff/7039/Lib/idlelib/help.txt#newcode199
Lib/idlelib/help.txt:199: tutorials, available at www.python.org/doc. 
Selected URLs can be added
I updated this line to docs.python.org..

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

From ezio.melotti at gmail.com  Wed Jan  9 06:25:22 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Wed, 09 Jan 2013 05:25:22 -0000
Subject: [docs] IDLE documentation for Unix obsolete/incorrect (issue
	5066)
Message-ID: <20130109052522.2596.67820@psf.upfronthosting.co.za>


http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst
File Doc/library/idle.rst (right):

http://bugs.python.org/review/5066/diff/7039/Doc/library/idle.rst#newcode361
Doc/library/idle.rst:361: Shell window one tab), number depends on
Indent width. (N.B. Currently tabs
On 2013/01/08 14:14:19, eric.araujo wrote:
> I don?t know if the abbreviation ?NB? exists in English.  
It's Latin and it's used in English too:
http://en.wikipedia.org/wiki/Nota_bene

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

From alex.rudnick at gmail.com  Thu Jan 10 07:41:34 2013
From: alex.rudnick at gmail.com (Alex Rudnick)
Date: Thu, 10 Jan 2013 01:41:34 -0500
Subject: [docs] tiny grammatical error in the argparse docs
Message-ID: <CAFQKO71PNB73nAOyf5j07UQrJERywGoL9uH5FqqH67Z6-V1HOw@mail.gmail.com>

On the page: http://docs.python.org/dev/library/argparse.html#metavar

In the sentence "When ArgumentParser generates help messages, it need
some way to refer to each expected argument."

"need" should be "needs".

Thanks! :)

--
-- alexr

From sandro.tosi at gmail.com  Fri Jan 11 10:34:20 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 11 Jan 2013 10:34:20 +0100
Subject: [docs] MOBI version of Python Docs
In-Reply-To: <D46D28DE7F71C346B708DCED59FDE64F0667EE82@uscolms01.arkadin.lan>
References: <D46D28DE7F71C346B708DCED59FDE64F0667EE82@uscolms01.arkadin.lan>
Message-ID: <CAB4XWXzZDaWrgqzedynKttjZWp_yKEQDanQsUZUxKmgR8Orkmw@mail.gmail.com>

Hello Ken,


On Mon, Jan 7, 2013 at 10:39 PM, Ken Langer <k.langer at arkadin.com> wrote:
> Would it be possible to get a MOBI version of the docs to go along with EPUB?  This will help Kindle owners along with other common e-readers.   This consideration would be appreciated.

This is not the first time we've asked for MOBI format, next time,
please check the archive before posting new questions.

The answer here is: we need to improve our documentation-generator
tool, sphinx, to generate MOBI format too; there's already a bug to
track this activity
https://bitbucket.org/birkenfeld/sphinx/issue/739/please-add-a-mobi-builder
so you can propose your help on the bug to speed up its resolution
(code patches or volunteer to test beta versions when the support will
be added is usually appreciated).

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

From sandro.tosi at gmail.com  Fri Jan 11 10:41:48 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 11 Jan 2013 10:41:48 +0100
Subject: [docs] Python glossary bug
In-Reply-To: <1B943F49-4B74-489B-8970-0E69201A2515@sbcglobal.net>
References: <1B943F49-4B74-489B-8970-0E69201A2515@sbcglobal.net>
Message-ID: <CAB4XWXx-HYZ7Hhr1MmxJ5cQxkr3yhVBqRmj2320NsezFEeG8_A@mail.gmail.com>

Hello Randall,

On Wed, Jan 2, 2013 at 12:53 AM, Randall Baker
<randall.baker at sbcglobal.net> wrote:
> Using an iPad, can't scroll through glossary without page jumping back to top of page.

This report is a bit incomplete: can you please tell us what version
of the documentation you were reading? what was the precise url you
were visiting? what version of iPad/Safari you were using?

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

From sandro.tosi at gmail.com  Fri Jan 11 10:52:21 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 11 Jan 2013 10:52:21 +0100
Subject: [docs] tiny grammatical error in the argparse docs
In-Reply-To: <CAFQKO71PNB73nAOyf5j07UQrJERywGoL9uH5FqqH67Z6-V1HOw@mail.gmail.com>
References: <CAFQKO71PNB73nAOyf5j07UQrJERywGoL9uH5FqqH67Z6-V1HOw@mail.gmail.com>
Message-ID: <CAB4XWXwECMyWE9qM29s2M3j5qqkrTkLiSn2BbcrzVnOu70g-Aw@mail.gmail.com>

Hello Alex,
thanks for your email

On Thu, Jan 10, 2013 at 7:41 AM, Alex Rudnick <alex.rudnick at gmail.com> wrote:
> On the page: http://docs.python.org/dev/library/argparse.html#metavar
>
> In the sentence "When ArgumentParser generates help messages, it need
> some way to refer to each expected argument."
>
> "need" should be "needs".

This has just been fixed on all the active branches of Python
development - thanks!

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

From sandro.tosi at gmail.com  Fri Jan 11 12:30:22 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 11 Jan 2013 12:30:22 +0100
Subject: [docs] possible bug in urllib.parse
In-Reply-To: <50E2FA2B.4090803@gmail.com>
References: <50E2FA2B.4090803@gmail.com>
Message-ID: <CAB4XWXyQxxikXP=urTzNefMmxRBCwtwDC0q9n56T9T=wTU1vYg@mail.gmail.com>

Hello xancorreu,

On Tue, Jan 1, 2013 at 4:00 PM, xancorreu <xancorreu at gmail.com> wrote:
> Hi,
>
> I found that:
> urllib.parse.urlparse('localhost:8080/a')
> ParseResult(scheme='localhost', netloc='', path='8080/a', params='',
> query='', fragment='')
>
> is it a doc bug or software bug? Really, in 'localhost:8080/a' the
> scheme=None, netloc='localhost:8080' and path='/a'. So I suspect it's really
> a software bug. In that case, can someone report that. Otherwise, please
> forgive me ;-)

I've just reported http://bugs.python.org/issue16932 to keep track of
it, thanks for spotting and reporting it!

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

From report at bugs.python.org  Fri Jan 11 15:57:54 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Jan 2013 14:57:54 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1357916274.87.0.571687568205.issue8145@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe this patch is correct in essence, but I think it would be helpful to clarify the explanation of what autocommit mode is.  I'll work on an updated patch.

It could also be considered a bug that the standard context manager does not support autocommit mode, but I'm going to treat that as a separate bug.  Perhaps a fix will come out of fixing issue 10740.

----------

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

From report at bugs.python.org  Fri Jan 11 16:31:22 2013
From: report at bugs.python.org (Jens Lechtenboerger)
Date: Fri, 11 Jan 2013 15:31:22 +0000
Subject: [docs] [issue16936] Documentation for stat.S_IFMT inconsistent
Message-ID: <1357918282.52.0.0217764551769.issue16936@psf.upfronthosting.co.za>


New submission from Jens Lechtenboerger:

The documentation for the stat module is inconsistent
(Doc/library/stat.rst, at least for Python 2.7.2 and 3.3.0):
It talks about a function stat.S_IFMT() and a bit mask stat.S_IFMT.
Only the former does exist.

Besides, it states: "For complete details about the stat(), fstat()
and lstat() calls, consult the documentation for your system."
I suggest to add some pointers on what systems one might consult
what documentation: "(e.g., on GNU/Linux invoke 'man 2 stat')"
I don't know about other systems, though.

So, doing "man 2 stat", which refers to the POSIX standard and which
seems to have served as blueprint for stat's interface, I expected
to find the bit mask S_IFMT.
However, that does not exist.  In contrast, in stat.py that bit mask
is hard-coded as 0o170000 in the definition of S_IFMT().

As long-term, backwards-incompatible fix, I suggest to export
S_IFMT = 0o170000
and to rename the function S_IFMT().  That way, stat would in fact
be aligned with the documentation for my system.

As short-term fix, I suggest to correct stat.rst.

Replace
> Use of the functions above is more portable than use of the first
> set of flags:
>
> stat.S_IFMT
>    Bit mask for the file type bit fields.

with
> Use of the functions above may be more portable than use of the
> first set of flags.
>
> Warning: Note that the stat module does not export a bit mask
> S_IFMT. (As stated incorrectly in previous versions of the
> documentation.)

Here, I replaced "is more portable" with "may be more portable" as
the constant 0o170000 is hard-coded into S_IFMT() in stat.py.  Maybe
somebody could add a hint in what sense portability is improved?
Alternatively that sentence could be deleted.

A diff for stat.rst (Python 3.3.0) is attached.

----------
assignee: docs at python
components: Documentation
files: stat.rst.diff
keywords: patch
messages: 179687
nosy: docs at python, lechten
priority: normal
severity: normal
status: open
title: Documentation for stat.S_IFMT inconsistent
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file28697/stat.rst.diff

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

From report at bugs.python.org  Fri Jan 11 17:22:17 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jan 2013 16:22:17 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1357921337.24.0.274877632681.issue16893@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 11 17:27:35 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 11 Jan 2013 16:27:35 +0000
Subject: [docs] [issue10894] Making stdlib APIs private
In-Reply-To: <1294838236.87.0.84648349826.issue10894@psf.upfronthosting.co.za>
Message-ID: <1357921655.62.0.350248274947.issue10894@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So I just closed the dependency on this issue as I figured the potential code breakage wasn't worth this (plus the referenced TODO item from the devguide is gone and was never turned into a proper task).

Now the question becomes do the guidelines SilentGhost wrote out belong somewhere in the docs?

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

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

From georg at python.org  Fri Jan 11 17:40:38 2013
From: georg at python.org (Georg Brandl)
Date: Fri, 11 Jan 2013 17:40:38 +0100
Subject: [docs] MOBI version of Python Docs
In-Reply-To: <CAB4XWXzZDaWrgqzedynKttjZWp_yKEQDanQsUZUxKmgR8Orkmw@mail.gmail.com>
References: <D46D28DE7F71C346B708DCED59FDE64F0667EE82@uscolms01.arkadin.lan>
	<CAB4XWXzZDaWrgqzedynKttjZWp_yKEQDanQsUZUxKmgR8Orkmw@mail.gmail.com>
Message-ID: <50F04086.4040504@python.org>

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

Am 11.01.2013 10:34, schrieb Sandro Tosi:
> Hello Ken,
> 
> 
> On Mon, Jan 7, 2013 at 10:39 PM, Ken Langer <k.langer at arkadin.com> wrote:
>> Would it be possible to get a MOBI version of the docs to go along with
>> EPUB?  This will help Kindle owners along with other common e-readers.
>> This consideration would be appreciated.
> 
> This is not the first time we've asked for MOBI format, next time, please
> check the archive before posting new questions.

Hi Sandro,

the archive is not readily available to people posting to this list; it is
not intended that everyone who sends a one-off bug report or suggestion has
to subscribe, and in any case docs.python.org does not talk about a mailing
list.

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

iEYEARECAAYFAlDwQIYACgkQN9GcIYhpnLA3jACfYdEyyw0sfZ6BOIMHzqqey921
P4YAn1S9fYziZhvC8891FlWTOjzdr1QH
=/WtG
-----END PGP SIGNATURE-----

From report at bugs.python.org  Fri Jan 11 18:32:46 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 11 Jan 2013 17:32:46 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1357925566.35.0.229871190171.issue16893@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

I like the proposition in general, but files should be synchronized first.

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

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

From report at bugs.python.org  Fri Jan 11 18:38:01 2013
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 11 Jan 2013 17:38:01 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1357925880.98.0.77083428628.issue16893@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Note that Sphinx' "make text" output already should be suitable. We already update the pydoc topics with that on every release, so we could just as well do the same for the IDLE doc.  No need for another separate script.

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

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

From report at bugs.python.org  Fri Jan 11 19:22:02 2013
From: report at bugs.python.org (Martijn Pieters)
Date: Fri, 11 Jan 2013 18:22:02 +0000
Subject: [docs] [issue16937] -u (unbuffered I/O) command line option
	documentation	mismatch for sys.stdin
Message-ID: <1357928522.67.0.838908652159.issue16937@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

Run `python3.3 -h` and the `-u` option is documented as:

>     -u     : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x
>              see man page for details on internal buffering relating to '-u'

Note that only `stdout` and `stderr` are mentioned.

The online documentation at http://docs.python.org/3/using/cmdline.html#cmdoption-u doesn't agree:

> ... the binary layer of the stdin, stdout and stderr streams ...

nor does `man python3.3`, which claims:

>    -u     Force the binary I/O layers of stdin, stdout and stderr to be unbuffered.  The text I/O layer will still
>           be line-buffered.

So, is `stdin` going to be unbuffered, or not, when using `-u`?

Running a simple test shows that `stdin` is firmly being buffered regardless of the `-u` switch:

    $ python3.3 -c 'import sys; print(sys.stdin.buffer, sys.stdout.buffer)'
    <_io.BufferedReader name='<stdin>'> <_io.BufferedWriter name='<stdout>'>
    $ python3.3 -u -c 'import sys; print(sys.stdin.buffer, sys.stdout.buffer)'
    <_io.BufferedReader name='<stdin>'> <_io.FileIO name='<stdout>' mode='wb'>

I'll presume here that `stdin` is deliberately buffered, regardless, and that the documentation and man page are out of date here (in python 2, `-u` does include `stdin`).

----------
assignee: docs at python
components: Documentation
messages: 179718
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: -u (unbuffered I/O) command line option documentation mismatch for sys.stdin
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan 11 19:36:05 2013
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 11 Jan 2013 18:36:05 +0000
Subject: [docs] [issue16937] -u (unbuffered I/O) command line option
	documentation	mismatch for sys.stdin
In-Reply-To: <1357928522.67.0.838908652159.issue16937@psf.upfronthosting.co.za>
Message-ID: <1357929365.15.0.402149273235.issue16937@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 11 20:26:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Jan 2013 19:26:01 +0000
Subject: [docs] [issue16936] Documentation for stat.S_IFMT inconsistent
In-Reply-To: <1357918282.52.0.0217764551769.issue16936@psf.upfronthosting.co.za>
Message-ID: <3YjYvr0sFXzS9y@mail.python.org>


Roundup Robot added the comment:

New changeset 0d7a8a4d6f30 by Georg Brandl in branch '2.7':
Closes #16936: fix duplicate/ambiguous description of stat.S_IFMT in the docs.
http://hg.python.org/cpython/rev/0d7a8a4d6f30

New changeset 3555391a9909 by Georg Brandl in branch '3.3':
Closes #16936: fix duplicate/ambiguous description of stat.S_IFMT in the docs.
http://hg.python.org/cpython/rev/3555391a9909

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

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

From report at bugs.python.org  Fri Jan 11 21:33:33 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 11 Jan 2013 20:33:33 +0000
Subject: [docs] [issue16933] argparse: remove magic from examples
In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za>
Message-ID: <1357936413.73.0.81745563466.issue16933@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Patch attached.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy, patch
nosy: +docs at python
stage: needs patch -> patch review
Added file: http://bugs.python.org/file28698/issue-16933-1.patch

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

From sandro.tosi at gmail.com  Fri Jan 11 23:36:23 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 11 Jan 2013 23:36:23 +0100
Subject: [docs] Minor addition to Multiprocessing doc
In-Reply-To: <op.wp1zgwm67c0ih3@transp20091>
References: <op.wp1zgwm67c0ih3@transp20091>
Message-ID: <CAB4XWXwK_2TT2gS0PhSSEdrrjteSzxGPVWYnCND=1y9_ihSyag@mail.gmail.com>

Hello Juan,
thanks for your email

On Sat, Dec 29, 2012 at 1:54 AM, Juan <juan_benavente_ponce at yahoo.es> wrote:
>  Hello! I use Python 3.3, and I have noticed that nowhere in the on-line
> documentation it is mentioned that a multiprocessing.Manager() object has a
> JoinableQueue method. Maybe it is a good idea to include this information,
> both for Python 3.3 and Python 2.7, like this:

Your email is very detailed, but "hard" to read: would you be able to
provide a patch, against our documentation, to implement what you are
mentioning in this email? You'd find a huge amount of information on
how to do it at http://docs.python.org/devguide/

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

From report at bugs.python.org  Fri Jan 11 23:47:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Jan 2013 22:47:46 +0000
Subject: [docs] [issue16937] -u (unbuffered I/O) command line option
	documentation	mismatch for sys.stdin
In-Reply-To: <1357928522.67.0.838908652159.issue16937@psf.upfronthosting.co.za>
Message-ID: <1357944466.59.0.778719352347.issue16937@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Indeed, stdin is always buffered, simply because it doesn't make a difference (except if you're trying to read raw data from fd 0).

----------

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

From sandro.tosi at gmail.com  Sat Jan 12 01:02:10 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 12 Jan 2013 01:02:10 +0100
Subject: [docs] maybe bugs of the Python Tutorial in 3.3.0 Documentation
In-Reply-To: <2013010721415410069811@126.com>
References: <2013010721415410069811@126.com>
Message-ID: <CAB4XWXxt4-P5x0LKyxVatBMPqqPrFYgWdsm+6K4TwvWe7Ym2xA@mail.gmail.com>

Hello,

On Mon, Jan 7, 2013 at 2:41 PM, itshuchong at 126.com <itshuchong at 126.com> wrote:
> In the chm format help file ,Title
> "3.2. First Steps Towards Programming" maybe should change to  "3.2. First
> Step Towards Programming".
>
> word step shouldn't have an 's'

I think the original title is correct: "first steps" is a sort of
idiomatic expression for situations where you're walked into an
argument, and since walking means making steps, here's the title.

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

From sandro.tosi at gmail.com  Sat Jan 12 01:34:06 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 12 Jan 2013 01:34:06 +0100
Subject: [docs] Cover alternative for the tutorial
In-Reply-To: <BLU002-W33598566DF695AF25146F8AA430@phx.gbl>
References: <BLU002-W33598566DF695AF25146F8AA430@phx.gbl>
Message-ID: <CAB4XWXydT33q74tmZCozvgKZkcfXS-n4dY8VNc6qyiOXA0HEjA@mail.gmail.com>

Hello Din?el,
thanks for your email.

On Fri, Nov 30, 2012 at 11:16 AM, Din?el Ta?p?nar <dincel at live.com> wrote:
> 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.

That seems like a nice front page to me. I think you'll get even more
reviews/opinions, if you can create a patch against our documentation
(you can refer to docs.python.org/devguide/ for how do to it) and post
it on the bug tracker at http://bugs.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 Jan 12 03:37:05 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Jan 2013 02:37:05 +0000
Subject: [docs] [issue16901] In http.cookiejar.FileCookieJar() the .load()
	and	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1357958225.11.0.589089896723.issue16901@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

First, a minor issue about class signatures:
doc: FileCookieJar(filename, delayload=None, policy=None)
code: def __init__(self, filename=None, delayload=False, policy=None)
Pretty clearly, doc should be changed to match code, as later code allow for possibility of filename = None (meaning that that is intentional).

Ditto for doc for FileCookieJar subclasses (which inherit __init__):
MozillaCookieJar(filename, delayload=None, policy=None) 
LWPCookieJar(filename, delayload=None, policy=None)

--- 
FileCookieJar has .load which in inherited by the subclasses. It checks for a filename and opens it and then calls ._really_load. The two subclasses have customized ._really_load methods that correspond to their customized .save methods.

FileCookieJar itself does not. If it did, it would have to somehow be 'generic'. This suggests to me that FileCookieJar was not intended to be directly used. This impression is reinforced by the definition of .save().

    def save(self, filename=None, ignore_discard=False, ignore_expires=False):
        """Save cookies to a file."""
        raise NotImplementedError()

In other words, there is no generic format to save to *or* load from.
There should be a corresponding ._really_load to raise the same exception.

Bottom line: as best I understand, your code is not intended to work, but both the doc and implementation are deficient in not saying so, and both should be improved.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, terry.reedy
stage:  -> test needed
versions: +Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Sat Jan 12 03:59:12 2013
From: report at bugs.python.org (Jason Alvarado)
Date: Sat, 12 Jan 2013 02:59:12 +0000
Subject: [docs] [issue16939] Broken link in 14. Cryptographic Service
Message-ID: <1357959551.72.0.678573558111.issue16939@psf.upfronthosting.co.za>


New submission from Jason Alvarado:

http://docs.python.org/3.1/library/crypto.html

The link to A.M, Kuchling URL is broken

http://www.amk.ca/python/code/crypto.html

----------
assignee: docs at python
components: Documentation
messages: 179758
nosy: Jason.Alvarado, docs at python
priority: normal
severity: normal
status: open
title: Broken link in 14. Cryptographic Service
versions: Python 3.1

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

From report at bugs.python.org  Sat Jan 12 04:10:19 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Jan 2013 03:10:19 +0000
Subject: [docs] [issue16933] argparse: remove magic from examples
In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za>
Message-ID: <1357960218.79.0.779955610312.issue16933@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The new examples are much better and to me the patch looks ready to apply.

----------
nosy: +terry.reedy
stage: patch review -> commit review

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

From report at bugs.python.org  Sat Jan 12 04:31:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Jan 2013 03:31:13 +0000
Subject: [docs] [issue16933] argparse: remove magic from examples
In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za>
Message-ID: <3Yjmgg4qnTzP5k@mail.python.org>


Roundup Robot added the comment:

New changeset b2bb3219d36d by Chris Jerdonek in branch '2.7':
Issue #16933: Improve choices examples in argparse documentation.
http://hg.python.org/cpython/rev/b2bb3219d36d

New changeset eaa2a6074741 by Chris Jerdonek in branch '3.2':
Issue #16933 (2.7 forward-port): Improve choices examples in argparse docs.
http://hg.python.org/cpython/rev/eaa2a6074741

New changeset de9eb3031f5a by Chris Jerdonek in branch '3.3':
Issue #16933 (merge from 3.2): Improve choices examples in argparse docs.
http://hg.python.org/cpython/rev/de9eb3031f5a

New changeset bddbaaf332d7 by Chris Jerdonek in branch 'default':
Issue #16933 (merge from 3.3): Improve choices examples in argparse docs.
http://hg.python.org/cpython/rev/bddbaaf332d7

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

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

From report at bugs.python.org  Sat Jan 12 04:33:15 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 12 Jan 2013 03:33:15 +0000
Subject: [docs] [issue16933] argparse: remove magic from examples
In-Reply-To: <1357911858.69.0.0703193383433.issue16933@psf.upfronthosting.co.za>
Message-ID: <1357961595.44.0.549851053842.issue16933@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks for reporting the suggestion, Thomas.  And thanks for looking over the patch, Terry.

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

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

From report at bugs.python.org  Sat Jan 12 04:36:48 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 12 Jan 2013 03:36:48 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1357961808.29.0.309219063445.issue11176@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Issue 16933 improved the "choices" examples.

----------

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

From report at bugs.python.org  Sat Jan 12 05:00:57 2013
From: report at bugs.python.org (paul j3)
Date: Sat, 12 Jan 2013 04:00:57 +0000
Subject: [docs] [issue16940] argparse 15.4.5.1. Sub-commands documentation
	missing	indentation
Message-ID: <1357963257.08.0.262737985676.issue16940@psf.upfronthosting.co.za>


New submission from paul j3:

Argparse
15.4.5.1. Sub-commands

In the example:

>>> parser.parse_args(['--help'])
usage: PROG [-h] [--foo] {a,b} ...

positional arguments:
  {a,b}   sub-command help
a     a help
b     b help

optional arguments:
  -h, --help  show this help message and exit
  --foo   foo help

The 'a help', 'b help' lines should be indented

----------
assignee: docs at python
components: Documentation
messages: 179766
nosy: docs at python, paul.j3
priority: normal
severity: normal
status: open
title: argparse 15.4.5.1. Sub-commands documentation missing indentation
versions: Python 2.7

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

From report at bugs.python.org  Sat Jan 12 09:41:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Jan 2013 08:41:04 +0000
Subject: [docs] [issue16940] argparse 15.4.5.1. Sub-commands documentation
	missing	indentation
In-Reply-To: <1357963257.08.0.262737985676.issue16940@psf.upfronthosting.co.za>
Message-ID: <3YjvY91bb4zSDB@mail.python.org>


Roundup Robot added the comment:

New changeset eae31f2b6f60 by Ezio Melotti in branch '2.7':
#16940: fix indentation in example.
http://hg.python.org/cpython/rev/eae31f2b6f60

New changeset 3d54723c9be6 by Ezio Melotti in branch '3.2':
#16940: fix indentation in example.
http://hg.python.org/cpython/rev/3d54723c9be6

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

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

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

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

From report at bugs.python.org  Sat Jan 12 09:41:47 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Jan 2013 08:41:47 +0000
Subject: [docs] [issue16940] argparse 15.4.5.1. Sub-commands documentation
	missing	indentation
In-Reply-To: <1357963257.08.0.262737985676.issue16940@psf.upfronthosting.co.za>
Message-ID: <1357980107.48.0.105614478256.issue16940@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

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

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

From sealy at live.co.uk  Fri Jan 11 21:41:12 2013
From: sealy at live.co.uk (Charlie Seale)
Date: Fri, 11 Jan 2013 20:41:12 +0000
Subject: [docs] Exported script - 01/11 20:40
Message-ID: <BLU0-SMTP2163B30E5AD557F56D0CD919C290@phx.gbl>

Can you have a look at this script please and tell me what I have done wrong?

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Converter
URL: <http://mail.python.org/pipermail/docs/attachments/20130111/7a8df0ab/attachment.ksh>

From sandro.tosi at gmail.com  Sat Jan 12 10:26:46 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 12 Jan 2013 10:26:46 +0100
Subject: [docs] Exported script - 01/11 20:40
In-Reply-To: <BLU0-SMTP2163B30E5AD557F56D0CD919C290@phx.gbl>
References: <BLU0-SMTP2163B30E5AD557F56D0CD919C290@phx.gbl>
Message-ID: <CAB4XWXyMpJUcM5T7UyT7TidLMJC=kS-sJHXm=k-WXDZ3eQC3Eg@mail.gmail.com>

Hello Charlie,

On Fri, Jan 11, 2013 at 9:41 PM, Charlie Seale <sealy at live.co.uk> wrote:
> Can you have a look at this script please and tell me what I have done wrong?

this mailing list is about bugs/enhancements to CPython documentation,
and your email doesn't fit this description. I'd suggest to contact a
user support forum, such as
http://mail.python.org/mailman/listinfo/python-list

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

From sandro.tosi at gmail.com  Sat Jan 12 10:27:29 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 12 Jan 2013 10:27:29 +0100
Subject: [docs] MOBI version of Python Docs
In-Reply-To: <50F04086.4040504@python.org>
References: <D46D28DE7F71C346B708DCED59FDE64F0667EE82@uscolms01.arkadin.lan>
	<CAB4XWXzZDaWrgqzedynKttjZWp_yKEQDanQsUZUxKmgR8Orkmw@mail.gmail.com>
	<50F04086.4040504@python.org>
Message-ID: <CAB4XWXw_QLsiD8kzVLRijD=zDNb_5eRyU0+i-p_44S3JMiVMjg@mail.gmail.com>

Hi Georg,

On Fri, Jan 11, 2013 at 5:40 PM, Georg Brandl <georg at python.org> wrote:
> the archive is not readily available to people posting to this list; it is
> not intended that everyone who sends a one-off bug report or suggestion has
> to subscribe, and in any case docs.python.org does not talk about a mailing
> list.

Ok, I see. Thanks for your email.

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

From report at bugs.python.org  Sat Jan 12 14:52:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Jan 2013 13:52:23 +0000
Subject: [docs] [issue16942] urllib still doesn't support persistent
	connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1357998743.34.0.187601147211.issue16942@psf.upfronthosting.co.za>


R. David Murray added the comment:

Please open a separate issue for your enhancement request in your second message (assuming there isn't already one open).  I'm not sure what your third message is about, but it also sounds off topic for your original bug report.

For the FileCookieJar issue, I agree that the documentation is unclear.  However, it is perfectly reasonable to have a documented base class that is an Abstract Base Class, and there is no reason for us to invent our own unique cookie file format just to make FileCookieJar work by itself.  ABCs didn't exist when FileCookieJar was implemented, so it should be turned in to one for 3.4 (it might break working code, so we shouldn't do that for bug fix releases).  That way you would get a useful error when you try to instantiate it, rather than when you try to use it.  And the docs should document it as being a base-class-only for all active releases.

----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +docs at python, r.david.murray
stage:  -> needs patch
type: enhancement -> behavior
versions: +Python 3.4 -Python 3.1

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

From report at bugs.python.org  Sun Jan 13 05:06:18 2013
From: report at bugs.python.org (Todd Rovito)
Date: Sun, 13 Jan 2013 04:06:18 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1358049977.8.0.630367394594.issue16893@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Andrew,
    Zachary and I worked on another issue together to sync idle.rst with help.txt here:
http://bugs.python.org/issue5066

Issue 5066 is ready for commit if you have time by the way.  Thanks!

----------

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

From report at bugs.python.org  Sun Jan 13 10:56:42 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 13 Jan 2013 09:56:42 +0000
Subject: [docs] [issue16949] removal of string exceptions is already done
Message-ID: <1358071002.08.0.359993938626.issue16949@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

This part of the PEP is written as if string exceptions are currently being removed, which is not the case.

Also, it is probably more accurate to say "they are forbidden *and* are removed", instead of "they are forbidden *because* they are are removed.

----------
assignee: docs at python
components: Documentation
files: string-exceptions.diff
keywords: patch
messages: 179854
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: removal of string exceptions is already done
Added file: http://bugs.python.org/file28712/string-exceptions.diff

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

From report at bugs.python.org  Sun Jan 13 11:07:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 13 Jan 2013 10:07:42 +0000
Subject: [docs] [issue16949] removal of string exceptions is already done
In-Reply-To: <1358071002.08.0.359993938626.issue16949@psf.upfronthosting.co.za>
Message-ID: <1358071662.16.0.369257316221.issue16949@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan 13 11:20:38 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 13 Jan 2013 10:20:38 +0000
Subject: [docs] [issue16950] the old raise syntax is not legal in Python 3
Message-ID: <1358072438.43.0.0984946065161.issue16950@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

There is an outdated statement that "the old form of raising exceptions *will* be removed in Python 3". It's ambiguous in that you don't know if such was ever in Python 3, and it is also time-sensitive (and now outdated).

----------
assignee: docs at python
components: Documentation
messages: 179857
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: the old raise syntax is not legal in Python 3

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

From report at bugs.python.org  Sun Jan 13 11:20:58 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 13 Jan 2013 10:20:58 +0000
Subject: [docs] [issue16950] the old raise syntax is not legal in Python 3
In-Reply-To: <1358072438.43.0.0984946065161.issue16950@psf.upfronthosting.co.za>
Message-ID: <1358072458.04.0.689975270329.issue16950@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file28713/raise-exception.diff

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

From report at bugs.python.org  Sun Jan 13 11:26:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Jan 2013 10:26:31 +0000
Subject: [docs] [issue16949] removal of string exceptions is already done
In-Reply-To: <1358071002.08.0.359993938626.issue16949@psf.upfronthosting.co.za>
Message-ID: <3YkYrQ1YzMzR3j@mail.python.org>


Roundup Robot added the comment:

New changeset bf68a42a43bf by Georg Brandl in branch 'default':
Closes #16949: update wording about string exceptions.
http://hg.python.org/peps/rev/bf68a42a43bf

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

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

From report at bugs.python.org  Sun Jan 13 11:27:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Jan 2013 10:27:09 +0000
Subject: [docs] [issue16950] the old raise syntax is not legal in Python 3
In-Reply-To: <1358072438.43.0.0984946065161.issue16950@psf.upfronthosting.co.za>
Message-ID: <3YkYs86mCnzRws@mail.python.org>


Roundup Robot added the comment:

New changeset 89db18c77152 by Georg Brandl in branch 'default':
Closes #16950: update wording about raise syntax.
http://hg.python.org/peps/rev/89db18c77152

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

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

From report at bugs.python.org  Sun Jan 13 11:43:21 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 13 Jan 2013 10:43:21 +0000
Subject: [docs] [issue16951] expand on meaning of 'string literals that rely
	on	significant trailing whitespace'
Message-ID: <1358073801.18.0.127692907122.issue16951@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

In PEP 8, there is:

> Don't write string literals that rely on significant trailing whitespace

It's not clear to me what this means, and therefore likely needs further explanation, or maybe an example.

----------
assignee: docs at python
components: Documentation
messages: 179861
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: expand on meaning of 'string literals that rely on significant trailing whitespace'

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

From report at bugs.python.org  Sun Jan 13 11:47:36 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 13 Jan 2013 10:47:36 +0000
Subject: [docs] [issue16951] expand on meaning of 'string literals that rely
	on	significant trailing whitespace'
In-Reply-To: <1358073801.18.0.127692907122.issue16951@psf.upfronthosting.co.za>
Message-ID: <1358074056.38.0.844333692594.issue16951@psf.upfronthosting.co.za>


Georg Brandl added the comment:

It means not write 

a = "abc    "

as

a = """abc    
"""

with the four spaces trailing at the end of the line.  I don't think there is a more concise way of putting it in the PEP.

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

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

From report at bugs.python.org  Sun Jan 13 15:21:34 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 13 Jan 2013 14:21:34 +0000
Subject: [docs] [issue16951] expand on meaning of 'string literals that rely
	on	significant trailing whitespace'
In-Reply-To: <1358074056.38.0.844333692594.issue16951@psf.upfronthosting.co.za>
Message-ID: <CAA77j2ChzktxnOtYvKq06uS_UhR6WOS_N6cyn66kErLgQ7e=hw@mail.gmail.com>


Tshepang Lekhonkhobe added the comment:

> I don't think there is a more concise way of putting it in the PEP.

Is it not more important to be clear than to be concise? Can't you put
this info that PEP, or at least a link to this issue?

----------

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

From report at bugs.python.org  Sun Jan 13 15:38:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Jan 2013 14:38:20 +0000
Subject: [docs] [issue16951] expand on meaning of 'string literals that rely
	on	significant trailing whitespace'
In-Reply-To: <1358073801.18.0.127692907122.issue16951@psf.upfronthosting.co.za>
Message-ID: <1358087900.71.0.765776201944.issue16951@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think the sentence is already clear enough --- editors often remove trailing spaces, so if they are significant (e.g. if they are in a string literal) they are at risk.  This is actually more a general advice than a styling guideline, so I'm not even sure it belongs to the PEP 8.

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

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

From report at bugs.python.org  Sun Jan 13 16:26:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Jan 2013 15:26:53 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
Message-ID: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Perhaps almost all Doxygen comments in ElementTree module should be converted to docstrings.

----------
assignee: docs at python
components: Documentation, XML
messages: 179881
nosy: docs at python, eli.bendersky, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add docstrings for ElementTree module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan 13 17:10:59 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 13 Jan 2013 16:10:59 +0000
Subject: [docs] [issue16580] Add examples to int.to_bytes and int.from_bytes
In-Reply-To: <1354217109.61.0.534443148437.issue16580@psf.upfronthosting.co.za>
Message-ID: <1358093459.88.0.575973913512.issue16580@psf.upfronthosting.co.za>


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


----------
title: Add examples to int.to_bytres and int.from_bytes -> Add examples to int.to_bytes and int.from_bytes

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

From report at bugs.python.org  Sun Jan 13 18:17:03 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 13 Jan 2013 17:17:03 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1358097423.73.0.827340278787.issue16954@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Definitely. And this is one of those issues where I can wholeheartedly say that patches are welcome :-)

Even incremental patching will be OK (i.e. patches documenting single methods or groups of methods).

Incidentally, while replacing the comment by docstring for issue #14377, I noticed an argument (default_namespace) that wasn't documented anywhere, including the ReST docs. So such a transition can have more benefits than seems on the surface.

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

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

From report at bugs.python.org  Mon Jan 14 01:13:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jan 2013 00:13:57 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1358122436.97.0.767148288235.issue8145@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here is a revised patch.  I am leaving out the changes relating to the transaction manager.  It turns out that the transaction manager doesn't do anything useful even if isolation_level is not None.  I'm going to open a new issue to discuss the best way to fix it, and any documentation changes relating to any leftover brokenness will be part of that issue.

----------
Added file: http://bugs.python.org/file28719/sqlite_transaction_doc.patch

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

From report at bugs.python.org  Mon Jan 14 01:18:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jan 2013 00:18:51 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1358122731.54.0.356700653301.issue8145@psf.upfronthosting.co.za>


R. David Murray added the comment:

I misspoke, the transaction manager does do something useful in non-None isolation level.  I'm still going to open a bug about isolation_level None.

----------

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

From report at bugs.python.org  Mon Jan 14 01:47:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Jan 2013 00:47:22 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1358124442.55.0.794342511516.issue8145@psf.upfronthosting.co.za>


R. David Murray added the comment:

Opened issue 16958 for the transaction manager problem.

----------

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

From report at bugs.python.org  Mon Jan 14 03:17:44 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 14 Jan 2013 02:17:44 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1358129864.68.0.874044097117.issue16954@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan 14 12:09:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Jan 2013 11:09:56 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1358161796.88.0.497945995964.issue16954@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka

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

From report at bugs.python.org  Mon Jan 14 17:52:38 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 14 Jan 2013 16:52:38 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1358182358.88.0.391068480036.issue16893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Georg:
> Note that Sphinx' "make text" output already should be suitable. We 
> already update the pydoc topics with that on every release, so we could 
> just as well do the same for the IDLE doc.  No need for another 
> separate script.

I take it this would mean generating help.txt and then checking it in?  Otherwise, users who built their own Python would likely run into issues with IDLE not finding its help file, or would be required to have sphinx available.  That's not quite what I had in mind, but if we already do it for pydoc topics, it sounds fine to me.

----------

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

From report at bugs.python.org  Mon Jan 14 18:27:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Jan 2013 17:27:48 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <3YlM832zflzR26@mail.python.org>


Roundup Robot added the comment:

New changeset d1ef91025d70 by Andrew Svetlov in branch 'default':
Issue #5066: Update IDLE docs
http://hg.python.org/cpython/rev/d1ef91025d70

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

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

From report at bugs.python.org  Mon Jan 14 18:28:17 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 14 Jan 2013 17:28:17 +0000
Subject: [docs] [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1358184496.97.0.594759371407.issue5066@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Pushed. Thanks.

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

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

From report at bugs.python.org  Mon Jan 14 18:31:04 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 14 Jan 2013 17:31:04 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1358184664.66.0.922614747849.issue16893@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Regenerating idle.txt and committing it is fine to me.

----------

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

From report at bugs.python.org  Mon Jan 14 19:00:36 2013
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Jan 2013 18:00:36 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1358186436.86.0.128557328409.issue16893@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> I take it this would mean generating help.txt and then checking it in? Otherwise, users who built their own Python would likely run into issues with IDLE not finding its help file, or would be required to have sphinx available.

Yes, it will be checked in.

> That's not quite what I had in mind, but if we already do it for pydoc topics, it sounds fine to me.

I don't think we have to worry about it getting out of date quickly.  Automatically generating the IDLE help at run time from a documentation source file is not posssible anyway, since the doc sources are not available in a standard location for installed Pythons.

----------

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

From report at bugs.python.org  Mon Jan 14 19:06:20 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 14 Jan 2013 18:06:20 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1358186779.44.0.553755410795.issue16893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

> I don't think we have to worry about it getting out of date quickly.  

Fair point :)

> Automatically generating the IDLE help at run time from a documentation 
> source file is not posssible anyway, since the doc sources are not 
> available in a standard location for installed Pythons.

This isn't quite what I meant either; I had intended it to be done at either Python build or install time.  Your method is much simpler, though, I like it.

That said, here's the diff between the (now) current Lib/idlelib/help.txt and the Sphinx ``make text`` output of Doc/library/idle.rst.  I've not found where we've automated the pydoc topics generation, else I'd try to provide a patch to do this as well.

----------
keywords: +patch
Added file: http://bugs.python.org/file28725/issue16893.diff

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

From report at bugs.python.org  Mon Jan 14 19:15:22 2013
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Jan 2013 18:15:22 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1358187322.73.0.672584899071.issue16893@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The unified diff is not very helpful; I think somebody has to put the files side by side and merge.

The pydoc topics are built with a custom Sphinx builder implemented in tools/sphinxext/pyspecific.py -- but if we just want the vanilla text builder output it should be enough to add a Doc/Makefile target:

idledoc: BUILDER = text
idledoc: SOURCES = library/idle
idledoc: build
	@echo "Build finished; now copying build/text/library/idle.txt to ../Lib/idlelib/help.txt."
	@cp build/text/library/idle.txt ../Lib/idlelib/help.txt

and I add a step to PEP 101 to run this.

----------

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

From report at bugs.python.org  Mon Jan 14 19:16:07 2013
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Jan 2013 18:16:07 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1358187367.76.0.505940606462.issue16893@psf.upfronthosting.co.za>


Georg Brandl added the comment:

To make it actually work, replace "library/idle" by "library/idle.rst".

----------

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

From report at bugs.python.org  Mon Jan 14 23:00:55 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 14 Jan 2013 22:00:55 +0000
Subject: [docs] [issue16823] Python crashes on running tkinter code with
	threads
In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za>
Message-ID: <1358200855.14.0.65259196369.issue16823@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/issue16823>
_______________________________________

From report at bugs.python.org  Mon Jan 14 23:04:51 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 14 Jan 2013 22:04:51 +0000
Subject: [docs] [issue16901] In http.cookiejar.FileCookieJar() the .load()
	and	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1358201091.57.0.257927995246.issue16901@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/issue16901>
_______________________________________

From report at bugs.python.org  Tue Jan 15 04:12:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Jan 2013 03:12:20 +0000
Subject: [docs] [issue16823] Python quits on running tkinter code with
	threads
In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za>
Message-ID: <1358219540.1.0.482212716044.issue16823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

We use 'crash' to mean a segfault (and core dump, on *nix) or the Windows equivalent. We avoid those if at all possible. A Python traceback is not a crash but a semi-graceful shutdown that has be planned for, given the circumstances. What is annoying here is getting a different exception (or at least message type) each time. I presume it depends on what data gets corrupted, and that is somewhat haphazard. The quote seems to be accurate.

I know little about threading, but if it were possible to detect tkinter access from other than the main thread (without excessive slowdown), then a consistent exception might be raised. But I am doubtful that this can be done sensibly. Hence a doc change seems like the best first step.

----------
title: Python crashes on running tkinter code with threads -> Python quits on running tkinter code with threads

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

From report at bugs.python.org  Tue Jan 15 05:34:57 2013
From: report at bugs.python.org (David Lam)
Date: Tue, 15 Jan 2013 04:34:57 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1358224497.74.0.767372305329.issue16954@psf.upfronthosting.co.za>


Changes by David Lam <d at dlam.me>:


----------
nosy: +dlam

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

From report at bugs.python.org  Tue Jan 15 11:21:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2013 10:21:29 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1358245289.03.0.87712595332.issue16954@psf.upfronthosting.co.za>


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


----------
assignee: serhiy.storchaka -> docs at python

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

From report at bugs.python.org  Tue Jan 15 19:27:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2013 18:27:39 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1358274459.41.0.692042874515.issue15436@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 15 19:27:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2013 18:27:47 +0000
Subject: [docs] [issue16643] Wrong documented default value for timefunc
	parameter in	sched.scheduler()
In-Reply-To: <1354964381.71.0.639628706124.issue16643@psf.upfronthosting.co.za>
Message-ID: <1358274467.76.0.458814609692.issue16643@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 15 19:28:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2013 18:28:12 +0000
Subject: [docs] [issue16700] Document that bytes OS API can returns unusable
	results	on Windows
In-Reply-To: <1355677117.39.0.191453655217.issue16700@psf.upfronthosting.co.za>
Message-ID: <1358274492.96.0.766691248322.issue16700@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 15 19:30:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2013 18:30:16 +0000
Subject: [docs] [issue15984] Wrong documentation for PyUnicode_FromObject()
In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za>
Message-ID: <1358274616.04.0.550448248207.issue15984@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 15 20:22:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2013 19:22:58 +0000
Subject: [docs] [issue7340] Doc for sys.exc_info has warning that is no
	longer valid
In-Reply-To: <1258481567.01.0.124523901293.issue7340@psf.upfronthosting.co.za>
Message-ID: <1358277778.94.0.765999269828.issue7340@psf.upfronthosting.co.za>


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


----------
keywords: +easy
versions: +Python 3.3, Python 3.4 -Python 3.1

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

From report at bugs.python.org  Tue Jan 15 20:21:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2013 19:21:00 +0000
Subject: [docs] [issue7468] PyErr_Format documentation doesn't mention all
	format	codes
In-Reply-To: <1260444170.83.0.494210811062.issue7468@psf.upfronthosting.co.za>
Message-ID: <1358277660.28.0.16232506873.issue7468@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed in r86838.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan 15 21:12:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2013 20:12:43 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1358280763.45.0.991980984337.issue11367@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Already fixed in 3.3+.

----------
keywords: +easy
nosy: +eli.bendersky, serhiy.storchaka
stage:  -> needs patch
type:  -> enhancement
versions: +Python 2.7, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Tue Jan 15 22:49:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 15 Jan 2013 21:49:42 +0000
Subject: [docs] [issue7340] Doc for sys.exc_info has warning that is no
	longer valid
In-Reply-To: <1258481567.01.0.124523901293.issue7340@psf.upfronthosting.co.za>
Message-ID: <3Ym4vn3YDxzRGV@mail.python.org>


Roundup Robot added the comment:

New changeset 3fa3e7975724 by Benjamin Peterson in branch '3.3':
remove warning about tb circular reference (closes #7340)
http://hg.python.org/cpython/rev/3fa3e7975724

New changeset d866bbdd68e8 by Benjamin Peterson in branch 'default':
merge 3.3 (#7340)
http://hg.python.org/cpython/rev/d866bbdd68e8

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

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

From report at bugs.python.org  Wed Jan 16 07:39:36 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 16 Jan 2013 06:39:36 +0000
Subject: [docs] [issue16978] fix grammar in 'threading' documentation
Message-ID: <1358318376.05.0.299917278497.issue16978@psf.upfronthosting.co.za>


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


----------
assignee: docs at python
components: Documentation
files: grammar.diff
keywords: patch
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: fix grammar in 'threading' documentation
versions: Python 2.7
Added file: http://bugs.python.org/file28748/grammar.diff

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

From report at bugs.python.org  Wed Jan 16 08:58:27 2013
From: report at bugs.python.org (wim glenn)
Date: Wed, 16 Jan 2013 07:58:27 +0000
Subject: [docs] [issue16697] argparse kwarg 'choices' documentation
In-Reply-To: <1355666035.13.0.877787561314.issue16697@psf.upfronthosting.co.za>
Message-ID: <1358323107.96.0.939318441697.issue16697@psf.upfronthosting.co.za>


Changes by wim glenn <wim.glenn at gmail.com>:


----------
nosy:  -wim.glenn

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

From report at bugs.python.org  Wed Jan 16 19:35:48 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 16 Jan 2013 18:35:48 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1358361348.46.0.663117988468.issue16893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Sorry, I wasn't as clear as I meant to be in my last message, I was suddenly rushed and didn't realize I'd left out what I meant to say, which was:

Now that Andrew has committed Todd's fix to issue 5066, idle.rst and help.txt are very well-aligned.  I believe the transition could be made now with no negative impact on the quality or usefulness of help.txt.

Here now is a patch to Doc/Makefile and Doc/make.bat to add an 'idledoc' target.  I haven't been able to test the Makefile change yet, but as it's a direct quote of your suggestion (with correction), Georg, I figure it ought to work :).  I have tested the make.bat change, though, and it works well for me.

----------
Added file: http://bugs.python.org/file28754/issue16893_makefiles.diff

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

From report at bugs.python.org  Wed Jan 16 20:30:22 2013
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 16 Jan 2013 19:30:22 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1358364622.11.0.577466581128.issue16893@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I did test the Makefile change, so this should be good to go.  I'll upate PEP 101 once it's in.

----------

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

From report at bugs.python.org  Wed Jan 16 22:07:20 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 16 Jan 2013 21:07:20 +0000
Subject: [docs] [issue16978] fix grammar in 'threading' documentation
Message-ID: <1358370440.72.0.85153283969.issue16978@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

Also, sentence starting with "Due to the" does not flow so nice for me... maybe a comma is needed after "CPython"?

----------
type:  -> enhancement

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

From report at bugs.python.org  Wed Jan 16 22:43:44 2013
From: report at bugs.python.org (Craig McQueen)
Date: Wed, 16 Jan 2013 21:43:44 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1358372624.63.0.994213163229.issue12758@psf.upfronthosting.co.za>


Craig McQueen added the comment:

Alexander Belopolsky wrote:
> No.  Seconds since the epoch is neither local nor UTC.  It is just
> an elapsed number of seconds since an agreed upon time called the
> "epoch".

This statement just seems wrong. And I have just been confused by the current documentation, hence finding this issue. In what timezone is the "epoch"? It makes a difference. It seems with the current behaviour, the "epoch" is _in the local timezone_. So I reckon the documentation is unclear, because the way I read it, I interpretted it to mean UTC. I think it does need to state "in local time".

However, what I'd really prefer is a new function that returns the seconds since the epoch in UTC.

----------
nosy: +cmcqueen1975

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

From report at bugs.python.org  Wed Jan 16 22:53:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Jan 2013 21:53:00 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1358373180.02.0.525948062265.issue12758@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> It makes a difference. It seems with the current behaviour, the
> "epoch" is _in the local timezone_.

No it isn't. Two different machines:

$ LANG=C date
Wed Jan 16 21:47:03 UTC 2013
$ python -c "import time; print(time.time())"
1358372827.5

$ LANG=C date
Wed Jan 16 22:47:21 CET 2013
$ python -c "import time; print(time.time())"
1358372848.2

time.time() *is* timezone-independent.

Now to your question:

> However, what I'd really prefer is a new function that returns the
> seconds since the epoch in UTC.

>>> epoch = datetime(1970, 1, 1)
>>> (datetime.utcnow() - epoch).total_seconds()
1358372978.448235
>>> time.time()
1358372980.176238

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

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

From report at bugs.python.org  Wed Jan 16 23:09:15 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Jan 2013 22:09:15 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1358374155.91.0.72311489008.issue12758@psf.upfronthosting.co.za>


R. David Murray added the comment:

On linux/posix, the epoch is *defined* to be 1970, 1, 1 in UTC.  Python just uses whatever the OS defines the epoch to be, as far as I know.

----------

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

From report at bugs.python.org  Thu Jan 17 01:38:27 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Jan 2013 00:38:27 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1358383107.32.0.230739325412.issue15436@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/issue15436>
_______________________________________

From report at bugs.python.org  Thu Jan 17 12:09:42 2013
From: report at bugs.python.org (Jerome Dubois)
Date: Thu, 17 Jan 2013 11:09:42 +0000
Subject: [docs] [issue16633] os.environ updates only one copy of env vars
	under	Windows (GetEnvironmentVariable vs. getenv)
In-Reply-To: <1354881703.99.0.276690917603.issue16633@psf.upfronthosting.co.za>
Message-ID: <1358420982.06.0.279434226511.issue16633@psf.upfronthosting.co.za>


Jerome Dubois added the comment:

We encountered the same issue when upgrading our application's JRE from 1.5 to 1.6.
We use a kind of grid, which has engines written in C, which uses an embedded JAVA JVM, which loads C dll. One of these uses python.

Here is what happens:
1. C executable launches an embedded JVM, which loads its required dlls.
2. JVM sets PYTHONHOME environment variable through windows kernel API: SetEnvironmentVariable
3. JVM loads our C dlls to start computations
3. One of the dlls invokes Py_InitializeEx, which must read PYTHONHOME in some way (C runtime getenv?). Python 2.5 here, with MSVCR71.dll loaded.
4. Computations are done with invoked python

With JRE 1.5, Python is able to get correct PYTHONHOME, and can do "import os" in our script.

With JRE 1.6, this is not the case, as JRE 1.6 loads MSVCR71.dll @ step 1. JRE 1.5 did not.

As stated in the previous comments, and from my understanding, in Windows there is the "Process Environment Variables Space" and possibly several "C Runtime Environment Variables Space".
The first time a C runtime dll is loaded, it copies the Process Env Var into its own buffer.

Our JRE 1.6 loads msvcr71.dll (C runtime), and so copies env var @ step 1.
It happens before we set PYTHONHOME with JAVA @ step 2.

To correct this, we had to use the Py_SetPythonHome function before calling Py_PyInit to set PYTHONHOME ourselves
This way, Python executes our code fine when we use JRE 1.6.

But this is because we do not call any getenv functionality within python at the moment, but it could happen in the future...

As stated by eudoxos, the safest solution for windows is to use GetEnvironmentVariable (win32 kernel API).

Is there any schedule for a fix for this problem?

Thanks for you time and answer.

Regards.

----------
nosy: +goungy

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

From report at bugs.python.org  Thu Jan 17 16:10:39 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 17 Jan 2013 15:10:39 +0000
Subject: [docs] [issue16985] Docs reference a concrete UTC tzinfo,
	but none exists
Message-ID: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

The Python 2.7 docs for datetime state, "The standard library has no tzinfo instances except for UTC," but if I read issue5094 correctly, Python 2.7 does not even have a UTC tzinfo instance, and never will. Is there any reason I shouldn't correct the docs to remove 'except for UTC'?

----------
assignee: docs at python
components: Documentation
messages: 180138
nosy: docs at python, jason.coombs
priority: normal
severity: normal
status: open
title: Docs reference a concrete UTC tzinfo, but none exists
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 17 17:45:32 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 17 Jan 2013 16:45:32 +0000
Subject: [docs] [issue7353] cporting docs recommend using
	Include/intobject.h, which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1358441132.77.0.939212553366.issue7353@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Bump... is this still valid?

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

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

From report at bugs.python.org  Thu Jan 17 21:22:59 2013
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Jan 2013 20:22:59 +0000
Subject: [docs] [issue7353] cporting docs recommend using
	Include/intobject.h, which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1358454179.56.0.00883104304568.issue7353@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I tend to agree with the argument that the removal of intobject.h was
a good thing, since it avoids subtle errors.

Probably no one wants to reinstate intobject.h at this point, so unless
there are objections, I'll update the docs in a couple of days.

----------
keywords: +patch
nosy: +skrah
Added file: http://bugs.python.org/file28758/issue7353.diff

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

From report at bugs.python.org  Thu Jan 17 22:30:15 2013
From: report at bugs.python.org (Robert Leenders)
Date: Thu, 17 Jan 2013 21:30:15 +0000
Subject: [docs] [issue16988] argparse: PARSER option for nargs not documented
Message-ID: <1358458215.07.0.403888123098.issue16988@psf.upfronthosting.co.za>


New submission from Robert Leenders:

There is a value for nargs: PARSER="A..." which is not documented at http://docs.python.org/3.4/library/argparse.html#nargs. The docstring for the action class in argparse.py also does not list PARSER as a valid value for nargs.

In argparse.py on line 2199-2201 it says:
# Allow one argument followed by any number of options or arguments
elif nargs == PARSER:
    nargs_pattern = '(-*A[-AO]*)'

This is the only hint that I could find on what it is about.

----------
assignee: docs at python
components: Documentation
messages: 180155
nosy: ReDAeR, bethard, docs at python
priority: normal
severity: normal
status: open
title: argparse: PARSER option for nargs not documented
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan 17 22:38:10 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 17 Jan 2013 21:38:10 +0000
Subject: [docs] [issue16988] argparse: PARSER option for nargs not documented
In-Reply-To: <1358458215.07.0.403888123098.issue16988@psf.upfronthosting.co.za>
Message-ID: <1358458690.51.0.516120045395.issue16988@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/issue16988>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:35:29 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 18 Jan 2013 10:35:29 +0000
Subject: [docs] [issue16939] Broken link in 14. Cryptographic Service
In-Reply-To: <1357959551.72.0.678573558111.issue16939@psf.upfronthosting.co.za>
Message-ID: <1358505329.07.0.772391660285.issue16939@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

This was fixed a year and a half ago by issue 12351.  For example, see:

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

----------
nosy: +chris.jerdonek
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Update URL for pycrypto project

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

From report at bugs.python.org  Fri Jan 18 16:11:01 2013
From: report at bugs.python.org (Jeff Knupp)
Date: Fri, 18 Jan 2013 15:11:01 +0000
Subject: [docs] [issue16988] argparse: PARSER option for nargs not documented
In-Reply-To: <1358458215.07.0.403888123098.issue16988@psf.upfronthosting.co.za>
Message-ID: <1358521861.86.0.384728687708.issue16988@psf.upfronthosting.co.za>


Jeff Knupp added the comment:

This is not a bug.

The 'PARSER' nargs choice is an implementation detail as a way to handle subparsers. The parser needs to know that the first value should be handled, but everything that follows will be handled by the subparser.

By using a subparser, you're effectively using 'PARSER', but it wouldn't make sense to allow 'PARSER' to be set directly as it only makes sense when used in conjunction with a subparser.

----------
nosy: +jeffknupp

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

From report at bugs.python.org  Fri Jan 18 16:13:25 2013
From: report at bugs.python.org (Alexey Kachayev)
Date: Fri, 18 Jan 2013 15:13:25 +0000
Subject: [docs] [issue16774] Additional recipes for itertools docs
In-Reply-To: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za>
Message-ID: <1358522005.82.0.915301100672.issue16774@psf.upfronthosting.co.za>


Alexey Kachayev added the comment:

Updated patch with:
* fix error in islice function name
* made n=None default second argument for consume(iterator, n=None) cause it provides specific behavior when n is None which can be assumed as default for function

----------
Added file: http://bugs.python.org/file28768/itertools.doc.v3.diff

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

From report at bugs.python.org  Fri Jan 18 18:59:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Jan 2013 17:59:34 +0000
Subject: [docs] [issue16978] fix grammar in 'threading' documentation
In-Reply-To: <1358370440.72.0.85153283969.issue16978@psf.upfronthosting.co.za>
Message-ID: <3Ynqfs4BtJzNS8@mail.python.org>


Roundup Robot added the comment:

New changeset 8886d7ca159b by Ezio Melotti in branch '2.7':
#16978: rephrase sentence and fix typo.  Initial patch by Tshepang Lekhonkhobe.
http://hg.python.org/cpython/rev/8886d7ca159b

New changeset 4a1a88d25fec by Ezio Melotti in branch '3.2':
#16978: rephrase sentence and fix typo.  Initial patch by Tshepang Lekhonkhobe.
http://hg.python.org/cpython/rev/4a1a88d25fec

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

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

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

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

From report at bugs.python.org  Fri Jan 18 19:00:17 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Jan 2013 18:00:17 +0000
Subject: [docs] [issue16978] fix grammar in 'threading' documentation
In-Reply-To: <1358370440.72.0.85153283969.issue16978@psf.upfronthosting.co.za>
Message-ID: <1358532017.84.0.495793544161.issue16978@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

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

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

From report at bugs.python.org  Fri Jan 18 19:02:03 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 18 Jan 2013 18:02:03 +0000
Subject: [docs] [issue16985] Docs reference a concrete UTC tzinfo,
	but none exists
In-Reply-To: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za>
Message-ID: <1358532123.03.0.452202263738.issue16985@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky, brett.cannon, rafe

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

From report at bugs.python.org  Fri Jan 18 19:18:11 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 18 Jan 2013 18:18:11 +0000
Subject: [docs] [issue16985] Docs reference a concrete UTC tzinfo,
	but none exists
In-Reply-To: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za>
Message-ID: <1358533091.08.0.808336556323.issue16985@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Nope, no reason. I bet it was a bad merge somewhere in the docs from Python 3 to 2.7 at some point.

----------

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

From report at bugs.python.org  Fri Jan 18 19:56:34 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 18 Jan 2013 18:56:34 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1358535394.44.0.726529274027.issue16954@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 18 20:14:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Jan 2013 19:14:41 +0000
Subject: [docs] [issue16774] Additional recipes for itertools docs
In-Reply-To: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za>
Message-ID: <1358536481.85.0.980039200428.issue16774@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

How are popular the proposed recipes? Not every possible combination of functions is worth to mention in the documentation.

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

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

From report at bugs.python.org  Fri Jan 18 21:35:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Jan 2013 20:35:57 +0000
Subject: [docs] [issue16985] Docs reference a concrete UTC tzinfo,
	but none exists
In-Reply-To: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za>
Message-ID: <3Ynv7J5HPvzPNG@mail.python.org>


Roundup Robot added the comment:

New changeset 582ecb9a4061 by Jason R. Coombs in branch '2.7':
#16985: Remove incorrect phrase indication presence of non-present concrete UTC tzinfo instance.
http://hg.python.org/cpython/rev/582ecb9a4061

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

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

From report at bugs.python.org  Fri Jan 18 21:36:23 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 18 Jan 2013 20:36:23 +0000
Subject: [docs] [issue16985] Docs reference a concrete UTC tzinfo,
	but none exists
In-Reply-To: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za>
Message-ID: <1358541383.29.0.0823269135558.issue16985@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
resolution:  -> fixed

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

From report at bugs.python.org  Fri Jan 18 21:40:39 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 18 Jan 2013 20:40:39 +0000
Subject: [docs] [issue16985] Docs reference a concrete UTC tzinfo,
	but none exists
In-Reply-To: <1358435438.99.0.679592351451.issue16985@psf.upfronthosting.co.za>
Message-ID: <1358541639.77.0.61898440777.issue16985@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan 19 10:31:10 2013
From: report at bugs.python.org (Alexey Kachayev)
Date: Sat, 19 Jan 2013 09:31:10 +0000
Subject: [docs] [issue16774] Additional recipes for itertools docs
In-Reply-To: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za>
Message-ID: <1358587870.25.0.701910334724.issue16774@psf.upfronthosting.co.za>


Alexey Kachayev added the comment:

It's hard to evaluate how popular given recipes, but:
* drop is opposite to take, so it's as popular as take
* the same situation with splitat, splitby - it's one case of partition that's hard to write each time with enumerator (partition is already in documentation)
* takelast, droplast was added cause itertools.islice doesn't support negative indices (which is ok). both functions have not obvious implementation - I'm sure that recipes will be good example for users how to work with iterators even if concrete functions aren't so widely-spreaded

----------

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

From report at bugs.python.org  Sun Jan 20 01:37:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jan 2013 00:37:54 +0000
Subject: [docs] [issue16999] Remove cruft from unittest docs
Message-ID: <1358642170.4.0.233806283226.issue16999@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

There's a lot of obsolete or simply pointless cruft in the unittest docs, including references to the runTest method, or a detailed description of how to manually collect test suites. Following patch simplifies things a lot and makes the doc easier to read.

----------
assignee: docs at python
components: Documentation
files: unittest-doc-fix.patch
keywords: patch
messages: 180274
nosy: docs at python, ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Remove cruft from unittest docs
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28790/unittest-doc-fix.patch

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

From report at bugs.python.org  Sun Jan 20 01:37:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jan 2013 00:37:54 +0000
Subject: [docs] [issue17000] Remove cruft from unittest docs
Message-ID: <1358642170.4.0.68119991166.issue17000@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

There's a lot of obsolete or simply pointless cruft in the unittest docs, including references to the runTest method, or a detailed description of how to manually collect test suites. Following patch simplifies things a lot and makes the doc easier to read.

----------
assignee: docs at python
components: Documentation
files: unittest-doc-fix.patch
keywords: patch
messages: 180273
nosy: docs at python, ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Remove cruft from unittest docs
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28791/unittest-doc-fix.patch

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

From report at bugs.python.org  Sun Jan 20 06:16:44 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 20 Jan 2013 05:16:44 +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: <1358659004.08.0.916553643782.issue16557@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Attached is a patch. Note that this is my first Doc patch; please apologize errors.

----------
keywords: +patch
nosy: +ramchandra.apte
Added file: http://bugs.python.org/file28793/issue16557.patch

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

From report at bugs.python.org  Sun Jan 20 15:35:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 20 Jan 2013 14:35:26 +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: <3Ypz2M6tVTzS9C@mail.python.org>


Roundup Robot added the comment:

New changeset e0de6e6e992e by Ezio Melotti in branch '3.3':
#16557: update functional howto -- "return value" is valid after PEP 380.  Initial patch by Ramchandra Apte.
http://hg.python.org/cpython/rev/e0de6e6e992e

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

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

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

From report at bugs.python.org  Sun Jan 20 15:36:24 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 20 Jan 2013 14:36:24 +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: <1358692584.35.0.0477525685229.issue16557@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

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

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

From report at bugs.python.org  Sun Jan 20 17:13:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Jan 2013 16:13:14 +0000
Subject: [docs] =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0?=
 =?utf-8?q?and_readline=28=29_argument_names?=
Message-ID: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

read()?and readline() optional parameter which limit the amount of read data has different names in different classes. All this classes mimic (less or more) io classes. Keyword parameter name is a part of method specification. Therefore it will be good made all read() arguments names the same and all readline() arguments names the same (and be consistent with documentation and C implementation). At least we should choose most consistent name for new implementations. If existent C implementation of some method doesn't support keyword argument (all _io classes) or argument names in C and Python implementations are different then we are free to change this name without breaking existing code.

For example, read()'s parameter named as:

"n" in _pyio, zipfile, and io documentation;
"size" in gzip, bz2, imaplib, tarfile, codecs, mailbox;
"len"?in ssl;
"wtd" or "totalwtd" in binhex;
"amt" in http/client;
"chars" in codecs;
"buffersize" in os.

readline()'s parameter named as:

"limit" in _pyio, zipfile, and io documentation;
"size" in gzip, bz2, codecs, mailbox, lzma.

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 180298
nosy: benjamin.peterson, christian.heimes, docs at python, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Unification of read()?and readline() argument names
type: enhancement

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

From report at bugs.python.org  Sun Jan 20 17:15:16 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 20 Jan 2013 16:15:16 +0000
Subject: [docs] [issue7353] cporting docs recommend using
	Include/intobject.h, which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1358698516.59.0.144460248297.issue7353@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Go ahead!

The intobject header file used to make porting to Python 3 easier. Nowadays it's no longer required.

----------

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

From report at bugs.python.org  Sun Jan 20 17:22:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Jan 2013 16:22:49 +0000
Subject: [docs] =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0?=
 =?utf-8?q?and_readline=28=29_argument_names?=
In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>
Message-ID: <1358698969.35.0.34348647691.issue17003@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as size is most common parameter name for both read() and readline(). First, we can change the io documentation and _pyio signatures (it shouldn't break anything because _io doesn't support keyword arguments).

----------

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

From report at bugs.python.org  Sun Jan 20 18:14:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Jan 2013 17:14:49 +0000
Subject: [docs] =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0?=
 =?utf-8?q?and_readline=28=29_argument_names?=
In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>
Message-ID: <1358702089.07.0.69641910413.issue17003@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

"n" is the best choice IMO. "size" is ok too, although it may be confused with the byte-size of the result.

----------

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

From report at bugs.python.org  Sun Jan 20 18:19:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Jan 2013 17:19:48 +0000
Subject: [docs] =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0?=
 =?utf-8?q?and_readline=28=29_argument_names?=
In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>
Message-ID: <1358702387.65.0.392362553531.issue17003@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which changes name of optional parameter of read(), read1(), peek(), and readline() methods to most common name "size" in the documentation and _pyio module. truncate() in _pyio fixed to conform with documentation. This changes are safe.

There is open question about readlines(). It's optional parameter named as:

"hint" in _pyio and the documentation;
"size" in bz2;
"sizehint" in codecs and mailbox.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file28798/io_parameter_names.patch

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

From report at bugs.python.org  Sun Jan 20 18:21:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Jan 2013 17:21:36 +0000
Subject: [docs] =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0?=
 =?utf-8?q?and_readline=28=29_argument_names?=
In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>
Message-ID: <1358702496.08.0.292000609221.issue17003@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> "n" is the best choice IMO.

Unfortunately most stdlib modules vote for "size".

----------

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

From report at bugs.python.org  Sun Jan 20 23:31:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 20 Jan 2013 22:31:07 +0000
Subject: [docs] [issue7353] cporting docs recommend using
	Include/intobject.h, which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <3Yq9bG5SFTzMjc@mail.python.org>


Roundup Robot added the comment:

New changeset 6df456f8fc6d by Stefan Krah in branch '3.3':
Issue #7353: Remove references to Include/intobject.h in the C-porting howto.
http://hg.python.org/cpython/rev/6df456f8fc6d

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

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

From report at bugs.python.org  Sun Jan 20 23:33:00 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 20 Jan 2013 22:33:00 +0000
Subject: [docs] [issue7353] cporting docs recommend using
	Include/intobject.h, which was removed in 3.1?
In-Reply-To: <1258578341.2.0.19051074218.issue7353@psf.upfronthosting.co.za>
Message-ID: <1358721180.18.0.079368321178.issue7353@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


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

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

From report at bugs.python.org  Mon Jan 21 09:48:02 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 21 Jan 2013 08:48:02 +0000
Subject: [docs] [issue17006] Warn users about hashing secrets?
Message-ID: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Lot's of people still think that something like sha512(secret + message), sha1(password + salt) or even sha1(password) is secure. Except it isn't. Most crypto hash functions like md5, sha1, sha2 family (sha256, sha384, sha512) use a Merkle?Damg?rd construction [1]. The construction is vulnerable to several attack vectors like length extension attacks. Passwords needs special care, too.

I propose we add a warning to the documentation of hashlib. It's not the right place to teach cryptographics but it's a good place to raise attention. The warning should explain that you shouldn't solely hash secrets or messages containing a secret. For messages a MAC algorithm like HMAC should be used. For passwords a key stretching and key derivation function like PBKDF2, bcrypt or scrypt is much more secure.

[1] http://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_construction

----------
assignee: docs at python
components: Documentation
messages: 180330
nosy: christian.heimes, docs at python
priority: normal
severity: normal
status: open
title: Warn users about hashing secrets?
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 21 10:06:15 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 21 Jan 2013 09:06:15 +0000
Subject: [docs] [issue17006] Warn users about hashing secrets?
In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>
Message-ID: <1358759175.74.0.894702976601.issue17006@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

I think since we ship cryptographic functions, we should take responsibility and warn against the most common mistakes people do.

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

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

From report at bugs.python.org  Mon Jan 21 10:06:53 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Jan 2013 09:06:53 +0000
Subject: [docs] [issue17006] Warn users about hashing secrets?
In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>
Message-ID: <1358759213.92.0.0440237068948.issue17006@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan 21 12:16:05 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 21 Jan 2013 11:16:05 +0000
Subject: [docs] [issue17006] Warn users about hashing secrets?
In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>
Message-ID: <1358766965.04.0.751026240246.issue17006@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan 21 14:30:58 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 21 Jan 2013 13:30:58 +0000
Subject: [docs] [issue17006] Warn users about hashing secrets?
In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>
Message-ID: <1358775058.51.0.895147119361.issue17006@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

+1
"Better to be safe than sorry"

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

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

From report at bugs.python.org  Mon Jan 21 14:51:49 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 21 Jan 2013 13:51:49 +0000
Subject: [docs] [issue17006] Warn users about hashing secrets?
In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>
Message-ID: <1358776309.18.0.731387138081.issue17006@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/issue17006>
_______________________________________

From report at bugs.python.org  Mon Jan 21 18:31:40 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 21 Jan 2013 17:31:40 +0000
Subject: [docs] [issue17007] logging documentation clarifications
Message-ID: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Here are some suggestions of things to clarify in the logging documentation after consulting it as an end-user:

1. Clarify in Logger.filter(), Handler.filter(), and probably also in the Filter section that the case of more than filter behaves as follows: filters are applied until a filter says the record should not be processed.  In particular, a record gets processed only if all filters say it should be processed rather than at least one.

This is especially worth clarifying because with the above behavior combined with the Filter class's default behavior, it never makes sense to add more than one filter (because you can replace a group of filters with their lowest common ancestor).  It's only needed with custom filters.

2. Clarify that a handler can log the same record multiple times if it is attached to an ancestor logger.  This clarification perhaps best goes in the Logger.propagate section.  Currently, it's not clear whether loggers/handlers are "smart" in the sense that they keep track of whether a given message has already been passed to a given handler (independent of what loggers it is attached to): "Logger.propagate: If this evaluates to true, logging messages are passed by this logger and by its child loggers to the handlers of higher level (ancestor) loggers."

Incidentally, is there any case where you would want the same handler to process the same record more than once?

3. Clarify in the LogRecord section that the "name" attribute refers to the name of the logger used in the end-user's code rather than the name of the logger handling the message.  In particular, a record logged by a logger and an ancestor logger will have the same "name" field for both.

4. Clarify the last part of this sentence: "Note that filters attached to handlers are consulted whenever an event is emitted by the handler, whereas filters attached to loggers are consulted whenever an event is logged to the handler (using debug(), info(), etc.)"

It should say something like, "whereas filters attached to loggers are consulted prior to sending an event to its handlers."  In particular, there can be more than one handler, and it happens before rather than after being logged to the handlers ("whenever" is somewhat ambiguous).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 180344
nosy: chris.jerdonek, docs at python, vinay.sajip
priority: normal
severity: normal
status: open
title: logging documentation clarifications
type: enhancement

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

From report at bugs.python.org  Mon Jan 21 20:46:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Jan 2013 19:46:32 +0000
Subject: [docs] [issue17007] logging documentation clarifications
In-Reply-To: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za>
Message-ID: <3Yqjtw1KhTzP30@mail.python.org>


Roundup Robot added the comment:

New changeset 871519e1f146 by Vinay Sajip in branch '2.7':
Issue #17007: Improved logging documentation based on suggestions in the issue.
http://hg.python.org/cpython/rev/871519e1f146

New changeset 029785354dbc by Vinay Sajip in branch '3.2':
Issue #17007: Improved logging documentation based on suggestions in the issue.
http://hg.python.org/cpython/rev/029785354dbc

New changeset 1902e86dbb88 by Vinay Sajip in branch '3.3':
Issue #17007: Merged doc update from 3.2.
http://hg.python.org/cpython/rev/1902e86dbb88

New changeset 6110ed94f86d by Vinay Sajip in branch 'default':
Closes #17007: Merged doc update from 3.3.
http://hg.python.org/cpython/rev/6110ed94f86d

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

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

From report at bugs.python.org  Mon Jan 21 20:53:35 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 21 Jan 2013 19:53:35 +0000
Subject: [docs] [issue17007] logging documentation clarifications
In-Reply-To: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za>
Message-ID: <1358798015.06.0.25326115035.issue17007@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Your suggestions are good, and I implemented them more or less as you suggested. Additional comments:

> it never makes sense to add more than one filter

Except for readability. Although in theory one filter could do the work of several, it may be that different filters are added independently from configurations based on particular requirements.

> Clarify that a handler can log the same record multiple times

I've mentioned this as *emit* the same record multiple times.

> Incidentally, is there any case where you would want the same handler to process the same record more than once?

I can't think why you'd ever want this - it would just duplicate information in the log output.

> Clarify in the LogRecord section that the "name" attribute refers to the name of the logger used in the end-user's code

I think that part is clear enough by saying that it's the name of the logger used to log the event, but I've added a rider that this is so even when the event is emitted by a handler attached to an ancestor logger.

> Clarify the last part of this sentence: "Note that filters attached to handlers are consulted ..."

Done, this should now be clearer.

----------

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

From report at bugs.python.org  Mon Jan 21 21:22:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jan 2013 20:22:00 +0000
Subject: [docs] [issue17009] "Thread Programming With Python" should be
	removed
In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za>
Message-ID: <1358799720.8.0.796605492753.issue17009@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think these files are outside of the CPython doc tree, they are probably static files on the server. 
That said, I agree it would be good to either add the "deprecated, kept only for historical purposes" note at the top of every file there, or simply remove them.

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

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

From report at bugs.python.org  Mon Jan 21 21:42:55 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 21 Jan 2013 20:42:55 +0000
Subject: [docs] [issue17007] logging documentation clarifications
In-Reply-To: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za>
Message-ID: <1358800975.29.0.070530137407.issue17007@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Great, that looks a lot better.  Thanks!

A couple comments though:

+   .. note:: If you attach a handler to several loggers, it may emit the same
+      record multiple times. In general, you should not need to attach a
+      handler to more than one logger - if you just attach it to the
+      appropriate logger which is highest in the logger hierarchy, then it
+      will see all events logged by all descendant loggers, provided that
+      their propagate setting is left set to ``True``. A common scenario is to
+      attach handlers only to the root logger, and let propagation take care of
+      the rest.

Would it be better to say something like, "If you attach a handler to a logger and one of its ancestors [and similar changes later]..."  The reason I ask is that it seems like there is a valid use case for attaching a handler to more than one logger (which I have used), which is if the loggers aren't in the same ancestry chain.  For example, if I want loggers "app1" and "app2" to log and nothing else, I could attach a StreamHandler to those two loggers and a NullHandler to the root logger.  It seems like the above would discourage that pattern.  Or is that not recommended?  (I suppose you could also do this using a custom filter by name on the root logger, though I don't know which technique is preferred.)

> it never makes sense to add more than one filter

Here I was referring to the restricted case of using default filters by name.  For example, it seems like it would never make sense to filter by "A.B" and "A.C" because that is just an obfuscated way of filtering by the simpler and equivalent "A."  Does that make sense?  (I'm not suggesting any changes to the docs in this comment.)

----------

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

From report at bugs.python.org  Mon Jan 21 22:58:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Jan 2013 21:58:45 +0000
Subject: [docs] [issue17007] logging documentation clarifications
In-Reply-To: <1358789500.77.0.271536300349.issue17007@psf.upfronthosting.co.za>
Message-ID: <3YqmqS2nTszPRY@mail.python.org>


Roundup Robot added the comment:

New changeset 8de6f92c89e6 by Vinay Sajip in branch '2.7':
Issue #17007: Made minor changes to documentation wording.
http://hg.python.org/cpython/rev/8de6f92c89e6

New changeset c8614ec54a63 by Vinay Sajip in branch '3.2':
Issue #17007: Made minor changes to documentation wording.
http://hg.python.org/cpython/rev/c8614ec54a63

New changeset d0e9f64bd55c by Vinay Sajip in branch '3.3':
Issue #17007: Merged minor changes from 3.2.
http://hg.python.org/cpython/rev/d0e9f64bd55c

New changeset 6877957a5e91 by Vinay Sajip in branch 'default':
Issue #17007: Merged minor changes from 3.3.
http://hg.python.org/cpython/rev/6877957a5e91

----------

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

From report at bugs.python.org  Tue Jan 22 02:11:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Jan 2013 01:11:56 +0000
Subject: [docs] [issue17009] "Thread Programming With Python" should be
	removed
In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za>
Message-ID: <1358817116.4.0.0237436017677.issue17009@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Given that the note at the top says that it's an unfinished draft, I think removing it would be fine.  It might be nice to see if there's anything still relevant that could be moved to the official docs, and possibly find out who wrote it and if he's ok with the removal.

----------
type:  -> enhancement

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

From report at bugs.python.org  Tue Jan 22 05:03:09 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 22 Jan 2013 04:03:09 +0000
Subject: [docs] [issue17009] "Thread Programming With Python" should be
	removed
In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za>
Message-ID: <1358827389.32.0.927264246194.issue17009@psf.upfronthosting.co.za>


Ned Deily added the comment:

It's included in a directory of Guido's essays (http://www.python.org/doc/essays/).  Guido, any thoughts about this and the others?

----------
nosy: +gvanrossum, ned.deily

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

From report at bugs.python.org  Tue Jan 22 06:09:18 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Jan 2013 05:09:18 +0000
Subject: [docs] [issue17009] "Thread Programming With Python" should be
	removed
In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za>
Message-ID: <1358831358.57.0.295702595668.issue17009@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'd like to keep the essay around as a permalink, but I don't object against putting some red text at the top warning people is is horribly out of date, and linking to a better tutorial.

----------

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

From report at bugs.python.org  Tue Jan 22 08:39:34 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 22 Jan 2013 07:39:34 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1358840374.33.0.757265423368.issue11379@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I'm not sure if it's a good idea to keep bikeshedding about this for another two years. Personally, I would prefer having someone with commit rights fix this and be done with it.

Eric's last patch looks ok and parts of it went in already, so it's mostly just the heading that remains to be fixed.

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

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

From report at bugs.python.org  Tue Jan 22 11:51:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jan 2013 10:51:48 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1358851908.78.0.492115210702.issue11379@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Someone should go ahead and apply this. ?ric, perhaps?

----------
stage: needs patch -> commit review

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

From report at bugs.python.org  Tue Jan 22 13:49:37 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Jan 2013 12:49:37 +0000
Subject: [docs] [issue10994] implementation details in sys module
In-Reply-To: <1295876620.3.0.027428786588.issue10994@psf.upfronthosting.co.za>
Message-ID: <1358858977.78.7.45497809278e-05.issue10994@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 22 13:51:50 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Jan 2013 12:51:50 +0000
Subject: [docs] [issue8350] Document lack of support for keyword arguments
	in C	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1358859110.11.0.809055194895.issue8350@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
title: Document lack of support for keyword arguments in C	functions -> Document lack of support for keyword arguments in C functions
versions: +Python 3.3, Python 3.4 -Python 3.1

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

From report at bugs.python.org  Tue Jan 22 13:54:43 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Jan 2013 12:54:43 +0000
Subject: [docs] [issue9708] cElementTree iterparse does not support "parser"
	argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1358859283.16.0.327890122189.issue9708@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
versions: +Python 3.4

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

From report at bugs.python.org  Tue Jan 22 13:57:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Jan 2013 12:57:15 +0000
Subject: [docs] [issue10048] urllib.request documentation confusing
In-Reply-To: <1286535990.46.0.129844190964.issue10048@psf.upfronthosting.co.za>
Message-ID: <1358859435.01.0.48030864307.issue10048@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 22 14:00:40 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jan 2013 13:00:40 +0000
Subject: [docs] [issue4934] tp_del and tp_version_tag undocumented
In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za>
Message-ID: <1358859640.4.0.720981095155.issue4934@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

tp_cache and tp_weaklist are also for internal use only, but are documented.

One reason for documenting them is that users will run into them when running with a high enough warning level in GCC.

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Tue Jan 22 14:04:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Jan 2013 13:04:25 +0000
Subject: [docs] [issue4934] tp_del and tp_version_tag undocumented
In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za>
Message-ID: <1358859865.34.0.907615541519.issue4934@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/issue4934>
_______________________________________

From report at bugs.python.org  Tue Jan 22 14:52:11 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 22 Jan 2013 13:52:11 +0000
Subject: [docs] [issue9708] cElementTree iterparse does not support "parser"
	argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1358862731.53.0.470246108906.issue9708@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Could you point out specifically which methods in ET don't work with the argument, and describe the problem in general?

----------

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

From report at bugs.python.org  Tue Jan 22 15:34:55 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 22 Jan 2013 14:34:55 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1358865295.28.0.614339198529.issue11367@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Patches to documentation of 3.2 and 2.7 are welcome

----------

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

From report at bugs.python.org  Tue Jan 22 17:22:04 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 22 Jan 2013 16:22:04 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1358871724.26.0.517372164491.issue11379@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Sure, feel free to commit this.

----------

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

From report at bugs.python.org  Tue Jan 22 20:02:47 2013
From: report at bugs.python.org (Silvan Jegen)
Date: Tue, 22 Jan 2013 19:02:47 +0000
Subject: [docs] [issue9708] cElementTree iterparse does not support "parser"
	argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1358881367.33.0.406004506317.issue9708@psf.upfronthosting.co.za>


Silvan Jegen added the comment:

The situation is as follows.

According to the online documentation of Python 2.7 the
xml.etree.ElementTree.iterparse() function takes up to three arguments, two of them named ones:

    xml.etree.ElementTree.iterparse(source, events=None, parser=None)

In the C implementation of the function however, the "parser" argument does not seem to be supported:


    >>> import xml.etree.ElementTree as ET
    >>> import xml.etree.cElementTree as ETc # C version of the library 
    >>> result = ET.iterparse("xmltest.xml", None, ET.XMLParser()) # Works
    >>>

    >>> result = ETc.iterparse("xmltest.xml", None, ET.XMLParser()) # C version does'nt
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: __init__() takes at most 3 arguments (4 given)

The documentation does not mention the C version of the function not taking the "parser" argument as far as I know.

Additionally, the xml.etree.ElementTree.iterparse() online documentation
for Python 3.3 mentions the "parser" argument as well. When using this
argument however, Python throws an error:


    Python 3.3.0 (default, Dec 22 2012, 21:02:07) 
    [GCC 4.7.2] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import xml.etree.ElementTree as ET
    >>> ET.iterparse("xmltest.xml", None, ET.XMLParser())
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: __init__() takes from 2 to 3 positional arguments but 4 were given


A look at the pydoc output for xml.etree.ElementTree actually does not mention a named "parser" argument to iterparse() at all (Please note that iterparse seems to be a constructor in Python 3.3):

class iterparse(builtins.object)
     |  Methods defined here:
     |  
     |  __init__(self, file, events=None)


In these cases either the implementation or the documentation should be
changed.

Please feel free to ask away if you have more questions.

----------

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

From report at bugs.python.org  Tue Jan 22 21:50:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Jan 2013 20:50:22 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <3YrMG54QcczSNw@mail.python.org>


Roundup Robot added the comment:

New changeset c2ae1ed03853 by Ezio Melotti in branch '2.7':
#11379: rephrase minidom documentation to use the term "minimal" instead of "lightweight".  Patch by ?ric Araujo.
http://hg.python.org/cpython/rev/c2ae1ed03853

New changeset b9c0e050c935 by Ezio Melotti in branch '3.2':
#11379: rephrase minidom documentation to use the term "minimal" instead of "lightweight".  Patch by ?ric Araujo.
http://hg.python.org/cpython/rev/b9c0e050c935

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

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

----------

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

From report at bugs.python.org  Tue Jan 22 21:51:53 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 22 Jan 2013 20:51:53 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1358887913.5.0.162549713007.issue11379@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

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

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

From report at bugs.python.org  Wed Jan 23 17:59:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jan 2013 16:59:21 +0000
Subject: [docs] [issue4934] tp_del and tp_version_tag undocumented
In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za>
Message-ID: <1358960361.04.0.497245393334.issue4934@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> tp_cache and tp_weaklist are also for internal use only, but are
> documented.

Ok, so I guess tp_version_tag and tp_del should also be documented as "for internal use only".

----------

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

From report at bugs.python.org  Thu Jan 24 02:27:30 2013
From: report at bugs.python.org (benrg)
Date: Thu, 24 Jan 2013 01:27:30 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1358990850.05.0.650056835518.issue16701@psf.upfronthosting.co.za>


benrg added the comment:

This is bizarre:

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> x = y = [1, 2]
>>> x += [3]
>>> y
[1, 2, 3]
>>> x = y = {1, 2}
>>> x -= {2}
>>> y
{1}
>>>

Since when has this been standard behavior? The documentation says:

"An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to achieve a similar, but not exactly equal effect. In the augmented version, x is only evaluated once. Also, when possible, the actual operation is performed in-place, meaning that rather than creating a new object and assigning that to the target, the old object is modified instead."

What is "when possible" supposed to mean here? I always thought it meant "when there are known to be no other references to the object". If op= is always destructive on lists and sets, then "where possible" needs to be changed to "always" and a prominent warning added, like "WARNING: X OP= EXPR DOES NOT BEHAVE EVEN REMOTELY LIKE X = X OP EXPR IN PYTHON WHEN X IS A MUTABLE OBJECT, IN STARK CONTRAST TO EVERY OTHER LANGUAGE WITH A SIMILAR SYNTAX."

----------
nosy: +benrg

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

From report at bugs.python.org  Thu Jan 24 04:37:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Jan 2013 03:37:15 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1358998635.73.0.478702263053.issue16701@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> What is "when possible" supposed to mean here?

Generally it means "when the object is mutable":
>>> l = [1,2,3]
>>> id(l)
3074713484
>>> l += [4]
>>> id(l)
3074713484
>>> t = (1,2,3)
>>> id(t)
3074704004
>>> t += (4,)
>>> id(t)
3075304860

Tuples are not mutable, so it's not possible to modify them in place, and a new tuple needs to be created.
Note that while most mutable objects in the stdlib that support += do indeed modify the object rather than creating a new one, I don't think this is strictly required.
IOW that paragraph is already warning you that (with mutable objects) the object might be reused, depending on the implementation.  Maybe this should be clarified?
(IIRC in CPython it could be possible that in some situations an immutable object still has the same id after an augmented assignment, but, if it really happens, it is an implementation detail and shouldn't affect semantics.)

----------

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

From report at bugs.python.org  Thu Jan 24 05:10:02 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Jan 2013 04:10:02 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1359000602.86.0.893833148802.issue16701@psf.upfronthosting.co.za>


R. David Murray added the comment:

If you really want to freak out, try this:

>>> x = ([],)
>>> x[0] += [1]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> x
([1],)

but to answer your question, it has *always* worked that way, from the time augmented assignment was introduced (see, eg, issue 1306777, which was reported against python 2.4).  

Remember, Python names refer to pointers to objects, they are not variables in the sense that other languages have variables.

Guido resisted augmented assignment for a long time.  These confusions speak to why.

As far as I know Ezio is correct, "when possible" means "when the target is mutable".  The documentation should probably be clarified on that point.  I'm not sure it is practical to let whether or not the target is mutated be an implementation detail. IMO the behavior must be clearly defined for each type that is built in to Python.

----------

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

From report at bugs.python.org  Thu Jan 24 05:59:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Jan 2013 04:59:57 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1359003597.91.0.0119699438017.issue16701@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

To clarify, with "depends on the implementation" I meant the way a particular class is implemented (i.e. a class might decide to return a new object even if it's mutable).
The behavior of built-in types is well defined and should be the same across all the Python implementations.
Regarding the comment about immutable types, it's something specific to CPython (I don't remember the specific details though, so I might be wrong), and somewhat similar to:
>>> 'a'*20 is 'a'*20
True
>>> 'a'*25 is 'a'*25
False
This shouldn't be a problem though, so if you e.g. do "x = y = immutableobj;  y += 1", 'x' should never be affected.

----------

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

From report at bugs.python.org  Thu Jan 24 06:18:42 2013
From: report at bugs.python.org (benrg)
Date: Thu, 24 Jan 2013 05:18:42 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1359004722.06.0.51526932482.issue16701@psf.upfronthosting.co.za>


benrg added the comment:

> As far as I know Ezio is correct, "when possible" means "when the target is mutable".  The documentation should probably be clarified on that point.

Yes, it needs to be made very, very clear in the documentation. As I said, I'm not aware of any other language in which var op= expr does not mean the same thing as var = var op expr. I'm actually amazed that neither of you recognize the weirdness of this behavior (and even more amazed that GvR apparently didn't). I'm an experienced professional programmer, and I dutifully read the official documentation cover to cover when I started programming in Python, and I interpreted this paragraph wrongly, because I interpreted it in the only way that made sense given the meaning of these operators in every other language that has them. Python is designed to be unsurprising; constructs generally mean what it looks like they mean. You need to explain this unique feature of Python in terms so clear that it can't possibly be mistaken for the behavior of all of the other languages.

> Remember, Python names refer to pointers to objects, they are not variables in the sense that other languages have variables.

That has nothing to do with this. Yes, in Python (and Java and Javascript and many other languages) all objects live on the heap, local variables are not first-class objects, and var = expr is a special form. That doesn't change the fact that in all of those other languages, var += expr means var = var + expr. In C++ local variables are first-class objects and var += expr means var.operator+=(expr) or operator+=(var, expr), and this normally modifies the thing on the left in a way that's visible through references. But in C++, var = var + expr also modifies the thing on the left, in the same way.

In Python and Java and Javascript and ..., var = value never visibly mutates any heap object, and neither does var = var + value (in any library that defines a sane + operator), and therefore neither should var += value (again, in any sanely designed library). And it doesn't. Except in Python.

----------

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

From report at bugs.python.org  Thu Jan 24 07:22:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Jan 2013 06:22:22 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1359008542.86.0.495095094533.issue16701@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Python is designed to be unsurprising; constructs generally mean
> what it looks like they mean.

AFAIK in C "x += 1" is equivalent to "x++", and both are semantically more about incrementing (mutating) the value of x than about creating a new value that gets assigned to x.
Likewise it seems to me more natural to interpret "x += y" as "add the value of y to the object x" than "add x and y together and save the result in x".
Clearly if you are used to other languages with different semantics you might expect a different behavior, but you could say the same about the fact that int/int gives float on Python 3: it's surprising if you are used to other languages like C, but otherwise it's more natural.

> I interpreted this paragraph wrongly, because I interpreted it in the
> only way that made sense given the meaning of these operators in 
> every other language that has them.

It seems to me that the documentation doesn't leave much room for interpretation regarding the fact that the object is mutated in place; the only problem is that it doesn't specify clearly what are the objects that do this.

----------

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

From report at bugs.python.org  Thu Jan 24 16:17:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 24 Jan 2013 15:17:44 +0000
Subject: [docs] [issue9708] cElementTree iterparse does not support "parser"
	argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <3YsRnM4cnLzPN9@mail.python.org>


Roundup Robot added the comment:

New changeset cce526a28f81 by Eli Bendersky in branch '3.3':
Issue #9708: Fix support for iterparse(parser=...) argument per documentation.
http://hg.python.org/cpython/rev/cce526a28f81

New changeset 0c9268ac3ffa by Eli Bendersky in branch 'default':
Issue #9708: Fix support for iterparse(parser=...) argument per documentation.
http://hg.python.org/cpython/rev/0c9268ac3ffa

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

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

From report at bugs.python.org  Thu Jan 24 16:19:57 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 24 Jan 2013 15:19:57 +0000
Subject: [docs] [issue9708] cElementTree iterparse does not support "parser"
	argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1359040796.97.0.0405769254515.issue9708@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Support added in 3.3 and default

Documentation patches should be done for 2.7 and 3.2

----------

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

From report at bugs.python.org  Thu Jan 24 16:26:23 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 24 Jan 2013 15:26:23 +0000
Subject: [docs] [issue9708] cElementTree iterparse does not support "parser"
	argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1359041183.56.0.167824198956.issue9708@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Fix to 3.2 committed in 5b02d622d625

----------

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

From report at bugs.python.org  Thu Jan 24 16:27:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 24 Jan 2013 15:27:10 +0000
Subject: [docs] [issue14462] In re's named group the name cannot contain
	unicode	characters
In-Reply-To: <1333268208.65.0.802050679023.issue14462@psf.upfronthosting.co.za>
Message-ID: <1359041230.34.0.549714618352.issue14462@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which make re to use for groups the same rule as for Python 3 identifiers. In Python 2 the implementation confirms the documentation.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
versions: +Python 3.4 -Python 2.7
Added file: http://bugs.python.org/file28811/re_unicode_identifiers.patch

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

From report at bugs.python.org  Thu Jan 24 16:28:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 24 Jan 2013 15:28:46 +0000
Subject: [docs] [issue9708] cElementTree iterparse does not support "parser"
	argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <3YsS261nS6zRJm@mail.python.org>


Roundup Robot added the comment:

New changeset 8f2edea69d5d by Eli Bendersky in branch '2.7':
Issue #9708: clarify doc of iterparse - cElementTree doesn't support the parser argument
http://hg.python.org/cpython/rev/8f2edea69d5d

----------

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

From report at bugs.python.org  Thu Jan 24 16:29:16 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 24 Jan 2013 15:29:16 +0000
Subject: [docs] [issue9708] cElementTree iterparse does not support "parser"
	argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1359041356.62.0.525957561097.issue9708@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jan 24 19:02:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Jan 2013 18:02:10 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1359050530.62.0.55713537329.issue16954@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I would suggest to adapt the comments to follow PEP 257, and in particular:
"""
The docstring is a phrase ending in a period. It prescribes the function or method's effect as a command ("Do this", "Return that"), not as a description; e.g. don't write "Returns the pathname ...".
"""

Currently there are two docstrings, one for write() and one for iterparse() (recently added in #9708).  Only the former uses the correct form ("Return" instead of "Returns").

----------

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

From report at bugs.python.org  Thu Jan 24 19:15:11 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 24 Jan 2013 18:15:11 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1359050530.62.0.55713537329.issue16954@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-KnaaGUScjHunZKwgDGer=9hDf3rRHA0qYyXTeRCtT1g@mail.gmail.com>


Eli Bendersky added the comment:

On Thu, Jan 24, 2013 at 10:02 AM, Ezio Melotti <report at bugs.python.org>wrote:

>
> Ezio Melotti added the comment:
>
> I would suggest to adapt the comments to follow PEP 257, and in particular:
> """
> The docstring is a phrase ending in a period. It prescribes the function
> or method's effect as a command ("Do this", "Return that"), not as a
> description; e.g. don't write "Returns the pathname ...".
> """
>
> Currently there are two docstrings, one for write() and one for
> iterparse() (recently added in #9708).  Only the former uses the correct
> form ("Return" instead of "Returns").
>

Actually, the latter was copy-pasted from the ReST docs of the method. Does
that PEP 257 suggestion apply to ReST docs as well, or do we have a
discrepancy?

----------

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

From report at bugs.python.org  Thu Jan 24 19:19:14 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Jan 2013 18:19:14 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1359051554.78.0.285034472666.issue16954@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The docs should use "return" too, even though I'm not sure this is enforced.  Consistency within the doc page is more important, but I don't think that consistency between comments and docstrings in the code or between docstrings and documentation is so important.

----------

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

From report at bugs.python.org  Thu Jan 24 19:40:16 2013
From: report at bugs.python.org (benrg)
Date: Thu, 24 Jan 2013 18:40:16 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1359052816.69.0.160065600674.issue16701@psf.upfronthosting.co.za>


benrg added the comment:

> AFAIK in C "x += 1" is equivalent to "x++", and both are semantically
> more about incrementing (mutating) the value of x than about creating a
> new value that gets assigned to x. Likewise it seems to me more natural
> to interpret "x += y" as "add the value of y to the object x" than "add
> x and y together and save the result in x".

Look, it's very simple: in C, ++x and x += 1 and x = x + 1 all mean the same thing. You can argue about how to describe the thing that they do, but there's only one thing to describe. Likewise, in every other language that borrows the op= syntax from C, it is a shorthand for the expanded version with the bare operator. As far as I know, Python is the only exception. If you know of another exception please say so.


> >>> x = ([],)
> >>> x[0] += [1]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'tuple' object does not support item assignment
> >>> x
> ([1],)

I actually knew about this. It's an understandably difficult corner case, since the exception is raised after __iadd__ returns, so there's no chance for it to roll back its changes.

At least, I thought it was a difficult corner case back when I thought the in-place update was a mere optimization. But if += really means .extend() on lists, this should not raise an exception at all. In fact there's no sense in having __iadd__ return a value that gets assigned anywhere, since mutable objects always mutate and return themselves and immutable objects don't define __iadd__. It looks like the interface was designed with the standard semantics in mind but the implementation did something different, leaving a vestigial assignment that's always a no-op. What a disaster.

----------

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

From report at bugs.python.org  Thu Jan 24 20:39:27 2013
From: report at bugs.python.org (David Lam)
Date: Thu, 24 Jan 2013 19:39:27 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1359056367.32.0.437945018876.issue16954@psf.upfronthosting.co.za>


David Lam added the comment:

I had an innocent question about the format to use when listing function arguments in docstrings.  In the PEP 257 doc, there's a single example:

    def complex(real=0.0, imag=0.0):
        """Form a complex number.

        Keyword arguments:
        real -- the real part (default 0.0)
        imag -- the imaginary part (default 0.0)

I went digging through Lib/ for a good example to follow, but felt a little unsure because the exact format seemed to differ ever so slightly sometimes.

Like in ipaddress.py, a colon is used instead of two hyphens, and it's indented:

    def ip_address(address):
        """Take an IP string/int and return an object of the correct type.

        Args:
            address: A string or integer, the IP address.  Either IPv4 or
              IPv6 addresses may be supplied; integers less than 2**32 will
              be considered to be IPv4 by default.

Is there an "ideal" example in the source to try to copy?  
(or maybe this is just a use-your-common-sense thing)

----------

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

From report at bugs.python.org  Thu Jan 24 20:43:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 24 Jan 2013 19:43:15 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1359056595.08.0.194073730764.issue16954@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> (or maybe this is just a use-your-common-sense thing)

That's probably the best thing.  I don't think we follow any specific convention for args in the docstring.  Mostly they are just described in the text, without having lists of args.

----------

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

From report at bugs.python.org  Fri Jan 25 20:19:22 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Jan 2013 19:19:22 +0000
Subject: [docs] [issue12652] Keep test.support docs out of the global docs
	index
In-Reply-To: <1311925525.47.0.986284069415.issue12652@psf.upfronthosting.co.za>
Message-ID: <1359141562.48.0.682676943465.issue12652@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 25 20:20:18 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Jan 2013 19:20:18 +0000
Subject: [docs] [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1359141618.07.0.599673753439.issue12648@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 25 20:32:38 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Jan 2013 19:32:38 +0000
Subject: [docs] [issue11676] Improve imp.load_module and submodules doc
In-Reply-To: <1301089227.12.0.157951103986.issue11676@psf.upfronthosting.co.za>
Message-ID: <1359142358.39.0.102196099283.issue11676@psf.upfronthosting.co.za>


Brett Cannon added the comment:

imp.find_module() is now deprecated, so not worrying about adding more details to the docs for the function.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Jan 25 20:33:15 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Jan 2013 19:33:15 +0000
Subject: [docs] [issue13048] Handling of paths in first argument of
	imp.find_module()
In-Reply-To: <1316984733.77.0.135974751185.issue13048@psf.upfronthosting.co.za>
Message-ID: <1359142395.75.0.15821320817.issue13048@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 25 20:34:04 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Jan 2013 19:34:04 +0000
Subject: [docs] [issue13047] imp.find_module("") and imp.find_module(".")
In-Reply-To: <1316983798.48.0.694425302693.issue13047@psf.upfronthosting.co.za>
Message-ID: <1359142444.64.0.0300275876783.issue13047@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 25 22:13:13 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 25 Jan 2013 21:13:13 +0000
Subject: [docs] [issue17035] Use new style classes in {class,
	static}method examples
Message-ID: <1359148393.48.0.512379058161.issue17035@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The examples in the built-in functions documentation[1] should be consistent and use new style classes.

[1] http://docs.python.org/2.7/library/functions.html

----------
assignee: docs at python
components: Documentation
files: new-style-classes.diff
keywords: patch
messages: 180624
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Use new style classes in {class, static}method examples
versions: Python 2.7
Added file: http://bugs.python.org/file28831/new-style-classes.diff

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

From report at bugs.python.org  Sat Jan 26 14:26:51 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 26 Jan 2013 13:26:51 +0000
Subject: [docs] [issue17040] Document context manager support for shelf
	objects
Message-ID: <1359206810.79.0.264675757917.issue17040@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Context manager support for shelf objects was added in issue 13896, but not documented.

----------
assignee: docs at python
components: Documentation
files: shelve-context-manager-doc.diff
keywords: patch
messages: 180667
nosy: asvetlov, berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Document context manager support for shelf objects
versions: Python 3.4
Added file: http://bugs.python.org/file28843/shelve-context-manager-doc.diff

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

From report at bugs.python.org  Sat Jan 26 16:28:19 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 26 Jan 2013 15:28:19 +0000
Subject: [docs] [issue17009] "Thread Programming With Python" should be
	removed
In-Reply-To: <1358799622.32.0.0901338309925.issue17009@psf.upfronthosting.co.za>
Message-ID: <1359214099.16.0.279334835002.issue17009@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan 26 18:17:06 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 26 Jan 2013 17:17:06 +0000
Subject: [docs] =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0?=
 =?utf-8?q?and_readline=28=29_argument_names?=
In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>
Message-ID: <1359220626.35.0.540422799531.issue17003@psf.upfronthosting.co.za>


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


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

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

From a.hr.mostafavi at gmail.com  Fri Jan 25 10:48:57 2013
From: a.hr.mostafavi at gmail.com (ali mostafavi)
Date: Fri, 25 Jan 2013 13:18:57 +0330
Subject: [docs] bug
Message-ID: <CAApLAKB-GxZJVXNBNwQVcmHQ1GRn-S1+qm_-ZMdU5XJ0duGWLQ@mail.gmail.com>

hi!
i found a bug in python 2.7.3
if we make a list like this:
a = [[0]*3]*3
then change the a[y][x] like this:
a[1][1] = 1
the whole column changes. the result would be:
[[0,1,0],[0,1,0],[0,1,0]]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130125/b5e6b7d4/attachment.html>

From acmeros at gmail.com  Mon Jan 14 08:28:55 2013
From: acmeros at gmail.com (Dmitry Northerner)
Date: Mon, 14 Jan 2013 11:28:55 +0400
Subject: [docs] Typo
Message-ID: <CAPbDKXyXnk0Uaf=wqqy1z2nB+t9BtMcsbksSEjvGzXDVR82uzw@mail.gmail.com>

Hello!

I've found a little typo on the page http
://docs.python.org/2/reference/compound_stmts.html#try<http://docs.python.org/2/reference/compound_stmts.html#try>

If finally <http://docs.python.org/2/reference/compound_stmts.html#finally> is
present, it specifies a ?cleanup? handler. The
try<http://docs.python.org/2/reference/compound_stmts.html#try> clause
is executed, including any
except<http://docs.python.org/2/reference/compound_stmts.html#except>
 and else <http://docs.python.org/2/reference/compound_stmts.html#else>
clauses.
If an exception occurs in any of the clauses and is not handled, the
exception is temporarily saved. The
finally<http://docs.python.org/2/reference/compound_stmts.html#finally>
clause
is executed. If there is a saved exception, it is re-raised at the end of
the finally <http://docs.python.org/2/reference/compound_stmts.html#finally>
clause.
If the finally<http://docs.python.org/2/reference/compound_stmts.html#finally>
clause
raises another exception or executes a
return<http://docs.python.org/2/reference/simple_stmts.html#return>
 or break <http://docs.python.org/2/reference/simple_stmts.html#break>statement,
the saved exception is !!!dicarded!!!:  (I guess, here should be -
discarded)

Thanks for your great job, because we all need documentation...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130114/5ac6a76e/attachment.html>

From aharrin at luc.edu  Sun Jan 20 03:07:34 2013
From: aharrin at luc.edu (Andrew Harrington)
Date: Sat, 19 Jan 2013 20:07:34 -0600
Subject: [docs] typo in Python 3.3 section 4.6.6 on range
Message-ID: <CAOaxTE+-cXscRZfwV00x03eKFUN9G6G5vVapgmtJXDXN=gmsMg@mail.gmail.com>

You have "meant"  where it could be "meet" or maybe better "satisfy".

-- 
Dr. Andrew N. Harrington
  Computer Science Department
  Loyola University Chicago
Lakeshore office in the Math Department: 104 Loyola Hall
http://www.cs.luc.edu/~anh
Phone: 312-915-7999
Fax:    312-915-7998
aharrin at luc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130119/26d3a639/attachment-0001.html>

From ajbozdar at gmail.com  Tue Jan 22 05:03:20 2013
From: ajbozdar at gmail.com (Abdul J.)
Date: Tue, 22 Jan 2013 12:03:20 +0800
Subject: [docs] Python doesn't show time.now
Message-ID: <CA+BHdEnw=kxB89QK5TfgHdUXFocUtb+GaShdPhOgMeFsF-gPog@mail.gmail.com>

Hello,

Here is the problem which I am facing. I do not have any kind of suggestion
as I am a student.

Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
on win32
Type "copyright", "credits" or "license()" for more information.

from datetime import datetime
now = datetime.now()
print now
2013-01-22 11:22:53.503000
print now
2013-01-22 11:22:53.503000
print now
2013-01-22 11:22:53.503000

This is what along with results. I am worried what does meant by default
Apr. 20th. Isn't something wrong there?


You can see, "Python do not show date and time with now function". I am
using Python IDLE Shell and I just downloaded and installed. It also shows
"default Apr. 20th". I do not understand this.


Thank you,

Abdul Jabbar

Southeast University Nanjing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130122/cb2a5121/attachment.html>

From alberth289346 at gmail.com  Sun Jan 20 21:18:49 2013
From: alberth289346 at gmail.com (Albert Hofkamp)
Date: Sun, 20 Jan 2013 21:18:49 +0100
Subject: [docs] Python 3 int() conversion docs misses exception documentation
Message-ID: <CAEyAk51HugN1BfP8aJxAn+puNH=PRahLotbEFPww8OC40vqBGw@mail.gmail.com>

In http://docs.python.org/3/library/functions.html#int the int()
operation is described. It does however not say which errors can be
thrown. I found two:

Python 3.2.3 (default, Jun  8 2012, 05:36:09)
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> int('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: 'abc'
>>> int( ('0',) )
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string or a number, not 'tuple'
>>>

The former is expected (it happened in Python 2 as well). The latter
is quite unexpected, so I wanted to know when that could happen.


The float() documentation may have similar problems; it only speaks
about OverflowError


Sincerely,
Albert

From bkamili at apple.com  Thu Jan 17 19:40:40 2013
From: bkamili at apple.com (Bala Srinivas Kamili)
Date: Thu, 17 Jan 2013 10:40:40 -0800
Subject: [docs] URL not working
Message-ID: <7C9DEBEF-9BCA-45C1-8A3D-E52B45344F4C@apple.com>

http://wiki.python.org/moin/BeginnersGuide

URL isn't working from a few days. Can you please check.




Thanks & Regards
Bala Srinivas Kamili
bkamili at apple.com
469-323-9064

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130117/91b0d644/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_blueberry.gif
Type: image/gif
Size: 1077 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20130117/91b0d644/attachment.gif>

From coltonjphillips at gmail.com  Fri Jan 25 17:06:53 2013
From: coltonjphillips at gmail.com (Colton Phillips)
Date: Fri, 25 Jan 2013 08:06:53 -0800
Subject: [docs] doc bug: distutils doesnt do a good enough job of describing
 what distutils does
Message-ID: <CAPkRzQ7n2P0v-=bEoy=zO++vz4gzY5N4j+TtWATc6FkRZAPxiQ@mail.gmail.com>

its not immediately clear.

Cheers,
C

-- 
Colton Phillips
Software Engineer
UVic GameDev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130125/dd0cd7e7/attachment.html>

From fb at bytepark.de  Thu Jan 24 23:36:45 2013
From: fb at bytepark.de (Florian Batschi)
Date: Thu, 24 Jan 2013 23:36:45 +0100
Subject: [docs] Python docs as epub fail to convert
Message-ID: <5101B77D.40409@bytepark.de>

Hi,

just a short info:

I've downloaded the Python documentation in epub format and was trying
to convert it to .mobi (so as to use it on the Kindle). I used several
converters (including calibre, zamzar and multiple others) and all
failed doing so. They simply stalled and could not complete the conversion.

I think there is an issue with the epub, as all converters fail.

Maybe just a suggestion.

Greetings
Florian	

From james.d.harding at siemens.com  Wed Jan 16 21:11:24 2013
From: james.d.harding at siemens.com (Harding, James)
Date: Wed, 16 Jan 2013 20:11:24 +0000
Subject: [docs] The delimiter '->' is missing in section 2.6 documentation
Message-ID: <D88D6CBD04B9E647B778917814A70F9A923EDC10@USSLMMBX003.net.plm.eds.com>

Hello,

A minor quibble. I do not see the token '->' used with function annotations listed among the delimiters in section 2.6 of the reference manual for Python v3.3.0.

Thank you,

James Harding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130116/f943191f/attachment.html>

From larry at staff.htcomp.net  Sun Jan 20 23:37:37 2013
From: larry at staff.htcomp.net (Larry Anglin)
Date: Sun, 20 Jan 2013 16:37:37 -0600
Subject: [docs] 'that' vs. 'which'
Message-ID: <CAN76RuwBTZCF6-C5qR-CQ+54swViY1A9HjT_0Uu7cMHvxGAskg@mail.gmail.com>

The word 'which' is used incorrectly extensively in the documentation.
 Even the page that (not which) describes how to submit a documentation bug
report has it used in correctly.

The first sentence on the bug reporting page says:

"Python is a mature programming language which has established a reputation
for stability. "

The 'which' in that sentence should be 'that', or the sentence should be
re-phrased:

Python, which has established a reputation for stability, is a mature
programming language.

In the few pages of documentation I have read, there are dozens of
instances of 'which' used when it should be 'that'.

I think the team does a great job, keep up the good work.

-- 
Larry Anglin,
President
htcomp.net, Inc.
900 S. Rice
Hamilton, TX 76531
254-386-8925
254-386-8927 (fax)
http://www.htcomp.net
*larry at htcomp.net*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130120/0fc5b939/attachment.html>

From leo_one at telus.net  Mon Jan 21 02:48:35 2013
From: leo_one at telus.net (John Heselton)
Date: Sun, 20 Jan 2013 17:48:35 -0800
Subject: [docs] Documentation Bug
Message-ID: <C336636340DE490EB2DAD15F41B37B89@Apollo>

Gentlemen:

  I believe that there is an incorrect statement in the documentation at paragraph 4.6 where:

  f(100) = fib2(100)

  should be:

  f = fib2

  then calling:

  f(100)

  sincerely,

  John Heselton (leo_one at telus.net)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130120/d0b66b03/attachment.html>

From marselcaka at gmail.com  Tue Jan 15 22:44:09 2013
From: marselcaka at gmail.com (marsel caka)
Date: Tue, 15 Jan 2013 22:44:09 +0100
Subject: [docs] Exponential in python
Message-ID: <CA+8ZfWsi1wyS6gc3MTW79YnCica-WEdOypWipLMW4vDVShUXRw@mail.gmail.com>

Hi,
i'm a student of Milan University and i am looking a tutorial of python.My
python version is 3.3.
When i do -2*-2 it's give me 4 but when i do -2**2 give me -4, i'm doing
same thing in two examples but with different result. This happen in all
python version or only in mine?
Thank You

-- 

marsel caka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130115/6a91cdf5/attachment.html>

From masterteedy at gmail.com  Fri Jan 18 19:12:58 2013
From: masterteedy at gmail.com (Tyler Birgen)
Date: Fri, 18 Jan 2013 11:12:58 -0700
Subject: [docs] sorted() "Sorting HowTo" Link
Message-ID: <CAE+1BV226Ez09zAWc9HSva4OBfUYkuU5=wT+MmFZjs6PFrsANw@mail.gmail.com>

Hello,

There seems to be a broken link under the "sorted()" function
documentation.  Here is a direct link:
http://docs.python.org/2/library/functions.html#sorted

The link from the bottom of this function's documentation with the text
"Sorting HowTo" tries to go here:
http://wiki.python.org/moin/HowTo/Sorting/

It seems that link is broken.  I believe the correct link to be:
http://docs.python.org/2/howto/sorting.html

Hope this helps.

Thanks,
Tyler Birgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130118/3c3d344d/attachment.html>

From melissa.thielen at mwcradio.com  Wed Jan 23 23:00:42 2013
From: melissa.thielen at mwcradio.com (Melissa Thielen)
Date: Wed, 23 Jan 2013 16:00:42 -0600
Subject: [docs] Calendar Documentation Bug
Message-ID: <CAJASrS2T9Ju4sFRQ5adeFy4BxbsPMysSYj1X1zUksOwU2ZsPQA@mail.gmail.com>

Location: http://docs.python.org/2/library/calendar.html

For calendar.monthcalendar(), the documentation states "Each week begins
with Monday..."; however, really it is Sunday.

When doing a simple import calendar, calendar.firstweekday() in the python
shell, it returns 6 or Sunday. This is also confirmed when doing
calendar.monthcalendar(year, month) for any month. It's off by 1 if the
week were to begin on Monday, but correct if the week begins on Sunday.

Thanks!

-- 
Melissa Thielen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130123/a4dd15a0/attachment-0001.html>

From pszalwinski at gmail.com  Sat Jan 26 00:56:24 2013
From: pszalwinski at gmail.com (Philip Szalwinski)
Date: Fri, 25 Jan 2013 18:56:24 -0500
Subject: [docs] My first bug! (I think)
Message-ID: <CAA6AbJjwF5ufPe_MNUg59LpfaUFco4GjEkgdA+gzQJ8Zf9NHcg@mail.gmail.com>

Hi!

I was reading through the Python docs looking at the section on strings at
http://docs.python.org/2/tutorial/introduction.html#strings and it seems
like the last line in the first terminal box (is that what that is called?)
is printed incorrectly.

Instead of:
>>> '"Isn\'t," she said.'
'"Isn\'t," she said.'

It should read:
>>> '"Isn\'t," she said.'
"Isn't," she said.

Hope this helps!

Philip Szalwinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130125/f9e70ff2/attachment.html>

From vito.detullio at gmail.com  Thu Jan 24 09:57:56 2013
From: vito.detullio at gmail.com (Vito De Tullio)
Date: Thu, 24 Jan 2013 09:57:56 +0100
Subject: [docs] Little quirk with lateral menu
Message-ID: <CAGxu5EcDK0=OHGna7n6ADn-jD5_+eX_MA8R83XHBzbpNCVCu0A@mail.gmail.com>

Hi.

I found a little quirk with the lateral "collapsable" menu and I see this
email address at http://docs.python.org/3.4/bugs.html.

If you see a page with little documentation (for example
http://docs.python.org/3.4/library/macpath.html ) and you have the lateral
menu collapsed, the ">>" arrows are out of the "button" (the grey clickable
area to expand the lateral menu).

Moreover, if you expand the menu, the height button is fixed and do not
reach the end of the lateral menu area.

(I'm with firefox 18.0.1 on windows seven)

-- 
Vito De Tullio - Vito.DeTullio at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130124/578c0a59/attachment.html>

From xwhhsprings at gmail.com  Tue Jan 15 16:04:29 2013
From: xwhhsprings at gmail.com (=?ISO-2022-JP?B?GyRCSGtFchsoQg==?=)
Date: Wed, 16 Jan 2013 00:04:29 +0900
Subject: [docs] in FAQ:
 `http://wiki.python.org/moin/PythonSpeed/PerformanceTips` : not found
Message-ID: <CAHUjfXHiCqw1V0UMGnmCFLeQtiPL7bZokMEHwK-XPj5P8fKH8A@mail.gmail.com>

In
    http://docs.python.org/2.7/faq/programming.html?highlight=global#my-program-is-too-slow-how-do-i-speed-it-up

Sentence:
    There is a page on the wiki devoted to `performance tips
<http://wiki.python.org/moin/PythonSpeed/PerformanceTips>`_.


but, http://wiki.python.org/moin/PythonSpeed/PerformanceTips does not exist.

And, `sorting mini-HOWTO <http://wiki.python.org/moin/HowTo/Sorting>`_
does not exist, too.

From zabano at gmail.com  Fri Jan 25 20:22:46 2013
From: zabano at gmail.com (Omar Zabaneh)
Date: Fri, 25 Jan 2013 12:22:46 -0700
Subject: [docs] os.EX_NOTFOUND
Message-ID: <CAMZkrmCvKpYKSqBwcBJRYrdWhgDp0ZoJ-AeazJqNQYWPTE_ytw@mail.gmail.com>

Hi,

The exit code os.EX_NOTFOUND is not defined using Python 2.7.3 on
Linux (RedHat Enterprise).
I get the following error.
AttributeError: 'module' object has no attribute 'EX_NOTFOUND'

It seems like it is removed but that is not indicated in the documentation:
http://docs.python.org/2/library/os.html#os.EX_NOTFOUND

Thanks,
Omar

From zapbross at gmail.com  Wed Jan 16 16:35:50 2013
From: zapbross at gmail.com (Saravanan V)
Date: Wed, 16 Jan 2013 09:35:50 -0600
Subject: [docs] minor bug:
	http://docs.python.org/2/tutorial/datastructures.html#sets
Message-ID: <CAEhjGakkTY5ocBowUstfNF8gx2t_FVW3EgZSYECnEPaXUfEiqg@mail.gmail.com>

At  http://docs.python.org/2/tutorial/datastructures.html#sets

under set comprehensions the example uses {} it should be []

a = {x for x in 'abracadabra' if x not in 'abc'}a

-- 
Regards,
Saravanan V
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130116/faa7152b/attachment.html>

From sandro.tosi at gmail.com  Sat Jan 26 19:13:42 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 26 Jan 2013 19:13:42 +0100
Subject: [docs] in FAQ:
 `http://wiki.python.org/moin/PythonSpeed/PerformanceTips` : not found
In-Reply-To: <CAHUjfXHiCqw1V0UMGnmCFLeQtiPL7bZokMEHwK-XPj5P8fKH8A@mail.gmail.com>
References: <CAHUjfXHiCqw1V0UMGnmCFLeQtiPL7bZokMEHwK-XPj5P8fKH8A@mail.gmail.com>
Message-ID: <CAB4XWXy9OLi80_X8TiCqovh4hCa7vM2YD2O+dAkExzgTDyb3uw@mail.gmail.com>

Hello,
Thanks for your email.

On Tue, Jan 15, 2013 at 4:04 PM, ?? <xwhhsprings at gmail.com> wrote:
> but, http://wiki.python.org/moin/PythonSpeed/PerformanceTips does not exist.
>
> And, `sorting mini-HOWTO <http://wiki.python.org/moin/HowTo/Sorting>`_
> does not exist, too.

The wiki should be back, at least partially, so those links are
available again now; you can refer to
http://wiki.python.org/moin/WikiAttack2013 for additional details.

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

From sandro.tosi at gmail.com  Sat Jan 26 19:14:58 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 26 Jan 2013 19:14:58 +0100
Subject: [docs] URL not working
In-Reply-To: <7C9DEBEF-9BCA-45C1-8A3D-E52B45344F4C@apple.com>
References: <7C9DEBEF-9BCA-45C1-8A3D-E52B45344F4C@apple.com>
Message-ID: <CAB4XWXw=J24eBYNtSsbHObqCjRoc_NbZhz59APe6+H_7O1VEdw@mail.gmail.com>

Hello Bala,
thanks for your email.


On Thu, Jan 17, 2013 at 7:40 PM, Bala Srinivas Kamili <bkamili at apple.com> wrote:
> http://wiki.python.org/moin/BeginnersGuide
>
> URL isn't working from a few days. Can you please check.

The wiki should be back, at least partially, so that link is available
again now; you can refer to http://wiki.python.org/moin/WikiAttack2013
for additional details.

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

From sandro.tosi at gmail.com  Sat Jan 26 19:19:13 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 26 Jan 2013 19:19:13 +0100
Subject: [docs] minor bug:
	http://docs.python.org/2/tutorial/datastructures.html#sets
In-Reply-To: <CAEhjGakkTY5ocBowUstfNF8gx2t_FVW3EgZSYECnEPaXUfEiqg@mail.gmail.com>
References: <CAEhjGakkTY5ocBowUstfNF8gx2t_FVW3EgZSYECnEPaXUfEiqg@mail.gmail.com>
Message-ID: <CAB4XWXyuWm3-GdjSw5y8_xaH3znHZdaCnaDiSrtEPwEZZSbT7A@mail.gmail.com>

Hello Saravanan,
thanks for your email.

On Wed, Jan 16, 2013 at 4:35 PM, Saravanan V <zapbross at gmail.com> wrote:
> At  http://docs.python.org/2/tutorial/datastructures.html#sets
>
> under set comprehensions the example uses {} it should be []

Why do you think that?

> a = {x for x in 'abracadabra' if x not in 'abc'}
> a

the example shows the set comprehensions, and {} generates a set,
while [] generates a list:

>>> type({x for x in [1, 2]})
<type 'set'>
>>> type([x for x in [1, 2]])
<type 'list'>

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 Jan 26 19:20:38 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 26 Jan 2013 18:20:38 +0000
Subject: [docs] [issue17042] Example in C-API memory management doc has
	confusing	order
Message-ID: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za>


New submission from Eric Snow:

In http://docs.python.org/dev/c-api/memory.html#examples:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
char *buf1 = PyMem_New(char, BUFSIZ);
char *buf2 = (char *) malloc(BUFSIZ);
char *buf3 = (char *) PyMem_Malloc(BUFSIZ);
...
PyMem_Del(buf3);  /* Wrong -- should be PyMem_Free() */
free(buf2);       /* Right -- allocated via malloc() */
free(buf1);       /* Fatal -- should be PyMem_Del()  */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is there a good reason to have the second set of 3 lines in the opposite order as the first three?  At first I missed that they were in a different order and thought there was an error in the example.  If there's no good reason for the order, it would be worth fixing.  If there is a good reason,  a comment in the example would help.  Either way I'd be glad to patch it (will go ahead with fixing the ordering later today if no one does it first).

----------
assignee: docs at python
components: Documentation
messages: 180697
nosy: docs at python, eric.snow
priority: low
severity: normal
stage: needs patch
status: open
title: Example in C-API memory management doc has confusing order
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Jan 26 19:36:11 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 26 Jan 2013 18:36:11 +0000
Subject: [docs] [issue17042] Example in C-API memory management doc has
	confusing	order
In-Reply-To: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za>
Message-ID: <1359225371.57.0.0497750080939.issue17042@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Please don't change this: It's a common pattern in C to undo memory
allocations in the opposite order.

----------
nosy: +skrah

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

From report at bugs.python.org  Sat Jan 26 19:42:00 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Jan 2013 18:42:00 +0000
Subject: [docs] [issue17042] Example in C-API memory management doc has
	confusing	order
In-Reply-To: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za>
Message-ID: <1359225720.81.0.0734362721838.issue17042@psf.upfronthosting.co.za>


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


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

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

From simonhayward at gmail.com  Sat Jan 26 19:43:50 2013
From: simonhayward at gmail.com (Simon Hayward)
Date: Sat, 26 Jan 2013 18:43:50 +0000
Subject: [docs] Exponential in python
In-Reply-To: <CA+8ZfWsi1wyS6gc3MTW79YnCica-WEdOypWipLMW4vDVShUXRw@mail.gmail.com>
References: <CA+8ZfWsi1wyS6gc3MTW79YnCica-WEdOypWipLMW4vDVShUXRw@mail.gmail.com>
Message-ID: <CAPiJWbo4BBC4F399Z-HksUiSTd2fC_EH2ohKZff0JePgcfx6Hg@mail.gmail.com>

On 15 January 2013 21:44, marsel caka <marselcaka at gmail.com> wrote:
> Hi,
> i'm a student of Milan University and i am looking a tutorial of python.My
> python version is 3.3.
> When i do -2*-2 it's give me 4 but when i do -2**2 give me -4, i'm doing
> same thing in two examples but with different result. This happen in all
> python version or only in mine?
> Thank You
>
> --
>
> marsel caka
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>

Operator precedence
(http://docs.python.org/3/reference/expressions.html#operator-precedence)

You are doing this:
>>> -(2**2)
4

Whereas you may want this:
>>> (-2)**2
-4


-- 
Simon

From report at bugs.python.org  Sat Jan 26 19:49:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Jan 2013 18:49:10 +0000
Subject: [docs] [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1359226150.53.0.987851989118.issue16802@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch

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

From sandro.tosi at gmail.com  Sat Jan 26 23:13:19 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 26 Jan 2013 23:13:19 +0100
Subject: [docs] My first bug! (I think)
In-Reply-To: <CAA6AbJjwF5ufPe_MNUg59LpfaUFco4GjEkgdA+gzQJ8Zf9NHcg@mail.gmail.com>
References: <CAA6AbJjwF5ufPe_MNUg59LpfaUFco4GjEkgdA+gzQJ8Zf9NHcg@mail.gmail.com>
Message-ID: <CAB4XWXyGXs9==WwKZoytuGaETj_x2NYnfYXRyosOWOnuX538XA@mail.gmail.com>

Hello Philip,
thanks for your email.

On Sat, Jan 26, 2013 at 12:56 AM, Philip Szalwinski
<pszalwinski at gmail.com> wrote:
> Hi!
>
> I was reading through the Python docs looking at the section on strings at
> http://docs.python.org/2/tutorial/introduction.html#strings and it seems
> like the last line in the first terminal box (is that what that is called?)
> is printed incorrectly.

as a personal suggestion, just try the code :)

> Instead of:
>>>> '"Isn\'t," she said.'
> '"Isn\'t," she said.'

this is the correct output:

$ python
Python 2.7.3 (default, Sep  9 2012, 17:41:34)
[GCC 4.7.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> '"Isn\'t," she said.'
'"Isn\'t," she said.'
>>>

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

From sandro.tosi at gmail.com  Sat Jan 26 23:32:24 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 26 Jan 2013 23:32:24 +0100
Subject: [docs] doc bug: distutils doesnt do a good enough job of
 describing what distutils does
In-Reply-To: <CAPkRzQ7n2P0v-=bEoy=zO++vz4gzY5N4j+TtWATc6FkRZAPxiQ@mail.gmail.com>
References: <CAPkRzQ7n2P0v-=bEoy=zO++vz4gzY5N4j+TtWATc6FkRZAPxiQ@mail.gmail.com>
Message-ID: <CAB4XWXxijkpP2aSK1Yh1HWpHaPmjp9EjO7PMtJDhisW-2387aw@mail.gmail.com>

Hello Colton,
thanks for your email

On Fri, Jan 25, 2013 at 5:06 PM, Colton Phillips
<coltonjphillips at gmail.com> wrote:
> its not immediately clear.

Any suggestions on how to improve it?

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

From sandro.tosi at gmail.com  Sat Jan 26 23:33:18 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 26 Jan 2013 23:33:18 +0100
Subject: [docs] bug
In-Reply-To: <CAApLAKB-GxZJVXNBNwQVcmHQ1GRn-S1+qm_-ZMdU5XJ0duGWLQ@mail.gmail.com>
References: <CAApLAKB-GxZJVXNBNwQVcmHQ1GRn-S1+qm_-ZMdU5XJ0duGWLQ@mail.gmail.com>
Message-ID: <CAB4XWXzJnBs-87gR26yRR+NTO2_pOzT1SZ8yNHgwocLHsXnFTw@mail.gmail.com>

Hello Ali,
this mailing list is about bugs/enhancements to CPython documentation,
and your email doesn't fit this description. I'd suggest to contact a
user support forum, such as
http://mail.python.org/mailman/listinfo/python-list

Regards,
Sandro

On Fri, Jan 25, 2013 at 10:48 AM, ali mostafavi
<a.hr.mostafavi at gmail.com> wrote:
> hi!
> i found a bug in python 2.7.3
> if we make a list like this:
> a = [[0]*3]*3
> then change the a[y][x] like this:
> a[1][1] = 1
> the whole column changes. the result would be:
> [[0,1,0],[0,1,0],[0,1,0]]
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



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

From sandro.tosi at gmail.com  Sat Jan 26 23:44:21 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 26 Jan 2013 23:44:21 +0100
Subject: [docs] 'that' vs. 'which'
In-Reply-To: <CAN76RuwBTZCF6-C5qR-CQ+54swViY1A9HjT_0Uu7cMHvxGAskg@mail.gmail.com>
References: <CAN76RuwBTZCF6-C5qR-CQ+54swViY1A9HjT_0Uu7cMHvxGAskg@mail.gmail.com>
Message-ID: <CAB4XWXzvhQ1oCs7EffM_2H7c_KKsDwwAeu0HH5iXDHsBiNehww@mail.gmail.com>

Hello Larry,
thanks for your email.

On Sun, Jan 20, 2013 at 11:37 PM, Larry Anglin <larry at staff.htcomp.net> wrote:
> The word 'which' is used incorrectly extensively in the documentation.  Even
> the page that (not which) describes how to submit a documentation bug report
> has it used in correctly.

Many of us are not native speakers and thus we would love to receive
fix for things like this.

Do you think it's possible for you to identify all those occurrences
where 'which' needs to be replaced with 'that'? that would improve the
overall quality of the documentation. Ideally, a patch against our
documentation (as described at http://docs.python.org/devguide/) would
be lovely.

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

From sandro.tosi at gmail.com  Sat Jan 26 23:57:57 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 26 Jan 2013 23:57:57 +0100
Subject: [docs] Documentation Bug
In-Reply-To: <C336636340DE490EB2DAD15F41B37B89@Apollo>
References: <C336636340DE490EB2DAD15F41B37B89@Apollo>
Message-ID: <CAB4XWXyWfT+-6kC5icHmLRCQZO-h9MR0MPPC3Cgc_ZcX_TQvuw@mail.gmail.com>

Hello John,
thanks for your email.

On Mon, Jan 21, 2013 at 2:48 AM, John Heselton <leo_one at telus.net> wrote:
> Gentlemen:
>
>   I believe that there is an incorrect statement in the documentation at
> paragraph 4.6 where:
>
>   f(100) = fib2(100)
>
>   should be:
>
>   f = fib2

can you specify what is the document you're seeing (its URL for
example)? If I look at
http://docs.python.org/2/tutorial/controlflow.html#defining-functions
I can see

f100 = fib2(100)

is used.

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 Jan 26 23:58:35 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 26 Jan 2013 22:58:35 +0000
Subject: [docs] [issue17042] Example in C-API memory management doc has
	confusing	order
In-Reply-To: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za>
Message-ID: <1359241115.15.0.427047283219.issue17042@psf.upfronthosting.co.za>


Eric Snow added the comment:

Thanks for clarifying, Stefan.  Are you opposed to a comment in the example?

----------

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

From sandro.tosi at gmail.com  Sun Jan 27 00:00:54 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 27 Jan 2013 00:00:54 +0100
Subject: [docs] Python doesn't show time.now
In-Reply-To: <CA+BHdEnw=kxB89QK5TfgHdUXFocUtb+GaShdPhOgMeFsF-gPog@mail.gmail.com>
References: <CA+BHdEnw=kxB89QK5TfgHdUXFocUtb+GaShdPhOgMeFsF-gPog@mail.gmail.com>
Message-ID: <CAB4XWXz-S1zSto3a3-ywX=m7cgtt0fozLJcg5mC9kYATL74r_w@mail.gmail.com>

Hello Abdul,
this mailing list is about bugs/enhancements to CPython documentation,
and your email doesn't fit this description. I'd suggest to contact a
user support forum, such as
http://mail.python.org/mailman/listinfo/python-list

Regards,
Sandro

On Tue, Jan 22, 2013 at 5:03 AM, Abdul J. <ajbozdar at gmail.com> wrote:
> Hello,
>
> Here is the problem which I am facing. I do not have any kind of suggestion
> as I am a student.
>
> Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on
> win32
> Type "copyright", "credits" or "license()" for more information.
>
> from datetime import datetime
> now = datetime.now()
> print now
> 2013-01-22 11:22:53.503000
> print now
> 2013-01-22 11:22:53.503000
> print now
> 2013-01-22 11:22:53.503000
>
> This is what along with results. I am worried what does meant by default
> Apr. 20th. Isn't something wrong there?
>
>
> You can see, "Python do not show date and time with now function". I am
> using Python IDLE Shell and I just downloaded and installed. It also shows
> "default Apr. 20th". I do not understand this.
>
>
> Thank you,
>
> Abdul Jabbar
>
> Southeast University Nanjing
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



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

From sandro.tosi at gmail.com  Sun Jan 27 00:25:09 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 27 Jan 2013 00:25:09 +0100
Subject: [docs] Typo
In-Reply-To: <CAPbDKXyXnk0Uaf=wqqy1z2nB+t9BtMcsbksSEjvGzXDVR82uzw@mail.gmail.com>
References: <CAPbDKXyXnk0Uaf=wqqy1z2nB+t9BtMcsbksSEjvGzXDVR82uzw@mail.gmail.com>
Message-ID: <CAB4XWXwUtxJdXfuCC3r3Bot-_wc+_OW-1Z0_B16jE9Xe6vuPLQ@mail.gmail.com>

Hello Dmitry,
thanks for your email.

On Mon, Jan 14, 2013 at 8:28 AM, Dmitry Northerner <acmeros at gmail.com> wrote:
> I've found a little typo on the page
> http://docs.python.org/2/reference/compound_stmts.html#try
>
> If finally is present, it specifies a ?cleanup? handler. The try clause is
> executed, including any except and else clauses. If an exception occurs in
> any of the clauses and is not handled, the exception is temporarily saved.
> The finally clause is executed. If there is a saved exception, it is
> re-raised at the end of the finally clause. If the finally clause raises
> another exception or executes a return or breakstatement, the saved
> exception is !!!dicarded!!!:  (I guess, here should be - discarded)

I've just fixed it with the changeset 43084fa2577c .

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

From sandro.tosi at gmail.com  Sun Jan 27 00:34:02 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 27 Jan 2013 00:34:02 +0100
Subject: [docs] typo in Python 3.3 section 4.6.6 on range
In-Reply-To: <CAOaxTE+-cXscRZfwV00x03eKFUN9G6G5vVapgmtJXDXN=gmsMg@mail.gmail.com>
References: <CAOaxTE+-cXscRZfwV00x03eKFUN9G6G5vVapgmtJXDXN=gmsMg@mail.gmail.com>
Message-ID: <CAB4XWXy+_K_r+seTYrJnKL_VGK52WrqupwP11pivq9sN1mHn5Q@mail.gmail.com>

Hello Andrew,
Thanks for your email.

On Sun, Jan 20, 2013 at 3:07 AM, Andrew Harrington <aharrin at luc.edu> wrote:
> You have "meant"  where it could be "meet" or maybe better "satisfy".

i've just fixed it for the 3.3 and default branches.

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  Sun Jan 27 00:55:23 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 26 Jan 2013 23:55:23 +0000
Subject: [docs] [issue17042] Example in C-API memory management doc has
	confusing	order
In-Reply-To: <1359241115.15.0.427047283219.issue17042@psf.upfronthosting.co.za>
Message-ID: <20130126235525.GA17792@sleipnir.bytereef.org>


Stefan Krah added the comment:

Moderately opposed, yes. PyMem_Malloc()/PyMem_Free() and PyMem_New()/PyMem_Del()
are already explained in depth above.

----------

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

From report at bugs.python.org  Sun Jan 27 01:14:02 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 27 Jan 2013 00:14:02 +0000
Subject: [docs] [issue17042] Example in C-API memory management doc has
	confusing	order
In-Reply-To: <1359224437.99.0.267409459887.issue17042@psf.upfronthosting.co.za>
Message-ID: <1359245642.37.0.104025259976.issue17042@psf.upfronthosting.co.za>


Eric Snow added the comment:

Sorry, I'd meant something like this:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
char *buf1 = PyMem_New(char, BUFSIZ);
char *buf2 = (char *) malloc(BUFSIZ);
char *buf3 = (char *) PyMem_Malloc(BUFSIZ);
...
/* in reverse order */
PyMem_Del(buf3);  /* Wrong -- should be PyMem_Free() */
free(buf2);       /* Right -- allocated via malloc() */
free(buf1);       /* Fatal -- should be PyMem_Del()  */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This will help if someone does not know the common pattern.

----------

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

From report at bugs.python.org  Sun Jan 27 01:31:19 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 27 Jan 2013 00:31:19 +0000
Subject: [docs] [issue17045] Improve C-API doc for PyTypeObject
In-Reply-To: <1359245485.06.0.557532055897.issue17045@psf.upfronthosting.co.za>
Message-ID: <1359246679.88.0.447997645067.issue17045@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, ezio.melotti
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jan 27 02:15:59 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 27 Jan 2013 01:15:59 +0000
Subject: [docs] [issue13997] Clearly explain the bare minimum Python 3 users
	should	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1359249358.92.0.834195796959.issue13997@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

What's the status of this?

Issue #4153 might also be related.

----------

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

From report at bugs.python.org  Sun Jan 27 03:06:15 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 27 Jan 2013 02:06:15 +0000
Subject: [docs] [issue17045] Improve C-API doc for PyTypeObject
In-Reply-To: <1359245485.06.0.557532055897.issue17045@psf.upfronthosting.co.za>
Message-ID: <1359252374.62.0.209814806191.issue17045@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's an updated patch after feedback.  Thanks Ezio!

----------
Added file: http://bugs.python.org/file28865/typeobj-doc.diff

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

From report at bugs.python.org  Sun Jan 27 03:06:30 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 27 Jan 2013 02:06:30 +0000
Subject: [docs] [issue17045] Improve C-API doc for PyTypeObject
In-Reply-To: <1359245485.06.0.557532055897.issue17045@psf.upfronthosting.co.za>
Message-ID: <1359252390.68.0.246623892734.issue17045@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file28864/typeobj-doc.diff

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

From report at bugs.python.org  Sun Jan 27 06:08:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Jan 2013 05:08:02 +0000
Subject: [docs] [issue13997] Clearly explain the bare minimum Python 3 users
	should	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1359263282.18.0.947436932641.issue13997@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Current status:

#14015 is still valid (i.e. surrogateescape is not well documented)
#4153: the Unicode HOWTO still covers more than the bare minimum people need to know
Ned Batchelder's "Pragmatic Unicode" is one of the best intros to the topic I have seen: http://nedbatchelder.com/text/unipain.html

My full notes on the topic, which I'm still happy with as a "bare minimum Python 3 users should know about Unicode" are available at http://python-notes.boredomandlaziness.org/en/latest/python3/text_file_processing.html

----------

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

From report at bugs.python.org  Sun Jan 27 09:07:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Jan 2013 08:07:10 +0000
Subject: [docs] [issue17047] Fix double double words words
Message-ID: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In additional to changeset 07488c3c85f1, here are yet some possible word duplications:

Lib/_pyio.py:306:        Change the stream position to byte offset offset. offset is
Lib/concurrent/futures/_base.py:520:            fn: A callable that will take take as many arguments as there are
Lib/tkinter/__init__.py:3116:        have the same start and and end line as the parent widget, but
Lib/tkinter/tix.py:149:        """Locates a bitmap file of the name name.xpm or name in one of the
Lib/tkinter/tix.py:160:        """Locates an image file of the name name.xpm, name.xbm or name.ppm
Lib/lib2to3/pgen2/grammar.py:23:    """Pgen parsing tables tables conversion class.
Lib/lib2to3/pgen2/grammar.py:48:                     states, each state is is a list of arcs, and each
Lib/email/_header_value_parser.py:1866:    We allow anything except the excluded characters, but but if we find any
Lib/email/_encoded_words.py:17:# to to the CTE tables, but YAGNI for now.  'q' is Quoted Printable, 'b' is
Lib/email/mime/text.py:29:        # If no _charset was specified, check to see see if there are non-ascii
Lib/email/policy.py:26:    The API extensions enabled by this this policy are currently provisional.
Lib/unittest/mock.py:1420:    attributes that your production code creates at runtime. It is off by by
Lib/test/test_socket.py:845:        # Try udp, but don't barf it it doesn't exist
Lib/test/test_descrtut.py:322:getx() and and setx():
Lib/test/test_decimal.py:4495:        # Do operations and check that it didn't change change internal objects.
Lib/distutils/command/install.py:266:            raise DistutilsOptionError("can't combine user with with prefix/"
Lib/distutils/tests/test_install.py:168:        # can't combine user with with prefix/exec_prefix/home or
python-gdb.py:1466:        '''Is this frame "collect" within the the garbage-collector?'''
Include/pyport.h:884: * also also takes care of Apple's universal builds.
Modules/_io/iobase.c:79:    "Change the stream position to byte offset offset. offset is\n"
Modules/_heapqmodule.c:91:    /* The leaf at pos is empty now.  Put newitem there, and and bubble
Modules/_heapqmodule.c:431:    /* The leaf at pos is empty now.  Put newitem there, and and bubble
Modules/socketmodule.c:3547:           ensures that that doesn't happen. */
Modules/binascii.c:41:** I have attempted to break with this tradition, but I guess that that
Modules/posixmodule.c:9747:Return the value of extended attribute attribute on path.\n\
Modules/posixmodule.c:9825:Set extended attribute attribute on path to value.\n\
Modules/posixmodule.c:9890:Remove extended attribute attribute on path.\n\
PC/msvcrtmodule.c:133:Create a C runtime file descriptor from the file handle handle. The\n\
Doc/c-api/intro.rst:436::c:func:`sum_sequence` example above.  It so happens that that example doesn't
Doc/c-api/long.rst:206:   Return a C :c:type:`size_t` representation of of *pylong*.  *pylong* must be
Doc/c-api/long.rst:218:   Return a C :c:type:`unsigned PY_LONG_LONG` representation of of *pylong*.
Doc/library/stdtypes.rst:2640:      Cast 1D/unsigned char to to 2D/unsigned long::
Doc/library/email.policy.rst:330:      line breaks and and any (RFC invalid) binary data it may contain.
Doc/library/unittest.mock.rst:991:    attributes that your production code creates at runtime. It is off by by
Doc/whatsnew/3.3.rst:1539:New attribute attribute :data:`multiprocessing.Process.sentinel` allows a
Lib/idlelib/extend.txt:57:Here is a complete example example:
Lib/idlelib/extend.txt:75:used to to configure the loading of extensions and to establish key (or, more

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 180747
nosy: docs at python, ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix double double words words
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/issue17047>
_______________________________________

From report at bugs.python.org  Sun Jan 27 09:47:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Jan 2013 08:47:25 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1359276444.97.0.31319331223.issue17047@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And yet some:

Mac/README:40:  Create a universal binary build of of Python. This can be used with both
Misc/HISTORY:781:  some also support accepting an open file descriptor in place of of a path
Misc/HISTORY:1415:  trying to set a non-binary value as a comment is now now raised at the time
Misc/HISTORY:3055:  environment after Distutils set it.  Instead, have Distutils set the the
Tools/pybench/README:6:     Extendable suite of of low-level benchmarks for measuring

----------

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

From ericsnowcurrently at gmail.com  Sun Jan 27 02:14:58 2013
From: ericsnowcurrently at gmail.com (ericsnowcurrently at gmail.com)
Date: Sun, 27 Jan 2013 01:14:58 -0000
Subject: [docs] Improve C-API doc for PyTypeObject (issue 17045)
Message-ID: <20130127011458.14471.57142@psf.upfronthosting.co.za>

Thanks for the review, Ezio.  This really helps.  This page is packed
with information and I'm just hoping to distill some of the key
information here.  I'll take all the help I can get to get the markup
right and stay consistent with the docs as a whole, so thanks!


http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst
File Doc/c-api/typeobj.rst (right):

http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode29
Doc/c-api/typeobj.rst:29: | :c:member:`tp_name <PyTypeObject.tp_name>`  
                  |     | char *                 |
On 2013/01/27 01:30:46, ezio.melotti wrote:
> You can use :c:member:`~PyTypeObject.tp_name` instead.

Good tip.

http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode30
Doc/c-api/typeobj.rst:30:
+----------------------------------------------------------------+-----+------------------------+
On 2013/01/27 01:30:46, ezio.melotti wrote:
> Unless you want to rewrap to 80 chars and need to have more than one
line in the
> same cell, you can use the simpler syntax for tables, and get rid of
all the "|"
> lines (use a space to separate columns) and the "-" lines between rows
(you have
> to keep the ones around the header though).

I was going to do that, but was unsure of making it work with spaces in
a single cell.  Can you simply quote the cell contents or something?

http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode123
Doc/c-api/typeobj.rst:123: Names in square brackets are for internal use
only.
On 2013/01/27 01:30:46, ezio.melotti wrote:
> This is usually done via notes that are then listed at the end of the
table.

Good point.

> In
> this specific case it could be even better to move the
deprecated/internal
> methods in one or two separate tables/lists.

For a quick reference, as I hope the table will serve, I figured it
would be good to have some visual indicator right in the table. 
However, it could just as easily be an extra column or two.  If you
think that's not worth it, I'm open to what you are suggesting, pushing
that info off into a separate section that need not be very big.

http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode125
Doc/c-api/typeobj.rst:125: Inh:
On 2013/01/27 01:30:46, ezio.melotti wrote:
> This should be expanded a bit to clarify that it refers to the column
and what
> it means.

Agreed.

http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode131
Doc/c-api/typeobj.rst:131: ? - it's complicated; see the slot's
description.
On 2013/01/27 01:30:46, ezio.melotti wrote:
> This could be done with notes as well.

Will do.

http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode166
Doc/c-api/typeobj.rst:166: **Inheritance:**
On 2013/01/27 01:30:46, ezio.melotti wrote:
> This could be on the same line.
> I also wonder if there's a better way to mark this.  The markup you
are used is
> not used anywhere else in the docs AFAIK, and it might result a bit
inconsistent
> with the rest.

I'm totally open to suggestions here.  I wanted to have a uniform marker
for inheritance (and default) in the doc for each type slot -- one that
visually stands out, but not drastically.  However, the marker doesn't
need to be a reference of any kind.  Using a bold word was the simplest
thing I could think of.

http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode384
Doc/c-api/typeobj.rst:384: Group: :attr:`tp_getattr`,
:attr:`tp_getattro`
On 2013/01/27 01:30:46, ezio.melotti wrote:
> Mayne you can use a double signature instead of this (assuming that it
makes
> sense to do so).

I wasn't thinking of this as more than plain text, but only because I
didn't see it as more than a simple marker of inheritance groups.  I'm
fine with more if you have something in mind.

As you've seen, I haven't spent much time editing the docs, so my ReST
is pretty basic and my knowledge of how we do it in the docs is really
limited.  So I'm grateful for this feedback.  :)

http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode558
Doc/c-api/typeobj.rst:558: This field does not have a default.
On 2013/01/27 01:30:46, ezio.melotti wrote:
> Instead of keep repeating it, you could add at the top a line that
says
> something like "if no default it's specified the field has no
default".

Good idea.

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

From bgailer at gmail.com  Sun Jan 27 16:07:14 2013
From: bgailer at gmail.com (bob gailer)
Date: Sun, 27 Jan 2013 10:07:14 -0500
Subject: [docs] bug
In-Reply-To: <CAApLAKB-GxZJVXNBNwQVcmHQ1GRn-S1+qm_-ZMdU5XJ0duGWLQ@mail.gmail.com>
References: <CAApLAKB-GxZJVXNBNwQVcmHQ1GRn-S1+qm_-ZMdU5XJ0duGWLQ@mail.gmail.com>
Message-ID: <510542A2.8080602@gmail.com>

On 1/25/2013 4:48 AM, ali mostafavi wrote:
> hi!
> i found a bug in python 2.7.3
> if we make a list like this:
> a = [[0]*3]*3
> then change the a[y][x] like this:
> a[1][1] = 1
> the whole column changes. the result would be:
> [[0,1,0],[0,1,0],[0,1,0]]

Please be very sure you found a bug before reporting one.
a = [[0]*3 # creates a list of 3 zeros
b = a*3 # is the equivalent of b = [a, a, a]
b[1][1] = 1 changes a[1] to 1

I presume you expected [[0,0,0],[0,1,0],[0,0,0]]

There is a VERY useful tool at http://www.pythontutor.com/visualize.html#

I entered my code so you can run it and see the results. Use the link below.

http://www.pythontutor.com/visualize.html#code=a+%3D+%5B0%5D*3%0Ab+%3D+%5Ba%5D*3%0Ab%5B1%5D%5B1%5D+%3D+1%0A&mode=display&cumulative=false&heapPrimitives=false&drawParentPointers=false&textReferences=false&py=2&curInstr=3

-- 
Bob Gailer
919-636-4239
Chapel Hill NC


From ezio.melotti at gmail.com  Sun Jan 27 17:39:40 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sun, 27 Jan 2013 16:39:40 -0000
Subject: [docs] Improve C-API doc for PyTypeObject (issue 17045)
Message-ID: <20130127163940.6743.23262@psf.upfronthosting.co.za>

On 2013/01/27 02:14:57, eric.snow wrote:
> I was going to do that, but was unsure of making it work with spaces
in a single
> cell.  Can you simply quote the cell contents or something?
> 

What do you mean with "quote the cell contents"?

>
http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode123
> Doc/c-api/typeobj.rst:123: Names in square brackets are for internal
use only.
> On 2013/01/27 01:30:46, ezio.melotti wrote:
> > This is usually done via notes that are then listed at the end of
the table.
> 
> Good point.
> 

See http://docs.python.org/3/library/stdtypes.html#typesnumeric for an
example of this.

> > In
> > this specific case it could be even better to move the
deprecated/internal
> > methods in one or two separate tables/lists.
> 
> For a quick reference, as I hope the table will serve, I figured it
would be
> good to have some visual indicator right in the table.  However, it
could just
> as easily be an extra column or two.  If you think that's not worth
it, I'm open
> to what you are suggesting, pushing that info off into a separate
section that
> need not be very big.
> 

Since they are deprecated/internal, users shouldn't care about them, so
having them in the main table will just make it more difficult to
browse.
See for example
http://docs.python.org/3/library/unittest.html#assert-methods and
http://docs.python.org/3/library/unittest.html#deprecated-aliases
(except that here you can put the two tables closer).

>
http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode166
> Doc/c-api/typeobj.rst:166: **Inheritance:**
> On 2013/01/27 01:30:46, ezio.melotti wrote:
> > This could be on the same line.
> > I also wonder if there's a better way to mark this.  The markup you
are used
> is
> > not used anywhere else in the docs AFAIK, and it might result a bit
> inconsistent
> > with the rest.
> 
> I'm totally open to suggestions here.  I wanted to have a uniform
marker for
> inheritance (and default) in the doc for each type slot -- one that
visually
> stands out, but not drastically.  However, the marker doesn't need to
be a
> reference of any kind.  Using a bold word was the simplest thing I
could think
> of.
>

The simplest option is to always list this these in the last paragraph. 
People will find this easily even without special markups.  If you want
some extra markup, italic could be used instead of bold too (but I'll
have to see how it looks).

>
http://bugs.python.org/review/17045/diff/7222/Doc/c-api/typeobj.rst#newcode384
> Doc/c-api/typeobj.rst:384: Group: :attr:`tp_getattr`,
:attr:`tp_getattro`
> On 2013/01/27 01:30:46, ezio.melotti wrote:
> > Mayne you can use a double signature instead of this (assuming that
it makes
> > sense to do so).
> 
> I wasn't thinking of this as more than plain text, but only because I
didn't see
> it as more than a simple marker of inheritance groups.  I'm fine with
more if
> you have something in mind.
> 

The idea is to document the group -- a short note could be added to
mention that the all the slots are inherited together.  If the single
slots have separate documentations what you did might be fine.

(P.S. you can also reply to the individual comments in the diff view)


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

From report at bugs.python.org  Sun Jan 27 17:48:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 27 Jan 2013 16:48:13 +0000
Subject: [docs] [issue13997] Clearly explain the bare minimum Python 3 users
	should	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1359305293.68.0.0677563146352.issue13997@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Maybe the Unicode HOWTO could be reorganized so that it first introduces the bare minimum and then expands the concepts for whoever wants to know more?
Or should we have a "basic" and an "advanced" Unicode HOWTO?

----------

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

From report at bugs.python.org  Sun Jan 27 21:49:40 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Jan 2013 20:49:40 +0000
Subject: [docs] [issue13997] Clearly explain the bare minimum Python 3 users
	should	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1359319780.04.0.132184059215.issue13997@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I basically agree with Ezio. The doc currently starts with

Introduction to Unicode
History of Character Codes
...

It ends with

Tips for Writing Unicode-aware Programs.
  ...
  The most important tip is:
    Software should only work with Unicode strings internally, decoding the input data as soon as possible and encoding the output only at the end.

I think the how-to should *start* with that general principle and continue with the specific task-based how-tos from the thread. This will tell people who at least vaguely know the following material how to get going in a practical manner.

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

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

From report at bugs.python.org  Sun Jan 27 22:00:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 27 Jan 2013 21:00:29 +0000
Subject: [docs] [issue13997] Clearly explain the bare minimum Python 3 users
	should	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1359320429.65.0.294960603039.issue13997@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

If we agree on this, I can propose a patch in #4153 and this issue can be closed.

----------

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

From sandro.tosi at gmail.com  Mon Jan 28 00:09:09 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Mon, 28 Jan 2013 00:09:09 +0100
Subject: [docs] sorted() "Sorting HowTo" Link
In-Reply-To: <CAE+1BV226Ez09zAWc9HSva4OBfUYkuU5=wT+MmFZjs6PFrsANw@mail.gmail.com>
References: <CAE+1BV226Ez09zAWc9HSva4OBfUYkuU5=wT+MmFZjs6PFrsANw@mail.gmail.com>
Message-ID: <CAB4XWXwW0SOOxHgNjf1=CTxd0__arpK09egEX7bdU161j8wfYg@mail.gmail.com>

Hello Tyler,

On Fri, Jan 18, 2013 at 7:12 PM, Tyler Birgen <masterteedy at gmail.com> wrote:
> There seems to be a broken link under the "sorted()" function documentation.
> Here is a direct link:
> http://docs.python.org/2/library/functions.html#sorted
>
> The link from the bottom of this function's documentation with the text
> "Sorting HowTo" tries to go here:
> http://wiki.python.org/moin/HowTo/Sorting/
>
> It seems that link is broken.  I believe the correct link to be:
> http://docs.python.org/2/howto/sorting.html

Now the wiki is back online (there was a security breach and so it was
brought offline while recovering) but the wiki page and the
documentation page looks quite the same; I don't know if there's a
reason to keep also the wiki page, else i'm in favor of changing the
inter-documentation links to point to sorting.html. But I'd like to
hear first from someone that might know the story behind those pages.

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  Mon Jan 28 01:24:17 2013
From: report at bugs.python.org (Hobs)
Date: Mon, 28 Jan 2013 00:24:17 +0000
Subject: [docs] [issue17057] Data model documentation grammar
Message-ID: <1359332657.03.0.048046509713.issue17057@psf.upfronthosting.co.za>


New submission from Hobs:

New-style and old-style class expalanation in the datamodel section has minor grammatical errors and one minor ambiguity that could be improved.

http://docs.python.org/2/reference/datamodel.html#new-style-and-classic-classes

* "independently of" should always be "indepenent of"
* single hyphens (-) should be double-hyphens (--) for an m-dash
* "flavour" should be "flavor" (used 100x more often in docs.python)
* "only the symantics of..." is ambiguous. can't tell if 'only' modifies 'symantics' or 'new-style classes'?

----------
assignee: docs at python
components: Documentation
files: datamodel-reference-docs.patch
keywords: patch
messages: 180812
nosy: Hobson.Lane, docs at python
priority: normal
severity: normal
status: open
title: Data model documentation grammar
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file28876/datamodel-reference-docs.patch

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

From report at bugs.python.org  Mon Jan 28 02:50:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Jan 2013 01:50:02 +0000
Subject: [docs] [issue13997] Clearly explain the bare minimum Python 3 users
	should	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1359337802.02.0.514190642243.issue13997@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Include a couple of "See Also" links out to my essay and Ned's article and that sounds good to me.

(Assuming I've adjusted the DNS settings correctly, this alternate URL for my essay should start working soon: http://python-notes.curiousefficiency.org/en/latest/python3/text_file_processing.html

----------

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

From report at bugs.python.org  Mon Jan 28 03:20:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 28 Jan 2013 02:20:15 +0000
Subject: [docs] [issue13997] Clearly explain the bare minimum Python 3 users
	should	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1359339615.47.0.255399981167.issue13997@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

OK, I'm going to close this then.

I'll take a look at the links and see if what they say can be included in the HOWTO.  As I mentioned in an earlier post I made a few talks about Unicode and encodings, so I will take some material from there too.  Depending on the final result we can then decide if and what additional links are necessary.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Unicode HOWTO up to date?

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

From report at bugs.python.org  Mon Jan 28 05:28:16 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 28 Jan 2013 04:28:16 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1359347296.59.0.705404095727.issue17047@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Note that sometimes duplicates are actually typos: in http://hg.python.org/cpython/rev/07488c3c85f1/#l4.1 for exemple I think the intent was to write ?that the? instead of ?the the?.

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

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

From report at bugs.python.org  Mon Jan 28 07:24:15 2013
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 28 Jan 2013 06:24:15 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1359354255.93.0.829790896682.issue17047@psf.upfronthosting.co.za>


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


----------
priority: normal -> low

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

From report at bugs.python.org  Mon Jan 28 22:15:46 2013
From: report at bugs.python.org (Carsten Klein)
Date: Mon, 28 Jan 2013 21:15:46 +0000
Subject: [docs] [issue17067] Examples in documentation for 3.x in 23.1.3.4.
	Deferred	translations are rather weak
Message-ID: <1359407746.0.0.0107296426233.issue17067@psf.upfronthosting.co.za>


New submission from Carsten Klein:

The examples for the topic presented are rather weak. In fact, they merely present do nothing replacements for an actually working, deferred localization mechanism or some sort of prototypical implementation thereof.

As such I propose that they be replaced with something more meaningful,
for example such as 


class DeferredTranslation(object):

    def __init__(self, message, ...):

        self.message = message

    def __str__(self):

        return gettext.translation(...).lgettext(self.message)


def _(message, ...):

    return DeferredTranslation(message, ...)


MSG = _('localized message')


Or something else along that way other than the currently presented examples :D

----------
assignee: docs at python
components: Documentation
messages: 180882
nosy: carsten.klein at axn-software.de, docs at python
priority: normal
severity: normal
status: open
title: Examples in documentation for 3.x in 23.1.3.4. Deferred translations are rather weak
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Jan 28 23:00:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Jan 2013 22:00:14 +0000
Subject: [docs] [issue17067] Examples in documentation for 3.x in 23.1.3.4.
	Deferred	translations are rather weak
In-Reply-To: <1359407746.0.0.0107296426233.issue17067@psf.upfronthosting.co.za>
Message-ID: <1359410414.84.0.129664893665.issue17067@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for your suggestion, but...

The example currently in the docs is exactly how we do deferred translation in the project I am currently working on.  Your example is much more complex, and I don't see the benefit of it.

Specifically, using the example in the docs you can easily mix deferred translations with non-deferred translations, which what you generally end up wanting to do in real code.  (You use deferred translation with strings that are defined at import time, as in the example, and non-deferred with strings that are computed at runtime.)

Perhaps there is a need for additional text about how this works in practice, including an example of switching the language dynamically during runtime.

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

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

From report at bugs.python.org  Mon Jan 28 23:01:28 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Jan 2013 22:01:28 +0000
Subject: [docs] [issue17067] Examples in documentation for 3.x in 23.1.3.4.
	Deferred	translations are rather weak
In-Reply-To: <1359407746.0.0.0107296426233.issue17067@psf.upfronthosting.co.za>
Message-ID: <1359410488.48.0.0227126596872.issue17067@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sorry, I didn't mean "computed at runtime", I meant defined in code where the _ call is *executed* at runtime, rather than at import time.

----------

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

From report at bugs.python.org  Tue Jan 29 00:36:37 2013
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 28 Jan 2013 23:36:37 +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: <1359416197.91.0.297648488627.issue16509@psf.upfronthosting.co.za>


Changes by Thomas Kluyver <takowl at gmail.com>:


----------
nosy: +takluyver

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

From sandro.tosi at gmail.com  Tue Jan 29 00:37:51 2013
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Tue, 29 Jan 2013 00:37:51 +0100
Subject: [docs] Typo in Python 2.7 docs for random.random
In-Reply-To: <50AC0474.3030504@tyrope.nl>
References: <50AC0474.3030504@tyrope.nl>
Message-ID: <CAB4XWXyXCDP8mh-qak9c5z-bagmZyfFL-HtE7ZMN8xsHktpndA@mail.gmail.com>

Hello Dimitri,
sorry for this late reply.

On Tue, Nov 20, 2012 at 11:30 PM, Dimitri Molenaars <tyrope at tyrope.nl> wrote:
> 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].

In mathematics, there's a syntax to express ranges without some of the
endpoints: http://en.wikipedia.org/wiki/Interval_(mathematics)#Excluding_the_endpoints

The why the range in the doc is expressed is to follow that notation.

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  Tue Jan 29 18:57:50 2013
From: report at bugs.python.org (Zearin)
Date: Tue, 29 Jan 2013 17:57:50 +0000
Subject: [docs] [issue17074] (docs) Consistent formatting of constants
Message-ID: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za>


New submission from Zearin:

When reading the docs, I noticed that the capitalization and formatting of the Python constants ``True``, ``False``, and ``None`` were inconsistent.

The attached patch contains a fix for all such occurrences under ``/Doc/library/``.

(I **think** I correctly made the patch.  I hardly ever make patches, so if I screwed up, let me know and I?ll see if I can get it right. ?)


Parent commit: 
9137e2d1c00c6906af206d1c9d217b15613bb1ed

----------
assignee: docs at python
components: Documentation
files: python_docs_constants.diff
keywords: patch
messages: 180918
nosy: docs at python, zearin
priority: normal
severity: normal
status: open
title: (docs) Consistent formatting of constants
versions: Python 2.7
Added file: http://bugs.python.org/file28897/python_docs_constants.diff

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

From report at bugs.python.org  Tue Jan 29 18:58:57 2013
From: report at bugs.python.org (Zearin)
Date: Tue, 29 Jan 2013 17:58:57 +0000
Subject: [docs] [issue17074] (docs) Consistent formatting of constants
In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za>
Message-ID: <1359482337.49.0.619021713409.issue17074@psf.upfronthosting.co.za>


Changes by Zearin <zearin at users.sourceforge.net>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Tue Jan 29 19:05:06 2013
From: report at bugs.python.org (Aaron Sherman)
Date: Tue, 29 Jan 2013 18:05:06 +0000
Subject: [docs] [issue17075] logging documentation for library cleanup
Message-ID: <1359482706.26.0.367132377172.issue17075@psf.upfronthosting.co.za>


New submission from Aaron Sherman:

This documentation states that libraries can turn off logging by adding a NullHandler:

http://docs.python.org/2/howto/logging.html#configuring-logging-for-a-library

This is not entirely true. It only holds true if the application which calls the library has not called basicConfig on the root logger. If it has, you get logs to both the root logger and the NullLogger, defeating the point of having added a NullLogger in the first place.

The correct way for a library to silence log messages is to both set a NullHandler and set propagate to false.

For an example of the behavior on the current docs, see:

  import logging
  import sys
  # Application configures its root logger
  logging.basicConfig(level=logging.DEBUG)
  
  # Library configures a NullLogger:
  logger = logging.getLogger('foo')
  logger.setLevel(logging.DEBUG)
  handler = logging.NullHandler()
  handler.setLevel(logging.DEBUG)
  logger.addHandler(handler)
  
  # Library then logs:
  logger.warning("BLAH")

This example is not terribly interesting, but the more interesting example is when the library configures a real log handler (e.g. in order to create a separate security log in an authorization module). In this case, the log messages will be sent to both the file log and the root logger by default, as long as any part of the application has configured the root logger.

IMHO, propagate should always be False for all new loggers, but at the very least the fact that it is True should be documented in the section on library logging...

----------
assignee: docs at python
components: Documentation
messages: 180919
nosy: ajs, docs at python
priority: normal
severity: normal
status: open
title: logging documentation for library cleanup
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan 29 19:27:56 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 29 Jan 2013 18:27:56 +0000
Subject: [docs] [issue17074] (docs) Consistent formatting of constants
In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za>
Message-ID: <1359484076.89.0.904596531521.issue17074@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

This has already been proposed in issue 15580.  By the way, you don't always want to replace "true" with ``True``.  The former has a different connotation/meaning which is boolean true rather than the object True.

----------
nosy: +chris.jerdonek
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> fix True/False/None reST markup

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

From report at bugs.python.org  Tue Jan 29 19:34:53 2013
From: report at bugs.python.org (Zearin)
Date: Tue, 29 Jan 2013 18:34:53 +0000
Subject: [docs] [issue17074] (docs) Consistent formatting of constants
In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za>
Message-ID: <1359484493.52.0.591112119429.issue17074@psf.upfronthosting.co.za>


Zearin added the comment:

Ah; I did look for dupes, but didn?t find it.  (So many issues?!)

Thanks for pointing me in the right direction.

> By the way, you don't always want to replace "true" with ``True``. 

The former has a different connotation/meaning which is boolean true =
rather than the object True.

Yes, I know.  I went through all the occurrences one by one, and I tried to take that into account.

*sigh* I guess it?s a moot point, now?

----

Got more to say on this subject, but I?ll do it in other issue.  Take care!

----------

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

From report at bugs.python.org  Tue Jan 29 19:45:01 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 29 Jan 2013 18:45:01 +0000
Subject: [docs] [issue17075] logging documentation for library cleanup
In-Reply-To: <1359482706.26.0.367132377172.issue17075@psf.upfronthosting.co.za>
Message-ID: <1359485101.24.0.00307093721047.issue17075@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> This documentation states that libraries can turn off logging by adding a NullHandler:

I don't think that's what the documentation says.  It says, "If for some reason you don?t want these messages printed *in the absence of any logging configuration* [my emphasis]....  If the library user configures logging for application use, presumably that configuration will add some handlers, and if levels are suitably configured then logging calls made in library code will send output to those handlers, as normal."

In other words, the documentation is acknowledging that logging won't get turned off if something else configures it.  This is the same as what you say further on:

> It only holds true if the application which calls the library has not called basicConfig on the root logger.

If there's some other part of the documentation that says otherwise, can you include a direct quote in the comment so we know what words you are referencing?

> The correct way for a library to silence log messages is to both set a NullHandler and set propagate to false.

This doesn't sound like good practice to me and isn't what the current docs were trying to say.

----------
nosy: +chris.jerdonek, vinay.sajip
status: open -> pending

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

From report at bugs.python.org  Tue Jan 29 19:48:07 2013
From: report at bugs.python.org (Zearin)
Date: Tue, 29 Jan 2013 18:48:07 +0000
Subject: [docs] [issue15580] fix True/False/None reST markup
In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>
Message-ID: <1359485287.28.0.154835908536.issue15580@psf.upfronthosting.co.za>


Zearin added the comment:

I recently attempted to enhance the documentation in #17074.  While I wasn?t linking all occurrences of True/False/None, I did mark them up as ``True``/``False``/``None``.  Additionally, I made sure that these were (when appropriate) capitalized.

I really disagree with the refusal to accept this issue.  Python is represented to the outside world through its documentation. As it is, there are inconsistencies in the capitalization and markup of constants.  

CONSTANTS!  

This isn?t exactly a nuanced part of the language.  Constants are dead-easy to spot, and they?re dead-easy to fix.  

This issue is **low-hanging fruit**.  

**Consistency** is also one of Python?s core values.  This is built right into the language itself --- as indentation-based scope.  The patch by chris.jerdonek helps make the documentation more consistent.  

I could understand if this isn?t the type of work you like doing.  If the inconsistency was identified, but no one was willing to do the work, **then** this might be considered an issue which ?cost[...] developer time that can better be spent elsewhere.?  

But that?s not the case.  Chris has already done the work.  

It?s low-hanging fruit, it improves Python?s image to the outside world, and it noticeably improves the readability (and usability) of the documentation.  

**Please** reconsider accepting this patch.

----------
nosy: +zearin

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

From report at bugs.python.org  Tue Jan 29 19:54:39 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 29 Jan 2013 18:54:39 +0000
Subject: [docs] [issue17074] (docs) Consistent formatting of constants
In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za>
Message-ID: <1359485679.07.0.368898881647.issue17074@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Yes, I know.  I went through all the occurrences one by one, and I tried to take that into account.

See issue 4945 for a discussion like this.  Might be relevant to what you have in mind.

----------

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

From report at bugs.python.org  Tue Jan 29 20:02:29 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 29 Jan 2013 19:02:29 +0000
Subject: [docs] [issue17074] (docs) Consistent formatting of constants
In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za>
Message-ID: <1359486149.46.0.423463859946.issue17074@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> This has already been proposed in issue 15580.

By the way, I should have said "something along the same lines."  Issue 15580 is about eliminating uses of :const:`None`, etc, whereas this targets a different case.  But it is similar in scope so the same discussion/reasons apply.

----------

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

From report at bugs.python.org  Tue Jan 29 20:04:21 2013
From: report at bugs.python.org (Zearin)
Date: Tue, 29 Jan 2013 19:04:21 +0000
Subject: [docs] [issue17074] (docs) Consistent formatting of constants
In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za>
Message-ID: <1359486261.35.0.388228873634.issue17074@psf.upfronthosting.co.za>


Zearin added the comment:

> By the way, I should have said "something along the same lines."  Issue 15580 is about eliminating uses of :const:`None`, etc, whereas this targets a different case.  But it is similar in scope so the same discussion/reasons apply.

Yep!  I read, and understood the difference.  

I still had 2? to add.  I?m kind of a nut for good documentation. ;)

----------

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

From report at bugs.python.org  Tue Jan 29 20:14:16 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jan 2013 19:14:16 +0000
Subject: [docs] [issue15580] fix True/False/None reST markup
In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>
Message-ID: <1359486856.41.0.596553517631.issue15580@psf.upfronthosting.co.za>


R. David Murray added the comment:

I prefer to have some of them be links and some of them be code markup.  That is, I think there is value in having some of them be links.  As Georg said, the devguide rule is more about it not being *necessary* to waste time marking them *all* up as constants.  Having some of them marked up as constants will be enough to lead a newbie to the documentation for them.

When writing new docs, I will typically mark them up as constants once or twice in the new docs, and make the remainder code markup.

----------

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

From report at bugs.python.org  Tue Jan 29 20:17:39 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jan 2013 19:17:39 +0000
Subject: [docs] [issue15580] fix True/False/None reST markup
In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>
Message-ID: <1359487059.53.0.905189670157.issue15580@psf.upfronthosting.co.za>


R. David Murray added the comment:

Note, by the way, that I apply the same rule to most link markup.  If I refer to, say, a module name in a paragraph or set of related paragraphs multiple times, I will typically only mark up the first occurrence as a :mod: link.  It's not a hard and fast rule, though: I go by feel as to what level of link markup seems appropriate.

----------

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

From report at bugs.python.org  Tue Jan 29 20:33:05 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 29 Jan 2013 19:33:05 +0000
Subject: [docs] [issue15580] fix True/False/None reST markup
In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>
Message-ID: <1359487985.26.0.549996546703.issue15580@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

It might be worth clarifying in the devguide then if True/False/etc shouldn't be treated differently from other things.  The current wording suggests that links shouldn't be used at all in those cases (e.g. "given that they?re fundamental to the language and should be known to any programmer").

----------

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

From report at bugs.python.org  Tue Jan 29 20:33:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jan 2013 19:33:57 +0000
Subject: [docs] [issue17075] logging documentation for library cleanup
In-Reply-To: <1359482706.26.0.367132377172.issue17075@psf.upfronthosting.co.za>
Message-ID: <1359488037.16.0.414873633339.issue17075@psf.upfronthosting.co.za>


R. David Murray added the comment:

Indeed.  The whole point of that section is to explain how the library can refrain from spewing unwanted logging *if the application doesn't care about logging*.  If the application does care (has configured logging), it would be wrong to block the logging.

I believe there is now a NullHandler or something similar set up by default, so I don't think this issue arises in Python3.

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

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

From report at bugs.python.org  Tue Jan 29 20:36:41 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Jan 2013 19:36:41 +0000
Subject: [docs] [issue17074] (docs) Consistent formatting of constants
In-Reply-To: <1359482269.16.0.953084487714.issue17074@psf.upfronthosting.co.za>
Message-ID: <1359488201.64.0.0755967280903.issue17074@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 29 20:37:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jan 2013 19:37:18 +0000
Subject: [docs] [issue15580] fix True/False/None reST markup
In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>
Message-ID: <1359488238.42.0.728169994793.issue15580@psf.upfronthosting.co.za>


R. David Murray added the comment:

True.  I disagree with the existing language, as I've indicated, but I'll leave it up to Georg as doc master.

----------

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

From report at bugs.python.org  Tue Jan 29 20:38:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Jan 2013 19:38:58 +0000
Subject: [docs] [issue15580] fix True/False/None reST markup
In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>
Message-ID: <1359488338.37.0.17660018534.issue15580@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jan 30 03:34:12 2013
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 30 Jan 2013 02:34:12 +0000
Subject: [docs] [issue8491] Need readline command and keybinding information
In-Reply-To: <1271879913.89.0.268262009322.issue8491@psf.upfronthosting.co.za>
Message-ID: <1359513252.14.0.0110766633569.issue8491@psf.upfronthosting.co.za>


Mitchell Model added the comment:

Ping. I just noticed that this is still unresolved in the Python 3.3 docs. This should be closed, with or without my suggested change.

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

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

From report at bugs.python.org  Wed Jan 30 07:39:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Jan 2013 06:39:29 +0000
Subject: [docs] [issue9536] defaultdict doc makes incorrect reference to
	__missing__	method
In-Reply-To: <1281106528.37.0.0435364267174.issue9536@psf.upfronthosting.co.za>
Message-ID: <1359527969.38.0.0916297149468.issue9536@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
status: pending -> open

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

From report at bugs.python.org  Wed Jan 30 10:05:10 2013
From: report at bugs.python.org (wohugb)
Date: Wed, 30 Jan 2013 09:05:10 +0000
Subject: [docs] [issue17081] documentation
Message-ID: <1359536710.85.0.764619753977.issue17081@psf.upfronthosting.co.za>


Changes by wohugb <wohugb at qq.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, wohugb
priority: normal
severity: normal
status: open
title: documentation
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan 30 11:00:08 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 30 Jan 2013 10:00:08 +0000
Subject: [docs] [issue17081] documentation
Message-ID: <1359540008.42.0.880132619705.issue17081@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jan 31 15:32:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Jan 2013 14:32:20 +0000
Subject: [docs] [issue14462] In re's named group the name cannot contain
	unicode	characters
In-Reply-To: <1333268208.65.0.802050679023.issue14462@psf.upfronthosting.co.za>
Message-ID: <1359642740.5.0.891715609248.issue14462@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka

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

From report at bugs.python.org  Thu Jan 31 17:02:17 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 31 Jan 2013 16:02: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: <1359648137.1.0.718882013187.issue16432@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

> ... as it is not the preferred system.
I prefer .format() but I don't think that's true for many people.

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

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

From report at bugs.python.org  Thu Jan 31 17:58:07 2013
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 31 Jan 2013 16:58:07 +0000
Subject: [docs] [issue17091] thread.lock.acquire docstring bug
Message-ID: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>


New submission from Armin Rigo:

The docstring of thread.lock.acquire() (or _thread on Python 3) is bogus: it says that if called without argument, the return value is None; it is only if called with a "blocking" argument that it returns True or False.  But since a long time it was always returning a boolean, never None.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 181035
nosy: arigo, docs at python
priority: normal
severity: normal
status: open
title: thread.lock.acquire docstring bug
versions: Python 2.7, Python 3.5

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

From seamuslethbridge at gmail.com  Mon Jan 28 14:53:41 2013
From: seamuslethbridge at gmail.com (=?iso-8859-1?Q?S=E9amus_O=27Shea?=)
Date: Mon, 28 Jan 2013 13:53:41 -0000
Subject: [docs] Documentation about python on os x
Message-ID: <5212601B-98ED-4B45-9E41-69D648DE7FCC@gmail.com>

Isn't it time to update this?


Mac OS X 10.5 comes with Python 2.5.1 pre-installed by Apple. If you wish, you are invited to install the most recent version of Python from the Python website (http://www.python.org). A current ?universal binary? build of Python, which runs natively on the Mac?s new Intel and legacy PPC CPU?s, is available there.

What you get after installing is a number of things:

A MacPython 2.5 folder in your Applications folder. In here you find IDLE, the development environment that is a standard part of official Python distributions; PythonLauncher, which handles double-clicking Python scripts from the Finder; and the ?Build Applet? tool, which allows you to package Python scripts as standalone applications on your system.
A framework /Library/Frameworks/Python.framework, which includes the Python executable and libraries. The installer adds this location to your shell path. To uninstall MacPython, you can simply remove these three things. A symlink to the Python executable is placed in /usr/local/bin/.


I appreciate the effort required to keep things up  to date and I understand it can't be easy. Nevertheless, this is very badly out of date.

Thanks


S?amus O'Shea
seamuslethbridge at gmail.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130128/81bddc0d/attachment-0001.html>

From yongjie989 at gmail.com  Mon Jan 28 15:08:32 2013
From: yongjie989 at gmail.com (YongJie Huang)
Date: Mon, 28 Jan 2013 14:08:32 -0000
Subject: [docs] =?windows-1252?q?Interesting_in_contributing_to_Python=92s?=
	=?windows-1252?q?_documentation?=
Message-ID: <CAEt=5C3DFxTMZZy9nEMmQbJi3KRdm138Pidp1bw5tRyMurArxg@mail.gmail.com>

Hi all,
My name is Yong Jie Huang(yj.huang), and interesting in contributing to
Python?s documentation. Who can tell me how to get starting, thank you.

Regards,
yj.huang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130128/df5f4f4c/attachment-0001.html>

From yongjie989 at gmail.com  Mon Jan 28 17:44:04 2013
From: yongjie989 at gmail.com (YongJie Huang)
Date: Mon, 28 Jan 2013 16:44:04 -0000
Subject: [docs] How to get starting to involve translator Python
	documentation?
Message-ID: <CAEt=5C2y-wPGEirc+U_SEtVQiH1dpiyjST=rqPS+hGcgWT4k=g@mail.gmail.com>

Hello all,
I am have interesting to invole the Python document translator, but
don't know how to starting. thank you.

From pmav99 at gmail.com  Sun Jan 27 22:09:32 2013
From: pmav99 at gmail.com (Panagiotis Mavrogiorgos)
Date: Sun, 27 Jan 2013 21:09:32 -0000
Subject: [docs] Bug in `Descriptor HowTo Guide`
Message-ID: <51059783.5070308@gmail.com>

The equivalent pure Python implementation uses Python 2 syntax for the 
exceptions

     def __set__(self, obj, value):
         if self.fset is None:
             raise AttributeError, "can't set attribute"
         self.fset(obj, value)

http://docs.python.org/3.3/howto/descriptor.html#properties
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130127/408b6959/attachment-0001.html>