From report at bugs.python.org  Thu Jul  1 04:34:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 01 Jul 2010 02:34:13 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1277951653.68.0.641787576252.issue9132@psf.upfronthosting.co.za>


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

Reference to "sorted (key, value) lists" is a bit misleading as well.  Dicts' equality is defined even if key or values are not orderable.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Thu Jul  1 16:13:57 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 01 Jul 2010 14:13:57 +0000
Subject: [docs] [issue8595] Explain the default timeout in
	http-client-related	libraries
In-Reply-To: <1272768884.43.0.28527344604.issue8595@psf.upfronthosting.co.za>
Message-ID: <1277993636.77.0.206397704703.issue8595@psf.upfronthosting.co.za>


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

I think you could preserve backward compatibility by doing something like the following (in httplib):

_sentinel = object()
__HTTP_DEFAULT_TIMEOUT = _sentinel

In httplib.HTTPConnection.__init__(), in Python 2.6.

   def __init__(self, host, port=None, strict=None,
                timeout=None):
      if timeout is None:
         if _HTTP_DEFAULT_TIMEOUT is _sentinel:
            timeout = socket._GLOBAL_DEFAULT_TIMEOUT
         else:
            timeout = _HTTP_DEFAULT_TIMEOUT

That way, if _HTTP_DEFAULT_TIMEOUT is never set, it will use the the socket timeout. Admittedly I'd rather see all uses of module globals go away, but I think this would be a good compromise.

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

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

From report at bugs.python.org  Thu Jul  1 17:04:51 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 01 Jul 2010 15:04:51 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1277996690.81.0.0291170086689.issue8939@psf.upfronthosting.co.za>


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

+1 on using the full name, PyUnicodeObject

The shorthand "PyUnicode" is too easy to confuse with Py_UNICODE (an actual type).

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

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

From report at bugs.python.org  Thu Jul  1 17:42:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Jul 2010 15:42:59 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1277998978.72.0.968911408057.issue8939@psf.upfronthosting.co.za>


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

To avoid the strange-looking ?a PyUnicodeObject object?, one can write ?an instance of PyUnicodeObject?.

Victor, have you kept the ```` around 0 and 1?

----------
resolution:  -> accepted
stage:  -> patch review

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

From report at bugs.python.org  Thu Jul  1 18:03:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Jul 2010 16:03:33 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1277998978.72.0.968911408057.issue8939@psf.upfronthosting.co.za>
Message-ID: <1278000208.3211.0.camel@localhost.localdomain>


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

> To avoid the strange-looking ?a PyUnicodeObject object?, one can write
> ?an instance of PyUnicodeObject?.

Or simply "a PyUnicodeObject".

----------

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

From bkorb at vmem.com  Thu Jul  1 17:12:33 2010
From: bkorb at vmem.com (Bruce Korb)
Date: Thu, 1 Jul 2010 08:12:33 -0700
Subject: [docs] Docs are not printable
Message-ID: <AANLkTilxf0_I0kaj5IiGFKxTUIJFmEufe8lNbbzTjg-A@mail.gmail.com>

The bug is that I need to burn trees for small pieces of the docs
and it is not possible with firefox to print the useful text with that
left side menu stuff.  Please put it on the right side and all will
be well.  Thank you.

http://docs.python.org/library/xml.dom.minidom.html

From merwok at netwok.org  Thu Jul  1 19:47:09 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 01 Jul 2010 19:47:09 +0200
Subject: [docs] spelling typo in 2to3 module description
In-Reply-To: <201006291302.o5TD2I1H006688@krypton.strw.leidenuniv.nl>
References: <201006291302.o5TD2I1H006688@krypton.strw.leidenuniv.nl>
Message-ID: <4C2CD49D.30000@netwok.org>

raise is a keyword, a sequence of characters reserved by the syntax.
It?s not possible to use it as a name.

BTW, you gave a wrong link.

Thanks anyway, and please report any other issue you find :)


From techtonik at gmail.com  Thu Jul  1 20:35:26 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 1 Jul 2010 21:35:26 +0300
Subject: [docs] Docs are not printable
In-Reply-To: <AANLkTilxf0_I0kaj5IiGFKxTUIJFmEufe8lNbbzTjg-A@mail.gmail.com>
References: <AANLkTilxf0_I0kaj5IiGFKxTUIJFmEufe8lNbbzTjg-A@mail.gmail.com>
Message-ID: <AANLkTikl67Wnr34sU8Q-wFkaG73GQvKR-Cietaznr3Vi@mail.gmail.com>

This is usually resolved with alternative CSS stylesheet for printing
[1] specified in html <head> section with:

<link rel="stylesheet" type="text/css" media="screen"
href="../_static/print.css" />

Currently d.p.o doesn't have any - http://docs.python.org/_static/

[1] http://www.w3.org/TR/CSS2/media.html
-- 
anatoly t.



On Thu, Jul 1, 2010 at 6:12 PM, Bruce Korb <bkorb at vmem.com> wrote:
> The bug is that I need to burn trees for small pieces of the docs
> and it is not possible with firefox to print the useful text with that
> left side menu stuff. ?Please put it on the right side and all will
> be well. ?Thank you.
>
> http://docs.python.org/library/xml.dom.minidom.html
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>

From merwok at netwok.org  Thu Jul  1 20:59:20 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 01 Jul 2010 20:59:20 +0200
Subject: [docs] Docs are not printable
In-Reply-To: <AANLkTikl67Wnr34sU8Q-wFkaG73GQvKR-Cietaznr3Vi@mail.gmail.com>
References: <AANLkTilxf0_I0kaj5IiGFKxTUIJFmEufe8lNbbzTjg-A@mail.gmail.com>
	<AANLkTikl67Wnr34sU8Q-wFkaG73GQvKR-Cietaznr3Vi@mail.gmail.com>
Message-ID: <4C2CE588.1060201@netwok.org>

> <link rel="stylesheet" type="text/css" media="screen"
> href="../_static/print.css" />
s/screen/print/


From techtonik at gmail.com  Thu Jul  1 21:18:42 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 1 Jul 2010 22:18:42 +0300
Subject: [docs] Docs are not printable
In-Reply-To: <4C2CE588.1060201@netwok.org>
References: <AANLkTilxf0_I0kaj5IiGFKxTUIJFmEufe8lNbbzTjg-A@mail.gmail.com>
	<AANLkTikl67Wnr34sU8Q-wFkaG73GQvKR-Cietaznr3Vi@mail.gmail.com>
	<4C2CE588.1060201@netwok.org>
Message-ID: <AANLkTinoZpW5zcGK9xJw93r2bjSlpwsAhDlSb3WROYIn@mail.gmail.com>

On Thu, Jul 1, 2010 at 9:59 PM, ?ric Araujo <merwok at netwok.org> wrote:
>> <link rel="stylesheet" type="text/css" media="screen"
>> href="../_static/print.css" />
> s/screen/print/

Exactly.
<link rel="stylesheet" type="text/css" media="print"
href="../_static/print.css" />
Thanks.
-- 
anatoly t.

From report at bugs.python.org  Thu Jul  1 23:48:54 2010
From: report at bugs.python.org (Aahz)
Date: Thu, 01 Jul 2010 21:48:54 +0000
Subject: [docs] [issue9138] Tutorial: classes intro paragraph icky
In-Reply-To: <1278020934.41.0.867324522486.issue9138@psf.upfronthosting.co.za>
Message-ID: <1278020934.41.0.867324522486.issue9138@psf.upfronthosting.co.za>


New submission from Aahz <aahz at pythoncraft.com>:

http://docs.python.org/dev/tutorial/classes.html

Chapter 9 of the Tutorial contains this intro paragraph:

    Python's class mechanism adds classes to the language with a minimum
    of new syntax and semantics. It is a mixture of the class mechanisms
    found in C++ and Modula-3. As is true for modules, classes in Python
    do not put an absolute barrier between definition and user, but
    rather rely on the politeness of the user not to "break into the
    definition." The most important features of classes are retained with
    full power, however:  the class inheritance mechanism allows multiple
    base classes, a derived class can override any methods of its base
    class or classes, and a method can call the method of a base class
    with the same name.  Objects can contain an arbitrary amount of data.

A coworker found particularly the third sentence incomprehensible, and
even with ten years of Python under my belt, I can't say that it makes
much more sense to me.  I know what it must be trying to say and
therefore proffer this suggested rewrite:

    Compared with other programming languages, Python's class mechanism
    adds classes with a minimum of new syntax and semantics.  It is a
    mixture of the class mechanisms found in C++ and Modula-3.  Python
    classes provide all the standard features of Object Oriented
    Programming: the class inheritance mechanism allows multiple base
    classes, a derived class can override any methods of its base class
    or classes, and a method can call the method of a base class with the
    same name.  Objects can contain arbitrary amounts and kinds of data.
    As is true for modules, classes partake of the dynamic nature of
    Python; users of a class can modify or break the class definition
    even without changing the source code.

----------
assignee: docs at python
components: Documentation
messages: 109080
nosy: aahz, docs at python
priority: critical
severity: normal
stage: patch review
status: open
title: Tutorial: classes intro paragraph icky
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul  2 00:07:06 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 01 Jul 2010 22:07:06 +0000
Subject: [docs] [issue9138] Tutorial: classes intro paragraph icky
In-Reply-To: <1278020934.41.0.867324522486.issue9138@psf.upfronthosting.co.za>
Message-ID: <1278022025.43.0.7669022587.issue9138@psf.upfronthosting.co.za>


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

+1 on the new wording.

Nits:

* Since many OOP languages don't support multiple inheritance, I don't think we can call multiple inheritance one of the "standard features of Object Oriented Programming". 

* Eventhough the wording is an improvement, I don't see how this could be prioritized as "critical".

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

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

From techtonik at gmail.com  Fri Jul  2 00:56:03 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 2 Jul 2010 01:56:03 +0300
Subject: [docs] [issue9138] Tutorial: classes intro paragraph icky
In-Reply-To: <1278020934.41.0.867324522486.issue9138@psf.upfronthosting.co.za>
References: <1278020934.41.0.867324522486.issue9138@psf.upfronthosting.co.za>
	<1278020934.41.0.867324522486.issue9138@psf.upfronthosting.co.za>
Message-ID: <AANLkTinGCADLFfrC2ToB6h8Spf4BEoB8ojTCMRcfNRHh@mail.gmail.com>

Much better definition. I stripped it down a little to avoid
"mechanism" repetition.

   Compared with other programming languages, Python provides
   object oriented approach with a minimum of new syntax and semantics.
   Its class mechanism is a mixture of concepts found in C++ and Modula-3.
   Python classes can be inherited from multiple base classes, a derived
   class can override any methods of its base class or classes, and a
   method can call the method of a base class with the
   same name.  Objects can contain arbitrary amounts and kinds of data.
   As is true for modules, classes partake of the dynamic nature of
   Python; users of a class can modify or break the class definition
   even without changing the source code.

However, the sentence about arbitrary amounts and kinds of data seems
strange to me. I would like to see it like "In comparison to XXX where
there is limitation that YYY Python objects can contain arbitrary
amounts and kinds of data."

"users of a class can modify or break the class definition even
without changing the source code." doesn't sound right to me. How can
I *break* the class definition? Maybe it was meant to

   The dynamic nature of Python allows new classes to be defined and
   existing classes modified at run-time.

From merwok at netwok.org  Fri Jul  2 12:17:58 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 02 Jul 2010 12:17:58 +0200
Subject: [docs] Documenting that dis is an implementation detail
In-Reply-To: <AANLkTikddC6l7VjMfHRKN3iZGp4_olNdjsTBHqXWuIvm@mail.gmail.com>
References: <201007021428.48162.steve@pearwood.info>	<3EB9ED56-3355-44F4-AD0C-B90E2137F531@twistedmatrix.com>
	<i0k13q$pu2$1@dough.gmane.org>	<AANLkTindvC1lYlCfSHYZwngyzJqnc55Dw5GY0hPP64a3@mail.gmail.com>
	<AANLkTikm-ZTKFDnIuoNGNJHfF1uR96yIwEx1u-PL3uBo@mail.gmail.com>
	<4C2D9332.9010002@v.loewis.de>
	<AANLkTikddC6l7VjMfHRKN3iZGp4_olNdjsTBHqXWuIvm@mail.gmail.com>
Message-ID: <4C2DBCD6.9070707@netwok.org>

Hello documenters

>From a python-dev thread:

Martin v. L?wis:
> The dis module is deliberately (*) not part of the Python language and
> standard library; it's an implementation detail (as is the func_code
> attribute, and the code object). [...]
>
> (*) Unfortunately, the documentation fails to mention that, probably
> because it's too obvious.

Maciej Fijalkowski
> Even more, Jython and IronPython don't have Python bytecode at all and
> they're considered python implementations.

The dis documentation should mention that it?s not authoritative for
Python, just a tool for CPython. I may be able to propose a patch this
week-end.

Do we need to open a bug report to track other mentions of bytecode that
fail to mention it?s an implementation detail?

Regards


From report at bugs.python.org  Fri Jul  2 15:23:05 2010
From: report at bugs.python.org (Catalin Iacob)
Date: Fri, 02 Jul 2010 13:23:05 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1278076985.52.0.856816875324.issue459007@psf.upfronthosting.co.za>


Changes by Catalin Iacob <iacobcatalin at gmail.com>:


----------
nosy: +catalin

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

From report at bugs.python.org  Sat Jul  3 04:21:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Jul 2010 02:21:54 +0000
Subject: [docs] [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1278123714.12.0.012407984382.issue8810@psf.upfronthosting.co.za>


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

Benjamin,

Is it too late to do anything about this.  Apparently Sean committed wrong patch and as a result 2.7 is about to be released with an error in tzinfo.fromutc docstring.  This method is confusing enough without documentation bugs.  Would you mind if I revert r81681?  This is a docstring only change.

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

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

From report at bugs.python.org  Sat Jul  3 05:39:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Jul 2010 03:39:17 +0000
Subject: [docs] [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1278128357.38.0.695654327181.issue8810@psf.upfronthosting.co.za>


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

Reverted r81681 and r81682 in r82466 and r82467.

It looks like docstring changes intended for utcoffset() landed in a docstring for fromutc().  Given that we are very close to 2.7 release, I am not attempting to improve the docs - just reverting an obvious error.

----------
assignee: docs at python -> belopolsky
versions:  -Python 2.7

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

From smm342 at cornell.edu  Fri Jul  2 17:40:10 2010
From: smm342 at cornell.edu (Steven McGrew)
Date: Fri, 02 Jul 2010 11:40:10 -0400
Subject: [docs] Interested in Contributing
Message-ID: <4C2E085A.8070007@cornell.edu>

In the interest of making myself useful this summer, I would like to 
contribute to the Python documentation.  Having used many obscure Python 
libraries in my projects, I have noticed a distinct lack of good 
documentation and code examples for some modules (especially some of the 
XML parsers out there), and I want to make using Python easier for other 
people.  I have not written documentation before, but I am willing to 
learn ReStructuredText and I consider myself to be a competent programmer.

If you have any suggestions for how I could get started or could point 
me in the write direction of the python doc community, I would greatly 
appreciate it.

-Steven McGrew

From report at bugs.python.org  Sat Jul  3 13:49:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 03 Jul 2010 11:49:27 +0000
Subject: [docs] [issue1576313] os.execvp[e] on win32 fails for current
	directory
Message-ID: <1278157766.73.0.777747622943.issue1576313@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

There should be one uniform behavior on all platforms if Python is crossplatoform.

As far as I can understand this issue - unix os.execv() requires "./" to be present to execute anything from current directory. On windows it is enough to specify just filename, but os.execv() doesn't work in this way - is that right and the issue is to make behavior of os.execv() like on windows?

The current behavior definitely needs to be documented.

----------
nosy: +docs at python, techtonik
versions: +Python 3.2

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

From report at bugs.python.org  Sat Jul  3 17:08:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Jul 2010 15:08:30 +0000
Subject: [docs] [issue1576313] os.execvp[e] on win32 fails for current
	directory
Message-ID: <1278169709.98.0.292227363321.issue1576313@psf.upfronthosting.co.za>


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

The unix model should be followed (requiring an explicit reference to the current directory if it is not already in PATH), rather than the insecure Windows behavior, and this is indeed the current situation.  The current behavior is documented ("a full or relative path"), but a footnote that this differs from the msvcrt behavior would probably be a useful addition.  So I'm changing this to a doc bug.  (I have verified that ./ works, I have not verified the msvcrt behavior.)

----------
assignee:  -> docs at python
components: +Documentation -Windows
nosy: +r.david.murray
stage: unit test needed -> needs patch
type: feature request -> behavior
versions: +Python 3.1

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

From report at bugs.python.org  Sat Jul  3 23:14:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Jul 2010 21:14:36 +0000
Subject: [docs] [issue9093] Tools/README is out of date
In-Reply-To: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>
Message-ID: <1278191676.02.0.868252448748.issue9093@psf.upfronthosting.co.za>


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

Non-existing tools removed by Mark in r82515.  There are still tools (see '-' lines above that need a README entry.)

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

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

From report at bugs.python.org  Sat Jul  3 23:18:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Jul 2010 21:18:13 +0000
Subject: [docs] [issue9093] Tools/README is out of date
In-Reply-To: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>
Message-ID: <1278191893.1.0.621353179717.issue9093@psf.upfronthosting.co.za>


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

Also I believe 2to3 deserves to be mentioned in README.

----------

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

From report at bugs.python.org  Sat Jul  3 23:27:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 03 Jul 2010 21:27:59 +0000
Subject: [docs] [issue9093] Tools/README is out of date
In-Reply-To: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>
Message-ID: <1278192479.7.0.373739903892.issue9093@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


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

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

From report at bugs.python.org  Sun Jul  4 02:25:54 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Jul 2010 00:25:54 +0000
Subject: [docs] [issue9086] Wrong linking terminology in windows FAQ
In-Reply-To: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>
Message-ID: <1278203153.29.0.685270843202.issue9086@psf.upfronthosting.co.za>


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

3.1 docs say same. For *nix, I would agree with your view of 'static', but perhaps MS uses a different terminology. Martin?

Or maybe the doc writer is using a local def of static simply as a terse, if potentially confusing, alternative to 'load-time linking'. But that could just be .lib linking versus .dll linking, which is crystal clear. Can you write an alternative paragraph or two that you think is better?

----------
nosy: +loewis, tjreedy
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jul  4 03:33:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Jul 2010 01:33:34 +0000
Subject: [docs] [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1278207214.12.0.707111478934.issue9101@psf.upfronthosting.co.za>


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

Specific suggested text and location for doc changes are more likely to get action.

"File Formats is chapter 13 in 3.x. The only text now is "The modules described in this chapter parse various miscellaneous file formats that aren?t markup languages or are related to e-mail."

PATCH 1: I am quite sure that 'or are related to e-mail' should be replaced by 'and are not related to email'.

In any case, this is not the place to add a specific comment about json. Perhaps you meant that in 13.2. configparser ? Configuration file parser, the following could be added to the end of the first paragraph.

PATCH 2: "The json module is also used for this purpose."

----------
keywords: +patch
nosy: +tjreedy
stage:  -> patch review
versions: +Python 3.1

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

From report at bugs.python.org  Sun Jul  4 03:47:01 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Jul 2010 01:47:01 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1278208021.31.0.576528515018.issue9106@psf.upfronthosting.co.za>


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

'Invalid' because invalid for this tracker and moved to sphinx tracker (there is no option for 'wrong tracker').

On Windows help-format docs, there are no numbers on the left. There are in the chapter TOC in the chapter pages. I would have to see an alternative before I would say yes to changing that.

I do wish the page/section for each module had a section toc with links so I could see what subsections there are and jump without scrolling. I gather that would be a sphinx tracker issue too.

----------
nosy: +tjreedy
resolution:  -> invalid

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

From report at bugs.python.org  Sun Jul  4 06:20:09 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Jul 2010 04:20:09 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1278217209.54.0.182052664306.issue9132@psf.upfronthosting.co.za>


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

The RefMan section is 5.9. Comparisons. The 3.x docs are by design pretty much free of 2.x references. Which is to say, they are a fresh start with 3.0 as the base. So I would also remove footnote 5. Footnote 4 is currently needed because the text suggests something that is not true. Instead fix the text and remove 4.


 I verified both behavior claims with 3.1:
>>> d1 = {1+1j: 2, 1+2j: 3}
>>> d2 = {1+1j: 2, 1+2j: 3}
>>> d1 == d2
True
>>> d1 < d2
Traceback (most recent call last):
  File "<pyshell#14>", line 1, in <module>
    d1 < d2
TypeError: unorderable types: dict() < dict()

PATCH suggestion: Replace the current entry with

"Mappings (dictionaries) compare equal if and only if they have the same key, value) pairs. Order comparision raise TypeError."

Remove footnotes 4 and 5.

"Comparisons other than equality testing raise a TypeError."
is not quite correct because 'comparisons' include 'is' and 'in' which do work as expected.

----------
keywords: +patch
nosy: +tjreedy
type:  -> behavior

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

From report at bugs.python.org  Sun Jul  4 07:07:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 04 Jul 2010 05:07:10 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1278217209.54.0.182052664306.issue9132@psf.upfronthosting.co.za>
Message-ID: <4C3016F4.3030609@netwok.org>


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

Thanks for tackling this Terry. Did you include a patch, i.e. a diff
file? If not, the ?patch? keyword does not apply, IIUC. Plain English
suggestions are helpful but they?re reviewed in a different way than a diff.

?The 3.x docs are by design pretty much free of 2.x references. Which is
to say, they are a fresh start with 3.0 as the base.?
True. That said, I would leave footnote 4, since it provides a useful
information for people caring about performance, and may interest them
in digging into the details of the implementation. It may need an
explicit mention ?in CPython?, though.

?So I would also remove footnote 5.?
I don?t know. It?s an historical note about an implementation detail; it
does no harm (apart maybe taking space for no gain) and may be
interesting to some people. Does a core dev have an opinion on that
(Georg?).

?Footnote 4 is currently needed because the text suggests something that
is not true.?
I can?t say if the text is inaccurate or just difficultly readable.

?"Mappings (dictionaries) compare equal if and only if they have the
same key, value) pairs. Order comparision raise TypeError."?
I?ll even say ?the same (key, value) pairs, irregardless of their
order?. Is the term ?order comparisons? used in the doc? If not, its
meaning is non-obvious, and I?d like to find something clearer.

?"Comparisons other than equality testing raise a TypeError." is not
quite correct because 'comparisons' include 'is' and 'in' which do work
as expected.?
I thought ?is? was clearly identity and ?in? membership or containement
testing in the doc. Can you support your claim?

Cheers

----------
nosy: +merwok

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

From report at bugs.python.org  Sun Jul  4 07:11:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 04 Jul 2010 05:11:11 +0000
Subject: [docs] [issue9101] reference json format in file formats chapter
In-Reply-To: <1278207214.12.0.707111478934.issue9101@psf.upfronthosting.co.za>
Message-ID: <4C3017EA.5070303@netwok.org>


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

1: Agreed. Alternate short formulation: ?nor related to email?.

2: Agreed with Anatoly. json should be linked from the File Formats
section, since it?s a file format unrelated to [SGML] markup languages
or email, and it?s used for a variety of purposes, not only config files.

----------
nosy: +merwok

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

From report at bugs.python.org  Sun Jul  4 10:06:01 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 04 Jul 2010 08:06:01 +0000
Subject: [docs] [issue9086] Wrong linking terminology in windows FAQ
In-Reply-To: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>
Message-ID: <1278230761.42.0.957569697478.issue9086@psf.upfronthosting.co.za>


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

I agree with John: this paragraph is technically incorrect. See

http://msdn.microsoft.com/en-us/library/ms681914%28v=VS.85%29.aspx

for an "official" definition of the relevant terms.

I vaguely recall objecting to that text when it got added, but in the discussion, it would have meant that I would have to rewrite the text myself, which I didn't want to (maybe I'm confusing this with something else, though).

In any case, it would be possible to actually use static linking as well for Python. There are currently no VS projects defined to create a static library, and such a thing couldn't dynamically load modules (which might not be necessary for embedding).

I agree with Terry that it would be best if John would produce some text he's happy with.

----------

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

From merwok at netwok.org  Sun Jul  4 13:36:13 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 04 Jul 2010 13:36:13 +0200
Subject: [docs] spelling typo in 2to3 module description
In-Reply-To: <4C2CD49D.30000@netwok.org>
References: <4C2CD49D.30000@netwok.org>
Message-ID: <4C30722D.8010805@netwok.org>

> raise is a keyword [...]. It?s not possible to use it as a name.

The modules that implement the fixers are named fix_*, so my reply is
invalid. The fixer name given on the command line is indeed ?raise?.
This bug you reported has been fixed by Benjamin Peterson, thank you for
pointing it :)

Regards


From willg at bluesock.org  Sun Jul  4 14:59:04 2010
From: willg at bluesock.org (will kahn-greene)
Date: Sun, 04 Jul 2010 08:59:04 -0400
Subject: [docs] Interested in Contributing
In-Reply-To: <4C2E085A.8070007@cornell.edu>
References: <4C2E085A.8070007@cornell.edu>
Message-ID: <4C308598.7070105@bluesock.org>

Hi!

I don't know if anyone responded to you individually, but I haven't seen
a response on the list yet.  I haven't contributed docs fixes before,
but this is how I think it works.

There's a page on the Python.org site that talks about how to get into
Python development.  The instructions there will help you for non-code
changes, too.

   http://python.org/dev/

Bugs are tracked in the Python bug tracker:

   http://bugs.python.org/

Docs bugs are all in the "Documentation" component:


http://bugs.python.org/issue?%40search_text=&title=&%40columns=title&id=&%40columns=id&stage=&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=4&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40action=search

Another way to look for issues that you might be interested in fixing is
through OpenHatch.org.  Their system polls the Python bugtracker for
bite-sized bugs.  I think in the Python bug-tracker, these are marked
with the "easy" keyword.  This includes both documentation and code bugs.

   http://openhatch.org/search/?project=Python

Any comments on and changes to docs bugs are cc:d to this list.  This is
the mailing list to discuss documentation issues.

Documentation fixes are best done through patches attached to the bugs
in question.  If there are things you want to fix that don't have bugs
for them already, you should create a new bug.

That's the best workflow.  The other workflow is to send docs problems
and fixes where the fixes are described in English to this list.  I see
Georg and some others periodically go through emails on this list, fix
things and check them in.  I shouldn't speak for these people, but I
suspect they prefer the patch workflow.

Documentation for Python is formatted in Restructured Text and uses Sphinx:

   http://docutils.sourceforge.net/rst.html

   http://sphinx.pocoo.org/

The Sphinx documentation is great.  In addition, there are a few
Sphinx-related videos on Python Miro Community:

   http://python.mirocommunity.org/search/?q=sphinx&x=0&y=0

I think that covers it.  I hope that:

1. I got this right (feel free to chime in where I'm mistaken)

2. that this helps you and anyone else looking to get more involved in
Python development

/will


On 07/02/2010 11:40 AM, Steven McGrew wrote:
> In the interest of making myself useful this summer, I would like to
> contribute to the Python documentation.  Having used many obscure Python
> libraries in my projects, I have noticed a distinct lack of good
> documentation and code examples for some modules (especially some of the
> XML parsers out there), and I want to make using Python easier for other
> people.  I have not written documentation before, but I am willing to
> learn ReStructuredText and I consider myself to be a competent programmer.
> 
> If you have any suggestions for how I could get started or could point
> me in the write direction of the python doc community, I would greatly
> appreciate it.
> 
> -Steven McGrew

From merwok at netwok.org  Sun Jul  4 15:40:19 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sun, 04 Jul 2010 15:40:19 +0200
Subject: [docs] Documenting that dis is an implementation detail
In-Reply-To: <4C2DBCD6.9070707@netwok.org>
References: <4C2DBCD6.9070707@netwok.org>
Message-ID: <4C308F43.8080003@netwok.org>

Already reported in #7829 and fixed by Terry Reedy and Brett Cannon.

Note to self: When I decide to write to docs@ instead of opening a bug
report, check anyway for an existing bug report.

Cheers


From report at bugs.python.org  Sun Jul  4 16:12:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 04 Jul 2010 14:12:32 +0000
Subject: [docs] [issue8910] Write a text file explaining why Lib/test/data
	exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1278252752.45.0.752943319666.issue8910@psf.upfronthosting.co.za>


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

Benjamin, is it too late?

----------
nosy: +benjamin.peterson
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Jul  4 17:21:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 04 Jul 2010 15:21:38 +0000
Subject: [docs] [issue8472] itertools.filterfalse() function missing
In-Reply-To: <1271781455.61.0.874507707977.issue8472@psf.upfronthosting.co.za>
Message-ID: <1278256898.82.0.871159622241.issue8472@psf.upfronthosting.co.za>


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


----------
nosy: +docs at python

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

From georg at python.org  Sun Jul  4 19:19:13 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 04 Jul 2010 19:19:13 +0200
Subject: [docs] Docs are not printable
In-Reply-To: <AANLkTikl67Wnr34sU8Q-wFkaG73GQvKR-Cietaznr3Vi@mail.gmail.com>
References: <AANLkTilxf0_I0kaj5IiGFKxTUIJFmEufe8lNbbzTjg-A@mail.gmail.com>
	<AANLkTikl67Wnr34sU8Q-wFkaG73GQvKR-Cietaznr3Vi@mail.gmail.com>
Message-ID: <4C30C291.3000903@python.org>

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

Am 01.07.2010 20:35, schrieb anatoly techtonik:
> This is usually resolved with alternative CSS stylesheet for printing
> [1] specified in html <head> section with:
> 
> <link rel="stylesheet" type="text/css" media="screen"
> href="../_static/print.css" />
> 
> Currently d.p.o doesn't have any - http://docs.python.org/_static/
> 
> [1] http://www.w3.org/TR/CSS2/media.html

On the contrary, if you check basic.css, it does have a @media print
section.

Bruce, I don't know why your Firefox doesn't respect that style info,
it works fine for me.

regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkwwwo4ACgkQN9GcIYhpnLD52QCdFogPn9belpqWLwhAGmBdgQIV
wNgAn01pviOLNiLhYgv9ObsG5cEljJw3
=AC2v
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sun Jul  4 19:28:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 04 Jul 2010 17:28:59 +0000
Subject: [docs] [issue8472] itertools.filterfalse() function missing
In-Reply-To: <1271781455.61.0.874507707977.issue8472@psf.upfronthosting.co.za>
Message-ID: <1278264539.61.0.792596552995.issue8472@psf.upfronthosting.co.za>


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

Thanks, applied the suggestion in r82548.

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

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

From report at bugs.python.org  Sun Jul  4 21:07:22 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Jul 2010 19:07:22 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1278270441.84.0.901724820129.issue9132@psf.upfronthosting.co.za>


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

On the 'patch' keyword: I thought the same as you (only for diff) until yesterday morning when Brett Cannon specifically told me that I should also set it for in-message text patches. This was in the context of him having not noticed for months (until I pinged him) that I had included a text patch in a message for an issue assigned to him, because he skims messages and looks for the keyword and other header changes. So until a 'higher' tracker authority tell me differently, I am following his direction. I am also highlighting the actual patch in the message to make it easy to find.


The current "compare equal if and only if their sorted (key, value) lists compare equal. [4]" was written when all objects were comparable and when dict == dict *was* written that way (according to [5]). The footnote was added to assure people that the new internal implementation was faster (ie, set comparison via hash lookup) than it once had been.

For a long time, that definition of dict equality has been invalid because it cannot be implemented that way; the definition is even more meaningless in Python3. So is footnote [4] saying that the meaningless definition is not the implementation. Both [4] and [5] are ancient fossils referring back to Python1. 

Without looking, I am confident that the actual implementation is O(1) if the dicts are unequal in size and an O(n) (key,value) set comparison if they are equal in size. My proposed revision is intended to imply that. Note that Python did not have sets when the sorted list definition was written. Also note that there is no footnote attached to set comparison (which once could have also been defined in terms of sorted lists).

Dicts are sets (of pairs), not unsorted lists (of pairs) and the current docs should reflect that.

The language def makes no guarantees about implementation efficiency.  In 13 years of watching c.l.p/python-list, I have not seen any particular concern about dict comparison that would warrant special notice. Rather, people worry about the big-O behavior of building large lists and dicts of millions of items. The sometimes need persuading that construction is more efficient than they might imagine. That is about the only thing I can think of for which an efficiency note might be a good idea.


'Comparisons other than equality testing' include 'is' and 'in'. They work for dictionaries as expected, which is to say, as identify and containment testing, as for everything else. They do not raise TypeError. So the statement that implies that they do is not correct.


PATCH REVISION: The suggested "Order comparision raise TypeError." has spelling and agreement errors in 'comparision' and should be "Order comparisons raise TypeError."

----------

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

From report at bugs.python.org  Sun Jul  4 22:07:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 04 Jul 2010 20:07:14 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1278274034.23.0.390737312556.issue9132@psf.upfronthosting.co.za>


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

Thanks for the explanation of the patch keyword. Its description (click on ?Keywords?) is indeed generic (?contains patch?), http://www.python.org/dev/patches/ should probably say it too.

I don?t have enough knowledge to make a useful comment on the rest of your reply. Other people most certainly will.

I think two of my remarks are not addressed by your reply:
- Is the term ?order comparisons? used in the doc? If not, its
meaning is non-obvious, and I?d like to find something clearer.
- Testing with ?is? is called identity testing, ?in? is membership or containement testing. Where are they called ?comparisons??

----------

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

From report at bugs.python.org  Mon Jul  5 01:55:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 04 Jul 2010 23:55:38 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1278287737.73.0.462997000377.issue9132@psf.upfronthosting.co.za>


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

I intentionally began my first post with "The RefMan section is 5.9. Comparisons." Look there, particularly the definition of comp_operator.

In this context, I think 'order comparison' is pretty clearly a comparison with an order operator, '<' and '>'. But fine with me if the editor want to list them explicitly.

POSSIBLE PATCH ADDITION: "('<', '<=', '>', '>=')"

----------

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

From report at bugs.python.org  Mon Jul  5 03:44:43 2010
From: report at bugs.python.org (Terrence Cole)
Date: Mon, 05 Jul 2010 01:44:43 +0000
Subject: [docs] [issue9158] PyArg_ParseTuple y* documentation is incorrect
In-Reply-To: <1278294261.08.0.252772210981.issue9158@psf.upfronthosting.co.za>
Message-ID: <1278294261.08.0.252772210981.issue9158@psf.upfronthosting.co.za>


New submission from Terrence Cole <terrence at zettabytestorage.com>:

The documented C type for y* should be [Py_buffer], not [Py_buffer *], as with the documentation for z* and the convention followed by the other types.

I'm not sure what 'type' this issue should have.  I've set it at 'crash' initially, since that's how the bug manifested for me.

----------
assignee: docs at python
components: Documentation
files: PyArgs_ParseTuple_ystar_doc_fix.patch
keywords: patch
messages: 109285
nosy: docs at python, terrence
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple y* documentation is incorrect
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file17862/PyArgs_ParseTuple_ystar_doc_fix.patch

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

From report at bugs.python.org  Mon Jul  5 03:47:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Jul 2010 01:47:50 +0000
Subject: [docs] [issue9158] PyArg_ParseTuple y* documentation is incorrect
In-Reply-To: <1278294261.08.0.252772210981.issue9158@psf.upfronthosting.co.za>
Message-ID: <1278294470.63.0.512777243033.issue9158@psf.upfronthosting.co.za>


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


----------
nosy: +haypo
stage:  -> patch review
type: crash -> feature request

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

From report at bugs.python.org  Mon Jul  5 05:27:59 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 05 Jul 2010 03:27:59 +0000
Subject: [docs] [issue9160] Documentation link of 3.2 not working at
	docs.python.org
In-Reply-To: <1278300479.72.0.619696598543.issue9160@psf.upfronthosting.co.za>
Message-ID: <1278300479.72.0.619696598543.issue9160@psf.upfronthosting.co.za>


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

This link: http://docs.python.org/dev/py3k/

Isn't working. I have always used it to see the latest documentation from 3.2, and it is linked in the left-hand side of the screen on docs.python.org as "Python 3.2 (in development)" under "Docs for other versions" if you're, for example here: http://docs.python.org/py3k/

----------
assignee: docs at python
components: Documentation
messages: 109289
nosy: docs at python, eliben
priority: normal
severity: normal
status: open
title: Documentation link of 3.2 not working at docs.python.org
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul  5 05:28:13 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 05 Jul 2010 03:28:13 +0000
Subject: [docs] [issue9160] Documentation link of 3.2 not working at
	docs.python.org
In-Reply-To: <1278300479.72.0.619696598543.issue9160@psf.upfronthosting.co.za>
Message-ID: <1278300493.69.0.783968419932.issue9160@psf.upfronthosting.co.za>


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


----------
type:  -> behavior

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

From report at bugs.python.org  Mon Jul  5 05:29:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jul 2010 03:29:36 +0000
Subject: [docs] [issue9158] PyArg_ParseTuple y* documentation is incorrect
In-Reply-To: <1278294261.08.0.252772210981.issue9158@psf.upfronthosting.co.za>
Message-ID: <1278300576.51.0.579638884987.issue9158@psf.upfronthosting.co.za>


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

y* and z* result is a Py_buffer, but in C you have to pass a reference to the result variable using &result. Full example:

static PyObject *
getargs_y_star(PyObject *self, PyObject *args)
{
    Py_buffer buffer;
    PyObject *bytes;
    if (!PyArg_ParseTuple(args, "y*", &buffer))
        return NULL;
    bytes = PyBytes_FromStringAndSize(buffer.buf, buffer.len);
    PyBuffer_Release(&buffer);
    return bytes;
}

Another example: "s" format result is char* (and not char**). You also have to pass a reference using &:

static PyObject *
getargs_s(PyObject *self, PyObject *args)
{
    char *str;
    if (!PyArg_ParseTuple(args, "s", &str))
        return NULL;
    return PyBytes_FromString(str);
}

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

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

From report at bugs.python.org  Mon Jul  5 05:30:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Jul 2010 03:30:02 +0000
Subject: [docs] [issue9160] Documentation link of 3.2 not working at
	docs.python.org
In-Reply-To: <1278300479.72.0.619696598543.issue9160@psf.upfronthosting.co.za>
Message-ID: <1278300602.88.0.963745226733.issue9160@psf.upfronthosting.co.za>


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

Also most of the links in http://www.python.org/doc/versions/ don't work.

----------
nosy: +ezio.melotti
priority: normal -> high
versions: +Python 2.5

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

From report at bugs.python.org  Mon Jul  5 08:49:11 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 05 Jul 2010 06:49:11 +0000
Subject: [docs] [issue9160] Documentation link of 3.2 not working at
	docs.python.org
In-Reply-To: <1278300479.72.0.619696598543.issue9160@psf.upfronthosting.co.za>
Message-ID: <1278312551.27.0.673154671276.issue9160@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

For me only http://www.python.org/doc/3.1.1/ gives 403.

Seems like all other links should be updated from http://www.python.org/doc/2.3.2/ to http://docs.python.org/release/2.3.2/ format to avoid additional redirect.

----------
nosy: +techtonik

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

From report at bugs.python.org  Mon Jul  5 09:07:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 05 Jul 2010 07:07:57 +0000
Subject: [docs] [issue9160] Documentation link of 3.2 not working at
	docs.python.org
In-Reply-To: <1278300479.72.0.619696598543.issue9160@psf.upfronthosting.co.za>
Message-ID: <1278313677.64.0.488605555095.issue9160@psf.upfronthosting.co.za>


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

3.1.1 docs are fixed.  Development docs will be rebuilt soon automatically; after that everything should work again.

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

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

From report at bugs.python.org  Mon Jul  5 17:32:31 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 05 Jul 2010 15:32:31 +0000
Subject: [docs] [issue9166] minor misstatement in What's New in 2.7
In-Reply-To: <1278343951.02.0.221627534967.issue9166@psf.upfronthosting.co.za>
Message-ID: <1278343951.02.0.221627534967.issue9166@psf.upfronthosting.co.za>


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

"Finally, the Mapping abstract base class now raises a NotImplemented exception..."

should read "returns" instead of "raises"

Here's the relevant code patch:
http://svn.python.org/view/python/trunk/Lib/_abcoll.py?r1=78800&r2=81414&pathrev=81414

----------
assignee: docs at python
components: Documentation
keywords: patch
messages: 109327
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: minor misstatement in What's New in 2.7
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul  5 19:48:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 05 Jul 2010 17:48:57 +0000
Subject: [docs] [issue9166] minor misstatement in What's New in 2.7
In-Reply-To: <1278343951.02.0.221627534967.issue9166@psf.upfronthosting.co.za>
Message-ID: <1278352137.38.0.673625282017.issue9166@psf.upfronthosting.co.za>


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

Thanks, fixed in r82587.

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

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

From report at bugs.python.org  Mon Jul  5 21:29:47 2010
From: report at bugs.python.org (Terrence Cole)
Date: Mon, 05 Jul 2010 19:29:47 +0000
Subject: [docs] [issue9158] PyArg_ParseTuple y* documentation is incorrect
In-Reply-To: <1278294261.08.0.252772210981.issue9158@psf.upfronthosting.co.za>
Message-ID: <1278358187.35.0.147496140342.issue9158@psf.upfronthosting.co.za>


Terrence Cole <terrence at zettabytestorage.com> added the comment:

@Victor: "y* and z* result is a Py_buffer"

Correct, so why is z* documented as [Py_buffer] and y* documented as [Py_buffer*]?  If I make 'buffer' from your example a Py_buffer*, as documented, then python puts writes sizeof(Py_buffer) bytes into a random spot in memory.  Thus the attached patch.

Thanks for giving this a look, but I don't think this issue is closed -- the documentation for y* is still wrong.

----------

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

From report at bugs.python.org  Mon Jul  5 23:39:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Jul 2010 21:39:08 +0000
Subject: [docs] [issue9158] PyArg_ParseTuple y* documentation is incorrect
In-Reply-To: <1278294261.08.0.252772210981.issue9158@psf.upfronthosting.co.za>
Message-ID: <1278365948.87.0.129683521224.issue9158@psf.upfronthosting.co.za>


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

Oh ok, sorry. Fixed in r82597 (3.x) and r82598 (3.1).

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

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

From report at bugs.python.org  Tue Jul  6 00:51:13 2010
From: report at bugs.python.org (Terrence Cole)
Date: Mon, 05 Jul 2010 22:51:13 +0000
Subject: [docs] [issue9158] PyArg_ParseTuple y* documentation is incorrect
In-Reply-To: <1278294261.08.0.252772210981.issue9158@psf.upfronthosting.co.za>
Message-ID: <1278370273.35.0.479896319924.issue9158@psf.upfronthosting.co.za>


Terrence Cole <terrence at zettabytestorage.com> added the comment:

Awesome!  Thanks, and sorry for communicating the problem so poorly initially.

----------

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

From report at bugs.python.org  Tue Jul  6 22:33:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 06 Jul 2010 20:33:54 +0000
Subject: [docs] [issue9182] argparse: optional argument w/ narg='+'
	conflicts w/	positional argsument
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1278448434.78.0.706047220029.issue9182@psf.upfronthosting.co.za>


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

I was suggesting a doc bug only if the current doc didn?t advertise clearly this way of combining nargs with positional arguments. Using ?--? is most certainly standard and right, 

Using ?--? to explicitly signal positional arguments is most certainly right and standard, but people have to read about that for the first time somewhere. In a perfect world, that would be in their shell?s man page, but better add a word about it in the reference. The ?--? marker is actually mentioned in one section: http://docs.python.org/dev/library/argparse#arguments-containing

I?m reopening, suggesting that a line be added to explain the standard ?--? separator for use cases like Sergey?s.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution: invalid -> 
stage:  -> needs patch
status: closed -> open

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

From report at bugs.python.org  Tue Jul  6 22:34:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 06 Jul 2010 20:34:50 +0000
Subject: [docs] [issue9182] argparse: optional argument w/ narg='+'
	conflicts w/	positional argsument
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1278448490.4.0.390461868102.issue9182@psf.upfronthosting.co.za>


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

Duh, please ignore the first two lines, I forgot to remove them after rephrasing my comment. Sorry.

----------

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

From fdrake at acm.org  Tue Jul  6 22:40:30 2010
From: fdrake at acm.org (Fred Drake)
Date: Tue, 6 Jul 2010 16:40:30 -0400
Subject: [docs] [issue9182] argparse: optional argument w/ narg='+'
	conflicts w/ positional argsument
In-Reply-To: <1278448434.78.0.706047220029.issue9182@psf.upfronthosting.co.za>
References: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za> 
	<1278448434.78.0.706047220029.issue9182@psf.upfronthosting.co.za>
Message-ID: <AANLkTim_zU7iYfOrAKhSSRKpejVrMjruZuuGXIoA46Vi@mail.gmail.com>

On Tue, Jul 6, 2010 at 4:33 PM, ?ric Araujo <report at bugs.python.org> wrote:
> Using ?--? to explicitly signal positional arguments is most certainly
> right and standard, but people have to read about that for the first
> time somewhere. In a perfect world, that would be in their shell?s man
> page, but better add a word about it in the reference.

It's a convention; not all applications in the larger world support it at all.

It needs to be documented for argparse, and also for specific applications
(which may or may not be built using argparse or Python.

This does not belong in the shell documentation unless needed for the shell
itself.

From report at bugs.python.org  Tue Jul  6 22:43:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 06 Jul 2010 20:43:19 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlOTE4Ml0gZG9jdW1lbnQg4oCcLS3igJ0gYXMgYSB3?=
 =?utf-8?q?ay_to_distinguish_option_w/_narg=3D=27+=27_from_positional_argu?=
 =?utf-8?q?ment_in_argparse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1278448999.28.0.670092311549.issue9182@psf.upfronthosting.co.za>


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

I always forget that not all programs follow getopt-style parsing rules, thanks for the reminder.

----------
keywords: +easy
resolution:  -> accepted
title: argparse: optional argument w/ narg='+' conflicts w/ positional argsument -> document ?--? as a way to distinguish option w/ narg='+' from positional argument in argparse

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

From report at bugs.python.org  Tue Jul  6 23:51:23 2010
From: report at bugs.python.org (Sergey Konoplev)
Date: Tue, 06 Jul 2010 21:51:23 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlOTE4Ml0gZG9jdW1lbnQg4oCcLS3igJ0gYXMgYSB3?=
 =?utf-8?q?ay_to_distinguish_option_w/_narg=3D=27+=27_from_positional_argu?=
 =?utf-8?q?ment_in_argparse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1278453083.2.0.875087333566.issue9182@psf.upfronthosting.co.za>


Sergey Konoplev <gray.ru at gmail.com> added the comment:

Thank you for the hint. It is realy not so obvious.

May be it is worth to add "--" into the usage string this way

usage: [-h] [-b BAR [BAR ...]] -- foo

Otherwise it leads to misunderstanding.

----------

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

From report at bugs.python.org  Tue Jul  6 23:58:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Jul 2010 21:58:09 +0000
Subject: [docs] [issue9184] open() doc: default value for buffering is -1,
	not None
In-Reply-To: <1278453489.46.0.972678242141.issue9184@psf.upfronthosting.co.za>
Message-ID: <1278453489.46.0.972678242141.issue9184@psf.upfronthosting.co.za>


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

Examples:
 * open(filename) works
 * open(filename, buffering=-1) works
 * open(filename, buffering=None) fails

In the code:
 * _pyio.open(): default value is -1, type is int, no default value in the docstring
 * _io.open(): default value is not specified (C function), type is int, default value in the docstring is None

In the doc:
 * open() default value is None

The default value should be -1 everywhere. None is rejected by io.open (_io) and _pyio.open.

Attached patch fixes _io.open() docstring Python documentation.

----------
assignee: docs at python
components: Documentation, IO, Interpreter Core
files: open_doc_buffering.patch
keywords: patch
messages: 109434
nosy: docs at python, haypo, pitrou
priority: normal
severity: normal
status: open
title: open() doc: default value for buffering is -1, not None
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17886/open_doc_buffering.patch

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

From bkorb at vmem.com  Tue Jul  6 16:56:39 2010
From: bkorb at vmem.com (Bruce Korb)
Date: Tue, 6 Jul 2010 07:56:39 -0700
Subject: [docs] Docs are not printable
In-Reply-To: <4C30C291.3000903@python.org>
References: <AANLkTilxf0_I0kaj5IiGFKxTUIJFmEufe8lNbbzTjg-A@mail.gmail.com> 
	<AANLkTikl67Wnr34sU8Q-wFkaG73GQvKR-Cietaznr3Vi@mail.gmail.com> 
	<4C30C291.3000903@python.org>
Message-ID: <AANLkTikG9MsHI51f_a6m0RfaTK5pH8v0XM5-GSxjgEw5@mail.gmail.com>

Hi Georg,

I suspect my firefox *would* respect that style info, were I to know how
to specify that style info.  I carefully read over the page and did not find
any links to a printable version (alternate style sheet).  It is possible that
I may have missed it, but I did go back over it several times before
writing.  I still may have missed it.  It is not an obvious "printer friendly"
icon.

On Sun, Jul 4, 2010 at 10:19 AM, Georg Brandl <georg at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 01.07.2010 20:35, schrieb anatoly techtonik:
>> This is usually resolved with alternative CSS stylesheet for printing
>> [1] specified in html <head> section with:
>>
>> <link rel="stylesheet" type="text/css" media="screen"
>> href="../_static/print.css" />
>>
>> Currently d.p.o doesn't have any - http://docs.python.org/_static/
>>
>> [1] http://www.w3.org/TR/CSS2/media.html
>
> On the contrary, if you check basic.css, it does have a @media print
> section.

The word, "basic" does not appear on the page.
Not with my browser, anyway.  It isn't in the html source, either.

> Bruce, I don't know why your Firefox doesn't respect that style info,
> it works fine for me.

Where's the link?  :)  Thank you!  Regards, Bruce

From tgibbons at umd.edu  Tue Jul  6 22:49:04 2010
From: tgibbons at umd.edu (Ted Gibbons)
Date: Tue, 6 Jul 2010 16:49:04 -0400
Subject: [docs] Small Typo
Message-ID: <AANLkTim0rqwGVcgsBF6S4cIxwPdAA_fpfHUSZpsUBT1Y@mail.gmail.com>

Hello,

I noticed a small typo in your otherwise wonderful documentation. In the
explanation for the -c option in the section explaining the command line
interface options<http://docs.python.org/using/cmdline.html#interface-options>,
the second sentence starts with "*command* can be one ore more
statements..." I assume that "ore" is supposed to be "or".

Have a good day and keep up the good work!
--
Ted Gibbons
University of Maryland Graduate Research Assistant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100706/3c13e30d/attachment.html>

From georg at python.org  Wed Jul  7 00:59:08 2010
From: georg at python.org (Georg Brandl)
Date: Wed, 07 Jul 2010 00:59:08 +0200
Subject: [docs] Docs are not printable
In-Reply-To: <AANLkTikG9MsHI51f_a6m0RfaTK5pH8v0XM5-GSxjgEw5@mail.gmail.com>
References: <AANLkTilxf0_I0kaj5IiGFKxTUIJFmEufe8lNbbzTjg-A@mail.gmail.com>
	<AANLkTikl67Wnr34sU8Q-wFkaG73GQvKR-Cietaznr3Vi@mail.gmail.com>
	<4C30C291.3000903@python.org>
	<AANLkTikG9MsHI51f_a6m0RfaTK5pH8v0XM5-GSxjgEw5@mail.gmail.com>
Message-ID: <4C33B53C.8020106@python.org>

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

Hi Bruce,

you shouldn't need to do anything special; there is no link to a separate
printer-friendly version.

The print-media styles are in http://docs.python.org/_static/basic.css,
which is in turn included by http://docs.python.org/_static/default.css,
and they should get used automatically whenever the browser determines it
renders the page for printing, and not for the screen.  For me, when I
call up the print preview, I can see that the sidebar is not rendered.

Georg

Am 06.07.2010 16:56, schrieb Bruce Korb:
> Hi Georg,
> 
> I suspect my firefox *would* respect that style info, were I to know how
> to specify that style info.  I carefully read over the page and did not find
> any links to a printable version (alternate style sheet).  It is possible that
> I may have missed it, but I did go back over it several times before
> writing.  I still may have missed it.  It is not an obvious "printer friendly"
> icon.
> 
> On Sun, Jul 4, 2010 at 10:19 AM, Georg Brandl <georg at python.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Am 01.07.2010 20:35, schrieb anatoly techtonik:
>>> This is usually resolved with alternative CSS stylesheet for printing
>>> [1] specified in html <head> section with:
>>>
>>> <link rel="stylesheet" type="text/css" media="screen"
>>> href="../_static/print.css" />
>>>
>>> Currently d.p.o doesn't have any - http://docs.python.org/_static/
>>>
>>> [1] http://www.w3.org/TR/CSS2/media.html
>>
>> On the contrary, if you check basic.css, it does have a @media print
>> section.
> 
> The word, "basic" does not appear on the page.
> Not with my browser, anyway.  It isn't in the html source, either.
> 
>> Bruce, I don't know why your Firefox doesn't respect that style info,
>> it works fine for me.
> 
> Where's the link?  :)  Thank you!  Regards, Bruce

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

iEYEARECAAYFAkwztTwACgkQN9GcIYhpnLDtwACdH4IruhNbpYPUJtpBRMKIeWQg
ZlsAn2Fm0o4JaPbeINun7Oebfz/krGmg
=xU+z
-----END PGP SIGNATURE-----

From georg at python.org  Wed Jul  7 01:00:11 2010
From: georg at python.org (Georg Brandl)
Date: Wed, 07 Jul 2010 01:00:11 +0200
Subject: [docs] Small Typo
In-Reply-To: <AANLkTim0rqwGVcgsBF6S4cIxwPdAA_fpfHUSZpsUBT1Y@mail.gmail.com>
References: <AANLkTim0rqwGVcgsBF6S4cIxwPdAA_fpfHUSZpsUBT1Y@mail.gmail.com>
Message-ID: <4C33B57B.5000203@python.org>

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

Am 06.07.2010 22:49, schrieb Ted Gibbons:
> Hello,
> 
> I noticed a small typo in your otherwise wonderful documentation. In the
> explanation for the -c option in the section explaining the command line
> interface options <http://docs.python.org/using/cmdline.html#interface-options>,
> the second sentence starts with "/command/ can be one ore more statements..." I
> assume that "ore" is supposed to be "or".
> 
> Have a good day and keep up the good work!

Hi Ted,

thanks for reporting, this is now fixed and will be online shortly.

regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkwztXsACgkQN9GcIYhpnLB9egCeOutnWGtauf/Jn6R1Pr9Xc4el
bxcAnibx7v/bJhcN9O/6gzaD5sVnAaVX
=gnqT
-----END PGP SIGNATURE-----

From report at bugs.python.org  Wed Jul  7 06:49:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 07 Jul 2010 04:49:26 +0000
Subject: [docs] [issue9063] TZ examples in datetime.rst are incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1278478163.74.0.970570412156.issue9063@psf.upfronthosting.co.za>


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

There is nothing we can do about misreporting of UTC offset.  Unlike time tuples, datetime objects do not store the DST flag and thus have no means to disambiguate between standard and DST during the hour after the clock is set back for DST to standard transition.

Nevertheless, dt = datetime.fromtimestamp(t) is a well defined operation, it is dt.dst() and dt.utcoffset() which are not so well defined.

According to the comment at the end of Modules/datetimemodule.c, in order for the default implementation of tzinfo.fromutc() to operate correctly, the concrete implementation of tzinfo.dst(dt) must treat dt that falls into the ambiguous hour (where it can be ether DST or standard time) as the standard time.  This is precisely what is done in the implementation of USTimeZone class.  The Local class, however, relies on mktime to choose between DST and standard and apparently, at least on OSX, mktime does not do what Python's tzinfo.fromutc() expects.

The attached patch for Doc/includes/tzinfo-examples.py fixes this problem by passing is_dst=0 instead of -1 to mktime and also adds __repr__ to LocalTimezone class.

With this patch,

>>> x = datetime(2010, 11, 7, 5)
>>> s = (x - datetime(1970, 1, 1))//timedelta(seconds=1)
>>> for i in range(-3600, 5000, 3600):
...     datetime.fromtimestamp(s + i, Local)
... 
datetime.datetime(2010, 11, 7, 0, 0, tzinfo=EST/EDT)
datetime.datetime(2010, 11, 7, 1, 0, tzinfo=EST/EDT)
datetime.datetime(2010, 11, 7, 1, 0, tzinfo=EST/EDT)

which is correct and consistent with Easter timezone:

>>> for i in range(-3600, 5000, 3600):
...     datetime.fromtimestamp(s + i, Eastern)
... 
datetime.datetime(2010, 11, 7, 0, 0, tzinfo=Eastern)
datetime.datetime(2010, 11, 7, 1, 0, tzinfo=Eastern)
datetime.datetime(2010, 11, 7, 1, 0, tzinfo=Eastern)

----------
keywords: +patch
nosy: +mark.dickinson
stage: needs patch -> commit review
type:  -> behavior
Added file: http://bugs.python.org/file17892/issue9063.diff

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

From stereotype441 at gmail.com  Wed Jul  7 20:37:44 2010
From: stereotype441 at gmail.com (Paul Berry)
Date: Wed, 7 Jul 2010 11:37:44 -0700
Subject: [docs] "What's new in Python 2.7" makes a confusing statement about
	string/float conversions.
Message-ID: <AANLkTim_ZBm9svXku_xjbfTdtVgBUCxzJpBv3gMa_Fh7@mail.gmail.com>

I found this phrase in the section
http://docs.python.org/whatsnew/2.7.html#python-3-1-features

Float-to-string and string-to-float conversions now round their results more
correctly, and repr() of a floating-point number x returns a result that?s
guaranteed to round back to the same number when converted back to a string.

I think this should say "...when converted back to a float."

Thanks,

Paul Berry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100707/a011563b/attachment.html>

From report at bugs.python.org  Thu Jul  8 08:36:48 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 08 Jul 2010 06:36:48 +0000
Subject: [docs] [issue9195] Link in docs from "String Formatting Operations"
	to	"Template Strings"
In-Reply-To: <1278571007.55.0.304215462236.issue9195@psf.upfronthosting.co.za>
Message-ID: <1278571007.55.0.304215462236.issue9195@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

I stumbled across "Template Strings" of PEP 292 by accident recently. I'd never heard of it before.

I'm familiar with the "string interpolation" aka "String Formatting Operations", and I know to find that in the docs under "Standard Types", i.e.
http://docs.python.org/library/stdtypes.html#string-formatting-operations
http://docs.python.org/py3k/library/stdtypes.html#old-string-formatting-operations

It would be good for that documentation to mention "Template Strings", and include a cross-reference to the docs for it, since it was created as an alternative string formatting. I.e. cross-reference to
http://docs.python.org/library/string.html#template-strings
http://docs.python.org/py3k/library/string.html#template-strings

----------
assignee: docs at python
components: Documentation
messages: 109515
nosy: cmcqueen1975, docs at python
priority: normal
severity: normal
status: open
title: Link in docs from "String Formatting Operations" to "Template Strings"
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul  8 08:38:00 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Jul 2010 06:38:00 +0000
Subject: [docs] [issue9195] Link in docs from "String Formatting Operations"
	to	"Template Strings"
In-Reply-To: <1278571007.55.0.304215462236.issue9195@psf.upfronthosting.co.za>
Message-ID: <1278571080.93.0.896485233724.issue9195@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/issue9195>
_______________________________________

From report at bugs.python.org  Thu Jul  8 09:07:10 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 08 Jul 2010 07:07:10 +0000
Subject: [docs] [issue9196] Improve docs for string interpolation "%s" re
	Unicode	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>


New submission from Craig McQueen <python at craig.mcqueen.id.au>:

I have just been trying to figure out how string interpolation works for "%s", when Unicode strings are involved. It seems it's a bit complicated, but the Python documentation doesn't really describe it. It just says %s "converts any Python object using str()".

Here is what I have found (I think), and it could be worth improving the documentation of this somehow.

Example 1:
    "%s" % test_object

>From what I can tell, in this case:
1. test_object.__str__() is called.
2. If test_object.__str__() returns a string object, then that is substituted.
3. If test_object.__str__() returns a Unicode object (for some reason), then test_object.__unicode__() is called, then _that_ is substituted instead. The output string is turned into Unicode. This behaviour is surprising.

[Note that the call to test_object.__str__() is not the same as str(test_object), because the former can return a Unicode object without causing an error, while the latter, if it gets a Unicode object, will then try to encode('ascii') to a string, possibly generating a UnicodeEncodeError exception.]


Example 2:
    u"%s" % test_object

In this case:
1. test_object.__unicode__() is called, if it exists, and the result is substituted. The output string is Unicode.
2. If test_object.__unicode__() doesn't exist, then test_object.__str__() is called instead, converted to Unicode, and substituted. The output string is Unicode.


Example 3:
    "%s %s" % (u'unicode', test_object)

In this case:
1. The first substitution causes the output string to be Unicode.
2. It seems that (1) causes the second substitution to follow the same rules as Example 2. This is a little surprising.

----------
assignee: docs at python
components: Documentation
messages: 109516
nosy: cmcqueen1975, docs at python
priority: normal
severity: normal
status: open
title: Improve docs for string interpolation "%s" re Unicode strings
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul  8 09:09:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Jul 2010 07:09:09 +0000
Subject: [docs] [issue9196] Improve docs for string interpolation "%s" re
	Unicode	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1278572949.27.0.21556164125.issue9196@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/issue9196>
_______________________________________

From report at bugs.python.org  Thu Jul  8 09:15:46 2010
From: report at bugs.python.org (Craig McQueen)
Date: Thu, 08 Jul 2010 07:15:46 +0000
Subject: [docs] [issue9196] Improve docs for string interpolation "%s" re
	Unicode	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1278573346.24.0.0257542666296.issue9196@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

Another thing I discovered, for Example 1:
4. If test_object.__str__() returns a Unicode object (for some reason), and test_object.__unicode__() does not exist, then the Unicode value from the __str__() call is used as-is (no conversion to string, no encoding errors). This is also a little surprising [in this situation unicode(test_object) also returns the Unicode object returned by __str__() as-is, so I guess there's some consistency there].

----------

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

From thomas.oliveira at gmail.com  Thu Jul  8 00:44:48 2010
From: thomas.oliveira at gmail.com (Thomas Oliveira)
Date: Wed, 07 Jul 2010 19:44:48 -0300
Subject: [docs] lib/python|version|/site-packages vs
	lib/python|version|/dist-packages
Message-ID: <4C350360.1080400@gmail.com>

Dear Admin,

According to what I see in my computer and after doing a Google search 
on the subject:

http://www.google.com/search?q=site-packages+dist-packages

it seems that on some Debian-based Linux distributions (including Ubuntu)
the "site-packages" directory described in the site module's 
documentation pages:

http://docs.python.org/release/2.6.5/library/site.html#module-site
http://docs.python.org/py3k/library/site.html#module-site

has been named "dist-packages", instead of "site-packages".

Could you please insert a note about it on these documentation pages?

I will prevent some beginner developers (like me!) to make confusion.


Thank you,

Thomas Oliveira

From richard.jolly at nhs.net  Thu Jul  8 12:23:58 2010
From: richard.jolly at nhs.net (Jolly Richard (DERBYSHIRE COUNTY PCT))
Date: Thu, 8 Jul 2010 11:23:58 +0100
Subject: [docs] Chnages to tutorial section
Message-ID: <BB5508F2DC493F46BBDC4CB56214BEAA5681AF5427@NHS-PCLI-MBC013.AD1.NHS.NET>

Hi

Just starting to learn python and I was going through your (very well put together) tutorial - however it appears some editing may be in order as a number of earlier "programming examples" - e.g section 3.2. "First Steps Towards Programming" - once it introduces 'print' statement - the syntax is wrong for the newer version of python (as I found out from some Google searches) - in that print is now a function and the brackets are required.

I know this may seem like nit-picking but sometimes when you are learning from scratch - little things like syntax errors - when you have typed exactly what is on the screen can be very frustrating.

Regards

Richard Jolly
Business Change Manager
Derbyshire Community Health Services

Tel: 01332 404122 Mob: 07917424987
Laurie House, Colyear Street, Derby DE1 1LJ
E-mail: richard.jolly at derbyshirecountypct.nhs.uk
NHS Mail: richard.jolly at nhs.net
Derbyshire Community Health Services is responsible for providing NHS Services in the Derbyshire area and is hosted by Derbyshire County Primary Care
Trust.

Advance Notice of Leave:

Save Paper - do you really need to print this email?

********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents:
to do so is strictly prohibited and may be unlawful.

Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland
NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSI recipients
NHSmail provides an email address for your career in the NHS and can be accessed anywhere
For more information and to find out how you can switch, visit www.connectingforhealth.nhs.uk/nhsmail

********************************************************************************************************************


From report at bugs.python.org  Thu Jul  8 20:09:56 2010
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 08 Jul 2010 18:09:56 +0000
Subject: [docs] [issue9204] The documentation of PyType_Type in py3k
	mentions	types.TypeType
In-Reply-To: <1278612596.78.0.246474788536.issue9204@psf.upfronthosting.co.za>
Message-ID: <1278612596.78.0.246474788536.issue9204@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

The documentation of PyType_Type (http://docs.python.org/dev/py3k/c-api/type.html#PyType_Type) is this: 
"This is the type object for type objects; it is the same object as type and types.TypeType  in the Python layer."

But in py3k there is no types.TypeType object.

----------
assignee: docs at python
components: Documentation
messages: 109560
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: The documentation of PyType_Type in py3k mentions types.TypeType
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jul  8 22:33:05 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 08 Jul 2010 20:33:05 +0000
Subject: [docs] [issue8946] PyBuffer_Release signature in 3.1 documentation
	is	incorrect
In-Reply-To: <1276028746.19.0.698782351102.issue8946@psf.upfronthosting.co.za>
Message-ID: <1278621184.54.0.046166589819.issue8946@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

The documentation issue appears present in 2.7 (and 2.6).
Further, the Py_buffer member 'obj' is undocumented, and the in-line comment in object.h falsely states that it is a "borrowed" reference, whereas PyBuffer_Release() Py_XDECREFs it and clears it.  Thus, it is also safe to call PyBuffer_Release() more than once, something that can be useful for certain error scenarios.

PEP 3118 also has not been updated to reflect the above.

----------
nosy: +krisvale

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

From report at bugs.python.org  Fri Jul  9 03:36:55 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Jul 2010 01:36:55 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1278639415.25.0.286231062859.issue5784@psf.upfronthosting.co.za>


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

A doc addition would seem like a good idea, so I am changing this to a doc issue for the current versions. Can you suggest specific text and a specific location to place it?

A behavior change could only go into 3.2. I do not know who, if anyone, maintains zlib. A reference to the desired algorithm might be necessary.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, tjreedy
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Fri Jul  9 05:24:07 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Jul 2010 03:24:07 +0000
Subject: [docs] [issue5962] Ambiguity about the semantics of sys.exit()
	and	os._exit() in multithreaded program
In-Reply-To: <1241722395.44.0.880118568656.issue5962@psf.upfronthosting.co.za>
Message-ID: <1278645847.06.0.309982423668.issue5962@psf.upfronthosting.co.za>


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

I know nothing about this. You might check
http://docs.python.org/dev/py3k/
to see if there has been any change or open a discussion on python-list to get suggestions for specific doc updates.

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

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

From report at bugs.python.org  Fri Jul  9 05:59:44 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Jul 2010 03:59:44 +0000
Subject: [docs] [issue6678] inspect.currentframe documentation omits
	optional depth	parameter
In-Reply-To: <1249928701.73.0.0206445902812.issue6678@psf.upfronthosting.co.za>
Message-ID: <1278647983.96.0.662058228954.issue6678@psf.upfronthosting.co.za>


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

The doc string seems correct, so I agree. A condensed and improved version of the docstring (with *depth* italicized as usual) might be

inspect.currentframe(depth=0) 
  Return the frame object depth calls below the top of the stack. If there is none, raise ValueError.

I do not think the internal comment is correct when it is exposed like this. Everything in inspect is specialized.

The doc string could be similarly condensed.

----------
assignee: georg.brandl -> docs at python
keywords: +patch
nosy: +docs at python, tjreedy
versions:  -Python 2.4, Python 2.5, Python 3.0

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

From report at bugs.python.org  Fri Jul  9 12:43:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jul 2010 10:43:13 +0000
Subject: [docs] [issue1945] Document back ported C functions
In-Reply-To: <1201445858.91.0.21119487494.issue1945@psf.upfronthosting.co.za>
Message-ID: <1278672193.23.0.837230760971.issue1945@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jul  9 12:45:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Jul 2010 10:45:30 +0000
Subject: [docs] [issue5962] Ambiguity about the semantics of sys.exit()
	and	os._exit() in multithreaded program
In-Reply-To: <1241722395.44.0.880118568656.issue5962@psf.upfronthosting.co.za>
Message-ID: <1278672330.87.0.268763880846.issue5962@psf.upfronthosting.co.za>


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


----------
nosy: +exarkun, gps

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

From report at bugs.python.org  Fri Jul  9 15:07:38 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 09 Jul 2010 13:07:38 +0000
Subject: [docs] [issue5121] PyRun_InteractiveLoop disagrees with
	documentation?
In-Reply-To: <1233457621.0.0.661616898289.issue5121@psf.upfronthosting.co.za>
Message-ID: <1278680858.48.0.613561403292.issue5121@psf.upfronthosting.co.za>


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

I'm assuming that this will be a doc change, in which case it applies to all versions.  The comment is actually against PyRun_InteractiveLoopFlags.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +BreamoreBoy, docs at python
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Fri Jul  9 16:15:06 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 09 Jul 2010 14:15:06 +0000
Subject: [docs] [issue1040439] Missing documentation on How To Link With
	libpython
Message-ID: <1278684906.75.0.507673016812.issue1040439@psf.upfronthosting.co.za>


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

The number of google hits tells me this is still an issue.

----------
assignee:  -> docs at python
nosy: +BreamoreBoy, docs at python
versions: +Python 3.2 -Python 2.6

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

From barthelemy at crans.org  Fri Jul  9 14:36:39 2010
From: barthelemy at crans.org (=?ISO-8859-1?Q?S=E9bastien_Barth=E9lemy?=)
Date: Fri, 9 Jul 2010 14:36:39 +0200
Subject: [docs] os.readlink recipe for getting an absolute path
Message-ID: <AANLkTimKWaFure1_ea9dcLyT8WMes5fReCe8W6XjmMQd@mail.gmail.com>

Hello,

In the doc of os.readlink [1], it is stated:
"Return a string representing the path to which the symbolic link
points. The result may be either an absolute or relative pathname; if
it is relative, it may be converted to an absolute pathname using
os.path.join(os.path.dirname(path), result)."

However, if `path` is relative, the result of this command will be
relative, which makes the documentation inaccurate.

The wording should be changed or the command updated to something like:
os.path.join(os.path.abspath(os.path.dirname(path)), result)

[1] http://docs.python.org/library/os.html#os.readlink

Cheers, and many thanks for the wonderful documentation

Sebastien

From report at bugs.python.org  Sat Jul 10 07:03:09 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 10 Jul 2010 05:03:09 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1278738189.46.0.311386613472.issue9132@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul 10 08:28:18 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Jul 2010 06:28:18 +0000
Subject: [docs] [issue1643712] Emphasize buffering issues when sys.stdin is
	used
Message-ID: <1278743298.02.0.349454225345.issue1643712@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
keywords: +patch
nosy: +docs at python
stage: unit test needed -> 
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Sat Jul 10 08:35:35 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Jul 2010 06:35:35 +0000
Subject: [docs] [issue1349732] urllib.urlencode provides two features in one
	param
Message-ID: <1278743735.45.0.685761311613.issue1349732@psf.upfronthosting.co.za>


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

"put something somewhere" will not get action.
Please suggest specific wording and a specific place to put it and mark it TEXT or PATCH or something so a doc person can find it.

I am assuming that this does not apply to 3.x.

----------
assignee: georg.brandl -> docs at python
nosy: +docs at python, tjreedy
versions: +Python 2.7

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

From report at bugs.python.org  Sat Jul 10 09:36:37 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 10 Jul 2010 07:36:37 +0000
Subject: [docs] [issue1720250] PyGILState_Ensure does not acquires GIL
Message-ID: <1278747397.02.0.173500361676.issue1720250@psf.upfronthosting.co.za>


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

This is still the case: the documentation should mention that PyEval_ReleaseLock() is not the correct function to release "the GIL", both the interpreter lock *and* the current thread state have to be released.

----------
assignee:  -> docs at python
components:  -Interpreter Core
nosy: +amaury.forgeotdarc, docs at python

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

From giecrilj at stegny.2a.pl  Sat Jul 10 13:04:19 2010
From: giecrilj at stegny.2a.pl (Krzysztof =?utf-8?q?=C5=BBelechowski?=)
Date: Sat, 10 Jul 2010 13:04:19 +0200
Subject: [docs] Tutorial 2.1.1: name 'sys' is not defined
Message-ID: <201007101304.19283.giecrilj@stegny.2a.pl>

Regarding the section "Argument Passing" [1]:

== Problem statement ==
When the student tells python to evaluate sys.argv[0] as described, she gets 
the following error: 

name 'sys' is not defined

== Suggestion ==
Please append the following example:

import sys
sys.argv[0]

___
[1] <URL:http://docs.python.org/tutorial/interpreter.html#argument-passing>

From report at bugs.python.org  Sat Jul 10 14:16:38 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 10 Jul 2010 12:16:38 +0000
Subject: [docs] [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1278764198.6.0.681346846594.issue4966@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul 10 14:20:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 10 Jul 2010 12:20:50 +0000
Subject: [docs] [issue8564] Update documentation on doctest/unittest2
	integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1278764450.38.0.265106176394.issue8564@psf.upfronthosting.co.za>


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

Applied in r82764. Thanks!

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

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

From report at bugs.python.org  Sat Jul 10 14:36:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Jul 2010 12:36:06 +0000
Subject: [docs] [issue1720250] PyGILState_Ensure does not acquires GIL
Message-ID: <1278765366.35.0.112568388224.issue1720250@psf.upfronthosting.co.za>


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

I'm not even sure what PyEval_AcquireLock() and PyEval_ReleaseLock() are good for. Perhaps they should be deprecated.

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

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

From report at bugs.python.org  Sat Jul 10 15:47:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 10 Jul 2010 13:47:22 +0000
Subject: [docs] [issue7303] pkgutil lacks documentation for useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1278769641.74.0.206637252999.issue7303@psf.upfronthosting.co.za>


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

Ulrik could you please submit a patch?

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

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

From report at bugs.python.org  Sat Jul 10 17:10:29 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 10 Jul 2010 15:10:29 +0000
Subject: [docs] [issue7797] base64 module docs should indicate that encode
	methods	return bytes, not strings
In-Reply-To: <1264657234.88.0.361902382991.issue7797@psf.upfronthosting.co.za>
Message-ID: <1278774629.36.0.886958108352.issue7797@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul 10 17:13:58 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 10 Jul 2010 15:13:58 +0000
Subject: [docs] [issue7935] Cross-reference ast.literal_eval() from eval()
	docs
In-Reply-To: <1266241099.84.0.200250637967.issue7935@psf.upfronthosting.co.za>
Message-ID: <1278774838.16.0.455622806355.issue7935@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul 10 17:44:38 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 10 Jul 2010 15:44:38 +0000
Subject: [docs] [issue1612012] builtin compile() doc needs
	PyCF_DONT_IMPLY_DEDENT
Message-ID: <1278776678.3.0.697654707618.issue1612012@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul 10 20:07:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Jul 2010 18:07:56 +0000
Subject: [docs] [issue7303] pkgutil lacks documentation for useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1278785276.63.0.937406919242.issue7303@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +merwok
resolution:  -> accepted
stage:  -> needs patch

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

From report at bugs.python.org  Sat Jul 10 21:28:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Jul 2010 19:28:49 +0000
Subject: [docs] [issue4966] Improving Lib Doc Sequence Types Section
In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za>
Message-ID: <1278790129.96.0.655223294982.issue4966@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.1

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

From report at bugs.python.org  Sat Jul 10 23:37:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Jul 2010 21:37:35 +0000
Subject: [docs] [issue8564] Update documentation on doctest/unittest2
	integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1278797855.18.0.00878053773006.issue8564@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 11 01:24:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Jul 2010 23:24:02 +0000
Subject: [docs] [issue7867] Proposed FAQ entry on pass-by-? semantics and
	the meaning	of 'variable' in python
In-Reply-To: <1265490255.73.0.743157337936.issue7867@psf.upfronthosting.co.za>
Message-ID: <1278804242.12.0.212765367932.issue7867@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 11 02:00:19 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Jul 2010 00:00:19 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1278806418.7.0.55551521475.issue8145@psf.upfronthosting.co.za>


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

If the content of the patch is correct, it looks ready to apply, with only a touch of editing. Do we have a resident expert of sqlite3? Or Laszlo, do you have a reference for the statements made?

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

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

From report at bugs.python.org  Sun Jul 11 04:18:07 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 11 Jul 2010 02:18:07 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1278814687.78.0.798790250223.issue8722@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 11 07:29:54 2010
From: report at bugs.python.org (Laszlo Nagy)
Date: Sun, 11 Jul 2010 05:29:54 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1278806418.7.0.55551521475.issue8145@psf.upfronthosting.co.za>
Message-ID: <AANLkTin_qHuQmCJlQG8rRA3EBV-tJ4as7qsE-di-Vw34@mail.gmail.com>


Laszlo Nagy <nagylzs at gmail.com> added the comment:

2010/7/11 Terry J. Reedy <report at bugs.python.org>

>
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> If the content of the patch is correct, it looks ready to apply, with only
> a touch of editing. Do we have a resident expert of sqlite3? Or Laszlo, do
> you have a reference for the statements made?
>

Sorry, the only reference I have is that mailing list thread (
http://mail.python.org/pipermail/python-list/2010-March/1239374.html ).

There you can find an example with SQL statements, showing the problem.

Ryan Kelly wrote the following:

<quote>
I have a theory, based on a quick perusal of the sqlite3 bindings
source.

The bindings think that "SAVEPOINT sp1" is a "non-DML, non-query"
statement. So when isolation_level is something other than None, this
statement implicitly commits the current transaction and throws away
your savepoints!
</quote>

So the problem is with the sqlite binding code, not sqlite itself. I'm not
an expert in C, so I'm not sure I can help more.

Thanks,

   Laszlo

----------
Added file: http://bugs.python.org/file17940/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8145>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">2010/7/11 Terry J. Reedy <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Terry J. Reedy &lt;<a href="mailto:tjreedy at udel.edu">tjreedy at udel.edu</a>&gt; added the comment:<br>
<br>
If the content of the patch is correct, it looks ready to apply, with only a touch of editing. Do we have a resident expert of sqlite3? Or Laszlo, do you have a reference for the statements made?<br></blockquote><br>Sorry, the only reference I have is that mailing list thread ( <a href="http://mail.python.org/pipermail/python-list/2010-March/1239374.html">http://mail.python.org/pipermail/python-list/2010-March/1239374.html</a> ).<br>
<br>There you can find an example with SQL statements, showing the problem. <br><br>Ryan Kelly wrote the following:<br><br>&lt;quote&gt;<br>
I have a theory, based on a quick perusal of the sqlite3 bindings<br>
source.<br>
<br>
The bindings think that &quot;SAVEPOINT sp1&quot; is a &quot;non-DML, non-query&quot;<br>
statement. So when isolation_level is something other than None, this<br>
statement implicitly commits the current transaction and throws away<br>
your savepoints!<br>
&lt;/quote&gt;<br><br>So the problem is with the sqlite binding code, not sqlite itself. I&#39;m not an expert in C, so I&#39;m not sure I can help more.<br><br>Thanks,<br><br>???? Laszlo<br><br></div>

From report at bugs.python.org  Sun Jul 11 10:37:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Jul 2010 08:37:22 +0000
Subject: [docs] [issue4968] Clarify inspect.is<callable> method docs
In-Reply-To: <1232162769.03.0.624026715862.issue4968@psf.upfronthosting.co.za>
Message-ID: <1278837442.15.0.106444977468.issue4968@psf.upfronthosting.co.za>


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

No, I've just had no time to review the suggested changes.

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

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

From report at bugs.python.org  Sun Jul 11 11:18:04 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 11 Jul 2010 09:18:04 +0000
Subject: [docs] [issue6774] socket.shudown documentation: on some platforms,
	closing one half closes the other half
In-Reply-To: <1251103521.34.0.917057608479.issue6774@psf.upfronthosting.co.za>
Message-ID: <1278839884.71.0.220286150257.issue6774@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 11 11:23:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Jul 2010 09:23:24 +0000
Subject: [docs] [issue6774] socket.shudown documentation: on some platforms,
	closing one half closes the other half
In-Reply-To: <1251103521.34.0.917057608479.issue6774@psf.upfronthosting.co.za>
Message-ID: <1278840204.6.0.796077608468.issue6774@psf.upfronthosting.co.za>


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

Thanks, applied in r82798.

----------
resolution:  -> accepted
status: open -> closed

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

From georg at python.org  Sun Jul 11 11:25:24 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 11 Jul 2010 11:25:24 +0200
Subject: [docs] "What's new in Python 2.7" makes a confusing statement
 about	string/float conversions.
In-Reply-To: <AANLkTim_ZBm9svXku_xjbfTdtVgBUCxzJpBv3gMa_Fh7@mail.gmail.com>
References: <AANLkTim_ZBm9svXku_xjbfTdtVgBUCxzJpBv3gMa_Fh7@mail.gmail.com>
Message-ID: <4C398E04.9010804@python.org>

Am 07.07.2010 20:37, schrieb Paul Berry:
> I found this phrase in the section
> http://docs.python.org/whatsnew/2.7.html#python-3-1-features
> 
> Float-to-string and string-to-float conversions now round their results more
> correctly, and repr() of a floating-point number x returns a result that?s
> guaranteed to round back to the same number when converted back to a string.
> 
> I think this should say "...when converted back to a float."

Hi Paul,

thanks for the report, this is now fixed and will be online shortly.

regards,
Georg

From georg at python.org  Sun Jul 11 11:28:01 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 11 Jul 2010 11:28:01 +0200
Subject: [docs] Chnages to tutorial section
In-Reply-To: <BB5508F2DC493F46BBDC4CB56214BEAA5681AF5427@NHS-PCLI-MBC013.AD1.NHS.NET>
References: <BB5508F2DC493F46BBDC4CB56214BEAA5681AF5427@NHS-PCLI-MBC013.AD1.NHS.NET>
Message-ID: <4C398EA1.4010904@python.org>

Am 08.07.2010 12:23, schrieb Jolly Richard (DERBYSHIRE COUNTY PCT):
> Hi
> 
> Just starting to learn python and I was going through your (very well put
> together) tutorial - however it appears some editing may be in order as a
> number of earlier "programming examples" - e.g section 3.2. "First Steps
> Towards Programming" - once it introduces 'print' statement - the syntax is
> wrong for the newer version of python (as I found out from some Google
> searches) - in that print is now a function and the brackets are required.
> 
> I know this may seem like nit-picking but sometimes when you are learning
> from scratch - little things like syntax errors - when you have typed exactly
> what is on the screen can be very frustrating.

Hi Richard,

thanks for your message -- it seems that you were looking at the tutorial
in the docs for Python 2.6 or 2.7, where the print statement is indeed
introduced as a statement.  In the tutorial for Python 3.1, which can be
found at http://docs.python.org/py3k/tutorial, the print function is
correctly introduced as a function and shown called with parentheses.

Regards,
Georg

From report at bugs.python.org  Sun Jul 11 11:33:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Jul 2010 09:33:51 +0000
Subject: [docs] [issue9184] open() doc: default value for buffering is -1,
	not None
In-Reply-To: <1278453489.46.0.972678242141.issue9184@psf.upfronthosting.co.za>
Message-ID: <1278840831.01.0.684827497825.issue9184@psf.upfronthosting.co.za>


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

Applied as r82801.

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

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

From report at bugs.python.org  Sun Jul 11 11:34:59 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 11 Jul 2010 09:34:59 +0000
Subject: [docs] [issue6867] return value of epoll.register
In-Reply-To: <1252461480.6.0.183531606536.issue6867@psf.upfronthosting.co.za>
Message-ID: <1278840899.78.0.247576544814.issue6867@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 11 11:42:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Jul 2010 09:42:15 +0000
Subject: [docs] [issue9184] open() doc: default value for buffering is -1,
	not None
In-Reply-To: <1278453489.46.0.972678242141.issue9184@psf.upfronthosting.co.za>
Message-ID: <1278841335.73.0.452825605357.issue9184@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 11 11:42:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Jul 2010 09:42:20 +0000
Subject: [docs] [issue7935] Cross-reference ast.literal_eval() from eval()
	docs
In-Reply-To: <1266241099.84.0.200250637967.issue7935@psf.upfronthosting.co.za>
Message-ID: <1278841340.54.0.0654866722901.issue7935@psf.upfronthosting.co.za>


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

Added reference in r82805. Thanks!

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

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

From report at bugs.python.org  Sun Jul 11 11:55:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 11 Jul 2010 09:55:41 +0000
Subject: [docs] [issue9223] distutils Command docs linking
In-Reply-To: <1278842118.98.0.447580746047.issue9223@psf.upfronthosting.co.za>
Message-ID: <1278842141.47.0.0126004235333.issue9223@psf.upfronthosting.co.za>


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


----------
nosy: +docs at python

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

From report at bugs.python.org  Sun Jul 11 12:16:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Jul 2010 10:16:07 +0000
Subject: [docs] [issue9184] open() doc: default value for buffering is -1,
	not None
In-Reply-To: <1278453489.46.0.972678242141.issue9184@psf.upfronthosting.co.za>
Message-ID: <1278843367.61.0.845020183571.issue9184@psf.upfronthosting.co.za>


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

?ric, I appreciate your wanting to help, but I don't think setting the stage after the fact makes much sense, especially since it is going away anyway...

----------

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

From report at bugs.python.org  Sun Jul 11 12:18:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Jul 2010 10:18:40 +0000
Subject: [docs] [issue9223] distutils Command docs linking
In-Reply-To: <1278842118.98.0.447580746047.issue9223@psf.upfronthosting.co.za>
Message-ID: <1278843520.68.0.503134588969.issue9223@psf.upfronthosting.co.za>


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

Note for someone wanting to propose a patch: distutils is in the process of being improved and cleaned up as distutils2. Improving the documentation is part of the process. Adding cross-links in the existing docs is okay, but I?d recommend against using too much time for distutils. For example, merging sections or doing other significant work would be IMO (which is only one opinion) time better spent on something else.

----------
assignee: tarek -> docs at python
components:  -Distutils
nosy: +alexis, merwok
stage:  -> needs patch
versions: +Python 3.1

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

From report at bugs.python.org  Sun Jul 11 12:22:41 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Jul 2010 10:22:41 +0000
Subject: [docs] [issue9184] open() doc: default value for buffering is -1,
	not None
In-Reply-To: <1278453489.46.0.972678242141.issue9184@psf.upfronthosting.co.za>
Message-ID: <1278843761.05.0.757959278883.issue9184@psf.upfronthosting.co.za>


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

I think it's still better to set it correctly. Even assuming that it will go away, if the stage is set correctly it will be easier to convert it to something else if necessary (e.g. if the stage is left on "patch review" it might be turned to "needs review" even if it gets closed).

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

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

From report at bugs.python.org  Sun Jul 11 12:26:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Jul 2010 10:26:25 +0000
Subject: [docs] [issue9223] distutils Command docs linking
In-Reply-To: <1278842118.98.0.447580746047.issue9223@psf.upfronthosting.co.za>
Message-ID: <1278843985.79.0.927786755139.issue9223@psf.upfronthosting.co.za>


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

Thanks, should be fixed in r82806.

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

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

From report at bugs.python.org  Sun Jul 11 12:29:09 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 11 Jul 2010 10:29:09 +0000
Subject: [docs] [issue9184] open() doc: default value for buffering is -1,
	not None
In-Reply-To: <1278453489.46.0.972678242141.issue9184@psf.upfronthosting.co.za>
Message-ID: <1278844149.08.0.00965128473597.issue9184@psf.upfronthosting.co.za>


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

Well, of course I don't want to make you unhappy, but don't ever expect me to make such a useless change myself :)  Especially when an issue is closed, nobody is going to look at it again except by accident.

----------

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

From report at bugs.python.org  Sun Jul 11 12:50:29 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 11 Jul 2010 10:50:29 +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: <1278845429.23.0.945708333753.issue7340@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 11 13:20:34 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 11 Jul 2010 11:20:34 +0000
Subject: [docs] [issue7674] select.select() corner cases: duplicate fds,
	out-of-range fds
In-Reply-To: <1263192751.1.0.719382931138.issue7674@psf.upfronthosting.co.za>
Message-ID: <1278847234.14.0.112171463707.issue7674@psf.upfronthosting.co.za>


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

Chris, to me it's as clear as mud but please produce a doc patch anyway. :)

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

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

From report at bugs.python.org  Sun Jul 11 13:30:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 11 Jul 2010 11:30:11 +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: <1278847811.82.0.734139607315.issue7340@psf.upfronthosting.co.za>


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


----------
resolution:  -> accepted
stage:  -> needs patch
versions:  -Python 3.0

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

From report at bugs.python.org  Sun Jul 11 13:36:47 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 11 Jul 2010 11:36:47 +0000
Subject: [docs] [issue9223] distutils Command docs linking
In-Reply-To: <1278842118.98.0.447580746047.issue9223@psf.upfronthosting.co.za>
Message-ID: <1278848207.21.0.993205746026.issue9223@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Eric, think about people who will be porting old code from distutils. They need to understand the behavior of distutils even if you'd like to force them to rewrite the logic for distutils2 from scratch.

----------

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

From report at bugs.python.org  Sun Jul 11 13:44:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Jul 2010 11:44:02 +0000
Subject: [docs] [issue7674] select.select() corner cases: duplicate fds,
	out-of-range fds
In-Reply-To: <1263192751.1.0.719382931138.issue7674@psf.upfronthosting.co.za>
Message-ID: <1278848642.05.0.377823472692.issue7674@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 11 16:28:57 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 11 Jul 2010 14:28:57 +0000
Subject: [docs] [issue2864] etree: Add XPath documentation
In-Reply-To: <1210863012.97.0.696135529968.issue2864@psf.upfronthosting.co.za>
Message-ID: <1278858537.79.0.940323737508.issue2864@psf.upfronthosting.co.za>


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


----------
nosy: +docs at python
stage:  -> needs patch

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

From report at bugs.python.org  Mon Jul 12 02:09:01 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Jul 2010 00:09:01 +0000
Subject: [docs] [issue4968] Clarify inspect.is<callable> method docs
In-Reply-To: <1232162769.03.0.624026715862.issue4968@psf.upfronthosting.co.za>
Message-ID: <1278893341.06.0.994846563866.issue4968@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.2 -Python 3.0

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

From jamon.ben at gmail.com  Mon Jul 12 08:12:28 2010
From: jamon.ben at gmail.com (Ben Fisher)
Date: Sun, 11 Jul 2010 23:12:28 -0700
Subject: [docs] Small suggestion, regular expressions
Message-ID: <AANLkTimR4Ym9AjtrJx7HAFuSgM09W3F7c2nGVUUbfb-u@mail.gmail.com>

Hi,
I have a small suggestion in Python docs, Standard library, section 7.2 re.
One of the examples 7.2.6.6. currently reads
>>> text = "Professor Abdolmalek, please report your absences promptly."
>>> re.sub("(\w)(\w+)(\w)", repl, text)
'Poefsrosr Aealmlobdk, pslaee reorpt your abnseces plmrptoy.'
>>> re.sub("(\w)(\w+)(\w)", repl, text)
'Pofsroser Aodlambelk, plasee reoprt yuor asnebces potlmrpy.'

I would suggest that the string literals be instead written
>>> re.sub(r"(\w)(\w+)(\w)", repl, text)
'Poefsrosr Aealmlobdk, pslaee reorpt your abnseces plmrptoy.'
>>> re.sub(r"(\w)(\w+)(\w)", repl, text)
'Pofsroser Aodlambelk, plasee reoprt yuor asnebces potlmrpy.'
with the r in front, even though this doesn't change the code's behavior.
In this way it would correspond with 7.2.6.7. and is better practice
in my opinion.


By the way, thanks for including such helpful examples. Ever since I
learned Python I've appreciated the documentation.

-Ben

From report at bugs.python.org  Mon Jul 12 20:06:42 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 12 Jul 2010 18:06:42 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1278958002.55.0.0942786510686.issue9132@psf.upfronthosting.co.za>


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

I agree with Terry's proposal. Here's a patch file for Doc/reference/expressions.rst that implements the change.

----------
Added file: http://bugs.python.org/file17967/issue9132.2.patch

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

From report at bugs.python.org  Mon Jul 12 21:52:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Jul 2010 19:52:00 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1278964320.7.0.73705780597.issue9132@psf.upfronthosting.co.za>


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

Looks good to me. Thanks Eli.

----------
stage: needs patch -> commit review

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

From report at bugs.python.org  Tue Jul 13 00:29:24 2010
From: report at bugs.python.org (rocky bernstein)
Date: Mon, 12 Jul 2010 22:29:24 +0000
Subject: [docs] [issue9237] Add sys.call_tracing to on-line sys module
	documentation
In-Reply-To: <1278973764.17.0.0501374635668.issue9237@psf.upfronthosting.co.za>
Message-ID: <1278973764.17.0.0501374635668.issue9237@psf.upfronthosting.co.za>


New submission from rocky bernstein <rocky at gnu.org>:

sys.call_tracing doesn't appear in Python documents and I think it should. For a start, one could use the docstring from sysmodule.c:

 call_tracing(func, args) -> object

 Call func(*args), while tracing is enabled.  The tracing state is saved, and restored afterwards.  This is intended to be called from a
debugger from a checkpoint, to recursively debug some other code.

Thanks.

----------
assignee: docs at python
components: Documentation
messages: 110145
nosy: docs at python, rocky
priority: normal
severity: normal
status: open
title: Add sys.call_tracing  to on-line sys module documentation
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul 13 01:33:24 2010
From: report at bugs.python.org (Ryan Kelly)
Date: Mon, 12 Jul 2010 23:33:24 +0000
Subject: [docs] [issue9238] zipfile incorrectly documented as not supporting
	archive	comments
In-Reply-To: <1278977604.77.0.794237265554.issue9238@psf.upfronthosting.co.za>
Message-ID: <1278977604.77.0.794237265554.issue9238@psf.upfronthosting.co.za>


New submission from Ryan Kelly <ryan at rfk.id.au>:

The zipfile module is prominently documented as "This module does not currently handle...ZIP files which have appended comments".  But as far as I can tell, it handles them fine - there's even a "comment" property on the ZipFile object that you can set to modify the comment.

I attach a simple doc patch that removes the apparently out-of-date information.

----------
assignee: docs at python
components: Documentation
files: zipfile_comment_doc.patch
keywords: patch
messages: 110147
nosy: docs at python, rfk
priority: normal
severity: normal
status: open
title: zipfile incorrectly documented as not supporting archive comments
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17973/zipfile_comment_doc.patch

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

From report at bugs.python.org  Tue Jul 13 23:49:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 13 Jul 2010 21:49:59 +0000
Subject: [docs] [issue9254] __import__ docstring should
	recommend	importlib.import_module()
In-Reply-To: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>
Message-ID: <1279057799.95.0.405829568808.issue9254@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
type:  -> feature request

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

From report at bugs.python.org  Wed Jul 14 01:24:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Jul 2010 23:24:18 +0000
Subject: [docs] [issue9254] __import__ docstring should
	recommend	importlib.import_module()
In-Reply-To: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>
Message-ID: <1279063457.46.0.765722016252.issue9254@psf.upfronthosting.co.za>


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

More rationale for not using a dummy fromlist, from Brett Cannon:

?Pulling from sys.modules is the correct way to do this. There are subtle
issues when using a bunk fromlist argument (empty modules, double
initialization, etc.). If one does not use importlib.import_module --
written *specifically* to prevent people from doing the nasty hack with the fromlist -- then you should use the sys.modules approach, period?

----------
nosy: +merwok

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

From report at bugs.python.org  Wed Jul 14 09:56:30 2010
From: report at bugs.python.org (Retro)
Date: Wed, 14 Jul 2010 07:56:30 +0000
Subject: [docs] [issue9258] Typos in docs for methods kqueue and kevent of
	module	'select'
In-Reply-To: <1279094189.8.0.55376365851.issue9258@psf.upfronthosting.co.za>
Message-ID: <1279094189.8.0.55376365851.issue9258@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

Fix the docs for every selected Python version. They all have the same typos.

The typos appear in the documentation of the 'select' module. These are the methods that need typo fixes:


select.kqueue()
(Only supported on BSD.)

Returns a kernel queue object object ...

[remove one of the words 'object' here because they are unnecessarily repeated]


select.kevent(ident, filter=KQ_FILTER_READ, flags=KQ_EV_ADD, fflags=0, data=0, udata=0)
(Only supported on BSD.)

Returns a kernel event object object; see section Kevent Objects below for the methods supported by kqueue objects.

[again, remove one of the words 'object' here because they are unnecessarily repeated; also, fix the word 'kqueue' to 'kevent']

----------
assignee: docs at python
components: Documentation
messages: 110255
nosy: Retro, docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: Typos in docs for methods kqueue and kevent of module 'select'
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul 14 10:00:35 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Jul 2010 08:00:35 +0000
Subject: [docs] [issue9258] Typos in docs for methods kqueue and kevent of
	module	'select'
In-Reply-To: <1279094189.8.0.55376365851.issue9258@psf.upfronthosting.co.za>
Message-ID: <1279094434.98.0.568870133778.issue9258@psf.upfronthosting.co.za>


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

Thanks, fixed in r82871.

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

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

From report at bugs.python.org  Wed Jul 14 10:05:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 14 Jul 2010 08:05:27 +0000
Subject: [docs] [issue9258] Typos in docs for methods kqueue and kevent of
	module	'select'
In-Reply-To: <1279094189.8.0.55376365851.issue9258@psf.upfronthosting.co.za>
Message-ID: <1279094727.51.0.988245904227.issue9258@psf.upfronthosting.co.za>


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

Just for your information, there is no 3.3 version yet. This value is useful for bugs that won?t be fixed in 3.2 (a.k.a. the py3k trunk).

----------
nosy: +merwok

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

From report at bugs.python.org  Wed Jul 14 10:20:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 14 Jul 2010 08:20:51 +0000
Subject: [docs] [issue9258] Typos in docs for methods kqueue and kevent of
	module	'select'
In-Reply-To: <1279094189.8.0.55376365851.issue9258@psf.upfronthosting.co.za>
Message-ID: <1279095651.32.0.967952104581.issue9258@psf.upfronthosting.co.za>


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

Ah yes, and please don't add me to the nosy list on doc issues.  docs at python is enough.

----------

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

From dechaume at cerfacs.fr  Mon Jul 12 11:43:05 2010
From: dechaume at cerfacs.fr (Antoine Dechaume)
Date: Mon, 12 Jul 2010 11:43:05 +0200
Subject: [docs] Bug ?
Message-ID: <5158A412-B1DE-4254-AEC8-337AC25E0D40@cerfacs.fr>

Hi,

HERE

It seems __setstate__ requires an argument, like in the examples, but  
the method doc do not mention it at all.


Antoine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100712/dd301aaa/attachment-0001.html>

From martin.ostergaard at gmail.com  Mon Jul 12 21:05:17 2010
From: martin.ostergaard at gmail.com (Martin Oestergaard)
Date: Mon, 12 Jul 2010 15:05:17 -0400
Subject: [docs] Python documentation in ePub?
Message-ID: <AANLkTimqO-l8s37mk-OtZZawpJ5BqvsNFVjVLGvW9MTY@mail.gmail.com>

I was wondering how easy it would be for you to release the Python
documentation in the ePub format (for use on e-reader devices)?

-- 
Sincerely,
Martin ?stergaard

From c.angustaylor at gmail.com  Tue Jul 13 23:24:24 2010
From: c.angustaylor at gmail.com (Charles Taylor)
Date: Tue, 13 Jul 2010 17:24:24 -0400
Subject: [docs] Broken Links
Message-ID: <AANLkTilwFSKU-5bnwtJqfhLSRTaFUqB1viN3JFmsHlGG@mail.gmail.com>

Hi there,
     I attempted to download the Python documentation just now, but got a
404 not found error. I tried all of the options.

Cheers,
C./


-- 
416-835-0314
www.CharlesAngusTaylor.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100713/beed568a/attachment.html>

From niraj at ncbs.res.in  Wed Jul 14 07:49:10 2010
From: niraj at ncbs.res.in (Niraj Dudani)
Date: Wed, 14 Jul 2010 11:19:10 +0530
Subject: [docs] Documentation for math.atan2() can be improved.
Message-ID: <4C3D4FD6.7070706@ncbs.res.in>

Hullo,

The documentation for math.atan2( y, x ) says:

--------8<--------
The point of atan2() is that the signs of both inputs are known to it, 
so it can compute the correct quadrant for the angle.
--------8<--------

This is correct, but incomplete. Another big advantage of using atan2() 
is that it works perfectly in the regime where x, the denominator, is 
close to, or equal to zero. While atan() will fail for x == 0, and may 
give inaccurate answers for x~= 0, atan2() should work fine.

Thanks,
Niraj


From fdrake at acm.org  Wed Jul 14 13:15:48 2010
From: fdrake at acm.org (Fred Drake)
Date: Wed, 14 Jul 2010 07:15:48 -0400
Subject: [docs] Python documentation in ePub?
In-Reply-To: <AANLkTimqO-l8s37mk-OtZZawpJ5BqvsNFVjVLGvW9MTY@mail.gmail.com>
References: <AANLkTimqO-l8s37mk-OtZZawpJ5BqvsNFVjVLGvW9MTY@mail.gmail.com>
Message-ID: <AANLkTik41fxC6-AobcpyxWRKK-sXZZevWEP-l459DxaA@mail.gmail.com>

On Mon, Jul 12, 2010 at 3:05 PM, Martin Oestergaard
<martin.ostergaard at gmail.com> wrote:
> I was wondering how easy it would be for you to release the Python
> documentation in the ePub format (for use on e-reader devices)?

Epub support is being developed for our documentation tools; I expect
some future release will see the addition of epub distributions.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"A storm broke loose in my mind."  --Albert Einstein

From report at bugs.python.org  Wed Jul 14 20:53:59 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 14 Jul 2010 18:53:59 +0000
Subject: [docs] [issue1349732] urllib.urlencode provides two features in one
	param
Message-ID: <1279133639.5.0.500397011301.issue1349732@psf.upfronthosting.co.za>


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

This was fixed as part of Issue8788. Closing this.

----------
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Jul 14 22:34:52 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 14 Jul 2010 20:34:52 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1279139692.28.0.958913199572.issue9132@psf.upfronthosting.co.za>


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

The patch was pretty good. Committed it in r82899 and r82900.
Thanks Eli for the patch & Terry for the review.

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

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

From report at bugs.python.org  Thu Jul 15 06:11:25 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 15 Jul 2010 04:11:25 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>


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

The documentation of the standard 'trace' module (Doc/library/trace.rst) is sorely lacking. Arguments are not explained, some key methods are not documented at all, and the CoverageResults class isn't documented.

Usage of these appears in the example but leaves the user confused as the only source of documentation for the example is the source code of the module.

I'm attaching a patch that fixes this issue, by providing documentation for the missing parts.

The patch was generated vs. the latest SVN trunk.

----------
assignee: docs at python
components: Documentation
files: tracedoc.3.patch
keywords: patch
messages: 110344
nosy: docs at python, eli.bendersky, tjreedy
priority: normal
severity: normal
status: open
title: trace.py documentation is incomplete
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18009/tracedoc.3.patch

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

From report at bugs.python.org  Thu Jul 15 13:46:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Jul 2010 11:46:31 +0000
Subject: [docs] [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1279194391.71.0.915073419478.issue9110@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul 15 17:41:44 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Jul 2010 15:41:44 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1279208503.47.0.512999222709.issue9264@psf.upfronthosting.co.za>


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

I am reviewing doc + patch against the code. Do not commit yet.

----------
assignee: docs at python -> tjreedy
stage:  -> patch review

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

From report at bugs.python.org  Fri Jul 16 16:20:20 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 16 Jul 2010 14:20:20 +0000
Subject: [docs] [issue1432343] Description of file-object read() method is
	wrong.
Message-ID: <1279290020.25.0.740068601133.issue1432343@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jul 16 18:22:20 2010
From: report at bugs.python.org (=?utf-8?q?Matthieu_Labb=C3=A9?=)
Date: Fri, 16 Jul 2010 16:22:20 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1279297340.86.0.593936467731.issue459007@psf.upfronthosting.co.za>


Changes by Matthieu Labb? <bugs.python.org at mattlabbe.com>:


----------
nosy: +matthieu.labbe

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

From report at bugs.python.org  Fri Jul 16 21:59:55 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 16 Jul 2010 19:59:55 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1279310394.59.0.620655860485.issue459007@psf.upfronthosting.co.za>


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

Tim, Brian I've added you to the nosy list as I think you could assist.  Unless I get a response within the next 10 years I will close this as "out of date"

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

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

From report at bugs.python.org  Fri Jul 16 22:10:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 16 Jul 2010 20:10:18 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1279311016.75.0.36527608575.issue459007@psf.upfronthosting.co.za>


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

Out of date seems an inaccurate status to me. Bugs may take weeks to years to be fixed. This one is tagged easy (according to amk in msg73954), so perhaps someone will have a go at it during a Bug Day or a spring, or one of the docs people will just do it (e.g. me after my summer job).

----------
nosy: +merwok

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

From report at bugs.python.org  Fri Jul 16 22:12:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 16 Jul 2010 20:12:31 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1279311150.88.0.221147374857.issue459007@psf.upfronthosting.co.za>


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

s/spring/sprint/ :)

----------

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

From georg at python.org  Fri Jul 16 22:19:19 2010
From: georg at python.org (Georg Brandl)
Date: Fri, 16 Jul 2010 22:19:19 +0200
Subject: [docs] Small suggestion, regular expressions
In-Reply-To: <AANLkTimR4Ym9AjtrJx7HAFuSgM09W3F7c2nGVUUbfb-u@mail.gmail.com>
References: <AANLkTimR4Ym9AjtrJx7HAFuSgM09W3F7c2nGVUUbfb-u@mail.gmail.com>
Message-ID: <4C40BEC7.9060506@python.org>

Am 12.07.2010 08:12, schrieb Ben Fisher:
> Hi,
> I have a small suggestion in Python docs, Standard library, section 7.2 re.
> One of the examples 7.2.6.6. currently reads
>>>> text = "Professor Abdolmalek, please report your absences promptly."
>>>> re.sub("(\w)(\w+)(\w)", repl, text)
> 'Poefsrosr Aealmlobdk, pslaee reorpt your abnseces plmrptoy.'
>>>> re.sub("(\w)(\w+)(\w)", repl, text)
> 'Pofsroser Aodlambelk, plasee reoprt yuor asnebces potlmrpy.'
> 
> I would suggest that the string literals be instead written
>>>> re.sub(r"(\w)(\w+)(\w)", repl, text)
> 'Poefsrosr Aealmlobdk, pslaee reorpt your abnseces plmrptoy.'
>>>> re.sub(r"(\w)(\w+)(\w)", repl, text)
> 'Pofsroser Aodlambelk, plasee reoprt yuor asnebces potlmrpy.'
> with the r in front, even though this doesn't change the code's behavior.
> In this way it would correspond with 7.2.6.7. and is better practice
> in my opinion.

Hi Ben,

thanks for the suggestion, that is indeed the better way to write
these regexes.  Should be corrected now and will be online soon.

regards,
Georg

From report at bugs.python.org  Fri Jul 16 22:58:47 2010
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 16 Jul 2010 20:58:47 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1279313927.14.0.314410837293.issue459007@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

FWIW, I think the rules are fairly well explained in the comments in PC/getpathp.c; last time I looked at this, the only thing I couldn't really decide was where in the official docs these comments should be put (after reformatting and minor rewording etc)

----------

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

From report at bugs.python.org  Sat Jul 17 01:08:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Jul 2010 23:08:46 +0000
Subject: [docs] [issue9274] code.InteractiveInterpreter fails to change
	locals when	invoked in a function
In-Reply-To: <1279300874.85.0.408315798568.issue9274@psf.upfronthosting.co.za>
Message-ID: <1279321726.22.0.176177214762.issue9274@psf.upfronthosting.co.za>


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

locals() does not give you a copy of the locals dictionary that you can modify and expect the values to affect the actual locals they were copied from.  This is documented:

http://docs.python.org/library/functions.html#locals

You would need to pass InteractiveInterpreter the "real" locals dict from the frame to make your code work, and it sounds like you've already done this.  However, I don't believe that this is going to work in the general case (eg: in the face of nested scopes), which is why locals() is not updatable. The use case for InteractiveInterpreter is implementing a python-command-line-like utility, and thus has no need to update the locals in the current function.

A doc note about this in InteractiveInterpreter along the lines of the one in the 'exec' docs is almost certainly appropriate, so I'll leave this open as a doc bug.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jul 17 01:14:48 2010
From: report at bugs.python.org (Eric Promislow)
Date: Fri, 16 Jul 2010 23:14:48 +0000
Subject: [docs] [issue9274] code.InteractiveInterpreter fails to change
	locals when	invoked in a function
In-Reply-To: <1279300874.85.0.408315798568.issue9274@psf.upfronthosting.co.za>
Message-ID: <1279322088.55.0.113144414925.issue9274@psf.upfronthosting.co.za>


Eric Promislow <ericp at activestate.com> added the comment:

Thanks for the response.

Note that our use case *is* to implement Python-console
functionality, but sometimes we do this in the context
of a currently running Python program, inside a function.
That's why I wrote the repro that way.  Using
code.InteractiveInterpreter(locals()).runsource(...)
in a function corresponds to interacting with the
debugger in a function, while the second call to
runsource() corresponds to interacting with the
program when it's stepping through top-level code.

Keep in mind that all of this takes place while
control flow of the main program is stuck in the
debugger's read-eval-print loop.

It would be useful if there was a way of accessing the
localsplus container in Python code

----------

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

From report at bugs.python.org  Sat Jul 17 01:23:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Jul 2010 23:23:14 +0000
Subject: [docs] [issue9274] code.InteractiveInterpreter fails to change
	locals when	invoked in a function
In-Reply-To: <1279300874.85.0.408315798568.issue9274@psf.upfronthosting.co.za>
Message-ID: <1279322593.99.0.840382080636.issue9274@psf.upfronthosting.co.za>


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

Well, you could discuss that possibility on python-dev, I suppose.

As long as you don't need the changes to persist outside of the debugging loop, you can use InteractiveInterpreter as designed and keep passing it the same (modified) dict every time, as was done in the pdb fix.

----------

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

From report at bugs.python.org  Sat Jul 17 01:31:33 2010
From: report at bugs.python.org (Eric Promislow)
Date: Fri, 16 Jul 2010 23:31:33 +0000
Subject: [docs] [issue9274] code.InteractiveInterpreter fails to change
	locals when	invoked in a function
In-Reply-To: <1279300874.85.0.408315798568.issue9274@psf.upfronthosting.co.za>
Message-ID: <1279323092.32.0.0634079718887.issue9274@psf.upfronthosting.co.za>


Eric Promislow <ericp at activestate.com> added the comment:

David, that won't work for a reason I'll get into in a bit.

I would drop the priority of this ... Komodo has a had a
Python debugger since late 2000, we only fixed updating
variables while debugging (using the variable viewer) yesterday,
and received fewer than 10 complaints about that over the years.

While looking at the code, something seemed wrong with our
handling of the variables in the interactive shell.  I tested
it, and it failed, and then wrote the standalone Python code
to isolate the problem.

Your solution will work sometimes, but not completely.  When
you're in interactive mode while debugging, you can type arbitrary
Python code, but can also use the variable viewer in the UI to change
variables.  These two functions are handled by different code
paths.

My recommendation is to resolve this as a limitation, and
document the module.

----------

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

From dcarter at mercycorps.org  Wed Jul 14 21:12:57 2010
From: dcarter at mercycorps.org (Doug Carter)
Date: Wed, 14 Jul 2010 12:12:57 -0700
Subject: [docs] Bug in email example
Message-ID: <20100714191257.GA24105@mercycorps.org>


On the page:

  http://docs.python.org/library/email-examples.html

At the bottom, under the heading:

  Here's an example of how to create an HTML message with an alternative
  plain text version:

In the code sample, the import from lines are incorrect:

  from email.mime.multipart import MIMEMultipart
  from email.mime.text import MIMEText

They should be:

  from email.MIMEMultipart import MIMEMultipart
  from email.MIMEText import MIMEText


Best,

Doug Carter





From d1_doris at hotmail.com  Fri Jul 16 18:15:41 2010
From: d1_doris at hotmail.com (Doris Hoogeveen)
Date: Fri, 16 Jul 2010 18:15:41 +0200
Subject: [docs] A bug in the documentation
Message-ID: <SNT144-w169B8FEAE2DE8BD0E9353DA6BC0@phx.gbl>


Hello,
The example on how to use the signal module at the bottom of paragraph 17.4 in the Python documentation (see: http://docs.python.org/library/signal.html#signal.SIG_DFL) does not work. 
This is the error I keep getting: AttributeError: 'module' object has no attribute 'SIGALRM'
I'm still quite new to Python, so unfortunately I don't have any suggestions on what should be changed. I'm sorry about that.
kind regards,
Doris 		 	   		  
_________________________________________________________________
Alles wat je wilt weten over Windows 7, en meer !
http://www.windows.nl/windows7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100716/6c69a33c/attachment.html>

From d1_doris at hotmail.com  Fri Jul 16 18:27:58 2010
From: d1_doris at hotmail.com (Doris Hoogeveen)
Date: Fri, 16 Jul 2010 18:27:58 +0200
Subject: [docs] nevermind!
Message-ID: <SNT144-w402DAEA458767CB3DF4F7AA6BC0@phx.gbl>


Hello,
I'm sorry to have bothered you. I should've guessed it was just me who didn't understand something.I read the explanation more carefully and now I know the example is right.
Once again I'm sorry. You probably receive a lot of mail.
Kind regards,
Doris 		 	   		  
_________________________________________________________________
De Nieuwste Internet Explorer speciaal voor Hotmail, download nu gratis
http://www.microsoft.com/netherlands/ie8/hotmail.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100716/d66a1698/attachment.html>

From merwok at netwok.org  Sat Jul 17 09:25:34 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 17 Jul 2010 09:25:34 +0200
Subject: [docs] Bug in email example
In-Reply-To: <20100714191257.GA24105@mercycorps.org>
References: <20100714191257.GA24105@mercycorps.org>
Message-ID: <4C415AEE.4050003@netwok.org>

Hello Doug

Thanks for your interest in improving Python.

Email modules have been renamed between 2.4 and 2.5, so the examples are
actually correct. Code using the older names still work because of
aliases provided by the package, sadly without deprecation warnings.

Kind regards


From report at bugs.python.org  Sun Jul 18 00:09:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 22:09:00 +0000
Subject: [docs] [issue9288] Disambiguate :option: and :cmdoption:
In-Reply-To: <1279404540.57.0.963765007492.issue9288@psf.upfronthosting.co.za>
Message-ID: <1279404540.57.0.963765007492.issue9288@psf.upfronthosting.co.za>


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

I made a doc patch in a followup to http://mail.python.org/pipermail/python-dev/2010-July/102011.html

----------
assignee: docs at python
components: Documentation
files: improve-check.diff
keywords: needs review, patch
messages: 110606
nosy: docs at python, merwok
priority: normal
severity: normal
status: open
title: Disambiguate :option: and :cmdoption:
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18046/improve-check.diff

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

From report at bugs.python.org  Sun Jul 18 00:09:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 22:09:13 +0000
Subject: [docs] [issue9288] Disambiguate :option: and :cmdoption:
In-Reply-To: <1279404540.57.0.963765007492.issue9288@psf.upfronthosting.co.za>
Message-ID: <1279404553.61.0.2699599677.issue9288@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18046/improve-check.diff

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

From report at bugs.python.org  Sun Jul 18 00:09:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 22:09:23 +0000
Subject: [docs] [issue9288] Disambiguate :option: and :cmdoption:
In-Reply-To: <1279404540.57.0.963765007492.issue9288@psf.upfronthosting.co.za>
Message-ID: <1279404563.33.0.932376436064.issue9288@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file18047/disambiguate-option-cmdoption.diff

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

From report at bugs.python.org  Sun Jul 18 00:17:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 22:17:13 +0000
Subject: [docs] [issue8910] Write a text file explaining why Lib/test/data
	exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1279405032.92.0.390594600858.issue8910@psf.upfronthosting.co.za>


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

Adding people listed for the testing interest area in the maintainers file.

----------
nosy: +giampaolo.rodola, michael.foord, pitrou

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

From report at bugs.python.org  Sun Jul 18 00:18:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 22:18:16 +0000
Subject: [docs] [issue6722] collections.namedtuple: confusing example
In-Reply-To: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
Message-ID: <1279405096.78.0.389133911956.issue6722@psf.upfronthosting.co.za>


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


----------
nosy: +docs at python

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

From report at bugs.python.org  Sun Jul 18 00:32:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 22:32:55 +0000
Subject: [docs] [issue4819] Misc/cheatsheet needs updating
In-Reply-To: <1230988594.32.0.497089911482.issue4819@psf.upfronthosting.co.za>
Message-ID: <1279405975.04.0.31426341165.issue4819@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 18 01:02:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 23:02:46 +0000
Subject: [docs] [issue7303] pkgutil lacks documentation for useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1279407766.07.0.746790382881.issue7303@psf.upfronthosting.co.za>


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

Thanks for your help proposal Ulrik. If I understand the documentation correctly, docstrings should contain enough usage information but not too much. In pkgutil, some examples and long explanations could be removed after you move them to the reST doc.

Make sure to work from a checkout of 3.2 (branch named py3k) to have the latest updates. This page contains some tips about patches: http://www.python.org/dev/patches/

You can ask any questions here or on the docs at python.org mailing list. Thanks again.

----------

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

From report at bugs.python.org  Sun Jul 18 01:04:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 23:04:15 +0000
Subject: [docs] [issue7303] pkgutil lacks documentation for useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1279407855.58.0.228593565534.issue7303@psf.upfronthosting.co.za>


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

Other useful advice:
http://docs.pythonsprints.com/core_development/beginners#building-the-documentation
http://docs.python.org/documenting/

----------

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

From report at bugs.python.org  Sun Jul 18 01:05:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Jul 2010 23:05:07 +0000
Subject: [docs] [issue7303] pkgutil lacks documentation for useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1279407907.72.0.152619136763.issue7303@psf.upfronthosting.co.za>


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

Wrong link, sorry everyone for the noise:
http://docs.pythonsprints.com/core_development/beginners.html#building-the-documentation

----------

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

From report at bugs.python.org  Sun Jul 18 12:03:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jul 2010 10:03:51 +0000
Subject: [docs] [issue9288] Disambiguate :option: and :cmdoption:
In-Reply-To: <1279404540.57.0.963765007492.issue9288@psf.upfronthosting.co.za>
Message-ID: <1279447430.95.0.915302124203.issue9288@psf.upfronthosting.co.za>


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

This patch is not really accurate; cmdoption *is* the directive where the link goes to.  option is the role to link to them (or not).

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

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

From bgailer at gmail.com  Sun Jul 18 03:17:05 2010
From: bgailer at gmail.com (bob gailer)
Date: Sat, 17 Jul 2010 21:17:05 -0400
Subject: [docs] Bug in http://docs.python.org/py3k/library/io.html#
Message-ID: <4C425611.2030903@gmail.com>

Under 15.2.1 - io.open it says: "/file/ is either a string or bytes 
object giving the name (and the path if the file isn't in the current 
working directory)"

Inaccurate in that you can provide the path even if the file is in the 
current working directory.

Better: "/file/ is either a string or bytes object giving either the 
filename or path + filename . If just the filename is given the current 
working directory is the path."

-- 
Bob Gailer
919-636-4239
Chapel Hill NC

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

From report at bugs.python.org  Sun Jul 18 15:06:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 18 Jul 2010 13:06:04 +0000
Subject: [docs] [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1279458364.06.0.373610903818.issue9110@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I've uploaded a new patch with additions to the docs. Let me know if it is ok or if you have any suggested amendments.

----------
Added file: http://bugs.python.org/file18049/contextlib_docs.patch

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

From report at bugs.python.org  Sun Jul 18 15:43:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Jul 2010 13:43:38 +0000
Subject: [docs] [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1279460618.58.0.458448462032.issue9110@psf.upfronthosting.co.za>


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

Applied, with small changes, in r82951.

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

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

From report at bugs.python.org  Sun Jul 18 23:12:12 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Jul 2010 21:12:12 +0000
Subject: [docs] [issue9110] contextlib.ContextDecorator
In-Reply-To: <1277765898.65.0.314299135702.issue9110@psf.upfronthosting.co.za>
Message-ID: <1279487532.25.0.325162969099.issue9110@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jul 19 04:30:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 02:30:37 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1279506637.6.0.295744599663.issue7229@psf.upfronthosting.co.za>


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

Georg,

Do you mind if I take this over?

While I have issues with east/west of UTC terminology, it is the accepted terminology throughout the manual and Brian's rewording is an improvement.

----------

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

From report at bugs.python.org  Mon Jul 19 05:51:27 2010
From: report at bugs.python.org (Scott Lawrence)
Date: Mon, 19 Jul 2010 03:51:27 +0000
Subject: [docs] [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1279511487.14.0.617790305373.issue9105@psf.upfronthosting.co.za>


Scott Lawrence <bytbox at gmail.com> added the comment:

Patch warning in relevant places of pickle's vulnerability to insecure data, including the place referenced by issue8855.

----------
keywords: +patch
nosy: +bytbox
Added file: http://bugs.python.org/file18057/picklesec.patch

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

From report at bugs.python.org  Mon Jul 19 05:58:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 03:58:05 +0000
Subject: [docs] [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1279511885.82.0.233130473645.issue9105@psf.upfronthosting.co.za>


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

LGTM

Unless someone objects, I will check that the patch generates reasonable HTML and apply.

----------
assignee: docs at python -> belopolsky
resolution:  -> accepted
stage: needs patch -> commit review

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

From report at bugs.python.org  Mon Jul 19 08:40:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 19 Jul 2010 06:40:24 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1279521624.23.0.361443303413.issue7229@psf.upfronthosting.co.za>


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

Please do!

----------
assignee: georg.brandl -> belopolsky

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

From report at bugs.python.org  Mon Jul 19 09:03:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 19 Jul 2010 07:03:51 +0000
Subject: [docs] [issue9288] Disambiguate :option: and :cmdoption:
In-Reply-To: <1279404540.57.0.963765007492.issue9288@psf.upfronthosting.co.za>
Message-ID: <1279523031.0.0.577485751593.issue9288@psf.upfronthosting.co.za>


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

The docs on :option: should now be clear in r82961.

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

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

From report at bugs.python.org  Mon Jul 19 10:59:59 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Jul 2010 08:59:59 +0000
Subject: [docs] [issue9300] c/profile Profile class is not documented
In-Reply-To: <1279529999.64.0.448186271222.issue9300@psf.upfronthosting.co.za>
Message-ID: <1279529999.64.0.448186271222.issue9300@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

http://docs.python.org/library/profile.html

...while it is, for example, for hotshot module:
http://docs.python.org/library/hotshot.html#hotshot.Profile

Profile class contains some useful methods which are surely worth mentioning, like print_stat() and runcall() above all.

----------
assignee: docs at python
components: Documentation
messages: 110722
nosy: docs at python, giampaolo.rodola
priority: normal
severity: normal
stage: needs patch
status: open
title: c/profile Profile class is not documented
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Jul 19 11:43:26 2010
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 19 Jul 2010 09:43:26 +0000
Subject: [docs] [issue9302] Distutils document problem?
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>


New submission from Ray.Allen <ysj.ray at gmail.com>:

The distutils api document for class Extension:

http://docs.python.org/dev/py3k/distutils/apiref.html#distutils.core.Extension

Among the argument, in fact, the type of the arguments "sources", "include_dirs", "library_dirs", "libraries", "runtime_library_dirs" must be list, but all of them are marked as "string". I think this is a problem. 

Here is a patch for this, against py3k.

----------
assignee: docs at python
components: Documentation
files: distutils_apiref.diff
keywords: patch
messages: 110724
nosy: docs at python, ysj.ray
priority: normal
severity: normal
status: open
title: Distutils document problem?
versions: Python 3.2
Added file: http://bugs.python.org/file18061/distutils_apiref.diff

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

From report at bugs.python.org  Mon Jul 19 12:11:00 2010
From: report at bugs.python.org (Ray.Allen)
Date: Mon, 19 Jul 2010 10:11:00 +0000
Subject: [docs] [issue9300] c/profile Profile class is not documented
In-Reply-To: <1279529999.64.0.448186271222.issue9300@psf.upfronthosting.co.za>
Message-ID: <1279534260.26.0.265615231699.issue9300@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

I guess this is intended not documented:

http://docs.python.org/dev/py3k/library/profile.html#extensions-deriving-better-profilers

Here it said:
"The Profile class of both modules, profile and cProfile, were written so that derived classes could be developed to extend the profiler. The details are not described here, as doing this successfully requires an expert understanding of how the Profile class works internally. Study the source code of the module carefully if you want to pursue this."

These sentences guide reader to read the source code.

----------
nosy: +ysj.ray

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

From Nicholas.Cameron at ecs.vuw.ac.nz  Mon Jul 19 12:37:51 2010
From: Nicholas.Cameron at ecs.vuw.ac.nz (Nicholas Cameron)
Date: Mon, 19 Jul 2010 22:37:51 +1200
Subject: [docs] possible bug in Python tutorial  sect 9.9
Message-ID: <4C442AFF.6060009@ecs.vuw.ac.nz>

Hi, there is either a bug or scope for some extra clarity in the 
iterators section of the Python tutorial:

http://docs.python.org/tutorial/classes.html#iterators

The docs state that the method used to get an iterator for an object is 
iter() (after the first example in the section), but after the second 
example, uses __iter__(). I'm new to Python so not sure if either is 
correct and the other incorrect or if the syntax changes when 
implementing the method yourself, I guess some clarification would help 
if it is the latter case.

Cheers, Nick

From georg at python.org  Mon Jul 19 14:26:01 2010
From: georg at python.org (Georg Brandl)
Date: Mon, 19 Jul 2010 13:26:01 +0100
Subject: [docs] possible bug in Python tutorial  sect 9.9
In-Reply-To: <4C442AFF.6060009@ecs.vuw.ac.nz>
References: <4C442AFF.6060009@ecs.vuw.ac.nz>
Message-ID: <4C444459.8060504@python.org>

Am 19.07.2010 11:37, schrieb Nicholas Cameron:
> Hi, there is either a bug or scope for some extra clarity in the 
> iterators section of the Python tutorial:
> 
> http://docs.python.org/tutorial/classes.html#iterators
> 
> The docs state that the method used to get an iterator for an object is 
> iter() (after the first example in the section), but after the second 
> example, uses __iter__(). I'm new to Python so not sure if either is 
> correct and the other incorrect or if the syntax changes when 
> implementing the method yourself, I guess some clarification would help 
> if it is the latter case.

Hi Nick,

yes, the latter is indeed the case.  I've added a line now to the example
for the class defining __iter__() that shows that calling iter() works
on it.

regards,
Georg

From report at bugs.python.org  Mon Jul 19 13:37:04 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 19 Jul 2010 11:37:04 +0000
Subject: [docs] [issue9300] c/profile Profile class is not documented
In-Reply-To: <1279529999.64.0.448186271222.issue9300@psf.upfronthosting.co.za>
Message-ID: <1279539424.83.0.827988713774.issue9300@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Oh right, I didn't notice that.
Closing this out as invalid.

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

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

From report at bugs.python.org  Mon Jul 19 14:41:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Jul 2010 12:41:35 +0000
Subject: [docs] [issue9302] Distutils document problem?
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1279543295.34.0.758158376846.issue9302@psf.upfronthosting.co.za>


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


----------
nosy: +tarek

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

From report at bugs.python.org  Mon Jul 19 17:25:53 2010
From: report at bugs.python.org (Carl Chenet)
Date: Mon, 19 Jul 2010 15:25:53 +0000
Subject: [docs] [issue9304] unreproducible example in the memoryview
	documentation
In-Reply-To: <1279553153.05.0.828630884678.issue9304@psf.upfronthosting.co.za>
Message-ID: <1279553153.05.0.828630884678.issue9304@psf.upfronthosting.co.za>


New submission from Carl Chenet <chaica at ohmytux.com>:

Hi,

In the current documentation at http://docs.python.org/library/stdtypes.html#memoryview, the first example announces : 

>>> v = memoryview('abcefg')
>>> v[1]
'b'
>>> v[-1]
'g'
>>> v[1:4]
<memory at 0x77ab28>
>>> str(v[1:4])
'bce'

Trying to reproduce this example I got : 

$ python
Python 2.7 (r27:82500, Jul 13 2010, 17:48:51) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> v = memoryview('abcefg')
>>> v[1]
'b'
>>> v[-1]
'g'
>>> v[1:4]
<memory at 0xa2a510>
>>> str(v[1:4])
'<memory at 0xa2a5a8>'

The last line of the example in the documentation is not reproducible. Hope it's only a documentation issue.

Bye,
Carl Chenet

----------
assignee: docs at python
components: Documentation
messages: 110766
nosy: chaica_, docs at python
priority: normal
severity: normal
status: open
title: unreproducible example in the memoryview documentation
versions: Python 2.7

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

From report at bugs.python.org  Mon Jul 19 17:57:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 15:57:26 +0000
Subject: [docs] [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1279555045.67.0.320446433176.issue9105@psf.upfronthosting.co.za>


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

The patch does not apply to py3k.  Also, when you generate patches please do so from the root directory of the branch.  For example, tutorial/inputoutput.rst should be patched as Doc/tutorial/inputoutput.rst.

Thanks.

----------

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

From report at bugs.python.org  Mon Jul 19 18:21:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 16:21:45 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I am opening this to supersede issue7229.  See discussion following msg107148.

In many places offsets representing the difference between local time and UTC are described as minutes or seconds east or west of UTC.   This is not correct because UTC is not a place and minutes and seconds don't measure distance in this context.  Replacing UTC with the Prime Meridian will not fix that because some regions in the western hemisphere use positive offsets from UTC.  or example, Madrid is at 3? 42' West, but uses Central European Time which is UTC+1.

I believe geographical references in the python documentation are irrelevant.  What users are interested in is how to convert local time to UTC and UTC to local time rather than what is the sign of time.timezone in Madrid.

I suggest the following wording for time.timezone description:

time.timezone: The number of seconds one must add to the local time to arrive at UTC.

Similarly, tzinfo.utcoffset() can be defined as "Returns timedelta one must add to UTC to arrive at local time."

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 110774
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Don't use east/west of UTC in date/time documentation
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul 19 18:28:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Jul 2010 16:28:17 +0000
Subject: [docs] [issue9304] unreproducible example in the memoryview
	documentation
In-Reply-To: <1279553153.05.0.828630884678.issue9304@psf.upfronthosting.co.za>
Message-ID: <1279556896.99.0.650394624903.issue9304@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jul 19 18:28:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Jul 2010 16:28:29 +0000
Subject: [docs] [issue9304] unreproducible example in the memoryview
	documentation
In-Reply-To: <1279553153.05.0.828630884678.issue9304@psf.upfronthosting.co.za>
Message-ID: <1279556909.12.0.15752167526.issue9304@psf.upfronthosting.co.za>


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


----------
nosy: +merwok

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

From report at bugs.python.org  Mon Jul 19 18:42:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 16:42:05 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1279557725.28.0.0531957042529.issue9305@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +Manual entry for time.daylight can be misleading

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

From report at bugs.python.org  Mon Jul 19 18:42:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 16:42:19 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1279557738.7.0.451210364964.issue7229@psf.upfronthosting.co.za>


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

After reading the new wording on a formatted page, I don't like the proposed changes:

"""
time.altzone

When daylight is nonzero, altzone specifies the offset of the local DST timezone, in seconds west of UTC. This is negative if the local DST timezone is east of UTC ...
"""

In the second sentence, it is not clear whether "this" refers to altzone or daylight.

"""
time.daylight

Whether or not DST is in effect, daylight specifies the DST offset. 
"""

This is simply wrong.  time.daylight does not necessarily specify the DST offset (and I think it does not on most systems.)  POSIX requires that "The tzset() function also shall set the external variable daylight to 0 if Daylight Savings Time conversions should never be applied for the timezone in use; otherwise, non-zero." [1]  This means that a compliant system may store just 0 or 1 in daylight rather than the DST offset.

For example, on my OSX system:

$ TZ=America/New_York python -c "import time; print(time.daylight)"
1
$ TZ=UTC python -c "import time; print(time.daylight)"
0
$ TZ=EDT python -c "import time; print(time.daylight)"
0

I will think some more on how to improve the current documentation, but at least with respect to time.daylight, current language is better than the proposed change.




[1] http://www.opengroup.org/onlinepubs/009695399/functions/tzset.html

----------
superseder:  -> Don't use east/west of UTC in date/time documentation

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

From report at bugs.python.org  Mon Jul 19 19:13:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jul 2010 17:13:20 +0000
Subject: [docs] [issue9304] unreproducible example in the memoryview
	documentation
In-Reply-To: <1279553153.05.0.828630884678.issue9304@psf.upfronthosting.co.za>
Message-ID: <1279559600.24.0.779740837217.issue9304@psf.upfronthosting.co.za>


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

Right, it should be `v[1:4].tobytes()` instead.

----------

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

From report at bugs.python.org  Mon Jul 19 19:50:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 17:50:25 +0000
Subject: [docs] [issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented
In-Reply-To: <1279561825.23.0.120090245801.issue9307@psf.upfronthosting.co.za>
Message-ID: <1279561825.23.0.120090245801.issue9307@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Is there a reason for not documenting Py_TPFLAGS_LONG_SUBCLASS (Py_TPFLAGS_INT_SUBCLASS in 2.x)?

This flag is used in PyLong_Check, but neither this flag or its inheritance properties are explained anywhere in the docs.

See also issue5476.

----------
assignee: docs at python
components: Documentation
messages: 110787
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_TPFLAGS_LONG_SUBCLASS is not documented
type: feature request

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

From report at bugs.python.org  Mon Jul 19 20:07:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 18:07:59 +0000
Subject: [docs] [issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented
In-Reply-To: <1279561825.23.0.120090245801.issue9307@psf.upfronthosting.co.za>
Message-ID: <1279562879.19.0.765360966702.issue9307@psf.upfronthosting.co.za>


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

Here are other similar flags that are not documented:


/* These flags are used to determine if a type is a subclass. */
#define Py_TPFLAGS_INT_SUBCLASS         (1L<<23)
#define Py_TPFLAGS_LONG_SUBCLASS        (1L<<24)
#define Py_TPFLAGS_LIST_SUBCLASS        (1L<<25)
#define Py_TPFLAGS_TUPLE_SUBCLASS       (1L<<26)
#define Py_TPFLAGS_BYTES_SUBCLASS       (1L<<27)
#define Py_TPFLAGS_UNICODE_SUBCLASS     (1L<<28)
#define Py_TPFLAGS_DICT_SUBCLASS        (1L<<29)
#define Py_TPFLAGS_BASE_EXC_SUBCLASS    (1L<<30)
#define Py_TPFLAGS_TYPE_SUBCLASS        (1L<<31)

On a similar note, TPFLAGS_IS_ABSTRACT is exposed in the inspect module, but is not documented in either inspect module documentation or C API documentation.

I believe that as long as these flags are available from the type objects as __flags__, all valid bits should be exposed in inspect module and properly documented.

----------
components: +Library (Lib)
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jul 19 20:11:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jul 2010 18:11:05 +0000
Subject: [docs] [issue9304] unreproducible example in the memoryview
	documentation
In-Reply-To: <1279553153.05.0.828630884678.issue9304@psf.upfronthosting.co.za>
Message-ID: <1279563065.22.0.973150655577.issue9304@psf.upfronthosting.co.za>


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

Fixed in r82981. Thank you for the report!

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

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

From report at bugs.python.org  Mon Jul 19 20:17:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Jul 2010 18:17:25 +0000
Subject: [docs] [issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented
In-Reply-To: <1279561825.23.0.120090245801.issue9307@psf.upfronthosting.co.za>
Message-ID: <1279563445.49.0.71847332292.issue9307@psf.upfronthosting.co.za>


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

It would probably be more useful to document them in the C API and put a reference to that in the inspect module docs. These flags are primarily useful for C extension developers, there's little point checking them from Python code.

----------
nosy: +pitrou
versions: +Python 3.1

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

From report at bugs.python.org  Mon Jul 19 20:32:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 19 Jul 2010 18:32:21 +0000
Subject: [docs] [issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented
In-Reply-To: <1279563445.49.0.71847332292.issue9307@psf.upfronthosting.co.za>
Message-ID: <AANLkTimJrP7V5TuODHTWuegA24uQev7WuS1lq9LTUAM3@mail.gmail.com>


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

On Mon, Jul 19, 2010 at 2:17 PM, Antoine Pitrou <report at bugs.python.org> wrote:

> .. These flags are primarily useful for C extension developers, there's little point checking them from Python code.

Of course there is: it helps debugging problems in types implemented
in C.  For example, someone working on the numpy issue described in
msg110788, would probably appreciate having
inspect.TPFLAGS_INT_SUBCLASS and would probaly use it in his or hers
unit tests.

My point is: we have __flags__ attribute on type objects exposed in
python there should be a way to interpret what it means without
looking up object.h or C API documentation.

BTW, __flags__ itself could grow a docstring and deserves to be
mentioned in the docs.  Note that copyreg.py uses it to determine
wither a class is dynamically allocated.   Maybe this should also go
to inspect as inspect.isheaptype().

----------

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

From report at bugs.python.org  Mon Jul 19 20:47:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Jul 2010 18:47:39 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1279565258.35.0.0541032190325.issue459007@psf.upfronthosting.co.za>


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

using/windows.rst seems the best place to add comments from PC/getpathp.c, under the ?Finding modules? section.

----------

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

From report at bugs.python.org  Mon Jul 19 23:00:57 2010
From: report at bugs.python.org (Tim Lesher)
Date: Mon, 19 Jul 2010 21:00:57 +0000
Subject: [docs] [issue9204] The documentation of PyType_Type in py3k
	mentions	types.TypeType
In-Reply-To: <1278612596.78.0.246474788536.issue9204@psf.upfronthosting.co.za>
Message-ID: <1279573257.26.0.433653734928.issue9204@psf.upfronthosting.co.za>


Tim Lesher <tlesher at gmail.com> added the comment:

There are a number of similar mentions in the C API docs and index; attached is a patch that removes each.

----------
keywords: +patch
nosy: +tlesher
Added file: http://bugs.python.org/file18068/remove-extraneous-types.diff

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

From report at bugs.python.org  Tue Jul 20 05:34:50 2010
From: report at bugs.python.org (Matt Bone)
Date: Tue, 20 Jul 2010 03:34:50 +0000
Subject: [docs] [issue2864] etree: Add XPath documentation
In-Reply-To: <1210863012.97.0.696135529968.issue2864@psf.upfronthosting.co.za>
Message-ID: <1279596889.75.0.62770666801.issue2864@psf.upfronthosting.co.za>


Matt Bone <thatmattbone at gmail.com> added the comment:

Here's a patch for 3.2 with some simple examples.  They're under the ElementTree findall method.  Maybe there should be similar examples for Element's find/findall methods?

----------
keywords: +patch
nosy: +mbone
Added file: http://bugs.python.org/file18076/xpath_examples.diff

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

From report at bugs.python.org  Tue Jul 20 06:19:47 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 20 Jul 2010 04:19:47 +0000
Subject: [docs] [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>


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

Due to a discussion on python-dev (Subject: "Markup of command-line options in Python's .rst documentation"), Georg Brandl checked in revision r82961 with a clarification of :option: markup which should only be used for Python interpreter's own flags.

However, several modules in stdlib use :option: for their own command-line options, which creates confusion (these options get linked by Sphinx to unrelated Python options).

I'm attaching a patch that fixes this issue for these files. The affected files are:

Doc/library/idle.rst
Doc/library/timeit.rst
Doc/library/test.rst
Doc/library/doctest.rst
Doc/library/unittest.rst
Doc/library/pydoc.rst
Doc/library/webbrowser.rst
Doc/library/compileall.rst

Note1: :option: was fixed to `` markup (code snippet) as per the recommendation in the updated documentation guide
Note2: I didn't patch trace.rst because it's overgoing a major rehaul (http://bugs.python.org/issue9264)

----------
assignee: docs at python
components: Documentation
messages: 110862
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: Fix usage of :option: markup in stdlib ReST docs
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 20 06:20:34 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 20 Jul 2010 04:20:34 +0000
Subject: [docs] [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <1279599634.81.0.701761740246.issue9312@psf.upfronthosting.co.za>


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

Patch

----------
keywords: +patch
Added file: http://bugs.python.org/file18080/issue9312.1.patch

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

From report at bugs.python.org  Tue Jul 20 07:43:29 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 20 Jul 2010 05:43:29 +0000
Subject: [docs] [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <1279604608.97.0.570824668349.issue9312@psf.upfronthosting.co.za>


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

The patch generally changes things like 

:option:`-e`   to   ``-e``   and

-r N/:option:`--repeat=N`   to   ``-r N/--repeat=N``

which is what I understand GB to have said to do.

:program:`python regrtest.py` :option:`test_spam.py`  to
:program:`python regrtest.py test_spam.py`

For the last, I presume that :program:`...` takes the place of ``...``
in the previous examples.

There are a few text changes in doctest.rst that I cannot comment on.

I presume this could and should be backported from 3.2 to other versions. Eli said in email that he has run 'make html' and checked the output.

----------
nosy: +tjreedy
stage:  -> commit review
versions: +Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Tue Jul 20 15:45:32 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 20 Jul 2010 13:45:32 +0000
Subject: [docs] [issue5901] missing meta-info in documentation pdf
In-Reply-To: <1241246578.79.0.771794251259.issue5901@psf.upfronthosting.co.za>
Message-ID: <1279633532.88.0.628768303282.issue5901@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jul 20 16:16:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Jul 2010 14:16:50 +0000
Subject: [docs] [issue9311] os.access can return bogus values when run as
	superuser
In-Reply-To: <1279591357.64.0.139129514793.issue9311@psf.upfronthosting.co.za>
Message-ID: <1279635409.99.0.359862053483.issue9311@psf.upfronthosting.co.za>


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

I'm curious, are the perl and sh functions you say do the right thing wrappers around 'access', or are they some other sort of function?  The Python code is just a thin wrapper around the system function, and as such will follow the system function's semantics.

I do agree that the FreeBSD interpretation of the semantics of access is...unexpected, as well as unfortunate :)  So, a doc note about the superuser X_OK quirk is appropriate.  Care to propose a doc patch?  Personally I wouldn't include the stat example, but rather simply refer to stat as the portable way to check if the execute bit is set (and then you still have to call os.access to see if the real uid has permission to execute).

On the other hand, proposing a portable version of 'access' for inclusion in shutils might be appropriate, if you want to open a new issue for that (preferably with a patch including docs and unit tests :)

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

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

From techtonik at gmail.com  Tue Jul 20 16:46:10 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 20 Jul 2010 17:46:10 +0300
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
References: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
	<1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <AANLkTikdgBfBw-7pw9gzaXBQ4vMDxbvXT8BkhxvC50Ig@mail.gmail.com>

On Mon, Jul 19, 2010 at 7:21 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
>
> I suggest the following wording for time.timezone description:
>
> time.timezone: The number of seconds one must add to the local time to arrive at UTC.

Makes sense. I can't see any other real explanation for -7200 value if
I am in +2 UTC timezone.

> Similarly, tzinfo.utcoffset() can be defined as "Returns timedelta one must add to UTC to arrive at local time."

I believe the correct convention is "Return timedelta...". Another
concern - if UTC is 0 reference point then there is no reason to add
something to it - you just can say - "Return timedelta equal to local
UTC offset."

From report at bugs.python.org  Tue Jul 20 17:17:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 20 Jul 2010 15:17:01 +0000
Subject: [docs] [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <1279639021.8.0.0143330298265.issue9312@psf.upfronthosting.co.za>


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

In documenting/markup:

program
    The name of an executable program. This may differ from the file name for the executable for some platforms. In particular, the .exe (or other) extension should be omitted for Windows programs.

So I believe the correct form would be ``python regrtest.py``.

----------
nosy: +merwok

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

From report at bugs.python.org  Tue Jul 20 17:29:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Jul 2010 15:29:07 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <AANLkTikdgBfBw-7pw9gzaXBQ4vMDxbvXT8BkhxvC50Ig@mail.gmail.com>
Message-ID: <AANLkTinGi_JMj6gbT0Pp9uMz_K9FuTfuinM1tiVU37Ct@mail.gmail.com>


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

On Tue, Jul 20, 2010 at 10:46 AM, anatoly techtonik
<report at bugs.python.org> wrote:
> .. Another
> concern - if UTC is 0 reference point then there is no reason to add
> something to it - you just can say - "Return timedelta equal to local
> UTC offset."

No, UTC is not a 0 reference point, it is a time scale.  UTC offset is
the value that is used to translate between time expressed in UTC and
local time.   To make an analogy, expressing time in UTC is like
expressing temperature in Kelvin scale.  You need to subtract 273 from
the value in ?K to arrive at the value in ?C.

Documenting utcoffset() as "Return timedelta equal to local UTC
offset." is almost circular.  It does not explain whether it has to be
added or subtracted from UTC to arrive at local time.

----------

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

From report at bugs.python.org  Tue Jul 20 17:39:38 2010
From: report at bugs.python.org (Tim Peters)
Date: Tue, 20 Jul 2010 15:39:38 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1279640377.85.0.0254511721825.issue9305@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

FYI, I like the change.  As I recall it, the current wording was just to avoid saying "ahead of UTC" or "behind UTC" (which was the original wording).  Technically pure or not, I never saw anyone get truly confused by "East of UTC" or "West of UTC", but I fully that what people really want to know is what to do with the thing (add or subtract it).

----------
nosy: +tim_one

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

From fdrake at acm.org  Tue Jul 20 17:46:52 2010
From: fdrake at acm.org (Fred Drake)
Date: Tue, 20 Jul 2010 11:46:52 -0400
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <AANLkTikdgBfBw-7pw9gzaXBQ4vMDxbvXT8BkhxvC50Ig@mail.gmail.com>
References: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za> 
	<AANLkTikdgBfBw-7pw9gzaXBQ4vMDxbvXT8BkhxvC50Ig@mail.gmail.com>
Message-ID: <AANLkTikHmmmE9f8CAn832KoCXfZbUafEr5Bq78pbXo2h@mail.gmail.com>

On Tue, Jul 20, 2010 at 10:46 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> I believe the correct convention is "Return timedelta...".

This is handled inconsistently in the documentation; I'm hoping the
current maintainers reinforce the "Returns ..." structure.  The
documentation is descriptive, not an external specification.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From report at bugs.python.org  Tue Jul 20 18:08:08 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 20 Jul 2010 16:08:08 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <AANLkTinGi_JMj6gbT0Pp9uMz_K9FuTfuinM1tiVU37Ct@mail.gmail.com>
Message-ID: <AANLkTil6qv86_4d49phmw_t9XXev9Wgk2_5OvQwFe4fT@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

> Documenting utcoffset() as "Return timedelta equal to local UTC
> offset." is almost circular. ?It does not explain whether it has to be
> added or subtracted from UTC to arrive at local time.

Ok. Sold.

>> I believe the correct convention is "Return timedelta...".
>
> This is handled inconsistently in the documentation; I'm hoping the
> current maintainers reinforce the "Returns ..." structure. ?The
> documentation is descriptive, not an external specification.

http://www.python.org/dev/peps/pep-0257/#one-line-docstrings

I've took the convention from here. I thought docs are generated from
docstrings.

----------

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

From report at bugs.python.org  Tue Jul 20 18:13:21 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 20 Jul 2010 16:13:21 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <AANLkTil6qv86_4d49phmw_t9XXev9Wgk2_5OvQwFe4fT@mail.gmail.com>
Message-ID: <AANLkTiloGO5hamua28-DVudkW648MRtho-tiv9k6BNEG@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Tue, Jul 20, 2010 at 12:08 PM, anatoly techtonik
<report at bugs.python.org> wrote:
> I've took the convention from here. I thought docs are generated from
> docstrings.

They're not, but I don't think that really matters.

Older documentation used the imperative form consistently, but that's
shifted over time.  (I, at least, think that's a good thing.)

I don't think it really matters with regard to this issue.

----------

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

From report at bugs.python.org  Tue Jul 20 18:14:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Jul 2010 16:14:39 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <1279640377.85.0.0254511721825.issue9305@psf.upfronthosting.co.za>
Message-ID: <AANLkTimHsb5w_ZCYEjOHPJjNBgfZ5ZzDjVeY_VDMf4Y2@mail.gmail.com>


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

On Tue, Jul 20, 2010 at 11:39 AM, Tim Peters <report at bugs.python.org> wrote:
>.. ?As I recall it, the current wording was just to avoid saying "ahead of UTC" or "behind UTC" (which was the original wording).

Interesting.  I actually like the original wording better.  For me,
"my watch is 6 hours behind UTC" makes it clear that when the Big Ben
clock shows tea time (18:00), my watch displays noon (17:00 - 6:00 =
12:00.)

I wonder if east/west is somehow more natural for native speakers of
English.   I would really like to hear more from the international
audience.  When it comes to measuring time there are many interesting
traditions that don't translate well between nations.  For example,
I've heard that in the Far East, the future is considered to be behind
because you can see the past but you cannot see the future.  If this
is the notion that you are used to, time being ahead or behind can be
truly confusing.

----------

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

From report at bugs.python.org  Tue Jul 20 18:18:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Jul 2010 16:18:37 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <AANLkTimHsb5w_ZCYEjOHPJjNBgfZ5ZzDjVeY_VDMf4Y2@mail.gmail.com>
Message-ID: <AANLkTin3NM-2U2BJaqf58vGVFjfQ0YdsfVGACTKWH9Wf@mail.gmail.com>


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

On Tue, Jul 20, 2010 at 12:14 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
> Interesting. ?I actually like the original wording better. ?For me,
> "my watch is 6 hours behind UTC" makes it clear that when the Big Ben
> clock shows tea time (18:00), my watch displays noon (17:00 - 6:00 =
> 12:00.)

I was too excited to add Alice in Wonderland humor to my post that did
not get the math right. :-)

The above should read 18:00 - 6:00 = 12:00, of course.  Or was it five
o'clock after all?

----------

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

From report at bugs.python.org  Tue Jul 20 19:17:47 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 20 Jul 2010 17:17:47 +0000
Subject: [docs] [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <1279646267.57.0.104306248696.issue9312@psf.upfronthosting.co.za>


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

Terry, 
Re doctest.rst - appears to be a merging issue. I will see how to resolve it once we figure out what to do with :program:

?ric, 
Good point - I'll ask pydev and will update the patch accordingly

----------

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

From report at bugs.python.org  Tue Jul 20 19:19:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 20 Jul 2010 17:19:52 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <AANLkTil6qv86_4d49phmw_t9XXev9Wgk2_5OvQwFe4fT@mail.gmail.com>
Message-ID: <AANLkTinjpFTK4ZpUymuwax7CwOcUObza0UhgRn6NktbG@mail.gmail.com>


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

On Tue, Jul 20, 2010 at 12:08 PM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> Ok. Sold.

Good.  All we need now is just a patch. :-)

----------

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

From report at bugs.python.org  Tue Jul 20 20:16:29 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 20 Jul 2010 18:16:29 +0000
Subject: [docs] [issue6251] c++ extension module implementation
	guide/example in	extending/embedding documentation
In-Reply-To: <1244621954.14.0.882115358869.issue6251@psf.upfronthosting.co.za>
Message-ID: <1279649788.76.0.429199770376.issue6251@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jul 20 20:26:08 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 20 Jul 2010 18:26:08 +0000
Subject: [docs] [issue9311] os.access can return bogus values when run as
	superuser
In-Reply-To: <1279591357.64.0.139129514793.issue9311@psf.upfronthosting.co.za>
Message-ID: <1279650368.65.0.870818991055.issue9311@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

Well, bash screws up in this dept:

$ ls -l typescript
-rw-r--r--  1 gcooper  gcooper  37875 Jul 12 22:19 typescript
$ sudo sh -c 'test -x typescript; echo $?'
1
$ sudo bash -c 'test -x typescript; echo $?'
0
$ csh
%if (-x typescript) then
if? echo "executable"
if? endif
%

test(1) is a built-in in bash; on FreeBSD/NetBSD(/OpenBSD?) it's a standalone app (which uses eaccess(2)). csh does some tricky code for testing file access in sh.exp.c (see sh_access).

perl does some tricky stuff in pp_sys.c (look for pp_ftrread), where it 
uses eaccess(2) if it's present, else falls back to access(2) to do its bidding. So maybe os.access should use eaccess(2) if it's present on the OS instead of access(2), and note that the item is OS implementation dependent (beware!)?

----------

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

From report at bugs.python.org  Wed Jul 21 02:21:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 21 Jul 2010 00:21:44 +0000
Subject: [docs] [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1279599587.56.0.337150515932.issue9312@psf.upfronthosting.co.za>
Message-ID: <1279671704.01.0.635017347974.issue9312@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/issue9312>
_______________________________________

From report at bugs.python.org  Wed Jul 21 03:27:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Jul 2010 01:27:15 +0000
Subject: [docs] [issue9311] os.access can return bogus values when run as
	superuser
In-Reply-To: <1279591357.64.0.139129514793.issue9311@psf.upfronthosting.co.za>
Message-ID: <1279675635.54.0.862141964962.issue9311@psf.upfronthosting.co.za>


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

Hmm.  The document you quoted said that eaccess doesn't necessarily get this right everywhere either, but it sounds like it would at least fix the problem on FreeBSD...but at the price of no longer being a simple wrapper around access.  I'm not sure what I think about that.  This may be a question for python-dev.

----------

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

From report at bugs.python.org  Wed Jul 21 03:32:30 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Wed, 21 Jul 2010 01:32:30 +0000
Subject: [docs] [issue9311] os.access can return bogus values when run as
	superuser
In-Reply-To: <1279591357.64.0.139129514793.issue9311@psf.upfronthosting.co.za>
Message-ID: <1279675950.72.0.313405662157.issue9311@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

My initial analysis was incorrect after talking with the bash(1) folks. test(1) is doing things wrong too:

        case FILEX:
                /* XXX work around eaccess(2) false positives for superuser */
                if (eaccess(nm, X_OK) != 0)
                        return 0;
                if (S_ISDIR(s.st_mode) || geteuid() != 0)
                        return 1;
                return (s.st_mode & (S_IXUSR | S_IXGRP | S_IXOTH)) != 0;

So it looks like test(1) is broken as well (doesn't check for ACLs, or MAC info).

Interesting why it's only implemented for X_OK though...

----------

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

From report at bugs.python.org  Wed Jul 21 03:32:54 2010
From: report at bugs.python.org (Garrett Cooper)
Date: Wed, 21 Jul 2010 01:32:54 +0000
Subject: [docs] [issue9311] os.access can return bogus values when run as
	superuser
In-Reply-To: <1279591357.64.0.139129514793.issue9311@psf.upfronthosting.co.za>
Message-ID: <1279675974.53.0.481257235019.issue9311@psf.upfronthosting.co.za>


Garrett Cooper <yanegomi at gmail.com> added the comment:

My initial analysis was incorrect after talking with the bash(1) folks. test(1) is doing things wrong too:

        case FILEX:
                /* XXX work around eaccess(2) false positives for superuser */
                if (eaccess(nm, X_OK) != 0)
                        return 0;
                if (S_ISDIR(s.st_mode) || geteuid() != 0)
                        return 1;
                return (s.st_mode & (S_IXUSR | S_IXGRP | S_IXOTH)) != 0;

So it looks like test(1) is broken as well (doesn't check for ACLs, or MAC info).

Interesting why it's only implemented for X_OK though...

Based on this analysis, I'd say that access(2) is broken on FreeBSD and needs to be fixed.

----------

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

From report at bugs.python.org  Wed Jul 21 09:07:26 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 21 Jul 2010 07:07:26 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Seems like os.environ is shared between multiple threads. This should be documented at least in threading chapters.

----------
assignee: docs at python
components: Documentation
messages: 111013
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: os.environ is global for threads
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From christian.opitz at thalesgroup.com  Mon Jul 19 14:38:28 2010
From: christian.opitz at thalesgroup.com (OPITZ Christian (D3S))
Date: Mon, 19 Jul 2010 14:38:28 +0200
Subject: [docs] Missing links on page
	http://docs.python.org/release/2.6/download
Message-ID: <3CF34B583782C147807E09365F884DA42EDCD9EB62@THSNCOA06MXS02P.ONE-06.GRP>

Missing links on page http://docs.python.org/release/2.6/download.

All links are missing the version number 2.6 inside the file names.
Mailto link is not working.
Tested with
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
--

Mit freundlichen Gr??en/Best regards

Dipl.-Ing. Christian Opitz
Systemplanungsingenieur TB/EII  - Rail Signalling Solutions
Thales Deutschland - Ground Transportation Solutions

Phone: +49(0)30-688 306-430
Fax: +49(0)30-688 306-302
E-Mail: Christian.Opitz at thalesgroup.com
--------------------------------------------------------------
Thales Rail Signalling Solutions GmbH
Colditzstrasse 34-36 - 12099 Berlin - Germany
--------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100719/626b0531/attachment-0001.html>

From loicseguin at gmail.com  Wed Jul 21 04:43:45 2010
From: loicseguin at gmail.com (=?ISO-8859-1?Q?Lo=EFc_S=E9guin-Charbonneau?=)
Date: Tue, 20 Jul 2010 22:43:45 -0400
Subject: [docs] Inaccurate example for the gzip module
Message-ID: <4C465EE1.9020900@gmail.com>

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

Hi,

First of all, thanks for maintaining great documentation! I use it
constantly, and it is very well written and easy to understand.

I spotted a bug in the gzip documentation for 3.1.2. At the bottom of
the page http://docs.python.org/py3k/library/gzip.html, section 12.2.1.
Examples of usage, we read the following:

import gzip
content = "Lots of content here"
f = gzip.open('/home/joe/file.txt.gz', 'wb')
f.write(content)
f.close()

Running this example fails, as shown below:

(default)Micron:py3k-1.2 loic$ python3
Python 3.1.2 (r312:79147, Jul 18 2010, 02:49:37)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> content = "Lots of content here"
>>> f = gzip.open('spotted.txt.gz', 'wb')
>>> f.write(content)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/gzip.py",
line 226, in write
    self.crc = zlib.crc32(data, self.crc) & 0xffffffff
TypeError: must be bytes or buffer, not str
>>>

The solution (which I found thanks to Google and diveintopython3.org) is
to change the fourth line in the example:

import gzip
content = "Lots of content here"
f = gzip.open('/home/joe/file.txt.gz', 'wb')
f.write(content.encode('utf-8'))
f.close()

I haven't check the last example on that webpage, but I think it has the
same problem.

Hope this helps,

Lo?c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxGXuEACgkQLKWiTxa2C806jQCgwRShTRSnJJwNyoZHwbckgYKe
wrcAnAuFkm1vI1X3FabP/I5btw9IhGMr
=kMgZ
-----END PGP SIGNATURE-----

From report at bugs.python.org  Wed Jul 21 10:43:37 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 21 Jul 2010 08:43:37 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279701817.32.0.0355943401106.issue9320@psf.upfronthosting.co.za>


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

I'm not sure where you'd put this. The defining characteristic of threads is that _all_ objects are shared among them.

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

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

From report at bugs.python.org  Wed Jul 21 10:50:22 2010
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Wed, 21 Jul 2010 08:50:22 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279702222.06.0.0278544492412.issue9320@psf.upfronthosting.co.za>


Konstantin Zemlyak <zart at zartsoft.ru> added the comment:

Environment variables have always been process-wide. It doesn't deserve any special mention in threads documentation.

----------
nosy: +zart

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

From report at bugs.python.org  Wed Jul 21 11:13:04 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 21 Jul 2010 09:13:04 +0000
Subject: [docs] [issue9007] CGIHTTPServer supports only Python CGI scripts
In-Reply-To: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>
Message-ID: <1279703584.34.0.945743514528.issue9007@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

It was actual only for old Mac versions without popen2/popen3 calls. popenX calls were replaced with subprocess which should be available on MacOS.

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

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

From report at bugs.python.org  Wed Jul 21 12:09:12 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 21 Jul 2010 10:09:12 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279701817.32.0.0355943401106.issue9320@psf.upfronthosting.co.za>
Message-ID: <AANLkTikZOyAxml3Jo-7tegon9HNxNCbcA4Mu0FhaTVn4@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Wed, Jul 21, 2010 at 11:43 AM, Eric Smith <report at bugs.python.org> wrote:
>
> I'm not sure where you'd put this. The defining characteristic of threads is that _all_ objects are shared among them.

Where is this defining characteristic of threads is described?

----------

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

From report at bugs.python.org  Wed Jul 21 12:31:13 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 21 Jul 2010 10:31:13 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <AANLkTikZOyAxml3Jo-7tegon9HNxNCbcA4Mu0FhaTVn4@mail.gmail.com>
Message-ID: <AANLkTinyAsmATbCeFTvu9FZp0mae1Y62XH0slT_QhOeO@mail.gmail.com>


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

>> I'm not sure where you'd put this. The defining characteristic of threads is that _all_ objects are shared among them.
> Where is this defining characteristic of threads is described?

in http://docs.python.org/library/thread.html
"""...multiple threads of control sharing their global data space..."""

That's how threads are understood in all programming languages.

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

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

From report at bugs.python.org  Wed Jul 21 13:05:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 21 Jul 2010 11:05:21 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279710320.97.0.38891855481.issue9320@psf.upfronthosting.co.za>


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

Closing in agreement with Eric/Amaury.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Wed Jul 21 20:35:36 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 21 Jul 2010 18:35:36 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279737336.45.0.0312948171373.issue9320@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

> in http://docs.python.org/library/thread.html
> """...multiple threads of control sharing their global data space..."""
>
> That's how threads are understood in all programming languages.

Do you mean this one?

"""This module provides low-level primitives for working with multiple threads (also called light-weight processes or tasks) ? multiple threads of control sharing their global data space.""" 

It is surely confusing and doesn't explain anything to people who never worked with threads (like me). It should either be split in two sentences or simplified.

http://en.wikipedia.org/wiki/Thread_(computer_science) says that threads can share resources, but not necessarily do so.

----------
status: closed -> pending

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

From report at bugs.python.org  Thu Jul 22 00:19:30 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 21 Jul 2010 22:19:30 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279750769.81.0.0931413977287.issue9320@psf.upfronthosting.co.za>


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

Quoting the wikipedia page: """multiple threads within a process share state as well as memory and other resources"""

If you never worked with threads, then you really need a tutorial about threads, or even a general explanation about threads; the reference manual is not such a place.
Programming with threads has really complex aspects that are not inherent to Python.

[Some people will also say: if you never worked with threads, don't start]

----------
status: pending -> closed

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

From report at bugs.python.org  Thu Jul 22 00:49:16 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 21 Jul 2010 22:49:16 +0000
Subject: [docs] [issue9328] str.__format__.__doc__ backport glitch
In-Reply-To: <1279752555.95.0.938195163481.issue9328@psf.upfronthosting.co.za>
Message-ID: <1279752555.95.0.938195163481.issue9328@psf.upfronthosting.co.za>


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

On Python list, 'jmfauth' reports
>>> >>> sys.version
2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)]
>>> >>> ''.format.__doc__
S.format(*args, **kwargs) -> unicode

I do not have 2.7 loaded to verify this, but assuming this is accurate,
'unicode' should be 'string'. I presume this is from mistaken conversion of 3.1 'string' to 2.7 'unicode' when backporting the new string format system.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 111130
nosy: docs at python, tjreedy
priority: normal
severity: normal
stage: needs patch
status: open
title: str.__format__.__doc__ backport glitch
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 22 02:34:43 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 22 Jul 2010 00:34:43 +0000
Subject: [docs] [issue9328] str.__format__.__doc__ backport glitch
In-Reply-To: <1279752555.95.0.938195163481.issue9328@psf.upfronthosting.co.za>
Message-ID: <1279758883.66.0.239378110662.issue9328@psf.upfronthosting.co.za>


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

Yes, that is what it says; and yes, it should be "string". Although why all of the methods say "string" and not "str" isn't clear to me. Probably historical.

The doc string for str.__format__ contains the same error.

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

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

From report at bugs.python.org  Thu Jul 22 02:40:50 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 22 Jul 2010 00:40:50 +0000
Subject: [docs] [issue9328] str.__format__.__doc__ backport glitch
In-Reply-To: <1279752555.95.0.938195163481.issue9328@psf.upfronthosting.co.za>
Message-ID: <1279759249.65.0.0509772453409.issue9328@psf.upfronthosting.co.za>


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

And now that I look at it, the subject contains "__format__" but the original message says "format". Both cases are already covered!

----------

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

From fdrake at acm.org  Thu Jul 22 02:45:45 2010
From: fdrake at acm.org (Fred Drake)
Date: Wed, 21 Jul 2010 20:45:45 -0400
Subject: [docs] [issue9328] str.__format__.__doc__ backport glitch
In-Reply-To: <1279758883.66.0.239378110662.issue9328@psf.upfronthosting.co.za>
References: <1279752555.95.0.938195163481.issue9328@psf.upfronthosting.co.za> 
	<1279758883.66.0.239378110662.issue9328@psf.upfronthosting.co.za>
Message-ID: <AANLkTiluHstFXrt5ZxhFi2Oo1qxvWLwknFVjBkkpB32d@mail.gmail.com>

On Wed, Jul 21, 2010 at 8:34 PM, Eric Smith <report at bugs.python.org> wrote:
> Although why all of the methods say "string" and not "str" isn't clear to me. Probably historical.

Indeed; we used "string" in the docs as an informal way to say what
eventually became known as basestring.


? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at gmail.com>
"A storm broke loose in my mind."? --Albert Einstein

From report at bugs.python.org  Thu Jul 22 02:48:10 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 22 Jul 2010 00:48:10 +0000
Subject: [docs] [issue9328] str.__format__.__doc__ backport glitch
In-Reply-To: <1279752555.95.0.938195163481.issue9328@psf.upfronthosting.co.za>
Message-ID: <1279759690.52.0.318046308557.issue9328@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy:  -fdrake

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

From alastors at gmail.com  Wed Jul 21 16:46:49 2010
From: alastors at gmail.com (Mario Santamaria)
Date: Wed, 21 Jul 2010 11:46:49 -0300
Subject: [docs] http://docs.python.org/
Message-ID: <AANLkTikBQjx17eABDPiYfwHviXXbg5Ch_BZzZiFGcmTY@mail.gmail.com>

please remove http://docs.python.org/ and put in a better documentation, I
wasted so much time reading that bad documentation that now I hate it and I
will never write code in python.

have a nice day.
<http://docs.python.org/>

-- 
Atte. Mario Santamaria.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100721/5aa2034e/attachment.html>

From arunchithanar at gmail.com  Wed Jul 21 21:54:17 2010
From: arunchithanar at gmail.com (Arun kumar)
Date: Thu, 22 Jul 2010 01:24:17 +0530
Subject: [docs] suggestion in python tutorial, section 4.6
Message-ID: <AANLkTilow-419s9Yog-nhRq7i9LGuDcYOOQrKVOWCDQJ@mail.gmail.com>

Dear Sir/Madam,

I am beginner, and I started learning python using the tutorial. As I
was reading till section 4.6, I was of the opinion that even integer
variables were objects. The following sentence appears in this
section:

"The actual parameters (arguments) to a function call are introduced
in the local symbol table of the called function when it is called;
thus, arguments are passed using call by value (where the value is
always an object reference, not the value of the object)."

When I tried to pass an integer to a function, which modifies the
integer passed, and then print the integer after the function is
called, I was surprised to find that the value was not modified. When
I tried it with a mutable object, it was. I feel an inclusion in this
section about types which are objects and which aren't would add more
clarity.

Thanks.

--
regards,
Arun Kumar

From georg at python.org  Thu Jul 22 12:12:57 2010
From: georg at python.org (Georg Brandl)
Date: Thu, 22 Jul 2010 11:12:57 +0100
Subject: [docs] http://docs.python.org/
In-Reply-To: <AANLkTikBQjx17eABDPiYfwHviXXbg5Ch_BZzZiFGcmTY@mail.gmail.com>
References: <AANLkTikBQjx17eABDPiYfwHviXXbg5Ch_BZzZiFGcmTY@mail.gmail.com>
Message-ID: <4C4819A9.8060008@python.org>

Am 21.07.2010 15:46, schrieb Mario Santamaria:
> please remove http://docs.python.org/ and put in a better documentation, I
> wasted so much time reading that bad documentation that now I hate it and I will
> never write code in python.
> 
> have a nice day.

Hi Mario,

thanks for your report.  Do you want to work on a patch?

regards,
Georg

From report at bugs.python.org  Thu Jul 22 12:15:24 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 22 Jul 2010 10:15:24 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279793723.72.0.280610343406.issue9320@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I have to debug CGIHTTPServer test case that apparently uses threads, and I expected to find at least some pointer about "what exactly a thread in Python is". I hope Python Manual is not only for system programmers. They do not need the manual anyway - they already know everything and there are plenty tutorials for them elsewhere.

-- 
"please remove http://docs.python.org/ and put in a better documentation, I wasted so much time reading that bad documentation that now I hate it and I will never write code in python" (c) Mario Santamaria

----------
status: closed -> pending

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

From report at bugs.python.org  Thu Jul 22 12:23:30 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 22 Jul 2010 10:23:30 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279794210.11.0.47359518683.issue9320@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I agree with Eric, Konstantin, Amaury and Georg. Closing for the third time.

----------
nosy: +skrah
status: pending -> open

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

From report at bugs.python.org  Thu Jul 22 12:23:49 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 22 Jul 2010 10:23:49 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279794229.91.0.537320791314.issue9320@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


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

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

From report at bugs.python.org  Thu Jul 22 12:37:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Jul 2010 10:37:55 +0000
Subject: [docs] [issue9320] os.environ is global for threads
In-Reply-To: <1279696046.14.0.777932115359.issue9320@psf.upfronthosting.co.za>
Message-ID: <1279795075.73.0.451778382663.issue9320@psf.upfronthosting.co.za>


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

Anatoly, I don't think it is a good idea to use signatures in tracker comments.

----------

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

From report at bugs.python.org  Thu Jul 22 17:33:44 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 22 Jul 2010 15:33:44 +0000
Subject: [docs] [issue7579] Patch to add docstrings to msvcrt
In-Reply-To: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
Message-ID: <1279812824.12.0.99570952352.issue7579@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul 22 17:37:56 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 22 Jul 2010 15:37:56 +0000
Subject: [docs] [issue7699] strptime, strftime documentation
In-Reply-To: <1263433562.71.0.126740414986.issue7699@psf.upfronthosting.co.za>
Message-ID: <1279813076.94.0.0350981459757.issue7699@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul 22 18:17:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 22 Jul 2010 16:17:43 +0000
Subject: [docs] [issue7579] Patch to add docstrings to msvcrt
In-Reply-To: <1261862969.81.0.926821098705.issue7579@psf.upfronthosting.co.za>
Message-ID: <1279815463.6.0.116053452512.issue7579@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee: docs at python -> brian.curtin

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

From report at bugs.python.org  Thu Jul 22 19:43:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 22 Jul 2010 17:43:38 +0000
Subject: [docs] [issue9331] sys.setprofile is not described as CPython
	implementation	detail
In-Reply-To: <1279820617.97.0.227411152808.issue9331@psf.upfronthosting.co.za>
Message-ID: <1279820617.97.0.227411152808.issue9331@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Unlike sys.settrace, sys.setprofile is not described as CPython implementation detail in Doc/library/sys.rst.

----------
assignee: docs at python
components: Documentation
messages: 111199
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: sys.setprofile is not described as CPython implementation detail
type: feature request

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

From report at bugs.python.org  Fri Jul 23 10:19:00 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 23 Jul 2010 08:19:00 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1279873139.97.0.853235033061.issue9264@psf.upfronthosting.co.za>


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

Attaching a patch vs. the 2.6 maintenance branch for the Doc/library/trace.rst file

* Fixed some formatting issues for command line options and class references
* Documented all relevant user-accessible methods
* Divided command-line options logically into sub-sections and improved their explanations

I ran `make html` from the Doc/ directory and made sure the HTML looks OK

----------
Added file: http://bugs.python.org/file18137/issue9262.py26.patch

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

From merwok at netwok.org  Fri Jul 23 12:38:21 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 23 Jul 2010 12:38:21 +0200
Subject: [docs] Outdated info in turtle docs
Message-ID: <4C49711D.4000108@netwok.org>

Hello

http://docs.python.org/dev/library/turtle.html (py3k) says:

?The turtle module is an extended reimplementation of the same-named
module from the Python standard distribution up to version Python 2.5.?

Regards


From report at bugs.python.org  Fri Jul 23 13:19:29 2010
From: report at bugs.python.org (Brian Brazil)
Date: Fri, 23 Jul 2010 11:19:29 +0000
Subject: [docs] [issue9339] threading is_alive documnetation is unclear
In-Reply-To: <1279883969.69.0.278185543155.issue9339@psf.upfronthosting.co.za>
Message-ID: <1279883969.69.0.278185543155.issue9339@psf.upfronthosting.co.za>


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

http://docs.python.org/py3k/library/threading.html

"Roughly, a thread is alive from the moment the start() method returns until its run() method terminates."

Using "Roughly" in relation to threading is a bit unspecific. I've had a look through _bootstrap_inner() and attached a patch to clarify this.

----------
assignee: docs at python
components: Documentation
files: threading-roughly-doc-fix.patch
keywords: patch
messages: 111278
nosy: bbrazil, docs at python
priority: normal
severity: normal
status: open
title: threading is_alive documnetation is unclear
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18140/threading-roughly-doc-fix.patch

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

From report at bugs.python.org  Fri Jul 23 13:29:52 2010
From: report at bugs.python.org (Brian Brazil)
Date: Fri, 23 Jul 2010 11:29:52 +0000
Subject: [docs] [issue9339] threading is_alive documnetation is unclear
In-Reply-To: <1279883969.69.0.278185543155.issue9339@psf.upfronthosting.co.za>
Message-ID: <1279884592.73.0.0969930602557.issue9339@psf.upfronthosting.co.za>


Changes by Brian Brazil <brian.brazil at gmail.com>:


Removed file: http://bugs.python.org/file18140/threading-roughly-doc-fix.patch

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

From report at bugs.python.org  Fri Jul 23 13:30:30 2010
From: report at bugs.python.org (Brian Brazil)
Date: Fri, 23 Jul 2010 11:30:30 +0000
Subject: [docs] [issue9339] threading is_alive documnetation is unclear
In-Reply-To: <1279883969.69.0.278185543155.issue9339@psf.upfronthosting.co.za>
Message-ID: <1279884630.27.0.145907328795.issue9339@psf.upfronthosting.co.za>


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

Here's a slightly cleaner version.

----------
Added file: http://bugs.python.org/file18141/threading-roughly-doc-fix.patch

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

From report at bugs.python.org  Fri Jul 23 14:30:37 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Jul 2010 12:30:37 +0000
Subject: [docs] [issue9339] threading is_alive documnetation is unclear
In-Reply-To: <1279883969.69.0.278185543155.issue9339@psf.upfronthosting.co.za>
Message-ID: <1279888237.34.0.943670563625.issue9339@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

3.2: 83080
3.1: 83081
2.7: 83082

----------
nosy: +brett.cannon
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Jul 23 14:57:27 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 12:57:27 +0000
Subject: [docs] [issue9343] Document that argparse "parents" must be fully
	declared	before children
In-Reply-To: <1279889847.13.0.579699796707.issue9343@psf.upfronthosting.co.za>
Message-ID: <1279889847.13.0.579699796707.issue9343@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

[From http://code.google.com/p/argparse/issues/detail?id=61]

It should be documented clearly that only the arguments present on the parent parser at the time ArgumentParser is called will be included in the parser.

>>> parent = argparse.ArgumentParser(add_help=False)
>>> child = argparse.ArgumentParser(parents=[parent])
>>> parent.add_argument('--foo', action='store_true')
>>> child.parse_args(['--foo'])
usage: [-h]
: error: unrecognized arguments: --foo

----------
assignee: docs at python
components: Documentation
messages: 111306
nosy: bethard, docs at python
priority: normal
severity: normal
status: open
title: Document that argparse "parents" must be fully declared before children
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 23 15:02:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Jul 2010 13:02:13 +0000
Subject: [docs] [issue9343] Document that argparse "parents" must be fully
	declared	before children
In-Reply-To: <1279889847.13.0.579699796707.issue9343@psf.upfronthosting.co.za>
Message-ID: <1279890133.12.0.838907375068.issue9343@psf.upfronthosting.co.za>


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

I removed 3.3, since it currently means ?won?t be done for 3.2, so note for later.? I don?t know if the report applies to 3.1 (doc fixes go into stable releases too), so I?m not adding it.

----------
nosy: +merwok
versions:  -Python 3.3

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

From report at bugs.python.org  Fri Jul 23 15:06:52 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 13:06:52 +0000
Subject: [docs] [issue9343] Document that argparse "parents" must be fully
	declared	before children
In-Reply-To: <1279889847.13.0.579699796707.issue9343@psf.upfronthosting.co.za>
Message-ID: <1279890412.25.0.430873768077.issue9343@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Ah, thanks for the fix. No it doesn't need to go in 3.1 - argparse is only in 2.7 and 3.2.

----------

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

From report at bugs.python.org  Fri Jul 23 15:46:36 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 23 Jul 2010 13:46:36 +0000
Subject: [docs] [issue9349] document argparse's help=SUPPRESS
In-Reply-To: <1279892796.46.0.177553560445.issue9349@psf.upfronthosting.co.za>
Message-ID: <1279892796.46.0.177553560445.issue9349@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Argparse supports silencing help for certain options using SUPPRESS.

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--foo', help=argparse.SUPPRESS)
>>> parser.print_help()
usage: [-h]

optional arguments:
  -h, --help  show this help message and exit

This should be documented in the description of help=

http://docs.python.org/library/argparse.html#help

----------
assignee: docs at python
components: Documentation
messages: 111320
nosy: bethard, docs at python
priority: normal
severity: normal
status: open
title: document argparse's help=SUPPRESS
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 23 18:25:28 2010
From: report at bugs.python.org (Brian Brazil)
Date: Fri, 23 Jul 2010 16:25:28 +0000
Subject: [docs] [issue9358] Document fnmatch.translate's lack of support for
	escaping
In-Reply-To: <1279902328.19.0.409453550243.issue9358@psf.upfronthosting.co.za>
Message-ID: <1279902328.19.0.409453550243.issue9358@psf.upfronthosting.co.za>


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

fnmatch.translate's docstraing says "There is no way to quote meta-characters.", but this isn't in the html docs. The attached patch fixes that.

----------
assignee: docs at python
components: Documentation
files: fnmatch_translate_doc.patch
keywords: patch
messages: 111358
nosy: bbrazil, docs at python
priority: normal
severity: normal
status: open
title: Document fnmatch.translate's lack of support for escaping
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file18156/fnmatch_translate_doc.patch

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

From report at bugs.python.org  Fri Jul 23 18:49:41 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Jul 2010 16:49:41 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1279903780.66.0.830183493225.issue9264@psf.upfronthosting.co.za>


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

To the doc person who reads this: this patch is only the first for this issue. It is being submitted now since the 2.6.6 release candidate is due in 10 days. Please leave the issue open after committing this.

I have read the diff but not the patched result (cannot make such yet), so someone else should recheck the formatted result.

Marked release blocker with agreement of Barry W., who also wants to take a look too.

----------
assignee: tjreedy -> docs at python
nosy: +barry
priority: normal -> release blocker
stage: patch review -> commit review

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

From report at bugs.python.org  Fri Jul 23 18:59:13 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 23 Jul 2010 16:59:13 +0000
Subject: [docs] [issue9358] Document fnmatch.translate's lack of support for
	escaping
In-Reply-To: <1279902328.19.0.409453550243.issue9358@psf.upfronthosting.co.za>
Message-ID: <1279904353.18.0.57513125779.issue9358@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jul 23 21:24:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 23 Jul 2010 19:24:03 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

This bikeshed have been repainted several times already, but here is a true story.

Cast:

Me = myself
Novice = a 14-year-old boy
Laptop = a MacBook Air

Novice: How do i exit [from python prompt]?
Me: What's your best guess?
Novice: [typing] exit [pressing Enter]
Laptop: Use exit() or Ctrl-D (i.e. EOF) to exit
Novice: [typing] Ctrl...
Me: OMG, you don't know what Ctrl-D means?  Look for the Ctrl key.
Novice: There is no such key.
    --- curtains ---

I suggest changing

Use exit() or Ctrl-D (i.e. EOF) to exit

 to 

Type exit() or quit() and press the Enter key to exit

  or

Type exit() or quit() and press Enter to exit

 or just

Use exit() to exit

My theory is that someone who knows what EOF is, will probably already know how to exit from common terminal oriented programs and Ctrl-D is not universally bound to EOF.

TOOWTDI: two ways to exit is more than enough to teach a novice.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 111374
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Make exit/quit hint more novice friendly
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Jul 23 23:27:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Jul 2010 21:27:02 +0000
Subject: [docs] [issue9237] Add sys.call_tracing to on-line sys module
	documentation
In-Reply-To: <1278973764.17.0.0501374635668.issue9237@psf.upfronthosting.co.za>
Message-ID: <1279920422.49.0.69838679391.issue9237@psf.upfronthosting.co.za>


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

I verified that in 3.1, sys.call_tracing exists but is undocumented.

I also noticed that the sys doc entries are *almost* in alphabetical order.

Out of place: subversion, dont_write_bytecode, api_version
Reversed pairs (abbreviated)
copyright  clearxxx
dllxxx disxxx
getrefxx getrecxx

----------
keywords: +easy
nosy: +tjreedy
stage:  -> needs patch
versions:  -Python 2.5, Python 3.3

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

From report at bugs.python.org  Fri Jul 23 23:54:21 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 23 Jul 2010 21:54:21 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1279922061.74.0.403524519647.issue9264@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

If the changes are to the documentation only, you've confirmed that the docs build in 2.6.6, and you get the changes in before 2.6.6rc1, then you can go ahead and commit them.  I don't need to review them too closely - I trust you - but if you want me to do a detailed review before rc1, let me know and I'm happy to.

----------
resolution:  -> accepted

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

From report at bugs.python.org  Sat Jul 24 03:42:25 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 24 Jul 2010 01:42:25 +0000
Subject: [docs] [issue8888] Promote SafeConfigParser and warn about
	ConfigParser
In-Reply-To: <1275565799.83.0.624762218664.issue8888@psf.upfronthosting.co.za>
Message-ID: <1279935745.77.0.313894495826.issue8888@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

This issue is superseeded by issue #6517 (because the other has an actual patch).

Brett, shall we close this as duplicate and resolve the original?

----------
nosy: +brett.cannon, lukasz.langa

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

From report at bugs.python.org  Sat Jul 24 04:28:22 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 24 Jul 2010 02:28:22 +0000
Subject: [docs] [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1279938502.63.0.934622715745.issue9101@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

1: Agreed.

2: Would use wording like: "The json module can also be used for this purpose." Can be used does not imply that it is its main function but it hints in the right direction.

----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Sat Jul 24 07:23:47 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 24 Jul 2010 05:23:47 +0000
Subject: [docs] [issue9364] some problems with the documentation of pydoc
In-Reply-To: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>
Message-ID: <1279949027.26.0.1869842795.issue9364@psf.upfronthosting.co.za>


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

The first paragraph in its documentation says:

"""
In the Python interpreter, do "from pydoc import help" to provide online
help.  Calling help(thing) on a Python object documents the object.
"""

Which is no longer accurate, because the help() function has long ago become a built-in.

Below is an excerpt from Terry Reedy in a private email discussion on this subject, that raises more issues.

---------------------------------------------

1. The output from help(help) could be made more clear.

The nature of 'help' has been a point of confusion. A recent python-list post asked something like "What is 'help'?"

Now (with some parallel examples:

>>> help(int)
Help on class int in module builtins:

class int(object)
[snip]

>>> help(1)
Help on int object:

class int(object)
[snip]

>>> help(help)
Help on _Helper in module site object:

class _Helper(builtins.object)
 |  Define the built-in 'help'.
 |  This is a wrapper around pydoc.help (with a twist).
 |
 |  Methods defined here:
 |
 |  __call__(self, *args, **kwds)
 |

a. 'module site object' is nonsense, it should just be 'module site', except that to be parallel to what is done for other instances, it should be 'Help on _Helper object'. Why should help special-case itself (with a slightly garbled line?) Is that done in site._Helper or pydoc.help?

However, it would be more helpful for all instances to give the location of the class when one asks for help on an instance, just as when one asks for help on the class itself. It is annoying to to have to repeat help(<classname>) just to get that info. So I would like to see
"Help on instance of class int in module builtins:"
"Help on instance of class _Helper in module site:"

This would be a code patch to pydoc.help

b. "This is a wrapper around pydoc.help" good so far
"(with a twist)" thanks a lot. I think the comment should be either removed or explained. A reference manual should explain, not tease.

Replace "Define the built-in 'help'." with something clearer and more accurate, such as "The name 'help' is injected in module builtins after being bound to an instance of this class.". Put this after, not before, the 'wrapper' line.

A patch for site._Helper doc string.


2. Improve manual chapter for site module.

a. It currently starts "Importing this module will append site-specific paths to the module search path." Add "inject 'help' into builtins and " after append. Then add a short explanation paragraph before the search path stuff. Something like

"This module contains a class (_Helper) that wraps function pydoc.help. An instance of the class is bound to name 'help' in the builtins module."

A recent discussion on pydev or maybe python-list (in the thread mentioned above?) implied that one could usefully make another instance of _Helper or maybe a subclass thereof. I did not pay enough attention, though, to really get it.

b. It currently ends with "XXX Update documentation XXX document python -m site ?user-base ?user-site"

----------
assignee: docs at python
components: Documentation
messages: 111426
nosy: docs at python, eli.bendersky, tjreedy
priority: normal
severity: normal
status: open
title: some problems with the documentation of pydoc
type: behavior
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jul 24 07:45:35 2010
From: report at bugs.python.org (Ron Adam)
Date: Sat, 24 Jul 2010 05:45:35 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1279950335.61.0.614604441185.issue9362@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

I agree it could be improved a bit.

A little experimenting comes up with the following inconsistencies.

>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>> exit
Use exit() or Ctrl-D (i.e. EOF) to exit

help(exit) and help(quit) is not helpful. It instead shows the Quitter class in site.py with no doc strings.

exit() and quit() are both equivalent to sys.exit() and both except an exit code or message.


I think your third choice is good.

Type exit() or quit() and press Enter to exit

Advance users can still use Cntl-D.

Add a topics entry for help('EXIT') which can explain exiting the console in more detail and include the Ctrl-D short cut. help('QUIT') can point to the same topics info used for 'EXIT'.

Then add a doc string the the Quitter class that says to use help('EXIT') or help('QUIT') to get help for exit and quit.  


On another note: I've sometimes wanted quit() to exit from a running script to the python console so I can do a little value checking.  And for exit() to exit both the program and the console. But I think it may be too lake to make that particular change.

----------
nosy: +ron_adam

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

From report at bugs.python.org  Sat Jul 24 12:49:07 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 24 Jul 2010 10:49:07 +0000
Subject: [docs] [issue9370] Add reader redirect from test package docs to
	unittest	module
In-Reply-To: <1279968547.11.0.280770421062.issue9370@psf.upfronthosting.co.za>
Message-ID: <1279968547.11.0.280770421062.issue9370@psf.upfronthosting.co.za>


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

Brett updated the docs for the test package to (correctly) point out that it is our internal testing package and isn't subject to the same stringent backwards compatibility rules as the rest of the standard library.

A "see also" link pointing readers that have landed there over to the unittest module for their testing infrastructure needs would be a friendly thing to include.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 111450
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add reader redirect from test package docs to unittest module
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Jul 24 13:26:42 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 24 Jul 2010 11:26:42 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1279970802.25.0.825795897531.issue9362@psf.upfronthosting.co.za>


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

I assume that this is on *nix boxes, on Windows it's:-

>>> quit
Use quit() or Ctrl-Z plus Return to exit
>>> exit
Use exit() or Ctrl-Z plus Return to exit

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

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

From report at bugs.python.org  Sat Jul 24 14:55:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 24 Jul 2010 12:55:30 +0000
Subject: [docs] [issue7635] 19.6 xml.dom.pulldom doc: stub?
In-Reply-To: <1262651647.28.0.891885115157.issue7635@psf.upfronthosting.co.za>
Message-ID: <1279976130.14.0.657090018876.issue7635@psf.upfronthosting.co.za>


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

Working off py3k is the thing to do. If the patch is trivial to apply to the other branches, the committer will probably use svnmerge to do it, else it may be useful to adapt your patch to 2.7. I?d recommend waiting for feedback before doing this.

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

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

From report at bugs.python.org  Sat Jul 24 16:32:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 24 Jul 2010 14:32:26 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1279981945.78.0.074747826137.issue9362@psf.upfronthosting.co.za>


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

> I assume that this is on *nix boxes

It's a bit of a stretch to call OSX unix, but yes:

>> Laptop = a MacBook Air

If you have not seen one of these, the control key is marked "control" on its keyboard.

----------

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

From report at bugs.python.org  Sat Jul 24 16:37:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 24 Jul 2010 14:37:25 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1279982244.95.0.474681675852.issue9362@psf.upfronthosting.co.za>


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

Now, as I look at it, the windows message is probably even worse.  What is "plus"?  Is "Ctrl-Z" control *minus* z?

For a novice, you really have to say: press Ctrl and Z keys together and then press Return or Enter key.  Of course this longer phrase is not appropriate for the exit hint.

----------

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

From report at bugs.python.org  Sat Jul 24 16:49:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 24 Jul 2010 14:49:39 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1279982978.8.0.561005262906.issue9362@psf.upfronthosting.co.za>


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

> On another note: I've sometimes wanted quit() to exit from a running
> script to the python console so I can do a little value checking.

This is what -i command line switch or PYTHONINSPECT environment variable is for.

See python -h output.

----------

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

From report at bugs.python.org  Sun Jul 25 00:02:58 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Jul 2010 22:02:58 +0000
Subject: [docs] [issue7635] 19.6 xml.dom.pulldom doc: stub?
In-Reply-To: <1262651647.28.0.891885115157.issue7635@psf.upfronthosting.co.za>
Message-ID: <1280008977.85.0.342758699683.issue7635@psf.upfronthosting.co.za>


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

Thank you for the patch. I can now imagine using the module. Comments:

"+   :synopsis: Iterative XML parsing with DOM nodes."
seem a bit too terse and confusing. Would

"+   :synopsis: Iterative parsing of XML to event, DOM node pairs, with option subtree creation."

be accurate?

-.. class:: PullDOM(documentFactory=None)
-   :class:`xml.sax.handler.ContentHandler` implementation that ...

I was expecting this to be filled out with the methods of PullDOM. But you new docstring
"+    """A ContentHandler that is used internally by :class:`DOMEventStream` to
+    provide an iterator over the nodes in an XML stream. This class would not
+    normally be used directly - its main responsibility is to produce DOM
+    nodes from SAX events."

suggests that it is sufficiently private that it should not be documented at all, and that anyone who wanted to use it directly should either try help(pullDom) or read the code. Correct?

I am not sure of the standard for when to document or not helper classes, so I will leave this question to a doc person.

"\ No newline at end of file"
Is this a message from diff to add one?
--------------

The py3k branch is now trunk. Most applicable patches should be developed on that branch and then possibly backported. The current pullDOM page is useless, so this should be backported. Since the docs appear to have been untouched since the beginning, the manual page, at least, should apply directly.

To go into 2.6.6, the final 2.6 bugfix release, a patch needs be applied by the end of July. So consider my first and third comments first and a possible minor update. I would recommend that for commit/review for at least 2.6.

----------
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Sun Jul 25 02:37:44 2010
From: report at bugs.python.org (ipatrol)
Date: Sun, 25 Jul 2010 00:37:44 +0000
Subject: [docs] [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1280018264.02.0.490119418589.issue8340@psf.upfronthosting.co.za>


ipatrol <ipatrol6010 at yahoo.com> added the comment:

Yeah, I'll say. I prefer bytearray to back-and-forth mapping with chr and ord. I use it particularly as a mid-step in working with binary representations of strings. Please backport these docs with changes reflecting 2.x's paradigms.

----------
nosy: +ipatrol
type: behavior -> feature request

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

From report at bugs.python.org  Sun Jul 25 07:00:38 2010
From: report at bugs.python.org (Grant Limberg)
Date: Sun, 25 Jul 2010 05:00:38 +0000
Subject: [docs] [issue7303] pkgutil lacks documentation for useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1280034037.13.0.0706862948248.issue7303@psf.upfronthosting.co.za>


Grant Limberg <glimberg at gmail.com> added the comment:

I've taken the liberty of creating a patch for this issue.  I've taken the docstrings fromt he pkgutil module and conveted them to reST.

Please let me know if there are any changes necessary.

----------
keywords: +patch
nosy: +Grant.Limberg
Added file: http://bugs.python.org/file18193/pkgutil-docs-py3k-branch.patch

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

From report at bugs.python.org  Sun Jul 25 10:27:01 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 25 Jul 2010 08:27:01 +0000
Subject: [docs] [issue7303] pkgutil lacks documentation for useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1280046421.33.0.571112365716.issue7303@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 25 10:52:02 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 25 Jul 2010 08:52:02 +0000
Subject: [docs] [issue8888] Promote SafeConfigParser and warn about
	ConfigParser
In-Reply-To: <1275565799.83.0.624762218664.issue8888@psf.upfronthosting.co.za>
Message-ID: <1280047922.7.0.83754178902.issue8888@psf.upfronthosting.co.za>


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

Closed as duplicate of #6517.

----------
nosy: +BreamoreBoy
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Sun Jul 25 10:58:22 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 25 Jul 2010 08:58:22 +0000
Subject: [docs] [issue2204] document ConfigParser behaviour when a file has
	same	section multiple times
In-Reply-To: <1204236720.35.0.634026900248.issue2204@psf.upfronthosting.co.za>
Message-ID: <1280048302.47.0.222058759171.issue2204@psf.upfronthosting.co.za>


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

@?ukasz: could you provide a patch that clarifies the default behaviour.

----------
assignee: georg.brandl -> docs at python
nosy: +BreamoreBoy, docs at python
stage: unit test needed -> needs patch

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

From report at bugs.python.org  Sun Jul 25 11:05:07 2010
From: report at bugs.python.org (Mark Smith)
Date: Sun, 25 Jul 2010 09:05:07 +0000
Subject: [docs] [issue7635] 19.6 xml.dom.pulldom doc: stub?
In-Reply-To: <1262651647.28.0.891885115157.issue7635@psf.upfronthosting.co.za>
Message-ID: <1280048705.83.0.173875117089.issue7635@psf.upfronthosting.co.za>


Mark Smith <mark.smith at practicalpoetry.co.uk> added the comment:

Terry, thanks for the feedback!

I have added a patch, replacing the previous one, which deals with your points 1 and 3 in the following ways:

1. I have used (an edited form of) your synopsis - I've removed the details of exactly what is returned from the iterator, as I thought it made the sentence structure slightly awkward - hope you don't mind. I've moved the old synopsis to the heading, which is where I intended it to be anyway.

3. I added the newline - I don't think this is really a problem, but neither is the fix :)

Regarding point 2: I agree with you - I struggled with whether to include references to these classes, eventually settling for what you see. I suppose they could be re-used for converting SAX events to DOM nodes, so it could be useful to know they are there.

SAX2DOM isn't even used internally, so is technically part of the module's public interface, but with such brittle behaviour that I think it should really be removed. It automatically adds children to their parent when they are parsed -- but the children will only be parsed if the buffer is large enough. If it isn't then you can get incorrectly empty or even partial subtrees.

----------
Added file: http://bugs.python.org/file18194/7635_2.patch

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

From report at bugs.python.org  Sun Jul 25 11:06:26 2010
From: report at bugs.python.org (Mark Smith)
Date: Sun, 25 Jul 2010 09:06:26 +0000
Subject: [docs] [issue7635] 19.6 xml.dom.pulldom doc: stub?
In-Reply-To: <1262651647.28.0.891885115157.issue7635@psf.upfronthosting.co.za>
Message-ID: <1280048786.52.0.686638029247.issue7635@psf.upfronthosting.co.za>


Changes by Mark Smith <mark.smith at practicalpoetry.co.uk>:


Removed file: http://bugs.python.org/file18179/7635.patch

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

From report at bugs.python.org  Sun Jul 25 12:10:14 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 25 Jul 2010 10:10:14 +0000
Subject: [docs] [issue2864] etree: Add XPath documentation
In-Reply-To: <1210863012.97.0.696135529968.issue2864@psf.upfronthosting.co.za>
Message-ID: <1280052613.94.0.872908754701.issue2864@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jul 25 13:58:47 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 25 Jul 2010 11:58:47 +0000
Subject: [docs] [issue9376] Refer to gnuwin32 diff util on development FAQ
In-Reply-To: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>
Message-ID: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>


New submission from Mark Lawrence <breamoreboy at yahoo.co.uk>:

Section 6.1 How to make a patch? currently reads in part

(a Windows version is available as part of the cygwin tools).

I suggest that this is reworded to read

(Windows versions are available as part of the cygwin tools or as part of the gnuwin32 project)

I simply find it much easier to download and install these individual tools, e.g. I also have their version of grep which is vastly superior to Windows find

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 111536
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: Refer to gnuwin32 diff util on development FAQ
type: feature request

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

From report at bugs.python.org  Sun Jul 25 15:05:56 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 25 Jul 2010 13:05:56 +0000
Subject: [docs] [issue1495229] W3C <-> Python DOM type mapping docs need
	updating
Message-ID: <1280063156.09.0.139025483592.issue1495229@psf.upfronthosting.co.za>


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

Nobody has objected to Terry Reedy's recommendations so can the docs be updated please.

----------
assignee: loewis -> docs at python
nosy: +BreamoreBoy, docs at python

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

From report at bugs.python.org  Sun Jul 25 15:17:09 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 25 Jul 2010 13:17:09 +0000
Subject: [docs] [issue7637] Improve 19.5. xml.dom.minidom doc
In-Reply-To: <1262659434.4.0.874382323645.issue7637@psf.upfronthosting.co.za>
Message-ID: <1280063828.85.0.382802347208.issue7637@psf.upfronthosting.co.za>


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

Items 1) and 3) have been committed, only 2) needs to be addressed.

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

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

From report at bugs.python.org  Sun Jul 25 23:34:35 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 25 Jul 2010 21:34:35 +0000
Subject: [docs] [issue1495229] W3C <-> Python DOM type mapping docs need
	updating
Message-ID: <1280093675.25.0.0121638112617.issue1495229@psf.upfronthosting.co.za>


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

Unlike with some issues, my in-message recommendations here do not constitute a patch.

docs at python could update the link immediately. I would be willing to review the more extensive patch for 3.x if someone makes one.

----------
keywords: +easy
stage:  -> needs patch

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

From report at bugs.python.org  Mon Jul 26 00:11:53 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 25 Jul 2010 22:11:53 +0000
Subject: [docs] [issue1495229] W3C <-> Python DOM type mapping docs need
	updating
Message-ID: <1280095913.61.0.332047947177.issue1495229@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

The current link in the docs works; it's http://www.omg.org/spec/PYTH/1.2/PDF/.

----------

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

From report at bugs.python.org  Mon Jul 26 00:34:15 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 25 Jul 2010 22:34:15 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280097255.45.0.787585382736.issue7447@psf.upfronthosting.co.za>


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

In order to have a chance at 2.6.6rc, due out in a week, I hand-edited the patch, incorporating Georg's suggestion, and uploaded. I think it is ready to commit.

Since this is not a critical doc fix, I am not marking it a blocker, but I still think it would be good to get it in.

Raymond, since you have not posted anything, I am assuming that your main interest was that the code not be changed, at least not without your notice. Since this is staying a doc issue, I am re-assigning.

----------
assignee: rhettinger -> docs at python
nosy: +docs at python
stage: patch review -> commit review
Added file: http://bugs.python.org/file18199/functions.rst.patch2

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

From report at bugs.python.org  Mon Jul 26 00:52:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 25 Jul 2010 22:52:59 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280098379.18.0.284065284287.issue7447@psf.upfronthosting.co.za>


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

FWIW, I like the new patch better, but still have a few nitpicks:

- Starting a sentence with an argument name is a bit awkward because that makes a sentence that starts with a lower case letter.  

- There is an extra space in :class: `list`.

- It would make more boring prose, but I would prefer to see similar language used in each alternative.  I.e.

   - To concatenate ...
   - To concatenate ...
   - To add ...

- Why "an *iterable* of iterables" but "a *sequence* of strings"?

- I am not sure it is correct to say "to concatenate an iterable", I think it should be "to concatenate items from an iterable."

----------

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

From report at bugs.python.org  Mon Jul 26 01:07:14 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 25 Jul 2010 23:07:14 +0000
Subject: [docs] [issue1495229] W3C <-> Python DOM type mapping docs need
	updating
Message-ID: <1280099233.96.0.209433126018.issue1495229@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Changed on the trunk in rev83149.

I removed both paragraphs after the table, adding null and DOMString to the table, and took the word 'primitive' out of the first sentence (so the table isn't listing just primitive types, but can list DOMString).

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

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

From report at bugs.python.org  Mon Jul 26 01:24:34 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 25 Jul 2010 23:24:34 +0000
Subject: [docs] [issue7637] Improve 19.5. xml.dom.minidom doc
In-Reply-To: <1262659434.4.0.874382323645.issue7637@psf.upfronthosting.co.za>
Message-ID: <1280100274.01.0.880377108441.issue7637@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

2) changed in rev83151.  I extensively rearranged the description of toxml(), hopefully making its meaning clearer.

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

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

From report at bugs.python.org  Mon Jul 26 01:39:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 25 Jul 2010 23:39:00 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280101139.95.0.627031006222.issue7447@psf.upfronthosting.co.za>


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

patch3 incorporates all your suggestions.

I verified the itertools hint:
>>> list(itertools.chain.from_iterable([[10],[1,2],['a']]))
[10, 1, 2, 'a']

I think the hints are clear enough; anyone with more questions should follow the link to the respective function doc.

----------
Added file: http://bugs.python.org/file18203/functions.rst.patch3

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

From report at bugs.python.org  Mon Jul 26 01:44:26 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 25 Jul 2010 23:44:26 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280101465.81.0.0187483092534.issue7447@psf.upfronthosting.co.za>


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

I want to look at this more before it goes forward.
The docs are roughly correct as-is.  In a effort
to make them precise, it is easy make them more
confusing or at least a bit harder to understand
the basic function of sum().

----------
assignee: docs at python -> rhettinger
priority: normal -> low

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

From report at bugs.python.org  Mon Jul 26 02:12:31 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Jul 2010 00:12:31 +0000
Subject: [docs] [issue7637] Improve 19.5. xml.dom.minidom doc
In-Reply-To: <1262659434.4.0.874382323645.issue7637@psf.upfronthosting.co.za>
Message-ID: <1280103150.78.0.931404957464.issue7637@psf.upfronthosting.co.za>


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

Thank you for the patches, but I do not think this is quite done.

1. "It is recommended that you always specify an encoding; you may use any encoding you like, but an argument of "utf-8" is the most common, avoid :exc:`UnicodeError` exceptions in case of unrepresentable text data."
The phrase after the comma is garbled. I think it means something like "It avoids :exc:`UnicodeError` exceptions for unrepresentable text data."

2. For Node.toprettyxml(indent="", newl="", encoding="")
I think 
"There's also an *encoding* argument, that behaves like the corresponding argument of :meth:`toxml`."
should simply say 
"The ``encoding`` argument behaves like the corresponding argument of :meth:`toxml`."

We already know there is one because it is there in the signature. I suspect saying so might date back to when there either was no signature or encoding was left out of it.

----------

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

From report at bugs.python.org  Mon Jul 26 06:53:04 2010
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 26 Jul 2010 04:53:04 +0000
Subject: [docs] [issue9381] syntax error in Unicode C API docs
In-Reply-To: <1280119983.35.0.570535028701.issue9381@psf.upfronthosting.co.za>
Message-ID: <1280119983.35.0.570535028701.issue9381@psf.upfronthosting.co.za>


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

See http://docs.python.org/py3k/c-api/unicode.html#file-system-encoding

Note the literal and unhyperlinked ":func:PyUnicode_FSConverter" in the last sentence of the first paragraph. I suspect there's a trivial syntax error in the ReST source.

----------
assignee: docs at python
components: Documentation
messages: 111596
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: syntax error in Unicode C API docs
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 26 07:24:09 2010
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 26 Jul 2010 05:24:09 +0000
Subject: [docs] [issue9382] os.popen referenced but not documented in Python
	3.x
In-Reply-To: <1280121849.18.0.464291520909.issue9382@psf.upfronthosting.co.za>
Message-ID: <1280121849.18.0.464291520909.issue9382@psf.upfronthosting.co.za>


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

http://docs.python.org/py3k/library/os.html  currently mentions os.popen() in several places. The docs for os.popen() itself say:
'These functions are described in section "File Object Creation"'

However, unlike the 2.x version of that section ( http://docs.python.org/library/os.html#file-object-creation ), the os.popen*() family is not documented there [or indeed anywhere] anymore ( http://docs.python.org/py3k/library/os.html#os-newstreams ); the entire section now only documents os.fdopen().

The 2.7 docs say that the os.popen*() family are deprecated, and indeed, of the family, only os.popen() seems to still exist in Python 3.x (at least based on my testing via ideone.com).

Thus, from what I can see, one of the following is the case:
(A) The entire os.popen*() family is supposed be gone in Python 3.x, so os.popen() should be removed entirely from both the code and the docs.
(B) os.popen() is the sole legitimate survivor of its family, and should be properly documented again.
(C) os.popen() was left in as a kludge, shouldn't be mentioned in the docs, and possibly should be renamed os._popen() to reflect its status.

So, which one of these is it?

----------
assignee: docs at python
components: Documentation
messages: 111597
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: os.popen referenced but not documented in Python 3.x
versions: Python 3.1

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

From darreny at MIT.EDU  Fri Jul 23 19:37:02 2010
From: darreny at MIT.EDU (Darren Yin)
Date: Fri, 23 Jul 2010 10:37:02 -0700
Subject: [docs] Request Object in urllib2 missing two methods in
	documentation
Message-ID: <AANLkTikwXNwdu6Z8LuUO0xP6Fxrengo+G7BL+6jm7jgj@mail.gmail.com>

http://docs.python.org/library/urllib2.html#request-objects

There are two undocumented getter methods in urllib2.Request:
get_header and header_items

Just an fyi, it might be good to at least put the method signatures
into the docs.

~Darren Yin

From thomharp at gmail.com  Fri Jul 23 21:48:04 2010
From: thomharp at gmail.com (Thom Harp)
Date: Fri, 23 Jul 2010 15:48:04 -0400
Subject: [docs] Triple quotes converted badly in PDF documentation for 3.1
Message-ID: <AANLkTim+TvxuW+kVG4wR7XEWnZfbXenTqV+F9DVJ9V-Y@mail.gmail.com>

Triple quotes in the restructured text sources are getting converted
badly in PDF documentation.  Consider this from
py3k/Doc/tutorial/introduction.rst:

    Or, strings can be surrounded in a pair of matching triple-quotes:
``"""`` or
    ``'''``.  End of lines do not need to be escaped when using
triple-quotes, but

Which converts to this in the PDF version downloaded from
http://docs.python.org/py3k/download.html:

    Or, strings can be surrounded in a pair of matching triple-quotes:
""" or ??. End of lines do not need to be escaped
    when using triple-quotes, but

Note that the ``'''`` in the source appears as "' in the PDF.

A more confusing instance is from py3k/Doc/reference/lexical_analysis.rst:

    shortstring: "'" `shortstringitem`* "'" | '"' `shortstringitem`* '"'
    longstring: "'''" `longstringitem`* "'''" | '"""' `longstringitem`* '"""'

Which converts to this:

    shortstring ::= ??? shortstringitem* ??? | ??? shortstringitem* ???
    longstring ::= ????? longstringitem* ????? | ????? longstringitem* ?????

Thanks,
Thom Harp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100723/0dd25474/attachment.html>

From barakstout at gmail.com  Sat Jul 24 10:48:51 2010
From: barakstout at gmail.com (Barak Stout)
Date: Sat, 24 Jul 2010 04:48:51 -0400
Subject: [docs] Python 3 docs
Message-ID: <EFA1D6AF-3334-40D3-A7A4-E003592784E1@gmail.com>

Hi,

I have tried to download the python 3 docs, it says the url is no found for all the options. Could you email me back when to expect it to be fixed?

Thanks,

Barak 




From amandsin at cisco.com  Mon Jul 26 08:54:46 2010
From: amandsin at cisco.com (Amandeep Singh (amandsin))
Date: Mon, 26 Jul 2010 12:24:46 +0530
Subject: [docs] python tutorial more a reference than a tutorial
Message-ID: <F790D9474379664BB03E53DA89E9218F0154E681@XMB-BGL-41A.cisco.com>

Hi,

 

I tried to study your python tutorial, release 2.6.4. But was very
disappointed the way it is written. It is more a reference than a
tutorial. Language could have been simpler, giving more examples.

 

Thanks,

Amandeep

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

From report at bugs.python.org  Mon Jul 26 10:52:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 26 Jul 2010 08:52:03 +0000
Subject: [docs] [issue9381] syntax error in Unicode C API docs
In-Reply-To: <1280119983.35.0.570535028701.issue9381@psf.upfronthosting.co.za>
Message-ID: <1280134323.54.0.0490020267458.issue9381@psf.upfronthosting.co.za>


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

Thanks, fixed in r83160.

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

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

From report at bugs.python.org  Mon Jul 26 13:31:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Jul 2010 11:31:35 +0000
Subject: [docs] [issue9382] os.popen referenced but not documented in Python
	3.x
In-Reply-To: <1280121849.18.0.464291520909.issue9382@psf.upfronthosting.co.za>
Message-ID: <1280143895.17.0.691069247007.issue9382@psf.upfronthosting.co.za>


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

(D) in python 3, os.popen has been reimplemented using subprocess.Popen.
So the other mentions of os.popen should probably be replaced with mentions of subprocess.Popen.

Your (C) is close...the continued existence of os.popen in Python3 is, I think, a bit of a kludge (I wasn't around for the discussion), but a backward compatibility one.  I don't know if there is a plan to deprecate it, but I suspect not.  On the other hand I certainly wouldn't recommend using it, since it does an import inside the function, which can get one into trouble if one uses threads.

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

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

From report at bugs.python.org  Mon Jul 26 14:54:53 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 26 Jul 2010 12:54:53 +0000
Subject: [docs] [issue7637] Improve 19.5. xml.dom.minidom doc
In-Reply-To: <1262659434.4.0.874382323645.issue7637@psf.upfronthosting.co.za>
Message-ID: <1280148893.13.0.320700516726.issue7637@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Thanks for the catch; it was intended to be ', avoiding ...'.  Fixed in rev83162, along with the sentence simplification you suggest.

----------

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

From techtonik at gmail.com  Mon Jul 26 15:19:47 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 26 Jul 2010 16:19:47 +0300
Subject: [docs] python tutorial more a reference than a tutorial
In-Reply-To: <F790D9474379664BB03E53DA89E9218F0154E681@XMB-BGL-41A.cisco.com>
References: <F790D9474379664BB03E53DA89E9218F0154E681@XMB-BGL-41A.cisco.com>
Message-ID: <AANLkTi=taXtg7w=cfh7UmV49COoSe7BudVQowa95o+mP@mail.gmail.com>

Loss of consistency is always a problem with documentation that is
maintained in patches.
The whole Python documentation lacks user submitted scenarios and examples.

I sell this idea for PSF for free. Take a look at online pages at
http://php.net/ for an inspiration.
--
anatoly t.



On Mon, Jul 26, 2010 at 9:54 AM, Amandeep Singh (amandsin)
<amandsin at cisco.com> wrote:
> Hi,
>
>
>
> I tried to study your python tutorial, release 2.6.4. But was very
> disappointed the way it is written. It is more a reference than a tutorial.
> Language could have been simpler, giving more examples.
>
>
>
> Thanks,
>
> Amandeep
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>
>

From report at bugs.python.org  Mon Jul 26 15:26:43 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 26 Jul 2010 13:26:43 +0000
Subject: [docs] [issue9376] Refer to gnuwin32 diff util on development FAQ
In-Reply-To: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>
Message-ID: <1280150802.95.0.799383854843.issue9376@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

There is diff.py utility that is already available from standard Python distribution.

----------
nosy: +techtonik

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

From report at bugs.python.org  Mon Jul 26 15:53:47 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 26 Jul 2010 13:53:47 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1280152426.95.0.814748905777.issue9362@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

+1 to improving the message and improving the help message too.

----------
nosy: +michael.foord

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

From report at bugs.python.org  Mon Jul 26 16:21:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 26 Jul 2010 14:21:30 +0000
Subject: [docs] [issue9376] Refer to gnuwin32 diff util on development FAQ
In-Reply-To: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>
Message-ID: <1280154089.73.0.475672003568.issue9376@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I don't think we should have a list of three alternatives to the single way you really should be creating diffs. If you are working on Python you should have Subversion and run "svn diff", or have Mercurual and run "hg diff".

I guess I'm -0 on this idea. I also don't even know where the dev/faq page is located in SVN to make any potential change.

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

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

From report at bugs.python.org  Mon Jul 26 16:24:39 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 26 Jul 2010 14:24:39 +0000
Subject: [docs] [issue9376] Refer to gnuwin32 diff util on development FAQ
In-Reply-To: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>
Message-ID: <1280154279.21.0.413044940155.issue9376@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

"svn diff" should be the one true way for creating patches, especially for windows users. This will all change when we switch to mercurial.

----------
nosy: +michael.foord

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

From report at bugs.python.org  Mon Jul 26 16:27:40 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 26 Jul 2010 14:27:40 +0000
Subject: [docs] [issue9376] Refer to gnuwin32 diff util on development FAQ
In-Reply-To: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>
Message-ID: <1280154460.4.0.315255835556.issue9376@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The better way would be
> python -m easy_install review
> python -m review

----------

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

From report at bugs.python.org  Mon Jul 26 16:30:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 26 Jul 2010 14:30:43 +0000
Subject: [docs] [issue9376] Refer to gnuwin32 diff util on development FAQ
In-Reply-To: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>
Message-ID: <1280154643.52.0.204821080583.issue9376@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Until Rietveld has a defined place in our workflow, I don't think that's a good idea.

I think that will be a part of the process in the future, but we're not defining that here.

----------

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

From report at bugs.python.org  Mon Jul 26 16:32:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 26 Jul 2010 14:32:35 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <AANLkTimMiSOvxGdDVZtcVkwke+uCawrP__bkhXSHfP_-@mail.gmail.com>
Message-ID: <AANLkTimBaitELhgrSfJf54Lj5y9ry9qE5KD=qrQhtojL@mail.gmail.com>


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

On Mon, Jul 26, 2010 at 9:48 AM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> Type exit() or press Ctrl-D to exit.

Anatoly,

I think you missed the point of the story that I posted.  The young
user, who was not completely new to computers, by the way, was not
familiar with "Ctrl"  abbreviation and there was no key marked that
way on his keyboard.

----------

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

From report at bugs.python.org  Mon Jul 26 16:50:56 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 26 Jul 2010 14:50:56 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1280155856.08.0.249111529401.issue9362@psf.upfronthosting.co.za>


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

1) I'm with Michael on this one.
2) Python is not responsible for dotting every i and crossing every t for a computer novice.  What would the novice make of my HP keyboard which doesn't have keys marked RETURN or BS, they both have symbols.  There isn't an ANY key on the keyboard either! :)

----------

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

From report at bugs.python.org  Mon Jul 26 17:07:02 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 26 Jul 2010 15:07:02 +0000
Subject: [docs] [issue9376] Refer to gnuwin32 diff util on development FAQ
In-Reply-To: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>
Message-ID: <1280156822.63.0.636283230392.issue9376@psf.upfronthosting.co.za>


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

I believe that the switch to mercurial is months if not years away, so I'd quite happily see just a reference to svn diff.  Failing that I wouldn't loose any sleep over closing this, ok to leave it with you Brian?

----------

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

From report at bugs.python.org  Mon Jul 26 17:09:48 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 26 Jul 2010 15:09:48 +0000
Subject: [docs] [issue9376] Refer to gnuwin32 diff util on development FAQ
In-Reply-To: <1280154643.52.0.204821080583.issue9376@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=pCb3MHmi+MKjJLzM+BBj-UdXQ5J0ywgiphStx@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

> Brian Curtin <curtin at acm.org> added the comment:
>
> Until Rietveld has a defined place in our workflow, I don't think that's a good idea.

1. AFAIK Python don't have any workflow. Do you speak about your own workflow?
2. What conditions should become True for you to think that's a good
idea? I.e. fill the blanks:
    if ... and ... and ...:
      debug("Rietveld has a defined place in out workflow")
      good_idea = True

----------

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

From report at bugs.python.org  Mon Jul 26 17:10:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 26 Jul 2010 15:10:39 +0000
Subject: [docs] [issue9376] Refer to gnuwin32 diff util on development FAQ
In-Reply-To: <1280059126.9.0.527330657398.issue9376@psf.upfronthosting.co.za>
Message-ID: <1280157038.93.0.447222365572.issue9376@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

"svn diff" is already explained a few times in the doc, including the line above the suggested change.

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

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

From report at bugs.python.org  Mon Jul 26 17:32:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 26 Jul 2010 15:32:20 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1280155856.08.0.249111529401.issue9362@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=sDhxJ2TP-ZiWPWugCu1FS=3rLvrSGOrzBCSPG@mail.gmail.com>


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

On Mon, Jul 26, 2010 at 10:50 AM, Mark Lawrence <report at bugs.python.org> wrote:
..
> 2) Python is not responsible for dotting every i and crossing every t for a computer novice.

Yes, but it is not responsible for teaching a novice more than one way
to exit the interpreter right off the bat.    Note that the
Ctrl-D/Ctrl-Z recommendation has a long history from the time when
there was no exit/quit object defined in the default site.py and the
alternative to the magic key-press was an unwieldy raise SystemExit.

Note the following bug report from IDLEfork project:

http://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579

Apparently, some IDEs may want to rebind Ctrl-Z form EOF to (in this
case) undo action.  This is quite reasonable, but it makes the exit
hint misleading.  There are many reasons outside of python control for
EOF to be bound to the keys other than Ctrl-Z/D.   The current logic
in site.py that makes a choice based on the filepath separator
character is quite fragile:

    if os.sep == ':':
        eof = 'Cmd-Q'
    elif os.sep == '\\':
        eof = 'Ctrl-Z plus Return'
    else:
        eof = 'Ctrl-D (i.e. EOF)'

> ?What would the novice make of my HP keyboard which doesn't have keys marked RETURN or BS,
> they both have symbols.

There is very little you can do at the command prompt without knowing
where your enter key is.  In fact, you will not even see the hint in
question if you don't press enter after typing exit.   On the other
hand, you can get quite far without using control key and if it is
marked "control" or a national equivalent on your keyboard, you may
not know the ctrl abbreviation for quite some time.  Note that my last
alternative, "Use exit() to exit" or "Enter exit() to exit"  does not
require knowing how the enter key is called.  The user just need to
know the means of entering commands and he or she must know this
before seeing the exit hint anyways.

> ?There isn't an ANY key on the keyboard either! :)

Right.  And computer industry would save loads of money in support
calls if they instructed users to press the space bar instead. :-)

----------

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

From report at bugs.python.org  Mon Jul 26 17:45:54 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 26 Jul 2010 15:45:54 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1280159154.09.0.253078853435.issue9362@psf.upfronthosting.co.za>


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

Could we (easily) add a third line at startup that says how to quit?

----------

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

From report at bugs.python.org  Mon Jul 26 18:03:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 26 Jul 2010 16:03:06 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1280159154.09.0.253078853435.issue9362@psf.upfronthosting.co.za>
Message-ID: <AANLkTimBeUr3nvnYqbQ9N_i0Gy=NuBrXDhOEXUPADUon@mail.gmail.com>


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

On Mon, Jul 26, 2010 at 11:45 AM, Mark Lawrence <report at bugs.python.org> wrote:
>
> Mark Lawrence <breamoreboy at yahoo.co.uk> added the comment:
>
> Could we (easily) add a third line at startup that says how to quit?

+1

Alternatively, we can add the second line to help output:

Type help() for interactive help, or help(object) for help about object.
Type exit() to exit python.

----------

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

From dmitry.medvinsky at gmail.com  Mon Jul 26 11:20:38 2010
From: dmitry.medvinsky at gmail.com (Dmitry Medvinsky)
Date: Mon, 26 Jul 2010 13:20:38 +0400
Subject: [docs] Small issue in argparse module docs
Message-ID: <AANLkTinTW5sZq_CcxX-Mskvnj9RV7302LCOzCw+Qu+TJ@mail.gmail.com>

Hello, folks.

I've noticed a small issue in the last example in the Action section
of argparse module documentation. Here's the link:

http://docs.python.org/library/argparse.html#action

There is wrong indentation in the definition of the __call__ method of
FooAction class. Not a big deal, but anyway.

From techtonik at gmail.com  Mon Jul 26 15:48:48 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Mon, 26 Jul 2010 16:48:48 +0300
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
References: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
	<1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <AANLkTimMiSOvxGdDVZtcVkwke+uCawrP__bkhXSHfP_-@mail.gmail.com>

On Fri, Jul 23, 2010 at 10:24 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
> I suggest changing
>
> Use exit() or Ctrl-D (i.e. EOF) to exit
>
> ?to
>
> Type exit() or quit() and press the Enter key to exit

Type exit() or press Ctrl-D to exit.

From report at bugs.python.org  Mon Jul 26 19:36:13 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 26 Jul 2010 17:36:13 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <AANLkTimBaitELhgrSfJf54Lj5y9ry9qE5KD=qrQhtojL@mail.gmail.com>
Message-ID: <AANLkTikCogO1tza3-3j8XQ-iFpcMPyuxPnunWOVcxaub@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Jul 26, 2010 at 5:32 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
>
> I think you missed the point of the story that I posted. ?The young
> user, who was not completely new to computers, by the way, was not
> familiar with "Ctrl" ?abbreviation and there was no key marked that
> way on his keyboard.

The stuff that should be explained once in a lifetime to every newborn
software engineer will waste million of braincycles over the world
every time the stuff is read. You need to consider changing the school
program in your region to add practical computer lessons where
chindren are explained all questions they have about computers.
--
anatoly t.

----------

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

From report at bugs.python.org  Mon Jul 26 19:47:32 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 26 Jul 2010 17:47:32 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1280166452.33.0.955350641752.issue9362@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
  File "<stdin>", line 1
    ?
    ^
SyntaxError: invalid syntax

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

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

From report at bugs.python.org  Mon Jul 26 19:42:27 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 26 Jul 2010 17:42:27 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <AANLkTimBeUr3nvnYqbQ9N_i0Gy=NuBrXDhOEXUPADUon@mail.gmail.com>
Message-ID: <AANLkTikwuwdWkkfWRo6qU5YJ+3KqABnHP47Wbo-r9LRy@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Jul 26, 2010 at 7:03 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
>>
>> Could we (easily) add a third line at startup that says how to quit?
>
> +1

+1

- Type "help", "copyright", "credits" or "license" for more information.
+ Type "help", "copyright", "credits" or "license" for more
information, "exit" to quit.

> Alternatively, we can add the second line to help output:
>
> Type help() for interactive help, or help(object) for help about object.
> Type exit() to exit python.

-0.5 (no beer from me)

BTW, Ctrl-D works on Windows also. No need to maintain system-specific
Ctrl-Z shortcut.

----------

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

From report at bugs.python.org  Mon Jul 26 20:06:45 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 26 Jul 2010 18:06:45 +0000
Subject: [docs] [issue8834] Define order of Misc/ACKS entries
In-Reply-To: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>
Message-ID: <1280167605.88.0.111682425443.issue8834@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

LGTM :)

----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Mon Jul 26 21:04:40 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 26 Jul 2010 19:04:40 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1280166452.33.0.955350641752.issue9362@psf.upfronthosting.co.za>
Message-ID: <AANLkTinZpRCH+J8itBdtgSvensapUCww2_KuXE+xFpcu@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

Something is broken in your 3.1.2 - this is Ctrl-D for me.

{{{
Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\~env\Python26>python
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>>

C:\~env\Python26>
}}}

----------

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

From report at bugs.python.org  Mon Jul 26 21:18:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 26 Jul 2010 19:18:36 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1280171915.53.0.478568876984.issue9362@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Do you have pyreadline installed? If so, that is causing it. If not, it's something else as Ctrl-D is not an EOF character on Windows.

----------

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

From report at bugs.python.org  Mon Jul 26 21:48:52 2010
From: report at bugs.python.org (Leonhard Vogt)
Date: Mon, 26 Jul 2010 19:48:52 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280173731.9.0.726954469023.issue7447@psf.upfronthosting.co.za>


Leonhard Vogt <leonhard.vogt at gmx.ch> added the comment:

Thank you.

I think the specific list of list example is better for the sum documentation because lists support the + operator. I don't think
that someone would consider using sum for chaining arbitrary iterables.
What about a concise "To concatenate lists use itertools.chain.from_iterable." and letting the "apply list constructor" part as an exercise to the reader?

I did the explicit reference to itertools.itertools.chain.from_iterable since the default or the explicit link to itertools.chain.from_iterable did not produce a correct link in the html docs.
I applied patch3 and ran make html; there is no html link to from_iterable produced.

----------

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

From report at bugs.python.org  Mon Jul 26 22:32:14 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 26 Jul 2010 20:32:14 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1280171915.53.0.478568876984.issue9362@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=DBFvYYGGystAAv4KHFEU-ROYxgu+_HUSdGg=F@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

It appears that `import pyreadline` goes ok. It appears that this lib
is used for unification of console incompatibilities between platform.
Why not to ship it in Python by default?

----------

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

From report at bugs.python.org  Mon Jul 26 22:38:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 26 Jul 2010 20:38:39 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <AANLkTi=DBFvYYGGystAAv4KHFEU-ROYxgu+_HUSdGg=F@mail.gmail.com>
Message-ID: <FDD0D0BC-7B36-4052-A1EB-BBE9B62C97D5@gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Jul 26, 2010, at 4:32 PM, anatoly techtonik  
<report at bugs.python.org> wrote:
>
> Why not to ship it in Python by default?
>

Because it is under GPL?

----------
nosy: +Alexander.Belopolsky

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

From report at bugs.python.org  Mon Jul 26 22:39:18 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 26 Jul 2010 20:39:18 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1280176758.96.0.276580204078.issue9362@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


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

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

From report at bugs.python.org  Mon Jul 26 22:48:45 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 26 Jul 2010 20:48:45 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1279913042.97.0.618415832845.issue9362@psf.upfronthosting.co.za>
Message-ID: <1280177325.41.0.954101652287.issue9362@psf.upfronthosting.co.za>


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

c:\py3k\Lib>py32
Python 3.2a0 (py3k:83057M, Jul 22 2010, 15:20:27) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
  File "<stdin>", line 1
    ?
    ^
SyntaxError: invalid syntax
[49008 refs]
>>>

This to me is getting stupid.  Let's make a decision and move on, there are far more pressing issues that need attention.

----------

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

From report at bugs.python.org  Tue Jul 27 06:09:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 27 Jul 2010 04:09:16 +0000
Subject: [docs] [issue9388] locale documentation describes non-existing
	ERA_YEAR	constant
In-Reply-To: <1280203756.3.0.102200795898.issue9388@psf.upfronthosting.co.za>
Message-ID: <1280203756.3.0.102200795898.issue9388@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Grepping through the source tree, reveals a single match for ERA_YEAR:

Doc/library/locale.rst:247:   .. data:: ERA_YEAR

Google search for it shows an OpenSolaris bug report that explains the origin of this constant:

"""
There appears to be an IBM-private field in _LC_time_t struct, 
era_year.   We should remove "era_year" from the _LC_time_t struct.  
This should only affect the LC_TIME functions, localedef 
command, and locale objects.  (nl_langinfo and langinfo.h are
unaffected because they don't reference era_year.) 
"""

I believe this entry should simply be removed.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 111683
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: locale documentation describes non-existing ERA_YEAR constant
versions: Python 3.2

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

From report at bugs.python.org  Tue Jul 27 19:29:36 2010
From: report at bugs.python.org (jeff)
Date: Tue, 27 Jul 2010 17:29:36 +0000
Subject: [docs] [issue3874] documentation bug: HTMLParser needs to
	document	unknown_decl
In-Reply-To: <1276813832.54.0.751318282558.issue3874@psf.upfronthosting.co.za>
Message-ID: <AANLkTikxkKJMdNFZrdpED6DiN4tKQj069kZDKTg8qwXf@mail.gmail.com>


jeff <freyley at gmail.com> added the comment:

On Thu, Jun 17, 2010 at 3:30 PM, Terry J. Reedy <report at bugs.python.org> wrote:
> In order for the doc maintainers to add an entry, someone knowledgeable must write it. Your paragraph of explanation is a start, but more editing is needed.
>
> Looking at dir(html.parser.HTMLParser) and help(...), I see that there are several public internal methods. Some have doc strings that show up with help(), some do not. I thing all should. Some are defined on HTMLParser and some inherited from the undocumented (I believe) _markupbase.ParserBase.
>
> I see that there are also several (completely undocumented except fir dir()) private ('_xyz') internal methods. This implies to me that the public internal methods were made public rather than private because there might be reason to override them. If so, perhaps there should be a new subsection on public internal methods to explain what is what with them. What do you think? Document just one, some, or all?

Terry,

I'm looking at the HTMLParser code, and I only see unknown_decl as a
method in there that is: a) not marked as internal or doing a lot, b)
not documented. There are a number of methods which should probably be
refactored to be _methodname rather than methodname, but that's beyond
the scope of this report.

HTMLParser.unknown_decl(data)?
Method called when an unrecognized SGML declaration is read by the
parser. The data parameter will be the entire contents of the
declaration inside the <!...> markup. It is sometimes useful to be be
overridden by a derived class; the base class implementation throws an
HTMLParseError.

There may be other undocumented methods showing up, but if so they're
part of a parent class.

Thanks,

Jeff

----------

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

From report at bugs.python.org  Tue Jul 27 20:44:42 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 27 Jul 2010 18:44:42 +0000
Subject: [docs] [issue3874] documentation bug: HTMLParser needs to
	document	unknown_decl
In-Reply-To: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>
Message-ID: <1280256282.26.0.62167644202.issue3874@psf.upfronthosting.co.za>


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

OK, your recommendation is to add one entry with the text suggested in the message. Given the name, the text seems reasonable. I will leave it to a doc person to format and apply.

----------
keywords: +patch
stage:  -> needs patch

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

From report at bugs.python.org  Wed Jul 28 00:35:53 2010
From: report at bugs.python.org (Leonhard Vogt)
Date: Tue, 27 Jul 2010 22:35:53 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280270153.12.0.196762395729.issue7447@psf.upfronthosting.co.za>


Leonhard Vogt <leonhard.vogt at gmx.ch> added the comment:

another patch:
- moved string case to first position, i think it's the most important.
- reworded (shortened) list case.
- wrapped for <80 caracter lines.

still using itertools.itertools.chain.from_iterable as mentioned in previous message. I missed georgs use of ~ in the link, but i think its clearer to mention the full name of the function anyway.

----------
Added file: http://bugs.python.org/file18223/functions.rst.patch4.txt

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

From report at bugs.python.org  Wed Jul 28 01:24:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 27 Jul 2010 23:24:16 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280273056.63.0.668447797006.issue7447@psf.upfronthosting.co.za>


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

You could also use start=0 in the signature.

----------

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

From report at bugs.python.org  Wed Jul 28 10:45:29 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 28 Jul 2010 08:45:29 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <FDD0D0BC-7B36-4052-A1EB-BBE9B62C97D5@gmail.com>
Message-ID: <AANLkTimxA7a438z0oGUzBFqoPush-dC4TPesU+TOYJFV@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

>> Why not to ship it in Python by default?
>
> Because it is under GPL?

pyreadline is under BSD.

----------

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

From report at bugs.python.org  Wed Jul 28 10:50:57 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 28 Jul 2010 08:50:57 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <1280177325.41.0.954101652287.issue9362@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=LXqh5wj5YjcaTJxYpz81JJT_nj_jxdmOeGk8U@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Jul 26, 2010 at 11:48 PM, Mark Lawrence <report at bugs.python.org> wrote:
>
> This to me is getting stupid. ?Let's make a decision and move on, there are far more pressing issues that need attention.

Do you think that getting `readline` module to run on Windows is stupid?
I think it is stupid that IPython ships pyreadline to fill the gap on
Windows - it should be done in Python distribution.

----------

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

From report at bugs.python.org  Wed Jul 28 10:53:39 2010
From: report at bugs.python.org (Tim Golden)
Date: Wed, 28 Jul 2010 08:53:39 +0000
Subject: [docs] [issue9362] Make exit/quit hint more novice friendly
In-Reply-To: <AANLkTi=LXqh5wj5YjcaTJxYpz81JJT_nj_jxdmOeGk8U@mail.gmail.com>
Message-ID: <4C4FF00D.9060203@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Not necessarily; pyreadline takes over from the standard console
functionality on Windows in order to emulate a more Unix-ish
approach. I prefer the Windows default.

There's nothing to stop someone downloading and installing
pyreadline as a third-party package on Windows

----------
nosy: +tim.golden

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

From merwok at netwok.org  Wed Jul 28 17:27:43 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Wed, 28 Jul 2010 17:27:43 +0200
Subject: [docs] python tutorial more a reference than a tutorial
In-Reply-To: <AANLkTi=taXtg7w=cfh7UmV49COoSe7BudVQowa95o+mP@mail.gmail.com>
References: <F790D9474379664BB03E53DA89E9218F0154E681@XMB-BGL-41A.cisco.com>
	<AANLkTi=taXtg7w=cfh7UmV49COoSe7BudVQowa95o+mP@mail.gmail.com>
Message-ID: <4C504C6F.2020802@netwok.org>

Hello Amandeep

Thank you for your feedback.

>> I tried to study your python tutorial, release 2.6.4. But was very
>> disappointed the way it is written. It is more a reference than a
>> tutorial. Language could have been simpler, giving more examples.

Can you point out examples of complicated language, or maybe give links
to other tutorials that have been better for you so that we can compare?

I remember that Dive Into Python was the accessible thing for me when I
started learning Python, the official tutorial came after. The first two
chapters (?Whetting Your Appetite? and ?Using the Python Interpreter?)
can certainly be off-putting for someone with no prior programming
experience.

Other tutorials may favor a hands-on approach, i.e. starting with a
project and going ahead, which is a very good way to learn. The official
tutorial seems more traditionally structured and less accessible; maybe
there?s room for a new, shorter, practical one (written from scratch or
copied from an external source).

[Anatoly]
> Loss of consistency is always a problem with documentation that is
> maintained in patches.

The documentation is files; editions are made with patches, like
everything else. What is the consistency problem? That people review the
patches and not the whole files maybe? I believe that there are readers
that catch consistency problems while reading the built doc, and I trust
Georg not to commit inconsistent changes.

> The whole Python documentation lacks user submitted scenarios and
> examples.

What are user-submitted scenarios? How are they useful?

Regarding examples, the doc of some modules is already so long that
there is need for a summary table, see for example itertools (other
modules would benefit from that). I don?t know if python-dev explicitly
wants the documentation to stay focused or if more examples are welcome;
at least, links to more detailed resources like
http://www.doughellmann.com/PyMOTW/ and
http://code.activestate.com/recipes/langs/python/ would be a useful
addition.

> I sell this idea for PSF for free. Take a look at online pages at
> http://php.net/ for an inspiration.

This doc has already been mentioned as example on mailing lists, only to
be shot down by other PHP users criticizing the low quality and
staleness of those user-submitted examples.

That said, there is a constant effort to lower the bar for
contributions. There has recently been changes to advertise this mailing
list and the bug tracker more prominently; what more can we do?

Regards


From report at bugs.python.org  Wed Jul 28 18:46:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 28 Jul 2010 16:46:43 +0000
Subject: [docs] [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1280335603.45.0.463808426966.issue9105@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


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

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

From report at bugs.python.org  Wed Jul 28 20:35:58 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Jul 2010 18:35:58 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280342158.25.0.779030181628.issue7447@psf.upfronthosting.co.za>


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

I am puzzled that the fake name 'itertools.itertools.chain.from_iterable' works better than the real name 'itertools.chain.from_iterable'. Some bug in the tool chain?

----------

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

From report at bugs.python.org  Thu Jul 29 00:49:27 2010
From: report at bugs.python.org (Andrew Wu)
Date: Wed, 28 Jul 2010 22:49:27 +0000
Subject: [docs] [issue9407] ConfigParser documentation does not
	mention	ConfigParser.Error as base exception class for
	ConfigParser exceptions
In-Reply-To: <1280357367.5.0.752576251051.issue9407@psf.upfronthosting.co.za>
Message-ID: <1280357367.5.0.752576251051.issue9407@psf.upfronthosting.co.za>


New submission from Andrew Wu <andrewwu at gmail.com>:

* Reference bug http://bugs.python.org/issue9406
* Reference documentation at http://docs.python.org/library/configparser.html

The docs list all the specific errors to look out for, but does not mention the base exception class for ConfigParser errors (ConfigParser.Error).  It may be useful to mention it to show the exception heirarchy as well as in the case a user may want to catch all ConfigParser errors generally.

----------
assignee: docs at python
components: Documentation
messages: 111866
nosy: docs at python, pekkle
priority: normal
severity: normal
status: open
title: ConfigParser documentation does not mention ConfigParser.Error as base exception class for ConfigParser exceptions
type: feature request
versions: Python 2.7

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

From report at bugs.python.org  Thu Jul 29 05:50:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Jul 2010 03:50:30 +0000
Subject: [docs] [issue9407] ConfigParser documentation does not
	mention	ConfigParser.Error as base exception class for
	ConfigParser exceptions
In-Reply-To: <1280357367.5.0.752576251051.issue9407@psf.upfronthosting.co.za>
Message-ID: <1280375430.98.0.181691914772.issue9407@psf.upfronthosting.co.za>


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


----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Thu Jul 29 15:39:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 29 Jul 2010 13:39:02 +0000
Subject: [docs] [issue3874] documentation bug: HTMLParser needs to
	document	unknown_decl
In-Reply-To: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>
Message-ID: <1280410742.08.0.0960663989485.issue3874@psf.upfronthosting.co.za>


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

Applied with some tweaks in r83223.  Thanks Jeff and Terry!

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

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

From report at bugs.python.org  Thu Jul 29 15:41:29 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Jul 2010 13:41:29 +0000
Subject: [docs] [issue3874] documentation bug: HTMLParser needs to
	document	unknown_decl
In-Reply-To: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>
Message-ID: <1280410889.39.0.512460693492.issue3874@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> committed/rejected

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

From report at bugs.python.org  Thu Jul 29 16:16:48 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 29 Jul 2010 14:16:48 +0000
Subject: [docs] [issue9407] ConfigParser documentation does not
	mention	ConfigParser.Error as base exception class for
	ConfigParser exceptions
In-Reply-To: <1280357367.5.0.752576251051.issue9407@psf.upfronthosting.co.za>
Message-ID: <1280413007.32.0.479194957446.issue9407@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

"It may be useful to mention it to show the exception heirarchy as well as in the case a user may want to catch all ConfigParser errors generally."

+1. I provide a patch for this.

----------
keywords: +patch
nosy: +ysj.ray
Added file: http://bugs.python.org/file18250/issue9407.diff

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

From report at bugs.python.org  Thu Jul 29 16:17:58 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 29 Jul 2010 14:17:58 +0000
Subject: [docs] [issue9407] ConfigParser documentation does not
	mention	ConfigParser.Error as base exception class for
	ConfigParser exceptions
In-Reply-To: <1280357367.5.0.752576251051.issue9407@psf.upfronthosting.co.za>
Message-ID: <1280413078.64.0.325860480981.issue9407@psf.upfronthosting.co.za>


Changes by Ray.Allen <ysj.ray at gmail.com>:


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

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

From report at bugs.python.org  Thu Jul 29 16:32:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 29 Jul 2010 14:32:36 +0000
Subject: [docs] [issue9407] ConfigParser documentation does not
	mention	ConfigParser.Error as base exception class for
	ConfigParser exceptions
In-Reply-To: <1280357367.5.0.752576251051.issue9407@psf.upfronthosting.co.za>
Message-ID: <1280413956.04.0.74586139147.issue9407@psf.upfronthosting.co.za>


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

Applied in r83229. Thanks!

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

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

From report at bugs.python.org  Thu Jul 29 16:37:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 29 Jul 2010 14:37:55 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280414275.35.0.118467847105.issue7447@psf.upfronthosting.co.za>


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

from_iterable() was marked up wrongly in the itertools docs; this is fixed now in r83230.

----------

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

From report at bugs.python.org  Thu Jul 29 16:49:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 29 Jul 2010 14:49:21 +0000
Subject: [docs] [issue9388] locale documentation describes non-existing
	ERA_YEAR	constant
In-Reply-To: <1280203756.3.0.102200795898.issue9388@psf.upfronthosting.co.za>
Message-ID: <1280414961.67.0.699241823484.issue9388@psf.upfronthosting.co.za>


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

Thanks, fixed in r83232.

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

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

From report at bugs.python.org  Thu Jul 29 20:00:39 2010
From: report at bugs.python.org (Leonhard Vogt)
Date: Thu, 29 Jul 2010 18:00:39 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280426438.97.0.753595549344.issue7447@psf.upfronthosting.co.za>


Changes by Leonhard Vogt <leonhard.vogt at gmx.ch>:


Removed file: http://bugs.python.org/file18223/functions.rst.patch4.txt

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

From report at bugs.python.org  Thu Jul 29 20:11:16 2010
From: report at bugs.python.org (Leonhard Vogt)
Date: Thu, 29 Jul 2010 18:11:16 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280427076.39.0.199393410154.issue7447@psf.upfronthosting.co.za>


Leonhard Vogt <leonhard.vogt at gmx.ch> added the comment:

Thank you Georg, I updated the patch

Ezio, wouldn't  start=0  in the signature  imply that sum accepted a keyword argument? I read "Documenting Python" (4.3) but am not sure about the distinction of default values or keyword arbuments.

>>> sum([1,2,3], start=4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sum() takes no keyword arguments

----------
Added file: http://bugs.python.org/file18258/functions.rst.patch5.txt

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

From report at bugs.python.org  Thu Jul 29 20:13:25 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 29 Jul 2010 18:13:25 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280427205.22.0.978405853963.issue7447@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

The oldest interfaces tend to have quirks like that. Similar issue: #9379. Won't be changed as well. I'm thinking of a better docstring though.

----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Thu Jul 29 23:00:36 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Jul 2010 21:00:36 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280437236.14.0.418402707267.issue7447@psf.upfronthosting.co.za>


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

For Python functions, all arguments can be keyword arguments. For many builtins, none can be (and maybe there should be a note to that effect at the top of the built-in functions chapter). 'Param = default' merely means that the parameter has a default argument and it is therefore optional to provide one. It says nothing about whether the argument can be identified by the parameter name or only by position.

----------

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

From report at bugs.python.org  Thu Jul 29 23:06:06 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 29 Jul 2010 21:06:06 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1280437236.14.0.418402707267.issue7447@psf.upfronthosting.co.za>
Message-ID: <79F9CE4C-280D-41F6-A9E8-D5E946C6C85F@langa.pl>


?ukasz Langa <lukasz at langa.pl> added the comment:

> For Python functions, all arguments can be keyword arguments. For many builtins, none can be (and maybe there should be a note to that effect at the top of the built-in functions chapter).

+1

Many Python users don't really grasp how builtins are different from regular functions. A note of this kind would be most helpful. Should I provide a patch for Doc/ ?

----------

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

From chnx.gao at gmail.com  Tue Jul 27 16:16:03 2010
From: chnx.gao at gmail.com (GAO Chenxi)
Date: Tue, 27 Jul 2010 22:16:03 +0800
Subject: [docs] Hi, I've got problem to access python2.6.2's doc,
	is it possible that 	you could send me a copy in HTML format
Message-ID: <AANLkTikzTMcAsF92y+Ydc0Zr5Tg9UXJywibS+299nW+j@mail.gmail.com>

I'm a python beginner, due to the network problem i can't get access python
2.6.2's doc, i'll be appreciate if i could get the tar.gz doc in HTML
format, thx )

-- 
Regards,
GAO Chenxi
Hebei University of Technology,
Computer Science and Software Engineering Department
0086 13520920190
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100727/946d4385/attachment-0001.html>

From rutt.4 at osu.edu  Wed Jul 28 03:53:31 2010
From: rutt.4 at osu.edu (Benjamin Rutt)
Date: Tue, 27 Jul 2010 21:53:31 -0400
Subject: [docs] Cannot 'Quick search' 2.6.5 docs
Message-ID: <AANLkTi=JO4auv6QtHyLMYy0=kViWPSZHSqz3=4ySMLwY@mail.gmail.com>

I can search the latest docs:

    *
http://docs.python.org/search.html?q=divmod&check_keywords=yes&area=default*<http://docs.python.org/search.html?q=divmod&check_keywords=yes&area=default>

But not the 2.6.5 docs:

    *
http://docs.python.org/release/2.6.5/search.html?q=divmod&check_keywords=yes&area=default
*<http://docs.python.org/release/2.6.5/search.html?q=divmod&check_keywords=yes&area=default>

(In the latter, I get no results, but I'm pretty sure 'divmod' was in 2.6.5
so I would expect results).

Pretty sure this falls under a doc bug.

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

From crocodilelll at msn.com  Wed Jul 28 17:43:10 2010
From: crocodilelll at msn.com (LILI Luo)
Date: Wed, 28 Jul 2010 15:43:10 +0000
Subject: [docs] Tutorial Chapter 5
Message-ID: <SNT136-w62765599DA07CCC80D5B4CDFA80@phx.gbl>


To whom it may concern:
             The following sample script doesn't work.
 
To loop over two or more sequences at the same time, the entries can be paired with the zip() function.

>>> questions = ['name', 'quest', 'favorite color']
>>> answers = ['lancelot', 'the holy grail', 'blue']
>>> for q, a in zip(questions, answers):
...     print 'What is your {0}?  It is {1}.'.format(q, a)
...
What is your name?  It is lancelot.
What is your quest?  It is the holy grail.
What is your favorite color?  It is blue.
 
 
 
--crocodile 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100728/528526fd/attachment-0001.html>

From jt at t35t.net  Thu Jul 29 18:02:57 2010
From: jt at t35t.net (Justin Time)
Date: Thu, 29 Jul 2010 18:02:57 +0200
Subject: [docs] Unwanted browser side effect in a link to a reference
Message-ID: <1280419377.12782.27.camel@5>

Side effect on page http://docs.python.org/library/functions.html

In built-in function desc.: memoryview(obj)

Maybe referenced link to memoryview type should be:
http://docs.python.org/library/stdtypes.html#memoryview-type
instead of: http://docs.python.org/library/stdtypes.html#typememoryview

If I open the link in a new browser tab (Iceweasel 3.0.6) it doesn't
jump to the 'memoryview type' chapter. It does if I open the link in the
same browser tab!

Also <dt id="memoryview"> is missing.

Have a nice day :-)


From report at bugs.python.org  Thu Jul 29 23:12:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 29 Jul 2010 21:12:38 +0000
Subject: [docs] [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1280437958.5.0.379067591541.issue7447@psf.upfronthosting.co.za>


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

Please do. This issue comes up often enough on python-list. Make it a separate doc issue, which will be auto-assigned to docs at python and add me as nosy.

----------

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

From bgailer at gmail.com  Fri Jul 30 06:11:42 2010
From: bgailer at gmail.com (bob gailer)
Date: Fri, 30 Jul 2010 00:11:42 -0400
Subject: [docs] =?iso-8859-1?q?Python_v2=2E6=2E4_documentation_=BB_The_Pyt?=
 =?iso-8859-1?q?hon_Language_Reference_=BB?=
Message-ID: <4C5250FE.2020604@gmail.com>


FTP.retrlines(/command/[, /callback/])
    Retrieve a file or directory listing in ASCII transfer mode.
    /command/ should be an appropriate RETR command (see retrbinary()
    <#ftplib.FTP.retrbinary>) or a command such as LIST, NLST or MLSD
    (usually just the string 'LIST'). The /callback/ function is called
    for each line, with the trailing CRLF stripped. The default
    /callback/ prints the line to sys.stdout.

Should read:

The /callback/ function is called for each line, /with a single string 
argument giving the line/, with the trailing CRLF stripped.

-- 
Bob Gailer
919-636-4239
Chapel Hill NC

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

From georg at python.org  Fri Jul 30 09:02:01 2010
From: georg at python.org (Georg Brandl)
Date: Fri, 30 Jul 2010 09:02:01 +0200
Subject: [docs]
 =?iso-8859-1?q?Python_v2=2E6=2E4_documentation_=BB_The_Pyt?=
 =?iso-8859-1?q?hon_Language_Reference_=BB?=
In-Reply-To: <4C5250FE.2020604@gmail.com>
References: <4C5250FE.2020604@gmail.com>
Message-ID: <4C5278E9.9070306@python.org>

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

Am 30.07.2010 06:11, schrieb bob gailer:
> 
> FTP.retrlines(/command/[, /callback/])
>     Retrieve a file or directory listing in ASCII transfer mode. /command/
>     should be an appropriate RETR command (see retrbinary()
>     <#ftplib.FTP.retrbinary>) or a command such as LIST, NLST or MLSD (usually
>     just the string 'LIST'). The /callback/ function is called for each line,
>     with the trailing CRLF stripped. The default /callback/ prints the line to
>     sys.stdout.
> 
> Should read:
> 
> The /callback/ function is called for each line, /with a single string argument
> giving the line/, with the trailing CRLF stripped.

Hi Bob,

thanks for the suggestion, I've made that change now and it will be online
soon (not in the 2.6 docs though, but the 2.7 ones at docs.python.org).

regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkxSeOgACgkQN9GcIYhpnLDhhACdHpalTrUJenVOC9+0PRdx8y7D
7dIAoIjzAfcxgs7gzUSAkdWNyv5nQF3s
=PPhH
-----END PGP SIGNATURE-----

From report at bugs.python.org  Fri Jul 30 10:34:17 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 30 Jul 2010 08:34:17 +0000
Subject: [docs] [issue9426] Explicitly state lack of support for keyword
	arguments in	builtin functions
In-Reply-To: <1280478856.92.0.712905377204.issue9426@psf.upfronthosting.co.za>
Message-ID: <1280478856.92.0.712905377204.issue9426@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

Currently it's somewhat surprising that while the documentation often states the default values for certain builtins, invoking the builtin with keyword arguments as described in the documentation does not work.

Original discussion: #7447

I'm going through all builtins to see how the keyword arg support looks and I'm going to present a patch for Doc/library/builtins.rst that explicitly states that builtins don't support this kind of invocation.

Expect a patch later today.

----------
assignee: docs at python
components: Documentation
messages: 112048
nosy: docs at python, lukasz.langa, tjreedy
priority: normal
severity: normal
status: open
title: Explicitly state lack of support for keyword arguments in builtin functions
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jul 30 13:56:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Jul 2010 11:56:44 +0000
Subject: [docs] [issue9426] Explicitly state lack of support for keyword
	arguments in	builtin functions
In-Reply-To: <1280478856.92.0.712905377204.issue9426@psf.upfronthosting.co.za>
Message-ID: <1280491004.71.0.48657072365.issue9426@psf.upfronthosting.co.za>


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

Is this a duplicate of #8350?

----------
nosy: +merwok

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

From report at bugs.python.org  Fri Jul 30 14:41:33 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 30 Jul 2010 12:41:33 +0000
Subject: [docs] [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1280493693.13.0.55142909616.issue8350@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Closing as invalid would not be wise because using named arguments as keywords is in Python taken for granted. Cases that are exceptions from this rule should be explicitly noted as to avoid confusion, especially for less experienced programmers.

Similar case for builtins: #9426

----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Fri Jul 30 14:42:42 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 30 Jul 2010 12:42:42 +0000
Subject: [docs] [issue9426] Explicitly state lack of support for keyword
	arguments in	builtin functions
In-Reply-To: <1280478856.92.0.712905377204.issue9426@psf.upfronthosting.co.za>
Message-ID: <1280493762.19.0.605457372717.issue9426@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Same problem, different context. Here we have an already accepted idea (from #7447) to extend the documentation by providing an explicit explanation that named arguments in builtins are usually positional only, contrary to the intuition. I've already commented in #8350 that I believe documentation should include a note that one cannot use specific arguments as keywords.

Both issues cover different parts of documentation so they're not duplicates.

----------

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

From report at bugs.python.org  Fri Jul 30 14:52:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Jul 2010 12:52:25 +0000
Subject: [docs] [issue9426] Explicitly state lack of support for keyword
	arguments in	builtin functions
In-Reply-To: <1280478856.92.0.712905377204.issue9426@psf.upfronthosting.co.za>
Message-ID: <1280494345.44.0.958902000972.issue9426@psf.upfronthosting.co.za>


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

The title of #8350 is outdated. The discussion has shifted from one specific function to the general doc problem. Since it contains references and opinions, I think it supersedes this one.

----------

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

From report at bugs.python.org  Fri Jul 30 15:15:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 30 Jul 2010 13:15:03 +0000
Subject: [docs] [issue9426] Explicitly state lack of support for keyword
	arguments in	builtin functions
In-Reply-To: <1280478856.92.0.712905377204.issue9426@psf.upfronthosting.co.za>
Message-ID: <1280495703.14.0.6548023451.issue9426@psf.upfronthosting.co.za>


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

I agree this should be closed and moved to #8350.

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

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

From report at bugs.python.org  Fri Jul 30 15:36:43 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 30 Jul 2010 13:36:43 +0000
Subject: [docs] [issue9426] Explicitly state lack of support for keyword
	arguments in	builtin functions
In-Reply-To: <1280478856.92.0.712905377204.issue9426@psf.upfronthosting.co.za>
Message-ID: <1280497003.13.0.983484571861.issue9426@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Let's do this then :)

Superseded by: #8350

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

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

From report at bugs.python.org  Fri Jul 30 15:37:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Jul 2010 13:37:15 +0000
Subject: [docs] [issue9426] Explicitly state lack of support for keyword
	arguments in	builtin functions
In-Reply-To: <1280478856.92.0.712905377204.issue9426@psf.upfronthosting.co.za>
Message-ID: <1280497035.76.0.774912413684.issue9426@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> os.mkdir doc comment is incorrect

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

From report at bugs.python.org  Fri Jul 30 15:38:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Jul 2010 13:38:10 +0000
Subject: [docs] [issue8350] Explicitly state lack of support for keyword
	arguments in	built-in functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1280497090.95.0.189653910443.issue8350@psf.upfronthosting.co.za>


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


----------
resolution:  -> accepted
stage:  -> needs patch
title: os.mkdir doc comment is incorrect -> Explicitly state lack of support for keyword arguments in built-in functions
type:  -> behavior
versions: +Python 3.2

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

From report at bugs.python.org  Fri Jul 30 15:38:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Jul 2010 13:38:34 +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: <1280497114.89.0.0175709929485.issue8350@psf.upfronthosting.co.za>


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


----------
title: Explicitly state lack of support for keyword arguments in built-in functions -> Document lack of support for keyword arguments in C functions

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

From report at bugs.python.org  Fri Jul 30 15:39:48 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 30 Jul 2010 13:39:48 +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: <1280497188.19.0.548113130237.issue8350@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Currently it's somewhat surprising that while the documentation often states the default values for certain builtins, invoking the builtin with keyword arguments as described in the documentation does not work.

Original discussion: #7447

I'm going through all builtins to see how the keyword arg support looks and I'm going to present a patch for Doc/library/builtins.rst that explicitly states that builtins don't support this kind of invocation.

Expect a patch for that case later today. As for `os` et al, the discussion goes on.

----------

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

From report at bugs.python.org  Fri Jul 30 15:43:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Jul 2010 13:43:13 +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: <1280497393.54.0.665115376762.issue8350@psf.upfronthosting.co.za>


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

You could copy this notice from reference/expressions#calls:

?An implementation may provide built-in functions whose positional parameters do not have names, even if they are ?named? for the purpose of documentation, and which therefore cannot be supplied by keyword.?

An addition to documenting/rest or documenting/markup would be useful too.

----------

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

From report at bugs.python.org  Fri Jul 30 15:51:09 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 30 Jul 2010 13:51:09 +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: <1280497869.61.0.608254737567.issue8350@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jul 30 18:49:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 30 Jul 2010 16:49:24 +0000
Subject: [docs] [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1280508564.01.0.81938076216.issue9264@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +belopolsky

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

From report at bugs.python.org  Fri Jul 30 20:57:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 30 Jul 2010 18:57:56 +0000
Subject: [docs] [issue9430] Document str() and repr() of timedelta.
In-Reply-To: <1280516276.66.0.738062201536.issue9430@psf.upfronthosting.co.za>
Message-ID: <1280516276.66.0.738062201536.issue9430@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attaching a tentative patch.  I think it is better to document these as operations rather than special methods.  It may need to be clarified that "-2 days, 0:00:22" is timedelta(-2, 22) rather than -timedelta(2, 22), but I cannot come up with anything short enough for the ops table.  Maybe this should be done in a footnote.

----------
assignee: docs at python
components: Documentation
files: datetime.rst.diff
keywords: easy, patch
messages: 112096
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Document str() and repr() of timedelta.
versions: Python 3.2
Added file: http://bugs.python.org/file18274/datetime.rst.diff

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

From report at bugs.python.org  Fri Jul 30 21:00:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 30 Jul 2010 19:00:07 +0000
Subject: [docs] [issue9430] Document str() and repr() of timedelta.
In-Reply-To: <1280516276.66.0.738062201536.issue9430@psf.upfronthosting.co.za>
Message-ID: <1280516407.95.0.891947356869.issue9430@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


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

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

From report at bugs.python.org  Fri Jul 30 21:18:48 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Jul 2010 19:18:48 +0000
Subject: [docs] [issue9430] Document str() and repr() of timedelta.
In-Reply-To: <1280516276.66.0.738062201536.issue9430@psf.upfronthosting.co.za>
Message-ID: <1280517528.4.0.192776590442.issue9430@psf.upfronthosting.co.za>


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

Adding a footnote with an example sounds like a good idea.
There's an odd number of square brackets in the str(t) description.

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

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

From sashko.kravchuk at gmail.com  Fri Jul 30 17:33:29 2010
From: sashko.kravchuk at gmail.com (Oleksandr Kravchuk)
Date: Fri, 30 Jul 2010 18:33:29 +0300
Subject: [docs] Bug in "7.3. struct -- Interpret strings as packed binary
	data"
Message-ID: <AANLkTimPxpzTGH+racbMrLDrSaosOh0gm-yvYuaBsPCf@mail.gmail.com>

Hi,

I've probably found a bug in first code example of "7.3.2.3. Examples"
section of http://docs.python.org/library/struct.html:
'pack('hhl', 1, 2, 3)' code returns '\x01\x00\x02\x00\x03\x00\x00\x00'
instead of '\x00\x01\x00\x02\x00\x00\x00\x03', that we have in document.

Also, first parameter of pack() function -- 'hhl' is probably incorrect,
because regarding to the table in the section "7.3.2.2. Format Characters",
we have to use 'hhh' value as we have 3 short digits.

Thank you! I hope I've described the problem clearly enough.

-- 
Oleksandr Kravchuk
http://www.sashko.rv.ua | @memoryleaks
+380 (63) 499-70-72 | Skype: sashko.kravchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100730/b5cdc61a/attachment.html>

From report at bugs.python.org  Sat Jul 31 02:37:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 31 Jul 2010 00:37:16 +0000
Subject: [docs] [issue9430] Document str() and repr() of timedelta.
In-Reply-To: <1280516276.66.0.738062201536.issue9430@psf.upfronthosting.co.za>
Message-ID: <1280536635.8.0.917452884147.issue9430@psf.upfronthosting.co.za>


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

First revision: issue9430.diff

----------
Added file: http://bugs.python.org/file18278/issue9430.diff

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

From report at bugs.python.org  Sat Jul 31 13:25:56 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 31 Jul 2010 11:25:56 +0000
Subject: [docs] [issue9430] Document str() and repr() of timedelta.
In-Reply-To: <1280516276.66.0.738062201536.issue9430@psf.upfronthosting.co.za>
Message-ID: <1280575556.45.0.426447141237.issue9430@psf.upfronthosting.co.za>


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

I think it would be clearer if the footnote said something like "Negative 1 day plus 19 hours is equivalent to the timedelta argument of -5 hours)". If I hadn't been following the discussion on #python-dev the point of this doc change would have been lost on me without much closer scrutiny, so a little more explanation would help.

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

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

From report at bugs.python.org  Sat Jul 31 13:35:51 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 31 Jul 2010 11:35:51 +0000
Subject: [docs] [issue4744] asynchat documentation needs to be more precise
In-Reply-To: <1230168171.56.0.381937953807.issue4744@psf.upfronthosting.co.za>
Message-ID: <1280576150.89.0.746076984782.issue4744@psf.upfronthosting.co.za>


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

Is there anyone with knowledge of asynchat who could provide a patch for this?

----------
assignee: georg.brandl -> docs at python
nosy: +BreamoreBoy, docs at python
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Sat Jul 31 13:36:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Jul 2010 11:36:58 +0000
Subject: [docs] [issue9430] Document str() and repr() of timedelta.
In-Reply-To: <1280516276.66.0.738062201536.issue9430@psf.upfronthosting.co.za>
Message-ID: <1280576218.19.0.670585308258.issue9430@psf.upfronthosting.co.za>


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

Looks good to me.

----------

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

From report at bugs.python.org  Sat Jul 31 13:37:07 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 31 Jul 2010 11:37:07 +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: <1280576227.72.0.25486757608.issue4934@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul 31 13:40:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Jul 2010 11:40:22 +0000
Subject: [docs] [issue9430] Document str() and repr() of timedelta.
In-Reply-To: <1280516276.66.0.738062201536.issue9430@psf.upfronthosting.co.za>
Message-ID: <1280576422.6.0.66975827635.issue9430@psf.upfronthosting.co.za>


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

Committed in r83341.

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

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

From report at bugs.python.org  Sat Jul 31 14:23:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Jul 2010 12:23:39 +0000
Subject: [docs] [issue4934] tp_del and tp_version_tag undocumented
In-Reply-To: <1231869285.41.0.170645063597.issue4934@psf.upfronthosting.co.za>
Message-ID: <1280579019.62.0.469320716848.issue4934@psf.upfronthosting.co.za>


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

I think the reason tp_del isn't documented is that, as we somehow learnt it with the new IO code, it isn't really meant for third-party types.
I would suggest checking with python-dev.

As for tp_version_tag, it's for internal use (it indicated whether the method cache is still fresh), I don't think extension authors should modify it.

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

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

From report at bugs.python.org  Sat Jul 31 14:24:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Jul 2010 12:24:20 +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: <1280579060.1.0.455993373281.issue4934@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul 31 17:48:13 2010
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 31 Jul 2010 15:48:13 +0000
Subject: [docs] [issue5626] misleading comment in socket.gethostname()
	documentation
In-Reply-To: <1238515382.33.0.784525971679.issue5626@psf.upfronthosting.co.za>
Message-ID: <1280591293.42.0.494803447721.issue5626@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul 31 20:24:44 2010
From: report at bugs.python.org (David Stanek)
Date: Sat, 31 Jul 2010 18:24:44 +0000
Subject: [docs] [issue9370] Add reader redirect from test package docs to
	unittest	module
In-Reply-To: <1279968547.11.0.280770421062.issue9370@psf.upfronthosting.co.za>
Message-ID: <1280600684.88.0.824753027406.issue9370@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

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

From report at bugs.python.org  Sat Jul 31 20:25:40 2010
From: report at bugs.python.org (David Stanek)
Date: Sat, 31 Jul 2010 18:25:40 +0000
Subject: [docs] [issue8910] Write a text file explaining why Lib/test/data
	exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1280600740.4.0.881166705305.issue8910@psf.upfronthosting.co.za>


Changes by David Stanek <dstanek at dstanek.com>:


----------
nosy: +dstanek

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

From report at bugs.python.org  Sat Jul 31 20:26:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Jul 2010 18:26:38 +0000
Subject: [docs] [issue8638] Remove suggestion for name mangling from the
	tutorial
In-Reply-To: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>
Message-ID: <1280600797.96.0.809047779074.issue8638@psf.upfronthosting.co.za>


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

No objections noted, closing.

----------
status: pending -> closed

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

From report at bugs.python.org  Sat Jul 31 21:07:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Jul 2010 19:07:51 +0000
Subject: [docs] [issue9328] str.__format__.__doc__ backport glitch
In-Reply-To: <1279752555.95.0.938195163481.issue9328@psf.upfronthosting.co.za>
Message-ID: <1280603271.22.0.83034756609.issue9328@psf.upfronthosting.co.za>


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

Fixed in r83354.

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

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

From report at bugs.python.org  Sat Jul 31 21:46:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Jul 2010 19:46:33 +0000
Subject: [docs] [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>


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

Attaching a patch to edit mention of ?build number? in library/sys.

I also don?t understand ?The first three characters are used to identify the version in the installation directories (where appropriate on each platform)?, maybe someone who does could enlighten me.

If #5778 is rejected, the doc will need another update to mention that there may be a newline in sys.version.

----------
assignee: docs at python
components: Documentation
files: sys.version1.diff
keywords: patch
messages: 112189
nosy: docs at python, merwok
priority: normal
severity: normal
stage: patch review
status: open
title: Update sys.version doc
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file18289/sys.version1.diff

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

From report at bugs.python.org  Sat Jul 31 21:57:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Jul 2010 19:57:46 +0000
Subject: [docs] [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <1280606266.85.0.427286658252.issue9061@psf.upfronthosting.co.za>


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


----------
priority: normal -> release blocker

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

From report at bugs.python.org  Sat Jul 31 21:58:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 31 Jul 2010 19:58:33 +0000
Subject: [docs] [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <1280606313.15.0.427352659049.issue9442@psf.upfronthosting.co.za>


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

I recommend to drop any specific guarantee of what the string looks like. Saying "svn info" is also going to be outdated soon, when the code becomes maintained in Mercurial.

Instead, the documentation should point to sys.version_info and the platform module for programmatic consumption, and explain that the string is meant for human readers.

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

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

From report at bugs.python.org  Sat Jul 31 22:06:13 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Jul 2010 20:06:13 +0000
Subject: [docs] [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <1280606773.51.0.832281343813.issue9442@psf.upfronthosting.co.za>


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

Yes, this is even better than my fix for #5778.  Changed in r83358 to:

   A string containing the version number of the Python interpreter plus additional
   information on the build number and compiler used.  This string is displayed
   when the interactive interpreter is started.  Do not extract version information
   out of it, rather, use :data:`version_info` and the functions provided by the
   :mod:`platform` module.

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

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

From report at bugs.python.org  Sat Jul 31 22:30:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Jul 2010 20:30:47 +0000
Subject: [docs] [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <1280608247.11.0.727504879503.issue9442@psf.upfronthosting.co.za>


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

Is ?The first three characters are used to identify the version in the installation directories (where appropriate on each platform)? clear for anyone but me?

----------

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

From report at bugs.python.org  Sat Jul 31 22:48:46 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 31 Jul 2010 20:48:46 +0000
Subject: [docs] [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <1280609326.5.0.813529075247.issue9442@psf.upfronthosting.co.za>


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

Ask yourself: what are the first three characters? If that's not clear, type sys.version[:3]. Is it still unclear what this is talking about?

----------

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

From report at bugs.python.org  Sat Jul 31 22:49:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Jul 2010 20:49:57 +0000
Subject: [docs] [issue9442] Update sys.version doc
In-Reply-To: <1280605593.44.0.301230771819.issue9442@psf.upfronthosting.co.za>
Message-ID: <1280609397.41.0.664478209967.issue9442@psf.upfronthosting.co.za>


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

I think it meant that '3.2' is the string used for determining the /usr/lib/python3.2 directory name.

----------

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

From report at bugs.python.org  Sat Jul 31 23:12:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Jul 2010 21:12:27 +0000
Subject: [docs] [issue8910] Write a text file explaining why Lib/test/data
	exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1280610746.74.0.303348507657.issue8910@psf.upfronthosting.co.za>


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

Added in r83362.

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

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

From merwok at netwok.org  Sat Jul 31 23:32:46 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 31 Jul 2010 23:32:46 +0200
Subject: [docs] =?utf-8?b?4oCcQmVya2VsZXnigJ0gbWlzc3BlbGxpbmdz?=
Message-ID: <4C54967E.9030904@netwok.org>

Hello

I found this typo in dbm.rst while reading recent changesets. According
to grep, there is no other occurrence anywhere else, apart from another
misspelling in Misc/NEWS.

Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: berkeley-typos.diff
Type: text/x-diff
Size: 871 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20100731/29faf7e9/attachment.diff>

From badomen02 at gmail.com  Sat Jul 31 13:42:43 2010
From: badomen02 at gmail.com (Jonas Lindberg)
Date: Sat, 31 Jul 2010 13:42:43 +0200
Subject: [docs] A missing link
Message-ID: <AANLkTinXHu=_QC0wXcv0AqetW8jXFwhP5TW7Cor50sTJ@mail.gmail.com>

Hi,
I was trying to download the Python 2.6 documents from this link:
http://docs.python.org/release/2.6.2/download
But I only got this message:
*The requested URL /ftp/python/doc/current/python-2.6.2-docs-pdf-a4.tar.bz2
was not found on this server.*

I got to that page by following the link download the
HTML<http://www.python.org/doc/2.6.2/download>in this page:
http://www.python.org/download/releases/2.6.2/

I saw that I was in the wrong place, it was Python 2.6.5 I was looking
for...And that link I have now found and it works just fine :)

But because I stumbled upon a dead link I thought I should tell you about
it.

-- 
"I am enough of an artist to draw freely upon my imagination. Imagination is
more important than knowledge. Knowledge is limited. Imagination encircles
the world."

- Albert Einstein

"The true delight is in the finding out rather than in the knowing."
- Isaac Asimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100731/fc53f662/attachment-0001.html>