From report at bugs.python.org  Sat May  1 03:13:18 2010
From: report at bugs.python.org (Jeff McNeil)
Date: Sat, 01 May 2010 01:13:18 +0000
Subject: [docs] [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1272676397.83.0.71995634104.issue8556@psf.upfronthosting.co.za>


Jeff McNeil <jeff at jmcneil.net> added the comment:

Attaching a patch against the trunk, unified format, changed to 'number' as per suggestion.

----------
versions: +Python 2.7 -Python 2.6
Added file: http://bugs.python.org/file17155/stdtypes.rst.trunk.patch

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

From report at bugs.python.org  Sat May  1 20:25:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 18:25:03 +0000
Subject: [docs] [issue8593] Improve c-api/arg.rst
In-Reply-To: <1272738302.73.0.83180845409.issue8593@psf.upfronthosting.co.za>
Message-ID: <1272738302.73.0.83180845409.issue8593@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch fixes, reorders and improves c-api/arg.rst.

I would even suggest to go further and single out a couple of "most useful" formats ('s', 'y*', 'i', 'l'...) so that people don't get lost in all the possibilities.

----------
assignee: docs at python
components: Documentation
files: argdoc.patch
keywords: patch
messages: 104736
nosy: docs at python, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Improve c-api/arg.rst
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17168/argdoc.patch

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

From merwok at netwok.org  Sat May  1 20:48:48 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Sat, 01 May 2010 20:48:48 +0200
Subject: [docs] Typo in io.rst and meta-question about patches workflow
Message-ID: <4BDC7790.4060106@netwok.org>

Hello everyone


In trunk?s Doc/library/io.rst, a change from IOError to ValueError has
left a stray ?an?:

--- Doc/library/io.rst	Sat May 01 14:16:39 2010 +0200
+++ Doc/library/io.rst	Sat May 01 15:26:32 2010 +0200
@@ -246,7 +246,7 @@
-      (e.g. reading or writing) will raise an :exc:`ValueError`.
+      (e.g. reading or writing) will raise a :exc:`ValueError`.


Is it ok to use the mailing list instead of the bug tracker for such
tiny patches? Apart from Georg, are there people with commit power on
the list? Do they prefer emails or bug reports? Should we wait until
we?ve collected a bunch of typo before reporting them instead of doing
it one message per found typo?


Regards

From report at bugs.python.org  Sat May  1 21:04:21 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sat, 01 May 2010 19:04:21 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272740661.27.0.887910976482.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

@r.david.murray: did you try running my test?  I think it shows that we are pretty darned close to fully portable.  I believe we could fix Popen to make it fully portable pretty easily.  In fact, there may be a pure-python fix.  Documenting the differences would also not be hard.  I would discourage you from relying *solely* on a description such as "uses execvpe on POSIX" to describe the semantics.  Aside from being a nonportable description, it doesn't help anyone who isn't familiar with the POSIX system calls.

----------

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

From report at bugs.python.org  Sat May  1 22:32:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 May 2010 20:32:37 +0000
Subject: [docs] [issue8593] Improve c-api/arg.rst
In-Reply-To: <1272738302.73.0.83180845409.issue8593@psf.upfronthosting.co.za>
Message-ID: <1272745957.2.0.494603697666.issue8593@psf.upfronthosting.co.za>


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

Patch uploaded at http://codereview.appspot.com/979047

----------

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

From report at bugs.python.org  Sat May  1 23:57:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 May 2010 21:57:09 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272751029.1.0.525938296328.issue8557@psf.upfronthosting.co.za>


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

I didn't run the script.  I have now, but I'm not clear from its output what each test is actually doing, and don't really have the time to figure it out from the code right now.

I think it is probably more efficient to just ask you what your suggestion is for making things more portable?

As for the docs, the docs link to the os.exec python docs, which explain the PATH semantics.  Linking to the Microsoft documentation would equivalently explain the Windows semantics.  An explicit footnote discussing the differences in PATH behavior in the subprocess context would probably be helpful.

----------

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

From report at bugs.python.org  Sun May  2 04:54:44 2010
From: report at bugs.python.org (Julian)
Date: Sun, 02 May 2010 02:54:44 +0000
Subject: [docs] [issue8595] Unexpected default timeout in
	http-client-related	libraries
In-Reply-To: <1272768884.43.0.28527344604.issue8595@psf.upfronthosting.co.za>
Message-ID: <1272768884.43.0.28527344604.issue8595@psf.upfronthosting.co.za>


New submission from Julian <python_org at somethinkodd.com>:

Since Python 2.6, httplib has offered a timeout parameter for fetches. As the documentation explains, if this parameter is not provided, it uses the global default.

What the document doesn't explain is httplib builds on top of the socket library. The socket library has a default timeout of None (i.e. forever). This may be an appropriate default for general sockets, but it is a poor default for httplib; typical http clients would use a timeout in the 2-10 second range.

This problem is propagated up to urllib2, which sits on httplib, and further obscures that the default might be unsuitable.

>From an inspection of the manuals, Python 3.0.1 suffers from the same problem except, the names have changed. urllib.response sits on http.client.

I, for one, made a brutal mistake of assuming that the "global default" would be some reasonable default for fetching web pages; I didn't have any specific timeout in mind, and was happy for the library to take care of it. Several million successful http downloads later, my server application thread froze waiting forever when talking to a recalcitrant web-server. I imagine others have fallen for the same trap.

While an ideal solution would be for httplib and http.client to use a more generally acceptable default, I can see it might be far too late to make such a change without breaking existing applications. Failing that, I would recommend that the documentation for httplib, urllib, urllib2, http.client and urllib.request (+ any other similar libraries sitting on socket? FTP, SMTP?) be changed to highlight that the default global timeout, sans deliberate override, is to wait a surprisingly long time.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 104763
nosy: docs at python, oddthinking
priority: normal
severity: normal
status: open
title: Unexpected default timeout in http-client-related libraries
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun May  2 05:23:06 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 02 May 2010 03:23:06 +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: <1272770586.31.0.262145112882.issue8595@psf.upfronthosting.co.za>


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

I am not sure, there can be a default timeout value for client libraries like httplib and urllib2. 

Socket connection do have timeout and as you may have figured out already, the option in httplib and urllib methods is to set/override the socket._GLOBAL_DEFALT_TIMEOUT which is None by default (Wait indefinitely).

Since client libraries are using a global, setting it at once place (say at httplib) has same timeout applicable for other modules within the same process.

I see docs can highlight it more or perhaps link to sockets timeout information.

----------
nosy: +orsenthil
title: Unexpected default timeout in http-client-related libraries -> Explain the default timeout in http-client-related libraries

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

From report at bugs.python.org  Sun May  2 05:43:28 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sun, 02 May 2010 03:43:28 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272771808.49.0.285116788172.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

I've uploaded a new probe.py that contains a win32 Popen wrapper that I think acts just like *nix's Popen w.r.t. PATH and environment (pass --fix to demonstrate).  I suggest using this or an equivalent wrapper for Win32, and documenting the fact that with shell=False, filename extensions need to be supplied explicitly on windows.

----------
Added file: http://bugs.python.org/file17180/probe.py

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

From report at bugs.python.org  Sun May  2 05:45:08 2010
From: report at bugs.python.org (Julian)
Date: Sun, 02 May 2010 03:45:08 +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: <1272771908.38.0.531194630524.issue8595@psf.upfronthosting.co.za>


Julian <python_org at somethinkodd.com> added the comment:

@orsenthil:

Consider the definition of httplib.HTTPConnection.__init__(), in Python 2.6.

   def __init__(self, host, port=None, strict=None,
                timeout=socket._GLOBAL_DEFAULT_TIMEOUT):


This could be replaced with:

   def __init__(self, host, port=None, strict=None,
                timeout=10):

or, perhaps better, 

   def __init__(self, host, port=None, strict=None,
                timeout=httplib._HTTP_DEFAULT_TIMEOUT):

This timeout value is passed to the call in socket.create_connection, so I believe if it is overriden, it only applies to the relevant sockets and not to all sockets globally.

Note: I am not arguing here that this SHOULD be done - it would break existing applications, especially those that were written before Python 2.6 - merely that it COULD be done.

----------

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

From report at bugs.python.org  Sun May  2 06:05:04 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 02 May 2010 04:05:04 +0000
Subject: [docs] [issue8595] Explain the default timeout in
	http-client-related	libraries
In-Reply-To: <1272771908.38.0.531194630524.issue8595@psf.upfronthosting.co.za>
Message-ID: <20100502040449.GA3810@remy>


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

On Sun, May 02, 2010 at 03:45:09AM +0000, Julian wrote:
> Note: I am not arguing here that this SHOULD be done - it would
> break existing applications, especially those that were written
> before Python 2.6 - merely that it COULD be done.

I get your point, Julian. What I was worried about is, is it the
"correct thing" to do? Which I am not sure and I believe it is not as
httplib and urllib are not client themselves but are libraries to
build clients. httplib and urllib can be considered as convenient
interfaces over underlying sockets.

Breaking of existing apps is the next question, which should
definitely be avoided. And an explanation in the docs certainly seems
to be the way to go.

----------

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

From report at bugs.python.org  Mon May  3 09:03:54 2010
From: report at bugs.python.org (Matt Wartell)
Date: Mon, 03 May 2010 07:03:54 +0000
Subject: [docs] [issue8602] documentation of bz2 module mildly erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>


New submission from Matt Wartell <matt.wartell+pt at gmail.com>:

This is related to http://bugs.python.org/issue8601 "bz2.BZ2File should support "with" protocol per PEP 343"

The documentation at http://docs.python.org/library/bz2.html states:

   "This module provides a comprehensive interface for the bz2 compression library. It implements a complete file interface,..." 

although bz2.BZ2File does not support the __enter__ and __exit__ methods so arguably doesn't implement the "complete file interface". If issue8601 is declined then the documentation should probably note this exception.

----------
assignee: docs at python
components: Documentation
messages: 104818
nosy: Matt.Wartell, docs at python
priority: normal
severity: normal
status: open
title: documentation of bz2 module mildly erroneous
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon May  3 18:09:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 May 2010 16:09:19 +0000
Subject: [docs] [issue8593] Improve c-api/arg.rst
In-Reply-To: <1272738302.73.0.83180845409.issue8593@psf.upfronthosting.co.za>
Message-ID: <1272902959.52.0.579812478582.issue8593@psf.upfronthosting.co.za>


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

I've applied Eric's and Brian's suggestions and committed the patch to r80714 (py3k) and r80715 (3.1). Thank you!

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

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

From report at bugs.python.org  Tue May  4 01:01:01 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Mon, 03 May 2010 23:01:01 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272927661.87.0.96869174642.issue8557@psf.upfronthosting.co.za>


Changes by Dave Abrahams <dave at boostpro.com>:


Removed file: http://bugs.python.org/file17142/probe.py

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

From report at bugs.python.org  Tue May  4 01:02:02 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Mon, 03 May 2010 23:02:02 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272927722.39.0.719538269743.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

Not to appear impatient, but...<bump>.
It's a fairly tidy answer, I think :-)

----------

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

From report at bugs.python.org  Tue May  4 01:37:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 May 2010 23:37:50 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272929870.02.0.551609090762.issue8557@psf.upfronthosting.co.za>


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

Sorry for my Windows ignorance, but if CreateProcess ignores the PATH, how does updating the PATH fix the problem?

----------

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

From report at bugs.python.org  Tue May  4 03:22:57 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 04 May 2010 01:22:57 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272936176.71.0.419525396643.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

I'm probably as ignorant as you are of Windows issues. I just know what my experiments tell me: if you force the contents of any explicit 'env' argument into os.environ before calling Popen, you get the same behavior as on *nix.

----------

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

From report at bugs.python.org  Tue May  4 04:37:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 May 2010 02:37:57 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272940676.99.0.859105767325.issue8557@psf.upfronthosting.co.za>


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

Well, it wouldn't be the first time the microsoft docs were wrong.

There are two questions here: (1) is this behavior consistent across all microsoft platforms we support?  (2) is this *change* in behavior of Popen acceptable?

For (1) we need a unit test added to the subprocess unit tests that can check this.

For (2)...well, I think it would be good for the behavior to be as consistent as practical, so I'd be in favor.  We need some second opinions, though, to make sure we aren't overlooking some negative consequence.  I'm also not sure that this qualifies as a bug fix, so it may only be possible to get it into 3.2, assuming it is acceptable.

Note that I have not tested your program on Windows myself, I'm taking your word for it that it works ;)  I'll be more inclined to test things if the tests are in the form of unit tests, which should be much easier to understand than your test program.

----------

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

From report at bugs.python.org  Tue May  4 07:38:41 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 04 May 2010 05:38:41 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272940676.99.0.859105767325.issue8557@psf.upfronthosting.co.za>
Message-ID: <m2k4rkql8u.wl%dave@boostpro.com>


Dave Abrahams <dave at boostpro.com> added the comment:

R. David Murray wrote:
> There are two questions here: (1) is this behavior consistent across all microsoft platforms we support?  

I'll be honest: I don't know.

> (2) is this *change* in behavior of Popen acceptable?

I don't know that either.

> I'll be more inclined to
> test things if the tests are in the form of unit tests, which should
> be much easier to understand than your test program.

I guess no good deed goes unpunished ;-)

I also guess that whether you think unit tests will be easier to
understand depends on what kind of information you expect to glean
from the code.  My script was designed to probe for all
inconsistencies between ?doze and POSIX behaviors, and it is more
revealing in that respect than a unit test would be.  The unit test
that would prompt the particular code change I'm suggesting would look
more like:

    put directory X in the env argument's PATH (but not in os.environ)
    attempt to launch X/some_executable as simply ?some_executable?
    assert that X/some_executable actually ran

I don't know what Popen's unit tests look like, and to be honest,
right now I just don't have any more time to pour into this particular
issue.  Even if it doesn't get fixed in Python I'm going to be using
my wrapper for uniformity.  I hope everything I've done so far is
useful to the community but if not, I still have what I need.

----------

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

From havaji at yahoo.com  Sun May  2 17:07:44 2010
From: havaji at yahoo.com (Bojan Djuric)
Date: Sun, 2 May 2010 08:07:44 -0700 (PDT)
Subject: [docs] unicode in 3.1
Message-ID: <316798.17470.qm@web110711.mail.gq1.yahoo.com>

u'Hello World !' from page http://docs.python.org/tutorial/introduction.html#unicode-strings does not work. Python 3.1, windows xp. 
probably cause http://docs.python.org/release/3.0.1/whatsnew/3.0.html  , "3.1.3. Unicode Strings" part.
Maybe you can add link to release page in tutorial, if not updating it. 


BR,





      

From lim at alumni.caltech.edu  Mon May  3 08:01:58 2010
From: lim at alumni.caltech.edu (David Lim)
Date: Sun, 2 May 2010 23:01:58 -0700
Subject: [docs] socket programming HOWTO - correction for bind to ''
Message-ID: <ED6D3F34-391D-4296-9250-CA87DC4EDC36@alumni.caltech.edu>

http://docs.python.org/howto/sockets.html


it says:

A couple things to notice: we used socket.gethostname() so that the socket would be visible   to the outside world. If we had used s.bind(('',80)) or s.bind(('localhost', 80)) or s.bind(('127.0.0.1', 80)) we would still have a ?server? socket, but one that was only visible within the same machine.

Actually I believe if you do s.bind(('',80)), that corresponds to INADDR_ANY for the host
which means that socket is visible to the outside world. I.e. the socket will respond
to any incoming connection to the host.  Binding it to socket.gethostname()
means it will respond to a specific incoming connection to that hostname. Thus
if you have a multi-homed host (multiple hostnames for the machine), it will respond to
only one specific hostname.

so I would correct the example code from

serversocket.bind((socket.gethostname(), 80))

to

serversocket.bind(('', 80))

and the text to say

A couple things to notice: we used the empty string ('') so that the socket would be visible   to the outside world. If we had used s.bind(('localhost', 80)) or s.bind(('127.0.0.1', 80)) we would still have a ?server? socket, but one that was only visible within the same machine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20100502/e8e83d17/attachment.bin>

From report at bugs.python.org  Tue May  4 14:06:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 May 2010 12:06:34 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1272974794.39.0.660494758519.issue8557@psf.upfronthosting.co.za>


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

Fair enough.  Thank you for your detective work, and hopefully someone will be interested enough to pick this up again later.

----------
status: open -> languishing

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

From report at bugs.python.org  Wed May  5 01:51:20 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Tue, 04 May 2010 23:51:20 +0000
Subject: [docs] [issue8617] Non-existent variables documented
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

http://docs.python.org/library/site.html#module-site mentions two variables that don't appear in my Python 2.6.5 installation's site module:

PYTHONNOUSERSITE
New in version 2.6.

PYTHONUSERBASE
New in version 2.6.

----------
assignee: docs at python
components: Documentation
messages: 104985
nosy: dabrahams, docs at python
priority: normal
severity: normal
status: open
title: Non-existent variables documented
versions: Python 2.6

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

From report at bugs.python.org  Wed May  5 03:40:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 01:40:29 +0000
Subject: [docs] [issue8617] Non-existent variables documented
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1273023629.38.0.978965048999.issue8617@psf.upfronthosting.co.za>


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

These are references to environment variables.  The markup marks them as such, but this does not translate into HTML in a visible way.  Without a text description it is also left to guesswork as to how they function. The 2.7 docs are even more confusing, adding 'getuserbase'.  Adding Tarek as nosy since he has been updating this doc most recently.

----------
nosy: +r.david.murray, tarek
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May  5 05:43:03 2010
From: report at bugs.python.org (Sriram Thaiyar)
Date: Wed, 05 May 2010 03:43:03 +0000
Subject: [docs] [issue8619] Doc bug for urllib.request._urlopener in Python
	3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>


New submission from Sriram Thaiyar <sriram.thaiyar at gmail.com>:

http://docs.python.org/dev/py3k/library/urllib.request.html#urllib.request._urlopener

[in the body]
urllib._urlopener should be urllib.request._urlopener

----------
assignee: docs at python
components: Documentation
messages: 104998
nosy: Sriram.Thaiyar, docs at python
priority: normal
severity: normal
status: open
title: Doc bug for urllib.request._urlopener in Python 3.1+
versions: Python 3.1

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

From report at bugs.python.org  Wed May  5 07:35:02 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 05 May 2010 05:35:02 +0000
Subject: [docs] [issue8619] Doc bug for urllib.request._urlopener in Python
	3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273037701.59.0.755820309664.issue8619@psf.upfronthosting.co.za>


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

Fixed in r80773 and r80774.

Thanks.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed May  5 08:19:13 2010
From: report at bugs.python.org (sri)
Date: Wed, 05 May 2010 06:19:13 +0000
Subject: [docs] [issue8619] Doc bug for urllib.request._urlopener in Python
	3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273040353.06.0.691619317692.issue8619@psf.upfronthosting.co.za>


sri <sriram.thaiyar at gmail.com> added the comment:

You missed the code part:

urllib._urlopener = AppURLopener()

----------

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

From report at bugs.python.org  Wed May  5 09:25:11 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 05 May 2010 07:25:11 +0000
Subject: [docs] [issue8619] Doc bug for urllib.request._urlopener in Python
	3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273044311.24.0.704009496428.issue8619@psf.upfronthosting.co.za>


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

Fixed in r80775 and r80776

----------

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

From report at bugs.python.org  Wed May  5 10:20:04 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Wed, 05 May 2010 08:20:04 +0000
Subject: [docs] [issue8617] Non-existent variables documented
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1273047602.98.0.241582644283.issue8617@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

site definitely needs more documentation about the per-user site-packages. 

We need to add a section about that. I am adding Christian to the nosy list, since he added those feature. I can work on a section sometimes next week and propose a patch here btw.

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Wed May  5 14:21:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 12:21:47 +0000
Subject: [docs] [issue8619] Doc bug for urllib.request._urlopener in Python
	3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273062106.85.0.283345623424.issue8619@psf.upfronthosting.co.za>


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

Why do we have a public API that begins with an '_'?

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

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

From report at bugs.python.org  Wed May  5 14:45:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 05 May 2010 12:45:32 +0000
Subject: [docs] [issue8619] Doc bug for urllib.request._urlopener in Python
	3.1+
In-Reply-To: <1273062106.85.0.283345623424.issue8619@psf.upfronthosting.co.za>
Message-ID: <20100505124521.GA6463@remy>


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

That is actually a private attribute of urllib (not urllib2) module
present from the very first version. It is intended strictly for
overriding purposes not for anything else. During the merge in py3k,
it has taken its place in urllib.request. I see no harm in it being
there. If it needs to be un-advertised, perhaps we can remove its
reference from the docs.

----------

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

From report at bugs.python.org  Wed May  5 17:11:51 2010
From: report at bugs.python.org (Daniel Urban)
Date: Wed, 05 May 2010 15:11:51 +0000
Subject: [docs] [issue8628] Incorrect numbers.Complex.imag documentation
In-Reply-To: <1273072311.36.0.918807999354.issue8628@psf.upfronthosting.co.za>
Message-ID: <1273072311.36.0.918807999354.issue8628@psf.upfronthosting.co.za>


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

The current documentation of the imag abstract property of numbers.Complex is this:
"Abstract. Retrieves the Real component of this number."
Of course the imag attribute is the imaginary component, not the real.

----------
assignee: docs at python
components: Documentation
messages: 105048
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Incorrect numbers.Complex.imag documentation
versions: Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May  5 18:53:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 16:53:16 +0000
Subject: [docs] [issue8628] Incorrect numbers.Complex.imag documentation
In-Reply-To: <1273072311.36.0.918807999354.issue8628@psf.upfronthosting.co.za>
Message-ID: <1273078396.61.0.898670118805.issue8628@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed May  5 19:27:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 05 May 2010 17:27:30 +0000
Subject: [docs] [issue8564] Update documentation on doctest/unittest2
	integration
In-Reply-To: <1272491514.09.0.168519244685.issue8564@psf.upfronthosting.co.za>
Message-ID: <1273080450.01.0.363692473609.issue8564@psf.upfronthosting.co.za>


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

I can?t tell if the code is correct (we can trust Michael about that), but the wording and the content are ok for me.

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

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

From report at bugs.python.org  Wed May  5 20:04:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 May 2010 18:04:33 +0000
Subject: [docs] [issue8619] Doc bug for urllib.request._urlopener in Python
	3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1273082673.21.0.797924278172.issue8619@psf.upfronthosting.co.za>


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

Mainly I'm saying that I don't think a public API should have a name starting with an '_'.  Sets a bad precedent :)

Looking at the functionality more closely, though, it does make me nervous that we are recommending changing the global state of the module.  Sounds like a recipe for hard to find bugs.  So maybe it should be removed from the docs, and a better way found to expose that functionality.

----------

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

From report at bugs.python.org  Wed May  5 21:02:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 05 May 2010 19:02:52 +0000
Subject: [docs] [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1273086172.81.0.0397276132817.issue8556@psf.upfronthosting.co.za>


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

Looks good to me.

----------

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

From report at bugs.python.org  Wed May  5 22:21:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 May 2010 20:21:54 +0000
Subject: [docs] [issue8626] TypeError: rsplit() takes no keyword arguments
In-Reply-To: <1273069691.09.0.629182954336.issue8626@psf.upfronthosting.co.za>
Message-ID: <1273090913.63.0.873848285373.issue8626@psf.upfronthosting.co.za>


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

This is more of a documentation issue than anything else. The fact that the argument is named "maxsplit" and accepts a default value doesn't mean it's usable as a keyword argument. It would be difficult to document a parameter without giving it a name anyway...

As a rule of thumb, methods accepting 2 parameters or less often don't accept any keyword arguments, since there's no point in doing so.

I suggest closing this issue.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou
stage: unit test needed -> 

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

From report at bugs.python.org  Wed May  5 23:55:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 May 2010 21:55:20 +0000
Subject: [docs] [issue8628] Incorrect numbers.Complex.imag documentation
In-Reply-To: <1273072311.36.0.918807999354.issue8628@psf.upfronthosting.co.za>
Message-ID: <1273096520.22.0.853425359723.issue8628@psf.upfronthosting.co.za>


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

Thanks for the report!  Fixed in r80826 through r80829.

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

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

From merwok at netwok.org  Thu May  6 17:06:20 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Thu, 06 May 2010 17:06:20 +0200
Subject: [docs] unicode in 3.1
In-Reply-To: <316798.17470.qm@web110711.mail.gq1.yahoo.com>
References: <316798.17470.qm@web110711.mail.gq1.yahoo.com>
Message-ID: <4BE2DAEC.2020507@netwok.org>

Hello

http://docs.python.org/ contains the documentation for Python 2.6, as
stated on the front page. You can find a link to the doc for 3.1 on the
left sidebar of the same page, it?s http://docs.python.org/py3k/

It?s normal that u'Hello' does not work with 3.x, the syntax is now just
'Hello'. There are docs about migrating from 2.x to 3.x that highlight that.

Regards

From report at bugs.python.org  Thu May  6 22:00:33 2010
From: report at bugs.python.org (Lucian Ursu)
Date: Thu, 06 May 2010 20:00:33 +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: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>


New submission from Lucian Ursu <lucian_ursu at yahoo.com>:

I suggest that name mangling should not be recommended as a way of having private attributes. Instead, one underscore should be suggested as a signal that the attribute is private.
This suggestion comes after discussing with some of the helpers from #python. Basically, they said that name mangling should never be used, so it would be appropriate to remove this recommendation from the tutorial.

----------
assignee: docs at python
components: Documentation
messages: 105161
nosy: LucianU, docs at python
priority: normal
severity: normal
status: open
title: Remove suggestion for name mangling from the tutorial
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Thu May  6 22:31:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 06 May 2010 20:31:49 +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: <1273177909.31.0.472984679341.issue8638@psf.upfronthosting.co.za>


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

Note that the opinion of people helping in #python does not necessarily (or frequently) match the one of core Python developers. That said, I agree with this particular suggestion.

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

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

From report at bugs.python.org  Fri May  7 01:46:14 2010
From: report at bugs.python.org (Dan Buch)
Date: Thu, 06 May 2010 23:46:14 +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: <1273189574.43.0.89030283526.issue8638@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Fri May  7 11:05:34 2010
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Fri, 07 May 2010 09:05:34 +0000
Subject: [docs] [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:

At the end of description of json.loads, dump() should be load().

----------
assignee: docs at python
components: Documentation
messages: 105187
nosy: docs at python, mft
priority: normal
severity: normal
status: open
title: json.loads description
versions: Python 2.6

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

From report at bugs.python.org  Fri May  7 13:13:41 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 07 May 2010 11:13:41 +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: <1273230821.32.0.414160027863.issue8638@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Maybe the wording should be changed, but name mangling serves a useful
purpose.  There are two definitions of "private" which seem to be a
bit conflated in this section:

* "private" as in, "this name is not part of the public API - use it
  at your own risk".

* "private" as in, "I don't want someone to accidentally stomp on this
  attribute name when subclassing this class".

I think it is valuable to mention both of these conventions in the
tutorial for a couple reasons:

* the tutorial is meant for people new to Python but with experience
  in other programming languages

* the distinction between _a and __a is a bit subtle and not obviously
  similar to privacy features present in other languages.

I work with a lot of C++ programmers who also write some Python
(sometimes a lot of Python).  It's clear at times that the distinction
hasn't always sunk in.

----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Fri May  7 17:55:36 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 15:55:36 +0000
Subject: [docs] [issue8645] PyUnicode_AsEncodedObject is undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>


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

PyUnicode_AsEncodedObject is undocumented.  It has the same signature as PyUnicode_AsEncodedString, although they do slightly different things based on a brief source code inspection (I'm not clear on what that difference is though).

----------
assignee: docs at python
components: Documentation
messages: 105203
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_AsEncodedObject is undocumented
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May  7 17:59:05 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 15:59:05 +0000
Subject: [docs] [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>


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

PyUnicode_EncodeDecimal is undocumented (although it's referenced in passing in the documentation for PyLong_FromUnicode).  There's a lengthy comment in unicodeobject.h describing PyUnicode_EncodeDecimal, which could be converted more or less directly into documentation.

----------
assignee: docs at python
components: Documentation
messages: 105205
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_EncodeDecimal is undocumented
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May  7 18:07:19 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 16:07:19 +0000
Subject: [docs] [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>


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

Here's the relevant signature:

/* Get the maximum ordinal for a Unicode character. */
PyAPI_FUNC(Py_UNICODE) PyUnicode_GetMax(void);

----------
assignee: docs at python
components: Documentation
messages: 105206
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: PyUnicode_GetMax is undocumented
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May  7 18:10:36 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 16:10:36 +0000
Subject: [docs] [issue8648] The UTF-7 codec functions are undocumented
In-Reply-To: <1273248636.7.0.217932609429.issue8648@psf.upfronthosting.co.za>
Message-ID: <1273248636.7.0.217932609429.issue8648@psf.upfronthosting.co.za>


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

The UTF-7 codec functions are undocumented:

PyUnicode_DecodeUTF7Stateful
PyUnicode_DecodeUTF7
PyUnicode_EncodeUTF7

----------
assignee: docs at python
components: Documentation
messages: 105207
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: The UTF-7 codec functions are undocumented
versions: Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri May  7 18:48:41 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 07 May 2010 16:48:41 +0000
Subject: [docs] [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>


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

Python provides several functions for manipulating raw Py_UNICODE strings, but they aren't documented.  Below are their signatures.

PyAPI_FUNC(size_t) Py_UNICODE_strlen(const Py_UNICODE *u);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strcpy(
    Py_UNICODE *s1, const Py_UNICODE *s2);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strncpy(
    Py_UNICODE *s1, const Py_UNICODE *s2, size_t n);

PyAPI_FUNC(int) Py_UNICODE_strcmp(
    const Py_UNICODE *s1, const Py_UNICODE *s2);

PyAPI_FUNC(Py_UNICODE*) Py_UNICODE_strchr(
    const Py_UNICODE *s, Py_UNICODE c
    );

----------
assignee: docs at python
components: Documentation
messages: 105214
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_UNICODE_* functions are undocumented
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri May  7 19:25:34 2010
From: report at bugs.python.org (Marien Zwart)
Date: Fri, 07 May 2010 17:25:34 +0000
Subject: [docs] [issue8652] Minor improvements to the "Handling Exceptions"
	part of	the tutorial
In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>
Message-ID: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>


New submission from Marien Zwart <m_zwart at 123mail.org>:

Based on questions asked on freenode's #python by people reading the tutorial I would like to suggest two improvements to http://docs.python.org/tutorial/errors.html#handling-exceptions :

- Mention the older "except SomeException, e:" syntax too, not just "except SomeException as e:". I have had people ask me to help them upgrade to a newer python because they thought their version of python did not support catching exception instances (their distro python being 2.5). A big fat warning that they're reading the Python 2.6 tutorial (with links to older tutorials) may also work.

- Mention "except IOError as e" before mentioning "except IOError as (errno, strerror):". The latter is an advanced and relatively unusual trick, combining regular exception catching and unpacking. Those two concepts need to be explained before the combination is. I have had people ask me how to do "except KeyError as (key, insert_something_here):" because they thought they *always* needed those parens there.

(perhaps just not mentioning unpacking here at all, using "except IOError as e:" and then using e.errno would make more sense, especially since "except IOError as (errno, strerror):" is a SyntaxError in python 3 and up (because of the unpacking) and python 2.5.x and down (because of the "as")...)

I can try to write a patch to the documentation if you like.

----------
assignee: docs at python
components: Documentation
messages: 105218
nosy: docs at python, marienz
priority: normal
severity: normal
status: open
title: Minor improvements to the "Handling Exceptions" part of the tutorial

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

From report at bugs.python.org  Fri May  7 20:39:02 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Fri, 07 May 2010 18:39:02 +0000
Subject: [docs] [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>


New submission from Dave Abrahams <dave at boostpro.com>:

The docstrings for these functions don't explain the 'scheme' parameter.  Even renaming it to default_scheme would help.

----------
assignee: docs at python
components: Documentation
messages: 105221
nosy: dabrahams, docs at python
priority: normal
severity: normal
status: open
title: urlparse.urlparse/urlsplit doc missing

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

From report at bugs.python.org  Fri May  7 23:52:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 May 2010 21:52:26 +0000
Subject: [docs] [issue8602] documentation of bz2 module mildly erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1273269146.68.0.683724585122.issue8602@psf.upfronthosting.co.za>


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

Now that #8601 is closed, would you mind providing a doc patch explaining the lack of context manager protocol support and its reason?

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

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

From report at bugs.python.org  Sat May  8 00:35:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 May 2010 22:35:49 +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: <1273271735.96.0.800586648716.issue8638@psf.upfronthosting.co.za>


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

Double underscore name mangling is for avoiding name clashes with base classes, not for 'private attributes'. This is such an advanced and rarely used feature that it hardly seems appropriate for the tutorial.

----------
nosy: +tjreedy

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

From report at bugs.python.org  Sat May  8 00:39:35 2010
From: report at bugs.python.org (Clovis Fabricio)
Date: Fri, 07 May 2010 22:39:35 +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: <1273271974.52.0.0941915171839.issue8638@psf.upfronthosting.co.za>


Clovis Fabricio <nosklo+python at gmail.com> added the comment:

I help in #python and always suggest people to not use double-underscore name mangling when they mean private. 
I agree that name mangling shouldn't be on the tutorial at all. It misleads everybody coming from other languages into thinking that it means "private" like it does in java or C++.

----------
nosy: +nosklo

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

From report at bugs.python.org  Sat May  8 01:17:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 07 May 2010 23:17:39 +0000
Subject: [docs] [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273274259.29.0.74029545367.issue8642@psf.upfronthosting.co.za>


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

Is it possible for you to propose a patch, as described in http://www.python.org/dev/patches/ ?

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

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

From report at bugs.python.org  Sat May  8 02:12:40 2010
From: report at bugs.python.org (Dan Buch)
Date: Sat, 08 May 2010 00:12:40 +0000
Subject: [docs] [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1273277559.87.0.382126965856.issue8653@psf.upfronthosting.co.za>


Changes by Dan Buch <daniel.buch at gmail.com>:


----------
nosy: +meatballhat

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

From report at bugs.python.org  Sat May  8 03:11:46 2010
From: report at bugs.python.org (Matt Wartell)
Date: Sat, 08 May 2010 01:11:46 +0000
Subject: [docs] [issue8602] documentation of bz2 module mildly erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1273281105.43.0.651901907963.issue8602@psf.upfronthosting.co.za>


Matt Wartell <matt.wartell+pt at gmail.com> added the comment:

Per request, I have attached a context diff for both bz2.txt and 3.0.txt suitable for http://docs.python.org/library/bz2.html and http://docs.python.org/release/3.0.1/whatsnew/3.0.html respectively. 

The modification in bz2.txt may border on redundant and overly verbose and should be reviewed for style consistency.

I have sanity-checked the modified files with sphinx-build html which generates clean, consistent markup.

----------
keywords: +patch
status: open -> pending
Added file: http://bugs.python.org/file17253/issue-8602.diff

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

From report at bugs.python.org  Sat May  8 03:43:14 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 08 May 2010 01:43:14 +0000
Subject: [docs] [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1273282993.57.0.501837608581.issue8653@psf.upfronthosting.co.za>


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

I don't see anything that is missing. Its here in the docs 
http://docs.python.org/library/urlparse.html#urlparse-result-object
And also docstrings has the information too.

Could you explain a bit more as what you were expecting and found missing?

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

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

From report at bugs.python.org  Sat May  8 04:17:10 2010
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Sat, 08 May 2010 02:17:10 +0000
Subject: [docs] [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273285029.17.0.980027181507.issue8642@psf.upfronthosting.co.za>


MATSUI Tetsushi <mft at users.sourceforge.net> added the comment:

OK, here you are.

----------
keywords: +patch
Added file: http://bugs.python.org/file17256/json.diff

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

From fdrake at acm.org  Sat May  8 06:51:34 2010
From: fdrake at acm.org (Fred Drake)
Date: Sat, 8 May 2010 00:51:34 -0400
Subject: [docs] [issue8638] Remove suggestion for name mangling from the
	tutorial
In-Reply-To: <1273271735.96.0.800586648716.issue8638@psf.upfronthosting.co.za>
References: <1273176032.85.0.0243971489868.issue8638@psf.upfronthosting.co.za>
	<1273271735.96.0.800586648716.issue8638@psf.upfronthosting.co.za>
Message-ID: <z2h9cee7ab81005072151g6d7f54d2w6e4a4022d1e3834d@mail.gmail.com>

On Fri, May 7, 2010 at 6:35 PM, Terry J. Reedy <report at bugs.python.org> wrote:
> This is such an advanced and rarely used feature that it hardly seems appropriate for the tutorial.

The problem with just leaving it out is that learners stumbling over
them in existing code (likely by trying to use something that looks
like it should be there and getting an AttributeError) won't have a
chance of knowing what the problem might be.

I'd be fine seeing new uses discouraged, especially for new learners,
but I think it's important that they be given a heads-up as well.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From report at bugs.python.org  Sat May  8 14:54:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 08 May 2010 12:54:59 +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: <1273323298.39.0.0265159478404.issue8638@psf.upfronthosting.co.za>


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

The section titled "Private Variables" was updated fairly recently to be more in line with the Python philosophy.  In its current form (which I verified to be present at e.g. http://docs.python.org/tutorial/classes#private-variables) I don't think it needs to be removed or revised (except for further clarification, of course.)

If someone disagrees, I would like to see a patch (or a suggestion for new wording).

----------
nosy: +georg.brandl
status: open -> pending

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

From report at bugs.python.org  Sat May  8 15:10:10 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 08 May 2010 13:10:10 +0000
Subject: [docs] [issue8660] py3k weakref documentation mentions the long
	built-in type
In-Reply-To: <1273324210.04.0.0772545090364.issue8660@psf.upfronthosting.co.za>
Message-ID: <1273324210.04.0.0772545090364.issue8660@psf.upfronthosting.co.za>


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

There is a sentence in the weakref module's documentation:
"Other built-in types such as tuple and long do not support weak references even when subclassed"
But there is no "long" type in py3k.

----------
assignee: docs at python
components: Documentation
messages: 105285
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: py3k weakref documentation mentions the long built-in type
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat May  8 17:31:41 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 08 May 2010 15:31:41 +0000
Subject: [docs] [issue8660] py3k weakref documentation mentions the long
	built-in type
In-Reply-To: <1273324210.04.0.0772545090364.issue8660@psf.upfronthosting.co.za>
Message-ID: <1273332701.92.0.364728136484.issue8660@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r80983.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat May  8 23:53:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 May 2010 21:53:33 +0000
Subject: [docs] [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273355613.86.0.519369034252.issue8642@psf.upfronthosting.co.za>


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

Seems ok to me.

----------

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

From report at bugs.python.org  Sun May  9 00:18:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 08 May 2010 22:18:14 +0000
Subject: [docs] [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1273357091.4.0.211490392306.issue8653@psf.upfronthosting.co.za>


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

I think you mean http://docs.python.org/library/urlparse.html#urlparse.urlparse

Dave, perhaps you were looking at an older version? Doc fixes for maintainance branches are welcome.

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

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

From report at bugs.python.org  Sun May  9 14:43:36 2010
From: report at bugs.python.org (bones7456)
Date: Sun, 09 May 2010 12:43:36 +0000
Subject: [docs] [issue8671] A small erorr on
	http://docs.python.org/library/re.html
In-Reply-To: <1273409015.67.0.984272084937.issue8671@psf.upfronthosting.co.za>
Message-ID: <1273409015.67.0.984272084937.issue8671@psf.upfronthosting.co.za>


New submission from bones7456 <bones7456 at gmail.com>:

In section \b , original text is:

Matches the empty string, but only at the beginning or end of a word. A word is defined as a sequence of alphanumeric or underscore characters, so the end of a word is indicated by whitespace or a non-alphanumeric, non-underscore character. Note that \b  is defined as the boundary between \w and \ W, so the precise set of characters deemed to be alphanumeric depends on the values of the UNICODE and LOCALE flags. Inside a character range, \b  represents the backspace character, for compatibility with Python?s string literals.

NOTE: there is space between "\" and "W", I think it is not needed.

----------
assignee: docs at python
components: Documentation
messages: 105391
nosy: bones7456, docs at python
priority: normal
severity: normal
status: open
title: A small erorr on http://docs.python.org/library/re.html
versions: Python 2.6

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

From report at bugs.python.org  Sun May  9 16:10:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 09 May 2010 14:10:03 +0000
Subject: [docs] [issue8671] A small erorr on
	http://docs.python.org/library/re.html
In-Reply-To: <1273409015.67.0.984272084937.issue8671@psf.upfronthosting.co.za>
Message-ID: <1273414203.3.0.906135621052.issue8671@psf.upfronthosting.co.za>


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

Fixed in:
trunk: r81026
release26-maint: r81027

It was already correct in py3k and release31-maint.

Thanks!

----------
nosy: +eric.smith
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Sun May  9 23:20:41 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sun, 09 May 2010 21:20:41 +0000
Subject: [docs] [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273357091.4.0.211490392306.issue8653@psf.upfronthosting.co.za>
Message-ID: <m2d3x4vkj8.wl%dave@boostpro.com>


Dave Abrahams <dave at boostpro.com> added the comment:

At Sat, 08 May 2010 22:18:13 +0000,
?ric Araujo wrote:
> 
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> I think you mean http://docs.python.org/library/urlparse.html#urlparse.urlparse
> 
> Dave, perhaps you were looking at an older version? Doc fixes for
> maintainance branches are welcome.

No, I was looking at (and reporting on) the docstrings.

----------

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

From bj at mbwit.com  Wed May  5 18:01:46 2010
From: bj at mbwit.com (Brian Johnson)
Date: Wed, 05 May 2010 12:01:46 -0400
Subject: [docs] logging.handlers StreamHandler/FileHandler
Message-ID: <4BE1966A.4050002@mbwit.com>

http://docs.python.org/library/logging.html#handler-objects

The FileHandler and StreamHandler are specified as being in 
logging.handers. but they're actually in logging.

-- 
Brian Johnson -- Mobius Works <http://mobiusworks.net>
o: 413-564-6942x104 | m: 413-531-2859
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100505/1d8a6884/attachment-0001.html>

From david.lindquist at gmail.com  Fri May  7 00:44:46 2010
From: david.lindquist at gmail.com (David Lindquist)
Date: Thu, 6 May 2010 15:44:46 -0700
Subject: [docs] typo in logging documentation
Message-ID: <j2n91488b8a1005061544ibbaed952ia6393603cfe1059d@mail.gmail.com>

Hello,

I found a typo in the logger documentation:

http://docs.python.org/library/logging.html#logging.handlers.FileHandler
http://docs.python.org/library/logging.html#logging.handlers.StreamHandler

These show FileHandler and StreamHandler as being defined in the
logging.handlers module, when in fact they are defined in the core logging
package.

Cheers,

David Lindquist
Phoenix, AZ USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100506/c30526d4/attachment-0001.html>

From r1chardj0n3s at gmail.com  Fri May  7 11:20:40 2010
From: r1chardj0n3s at gmail.com (Richard Jones)
Date: Fri, 7 May 2010 19:20:40 +1000
Subject: [docs] Suggested improvement to turtle module doc
Message-ID: <078F9AC2-7A0D-4258-8556-CFA51A46CC87@gmail.com>

Hi all,

I'm planning on playing turtle with my daughter tomorrow and figured I should look into how to get going before I do so.

It took me far longer than it should have to figure out how to do the most basic thing: from an interactive prompt (or elsewhere!) get the turtle window up and have a controllable turtle. In the end I just guessed and created a Turtle and it worked - though I still struggle to see where this is mentioned in the docs.

I believe the docs would benefit greatly from a simple example right at the top like:

"""
The easiest method of getting started is to open an interactive prompt and type:

>>> from turtle import *
>>> turtle = Turtle()
>>> turtle.pendown()
>>> turtle.forward(100)
>>> turtle.left(90)
>>> turtle.forward(100)
>>> turtle.left(90)
>>> turtle.forward(100)
>>> turtle.left(90)
>>> turtle.forward(100)
>>> turtle.penup()

"""


Regards,

     Richard


From contact at vincentollivier.com  Fri May  7 12:43:03 2010
From: contact at vincentollivier.com (Vincent Ollivier)
Date: Fri, 7 May 2010 12:43:03 +0200
Subject: [docs] Inversion in the documentation of 'xml.dom'
Message-ID: <l2y47b329f11005070343z7761503fh880d8c6120f56855@mail.gmail.com>

Hi,

There is a little inversion in the documentation of 'xml.dom':
http://docs.python.org/library/xml.dom.html

"""
19.6.2.3. NodeList Objects
A NodeList represents a sequence of nodes. These objects are used in two
ways
in the DOM Core recommendation: the Element objects provides one as its list
of
child nodes, and the getElementsByTagName() and getElementsByTagNameNS()
methods of Node return objects with this interface to represent query
results.
"""

It is the 'Node' objects who provides 'childNodes' and not the 'Element'
objects. And vice versa for the two methods 'getElementsByTagName()' and
'getElementsByTagNameNS()':

Node.childNodes
Element.getElementsByTagName(tagName)
Element.getElementsByTagNameNS(namespaceURI, localName)
Document.getElementsByTagName(tagName)
Document.getElementsByTagNameNS(namespaceURI, localName)

Cordially,

Vincent Ollivier
contact at vincentollivier.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100507/266b0f2d/attachment-0001.html>

From ralfganswindt at gmail.com  Sat May  8 15:58:52 2010
From: ralfganswindt at gmail.com (Ralf Ganswindt)
Date: Sat, 8 May 2010 08:58:52 -0500
Subject: [docs] Dead Link
Message-ID: <h2ned9c2bd51005080658g39da3a94k2249b6b354451cc@mail.gmail.com>

Hello,

The following link:

------------------------

See also
http://www.pysqlite.orgThe pysqlite web page ? sqlite3 is developed
externally under the name ?pysqlite?.------------------------in the Python
Library documentation, section 11.13.sqlite3, "
http://docs.python.org/library/sqlite3.html," appears to be a dead link.
Is "http://code.google.com/p/pysqlite/" the correct new location?

Ralf Ganswindt
RalfGanswindt at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100508/aa3bd3df/attachment-0001.html>

From Heiner.Marxen at DrB.Insel.DE  Mon May 10 01:37:44 2010
From: Heiner.Marxen at DrB.Insel.DE (Heiner Marxen)
Date: Mon, 10 May 2010 01:37:44 +0200 (CEST)
Subject: [docs] minor bugs in doc of python 3.1.2
Message-ID: <201005092337.o49NbiMT009177@drb9.drb.insel.de>

Hello,

I think I have found a small bug in the python manual.
URL: http://docs.python.org/py3k/reference/lexical_analysis.html
chapter: 2.4.1. String and Bytes literals,
Notes 4.: replace "exactly two hex digits" by "exactly four hex digits".

An additional note from a python newbie, reading the doc the first time:
At the very end of the above URL, there is clearly stated, that the
characters $ and ? are immediate errors (outside strings and comments).
But what about the backtick character ` (\x60)?
I do not find it mentioned anywhere, definitely not inside that URL.
Shouldn't that char then be mentioned in the bottom section?

Otherwise: many thanks for the really good documentation!

Regards,
-- 
Heiner Marxen				http://www.drb.insel.de/~heiner/

From db.pub.mail at gmail.com  Mon May 10 07:37:59 2010
From: db.pub.mail at gmail.com (dave b)
Date: Mon, 10 May 2010 15:37:59 +1000
Subject: [docs] Currently there is no warning in the python doc that using
	open() on user or other controlled filenames is dangerous.
Message-ID: <l2t25ae2d691005092237ic630431j5723a2da872ad772@mail.gmail.com>

Currently there is no warning in the python doc that using open() on
user or other controlled filenames is dangerous.
I think that a warning should be in the documentation to say that if
you are using open() and you do not have a set file parameter
(hard-coded) then you *SHOULD* check the filename will not escape or
point to places that are not desired.
Personally I feel that python should have an open() argument to say
"do not go out side FOO directory".

From ravi at p-static.net  Mon May 10 07:58:14 2010
From: ravi at p-static.net (Ravi Pinjala)
Date: Mon, 10 May 2010 00:58:14 -0500
Subject: [docs] doc bug: undocumented fields in tarfile.TarInfo
Message-ID: <4BE7A076.1050405@p-static.net>

Hi,

In the tarfile.TarInfo class, the devmajor and devminor fields are 
undocumented. tarfile supports character and block devices, but the 
undocumented fields are the only way to access the major/minor device 
numbers and actually make use of this support. These fields are only set 
for character and block devices.

--Ravi Pinjala

From report at bugs.python.org  Mon May 10 21:29:08 2010
From: report at bugs.python.org (Daniel Urban)
Date: Mon, 10 May 2010 19:29:08 +0000
Subject: [docs] [issue8676] Py3k Built-in Exceptions documentation mentions
	the raise	statement of 2.x
In-Reply-To: <1273519748.49.0.797934742899.issue8676@psf.upfronthosting.co.za>
Message-ID: <1273519748.49.0.797934742899.issue8676@psf.upfronthosting.co.za>


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

In the documentation of the exceptions (http://docs.python.org/dev/py3k/library/exceptions) there is a sentence:
"The associated value is the second argument to the raise statement."
But in py3k there is a different raise statement than in 2.x.

----------
assignee: docs at python
components: Documentation
messages: 105457
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Py3k Built-in Exceptions documentation mentions the raise statement of 2.x
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon May 10 22:49:44 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 May 2010 20:49:44 +0000
Subject: [docs] [issue8676] Py3k Built-in Exceptions documentation mentions
	the raise	statement of 2.x
In-Reply-To: <1273519748.49.0.797934742899.issue8676@psf.upfronthosting.co.za>
Message-ID: <1273524583.85.0.349916595434.issue8676@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks for the report. Fixed in r81057.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon May 10 23:03:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 10 May 2010 21:03:03 +0000
Subject: [docs] [issue8642] json.loads description
In-Reply-To: <1273223133.88.0.532176627145.issue8642@psf.upfronthosting.co.za>
Message-ID: <1273525382.94.0.522897028554.issue8642@psf.upfronthosting.co.za>


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

Thanks, fixed in r81059.

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

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

From georg at python.org  Mon May 10 23:12:00 2010
From: georg at python.org (Georg Brandl)
Date: Mon, 10 May 2010 23:12:00 +0200
Subject: [docs] Dead Link
In-Reply-To: <h2ned9c2bd51005080658g39da3a94k2249b6b354451cc@mail.gmail.com>
References: <h2ned9c2bd51005080658g39da3a94k2249b6b354451cc@mail.gmail.com>
Message-ID: <4BE876A0.2030609@python.org>

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

Am 08.05.2010 15:58, schrieb Ralf Ganswindt:
> Hello,
> 
> The following link:
> 
> ------------------------
> 
> See also
> 
> http://www.pysqlite.org <http://www.pysqlite.org/>
>     The pysqlite web page ? sqlite3 is developed externally under the
>     name ?pysqlite?.
> 
> ------------------------
> 
> in the Python Library documentation, section 11.13.sqlite3,
> "http://docs.python.org/library/sqlite3.html," appears to be a dead link.
> Is "http://code.google.com/p/pysqlite/" the correct new location?

Yes, it is.  Thanks for the report; this was already fixed in the trunk
docs, but not backported yet -- now it is!

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

iEYEARECAAYFAkvodqAACgkQN9GcIYhpnLBKmgCgnfVcHqtbE9HKIXgZrFwcKYGh
tr4AnjjZRl3iszSSuTXfi7pkT/2Dwx0L
=t+YA
-----END PGP SIGNATURE-----

From georg at python.org  Mon May 10 23:17:20 2010
From: georg at python.org (Georg Brandl)
Date: Mon, 10 May 2010 23:17:20 +0200
Subject: [docs] minor bugs in doc of python 3.1.2
In-Reply-To: <201005092337.o49NbiMT009177@drb9.drb.insel.de>
References: <201005092337.o49NbiMT009177@drb9.drb.insel.de>
Message-ID: <4BE877E0.4070503@python.org>

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

Am 10.05.2010 01:37, schrieb Heiner Marxen:
> Hello,
> 
> I think I have found a small bug in the python manual.
> URL: http://docs.python.org/py3k/reference/lexical_analysis.html
> chapter: 2.4.1. String and Bytes literals,
> Notes 4.: replace "exactly two hex digits" by "exactly four hex digits".
> 
> An additional note from a python newbie, reading the doc the first time:
> At the very end of the above URL, there is clearly stated, that the
> characters $ and ? are immediate errors (outside strings and comments).
> But what about the backtick character ` (\x60)?
> I do not find it mentioned anywhere, definitely not inside that URL.
> Shouldn't that char then be mentioned in the bottom section?

Hi Heiner,

thanks for the report; you're right on both counts, fixed now in subversion.
The backtick wasn't included in the erroneous characters list because it's
used in Python 2.x, and we forgot to include it here again.

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

iEYEARECAAYFAkvod+AACgkQN9GcIYhpnLBAGQCfT1YKYZNZNhZZRiF4g3HK95lv
bYMAnji8AqMCpBfRMnoqPTwxOfdTCwhG
=AT6a
-----END PGP SIGNATURE-----

From georg at python.org  Mon May 10 23:46:21 2010
From: georg at python.org (Georg Brandl)
Date: Mon, 10 May 2010 23:46:21 +0200
Subject: [docs] ftplib nit
In-Reply-To: <OFFA91675D.C14A9B2C-ON88257713.001C7AAB-88257713.001C7AB3@dot.ca.gov>
References: <OFFA91675D.C14A9B2C-ON88257713.001C7AAB-88257713.001C7AB3@dot.ca.gov>
Message-ID: <4BE87EAD.1070507@python.org>

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

Am 28.04.2010 07:11, schrieb Larry Tjoelker:
> in ftplib docs, http://docs.python.org/library/ftplib.html?highlight=ftplib#module-ftplib, 
> description of 
> 
> ftplib.all_errors
> 
> 3rd line:
> 
> "errors made by the caller). This set includes the four exceptions listed below as"
> 
> It should be:
> 
> "errors made by the caller). This set includes the four exceptions listed above as"

Thanks, fixed in development docs!

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

iEYEARECAAYFAkvofq0ACgkQN9GcIYhpnLAKxQCgjQ2XCLf213zDguH67NTdxRog
bgcAoKDZCh9VP+t+zEt6xXk89vp/z8pp
=9trn
-----END PGP SIGNATURE-----

From georg at python.org  Mon May 10 23:51:05 2010
From: georg at python.org (Georg Brandl)
Date: Mon, 10 May 2010 23:51:05 +0200
Subject: [docs] Typo in io.rst and meta-question about patches workflow
In-Reply-To: <4BDC7790.4060106@netwok.org>
References: <4BDC7790.4060106@netwok.org>
Message-ID: <4BE87FC9.1060001@python.org>

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

Am 01.05.2010 20:48, schrieb ?ric Araujo:
> Hello everyone
> 
> 
> In trunk?s Doc/library/io.rst, a change from IOError to ValueError has
> left a stray ?an?:
> 
> --- Doc/library/io.rst	Sat May 01 14:16:39 2010 +0200
> +++ Doc/library/io.rst	Sat May 01 15:26:32 2010 +0200
> @@ -246,7 +246,7 @@
> -      (e.g. reading or writing) will raise an :exc:`ValueError`.
> +      (e.g. reading or writing) will raise a :exc:`ValueError`.
> 
> 
> Is it ok to use the mailing list instead of the bug tracker for such
> tiny patches? Apart from Georg, are there people with commit power on
> the list? Do they prefer emails or bug reports? Should we wait until
> we?ve collected a bunch of typo before reporting them instead of doing
> it one message per found typo?

There are a few, but most are inactive.  Still, reporting each typo is
fine.

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

iEYEARECAAYFAkvof8kACgkQN9GcIYhpnLCzmgCeIiWoSLPX3nA0TTWmK6fuAPMZ
1FEAoKEkYwhwL1glnF8ppbrJRnbETqC8
=JgXw
-----END PGP SIGNATURE-----

From report at bugs.python.org  Tue May 11 13:13:56 2010
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 11 May 2010 11:13:56 +0000
Subject: [docs] [issue8686] "This isn't defined beyond that" phrase is not
	friendly	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/library/difflib.html#difflib.SequenceMatcher.quick_ratio
> This isn?t defined beyond that it is an upper bound on ratio(), and is faster to compute.

"beyond" is a bit confusing because it also means "over" and this
sentence refers upper bound.

I think "This isn't defined in detail more than..." is easier.

----------
assignee: docs at python
components: Documentation
messages: 105498
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: "This isn't defined beyond that" phrase is not friendly to non-native English speakers.
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue May 11 15:05:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 May 2010 13:05:20 +0000
Subject: [docs] [issue8686] "This isn't defined beyond that" phrase is not
	friendly	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273583118.96.0.705974847714.issue8686@psf.upfronthosting.co.za>


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

Unfortunately that wouldn't be correct English, as far as I know.

How about "This isn't defined other than that..."  I think that reads a bit more clearly than "beyond that" even to a native speaker, even though beyond is valid in this context.

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

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

From report at bugs.python.org  Tue May 11 15:05:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 May 2010 13:05:32 +0000
Subject: [docs] [issue8686] "This isn't defined beyond that" phrase is not
	friendly	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273583132.66.0.0556267091874.issue8686@psf.upfronthosting.co.za>


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


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

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

From yanchaowang at gmail.com  Tue May 11 12:38:10 2010
From: yanchaowang at gmail.com (WANG Yanchao)
Date: Tue, 11 May 2010 18:38:10 +0800
Subject: [docs] Bug in Python xml document
Message-ID: <AANLkTikiDh1ZzBcWf5GP_09IzrRi4La9Pk4pw04w3bKG@mail.gmail.com>

http://docs.python.org/library/xml.dom.html#attr-objects

Attr.value should be added here. I know this may be a common knowledge, but
for a new learner, it may be confusing.

Thanks!
Yanchao WANG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100511/7ddd58d4/attachment.html>

From report at bugs.python.org  Tue May 11 22:21:19 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 May 2010 20:21:19 +0000
Subject: [docs] [issue8691] Doc: left alignment is not the default for
	numbers
In-Reply-To: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>
Message-ID: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>


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

As reported on python-list by Alan G Isaac,
Lib Ref 6.1.3.1. Format Specification Mini-Language, for instance
http://docs.python.org/dev/py3k/library/string.html#formatstrings

wrongly says in the alignment section

"'<' 	Forces the field to be left-aligned within the available space (This is the default.)"

This latter, of course, is not true for number fields.

"(This is the default.)" could be replaced by "(the string default)."
(in any case, the '.' should be outside the () unless one is added after 'space' before '(') and "(the number default)" added to the next line. Or instead the issue of defaults could be addressed in the text below the table.

I am assuming that this issue affects 2.6/7.

----------
assignee: docs at python
components: Documentation
messages: 105536
nosy: docs at python, tjreedy
priority: normal
severity: normal
status: open
title: Doc: left alignment is not the default for numbers
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From fdrake at acm.org  Wed May 12 04:30:10 2010
From: fdrake at acm.org (Fred Drake)
Date: Tue, 11 May 2010 22:30:10 -0400
Subject: [docs] Bug in Python xml document
In-Reply-To: <AANLkTikiDh1ZzBcWf5GP_09IzrRi4La9Pk4pw04w3bKG@mail.gmail.com>
References: <AANLkTikiDh1ZzBcWf5GP_09IzrRi4La9Pk4pw04w3bKG@mail.gmail.com>
Message-ID: <AANLkTilIZb-XCgkZpN494cEnwrme8u7dJYI6gIkGFBgd@mail.gmail.com>

On Tue, May 11, 2010 at 6:38 AM, WANG Yanchao <yanchaowang at gmail.com> wrote:
> Attr.value should be added here. I know this may be a common knowledge, but
> for a new learner, it may be confusing.

This addition has been made in our sources, and will be included in the future.

Thanks!


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From report at bugs.python.org  Wed May 12 08:14:32 2010
From: report at bugs.python.org (Nathan Phillip Brink)
Date: Wed, 12 May 2010 06:14:32 +0000
Subject: [docs] [issue8694] python3 FAQ mentions unicode()
In-Reply-To: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>
Message-ID: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>


New submission from Nathan Phillip Brink <ohnobinki at ohnopublishing.net>:

http://docs.python.org/py3k/faq/programming.html#what-does-unicodeerror-ascii-decoding-encoding-error-ordinal-not-in-range-128-mean

When I try to use unicode() from within python3, the call fails. I would actually expect that the FAQ should contain more information concerning the merging of the unicode and str classes. It would be nice if, when this FAQ entry is updated, there is a short discussion on making the code compatible with both python2 and python3, as it appears that's the only way python3 adaption will ever happen.

----------
assignee: docs at python
components: Documentation
messages: 105574
nosy: docs at python, ohnobinki
priority: normal
severity: normal
status: open
title: python3 FAQ mentions unicode()
versions: Python 3.1

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

From report at bugs.python.org  Wed May 12 15:13:46 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 12 May 2010 13:13:46 +0000
Subject: [docs] [issue8686] "This isn't defined beyond that" phrase is not
	friendly	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273670026.29.0.239010935767.issue8686@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

How about just dropping those words entirely, and writing "Return an approximate upper bound on ratio() very quickly.  This is not as accurate as ratio(), but is faster to compute."  (We'd make similar changes to real_quick_ratio()'s text.)

----------
nosy: +akuchling

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

From report at bugs.python.org  Wed May 12 22:11:06 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 12 May 2010 20:11:06 +0000
Subject: [docs] [issue8694] python3 FAQ mentions unicode()
In-Reply-To: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>
Message-ID: <1273695066.94.0.614719820578.issue8694@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed May 12 22:21:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 May 2010 20:21:16 +0000
Subject: [docs] [issue8686] "This isn't defined beyond that" phrase is not
	friendly	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273695676.55.0.568331156592.issue8686@psf.upfronthosting.co.za>


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

I think it's important to note that this may err towards larger numbers (rather than being merely inaccurate).

I also find this "an upper bound on ratio()" difficult to understand. IIUC, it is the correct value being bounded, not the result of the function under discussion that is bounded (by the correct value).

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

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

From report at bugs.python.org  Wed May 12 22:42:25 2010
From: report at bugs.python.org (Tim Peters)
Date: Wed, 12 May 2010 20:42:25 +0000
Subject: [docs] [issue8686] "This isn't defined beyond that" phrase is not
	friendly	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273696945.68.0.627673850359.issue8686@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

I find this whole discussion to be hilarious ;-)

"Approximate upper bound" is gibberish - "upper bound" is a crisp concept that means what it says.  It's not necessarily true that an upper bound is inaccurate - it may be exactly right.  So "this is not as accurate as ratio()" overstates the case.

"quick_ratio() returns an upper bound on what ratio() returns" is the truth, and can't be improved by adding more words.   Appealing to a "correct" result would also be misleading (what ratio() returns is a more-or-less arbitrary computation whose only claim to "correctness" is that ratio() returns what it's documented to return).

If people find the gloss in the docs confusing, remove the gloss entirely, leaving just the correct:

"Return an upper bound on ratio() relatively quickly."

----------
nosy: +tim_one

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

From report at bugs.python.org  Thu May 13 03:10:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:10:37 +0000
Subject: [docs] [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1273713037.75.0.0154648426703.issue8649@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May 13 03:10:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:10:44 +0000
Subject: [docs] [issue8648] The UTF-7 codec functions are undocumented
In-Reply-To: <1273248636.7.0.217932609429.issue8648@psf.upfronthosting.co.za>
Message-ID: <1273713044.08.0.16921404455.issue8648@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May 13 03:10:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:10:50 +0000
Subject: [docs] [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1273713050.3.0.795828714094.issue8647@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May 13 03:10:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:10:56 +0000
Subject: [docs] [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1273713056.45.0.468547582924.issue8646@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May 13 03:11:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 May 2010 01:11:03 +0000
Subject: [docs] [issue8645] PyUnicode_AsEncodedObject is undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1273713063.13.0.614744628982.issue8645@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May 13 12:16:16 2010
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 13 May 2010 10:16:16 +0000
Subject: [docs] [issue8703] Py3k PyList_Type documentation mentions
	types.ListType
In-Reply-To: <1273745776.41.0.112445145635.issue8703@psf.upfronthosting.co.za>
Message-ID: <1273745776.41.0.112445145635.issue8703@psf.upfronthosting.co.za>


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

The Py3k documentation of PyList_Type [1] contains the sentence:
"This is the same object as list and types.ListType in the Python layer."
But there is no types.ListType object in py3k.

[1] http://docs.python.org/dev/py3k/c-api/list.html#PyList_Type

----------
assignee: docs at python
components: Documentation
messages: 105631
nosy: docs at python, durban
priority: normal
severity: normal
status: open
title: Py3k PyList_Type documentation mentions types.ListType
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May 13 23:14:40 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 May 2010 21:14:40 +0000
Subject: [docs] [issue8703] Py3k PyList_Type documentation mentions
	types.ListType
In-Reply-To: <1273745776.41.0.112445145635.issue8703@psf.upfronthosting.co.za>
Message-ID: <1273785279.71.0.995468130569.issue8703@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r81145. Thanks.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri May 14 01:36:31 2010
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 13 May 2010 23:36:31 +0000
Subject: [docs] [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/dev/library/telnetlib.html#telnetlib.Telnet

The part "number can be passed to the constructor... " is duplicated.

----------
assignee: docs at python
components: Documentation
messages: 105667
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Duplicated document in telnetlib.
versions: Python 2.7

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

From report at bugs.python.org  Fri May 14 02:43:13 2010
From: report at bugs.python.org (Jack Diederich)
Date: Fri, 14 May 2010 00:43:13 +0000
Subject: [docs] [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1273797793.01.0.869966214099.issue8707@psf.upfronthosting.co.za>


Changes by Jack Diederich <jackdied at gmail.com>:


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

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

From report at bugs.python.org  Fri May 14 09:43:15 2010
From: report at bugs.python.org (akira)
Date: Fri, 14 May 2010 07:43:15 +0000
Subject: [docs] [issue8709] mention explicitly Windows support for os.devnull
In-Reply-To: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>
Message-ID: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>


New submission from akira <4kir4.1i at gmail.com>:

Currently it is not obvious that os.devnull works on Windows.

----------
assignee: docs at python
components: Documentation
files: doc-os-devnull-windows-r81160.diff
keywords: patch
messages: 105688
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: mention explicitly Windows support for os.devnull
type: feature request
Added file: http://bugs.python.org/file17331/doc-os-devnull-windows-r81160.diff

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

From report at bugs.python.org  Fri May 14 14:26:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 12:26:24 +0000
Subject: [docs] [issue8709] mention explicitly Windows support for os.devnull
In-Reply-To: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>
Message-ID: <1273839984.6.0.607759371762.issue8709@psf.upfronthosting.co.za>


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

If there?s no note stating some object is only available on one platform, then it?s available for all. That said, for this case I agree with your patch.

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

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

From report at bugs.python.org  Fri May 14 15:34:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 13:34:16 +0000
Subject: [docs] [issue8711] Document PyUnicode_DecodeFSDefault()
	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>


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

Attached patch document PyUnicode_DecodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize() in Doc/c-api/, and fix comment in Include/unicodeobject.c (remove reference to bytearray, and specify that surrogateescape is used).

The patch adds also titles to group unicode functions and methods by topic.

----------
assignee: docs at python
components: Documentation, Unicode
files: unicode_doc.patch
keywords: patch
messages: 105706
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Document PyUnicode_DecodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize()
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17336/unicode_doc.patch

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

From report at bugs.python.org  Fri May 14 15:48:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 13:48:41 +0000
Subject: [docs] [issue8711]
	Document	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <4BED54B4.8030507@netwok.org>


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

The bulk of the patch seems good to me, with some minor remarks:
- You haven?t used title case consistently in all section titles.
- I?d just say ?wchar_t Support? in a title, deleting ?for platforms
which support it?.
- You could mark up ?bytes? so that users get a link.
- The verb form of ?fall back? is in two words, unless I?m lagging on
current technical English.
- You lack an article when saying ?the "surrogateescape" error handler?.
- Not sure: Is it better to say ?for encoding x, use y? or ?to encode x,
use y??

Sorry for not giving precise line numbers or a diff of a diff, that
wouldn?t be practical.

----------
nosy: +merwok
title: Document PyUnicode_DecodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize() -> Document PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()

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

From report at bugs.python.org  Fri May 14 16:45:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 May 2010 14:45:47 +0000
Subject: [docs] [issue8711]
	Document	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <1273848346.92.0.661096130405.issue8711@psf.upfronthosting.co.za>


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

> Is it better to say ?for encoding x, use y? or ?to encode x,
> use y??

The latter, IMO. "Encoding" is also a noun.

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

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

From report at bugs.python.org  Fri May 14 16:55:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 14:55:52 +0000
Subject: [docs]
	[issue8711]	Document	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273848346.92.0.661096130405.issue8711@psf.upfronthosting.co.za>
Message-ID: <4BED6475.20204@netwok.org>


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

In this case, it was a verb (a gerund form).

----------
title: Document PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize() -> Document	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()

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

From report at bugs.python.org  Fri May 14 17:08:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 15:08:01 +0000
Subject: [docs]
	[issue8711]	Document	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <1273849680.47.0.297308054054.issue8711@psf.upfronthosting.co.za>


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

Thanks for your remarks: updated patch.

----------
Added file: http://bugs.python.org/file17339/unicode_doc-2.patch

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

From report at bugs.python.org  Fri May 14 18:09:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 May 2010 16:09:08 +0000
Subject: [docs]
	[issue8711]	Document	PyUnicode_DecodeFSDefault()	and	PyUnicode_DecodeFSDefaultAndSize()
In-Reply-To: <1273844056.41.0.804262105587.issue8711@psf.upfronthosting.co.za>
Message-ID: <1273853348.22.0.55510763748.issue8711@psf.upfronthosting.co.za>


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

Commited: r81168 (py3k), r81169 (3.1).

I also added the paragraph titles to Python2: r81166 (trunk) and r81167 (2.6).

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

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

From merwok at netwok.org  Fri May 14 19:08:04 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 14 May 2010 19:08:04 +0200
Subject: [docs] Typo in callable doc
Message-ID: <4BED8374.6050800@netwok.org>

Hello

Revision 77096 fixed a bug in Doc/library/2to3.rst by changing
?hasattr(x, "__call_")? to ?isinstance(x, collections.Callable)?.
However, in the 2.6 documentation still visible at docs.python.org, the
incorrect ?__call_? is still present.

Regards

From report at bugs.python.org  Fri May 14 20:11:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 18:11:13 +0000
Subject: [docs] [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1273860673.21.0.8043945279.issue8649@psf.upfronthosting.co.za>


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

If, for this and your previous two issues, you could add a suggestion as to precisely where you would make an addition and what minimally adequate text you would add (even unformatted ascii text in a message) that is consistent with surrounding style, action would likely happen sooner.

----------
nosy: +tjreedy

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

From report at bugs.python.org  Fri May 14 21:11:01 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 19:11:01 +0000
Subject: [docs] [issue8686] "This isn't defined beyond that" phrase is not
	friendly	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273864261.18.0.236753697541.issue8686@psf.upfronthosting.co.za>


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

I agree with Tim. Drop the zero-info glosses. For real_quick_ratio(),
    "Return an upper bound on ratio() even more quickly."
should be sufficient (assuming that it *is* always quicker.

Just curious, The descriptions say ratio() <= quick_ratio() and ratio() <= very_quick_ratio. is it also guaranteed that quick_ratio() <= real_quick_ratio()? Or might one 'luck out' with a better answer from the faster method? (I can imagine either being true.)

----------
nosy: +tjreedy

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

From report at bugs.python.org  Fri May 14 21:17:10 2010
From: report at bugs.python.org (Tim Peters)
Date: Fri, 14 May 2010 19:17:10 +0000
Subject: [docs] [issue8686] "This isn't defined beyond that" phrase is not
	friendly	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1273864630.36.0.95117924796.issue8686@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Terry asks:

> is it also guaranteed that quick_ratio() <= real_quick_ratio()

Nope!  The docs don't say that, so it's not guaranteed.

It's not the _intent_ of the code that it be true, either.  The only point to quick_ratio() and real_quick_ratio() is speed.

----------

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

From report at bugs.python.org  Fri May 14 21:28:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 19:28:12 +0000
Subject: [docs] [issue8652] Minor improvements to the "Handling Exceptions"
	part of	the tutorial
In-Reply-To: <1273253134.08.0.147248211976.issue8652@psf.upfronthosting.co.za>
Message-ID: <1273865292.06.0.345590004997.issue8652@psf.upfronthosting.co.za>


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

The older exception catching syntax should not be promoted but could be mentioned, I agree. Adding a paragraph explaining why it was changed would do the trick.

Regarding the non-obviousness of which Python version the docs apply to, it is indeed mentioned on the front page of the docs, and repeated in the top-left corner of each page. You could propose making it bigger. Another way of doing this would be to have the page redirect to a URI that includes the version. That way, there would be another place to look for the version, and it would also make it easier to find out how to find the doc for other versions.

Last, exception unpacking being deprecated (because it?s horrible) and causing pain to newcomers seems a good reason to shot it down. Perhaps we should leave a short note about it, for people that get strange errors when using it inadvertently (or not getting an error where they thought they would).

I suggest you wait some more days for feedback from people with more experience with the docs. Sorry if my English was a bit convoluted :)

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

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

From report at bugs.python.org  Fri May 14 21:34:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 19:34:34 +0000
Subject: [docs] [issue8694] python3 FAQ mentions unicode()
In-Reply-To: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>
Message-ID: <1273865674.33.0.60735603335.issue8694@psf.upfronthosting.co.za>


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

Yes, the faq entry has example code like
 "value = unicode(value, "utf-8")"
This whole section now applies when 'value' is a bytes or bytearray object and one calls str(value).

For portability, one should in 2.6/7 use unicode strings as much as possible and the bytes and unicode functions but not the str function. Then 2to3.py will change 'unicode' to 'str'. This should be a separate FAQ entry (if not already), for both 2.x and 3.x, with more complete advice from MLV (from whom I am parroting the above).

----------
nosy: +tjreedy

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

From report at bugs.python.org  Fri May 14 21:47:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 19:47:28 +0000
Subject: [docs] [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1273866448.01.0.383023826006.issue8707@psf.upfronthosting.co.za>


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

Which is to say, the entire second paragraph beginning with 'number' should be deleted.  The same is true for 2.6, where it is also section 20.14, 3.1 (20.17), and 3.2 (19.17). Good catch. Thanks for reporting.

----------
keywords: +easy
nosy: +tjreedy
versions: +Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri May 14 22:01:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 20:01:47 +0000
Subject: [docs] [issue8709] mention explicitly Windows support for os.devnull
In-Reply-To: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>
Message-ID: <1273867307.24.0.45248446466.issue8709@psf.upfronthosting.co.za>


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

Given the mention of the posix example, I agree. The issue applies to 2.6 and 3.2 (that I checked) and so I assume to 2.7 and 3.1 also.

There is no doc string for devnull, which I presume should be in ntpath.

>>> help(os.devnull)
no Python documentation found for 'nul'

If this is a singular omission (as opposed to a general lack in that module), you might expand the patch to remedy that also.

----------
nosy: +tjreedy
stage:  -> commit review
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri May 14 22:03:37 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 May 2010 20:03:37 +0000
Subject: [docs] [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1273867417.42.0.852856939048.issue8649@psf.upfronthosting.co.za>


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


----------
versions: +Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri May 14 22:04:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 May 2010 20:04:25 +0000
Subject: [docs] [issue8709] mention explicitly Windows support for os.devnull
In-Reply-To: <1273867307.24.0.45248446466.issue8709@psf.upfronthosting.co.za>
Message-ID: <4BEDACC5.9090307@netwok.org>


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

os.devnull is a string, so ?pydoc os.devnull? will tell you about
strings, and ?help(os.devnull)? will be evaluated to
?help('/dev/null')? which won?t match any topic. Same thing with os.sep
and other module data; the doc is in the module?s docstring.

----------

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

From merwok at netwok.org  Fri May 14 22:10:46 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 14 May 2010 22:10:46 +0200
Subject: [docs] Move some modules in the library ToC
Message-ID: <4BEDAE46.4050501@netwok.org>

Hi

I suggest moving the index entries about argparse, optparse and logging
from the catch-all and slightly obscure ?Generic Operating System
Services? heading to ?Program Frameworks?.

I can open a bug and attach a patch if people are +1.

Regards

From report at bugs.python.org  Sat May 15 06:10:59 2010
From: report at bugs.python.org (Paul Davis)
Date: Sat, 15 May 2010 04:10:59 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>


New submission from Paul Davis <paul.joseph.davis at gmail.com>:

The docs for __getattr__ in the object model section could be more specific on the behavior when a @property raises an AttributeError and there is a custom __getattr__ defined. Specifically, it wasn't exactly clear that __getattr__ would be invoked after a @property was found and evaluated.

The attached script demonstrates the issue on OS X 10.6, Python 2.6.1

I'm thinking something along the lines of:

If the attribute search encounters an AttributeError (perhaps due to a @property raising the error) the search is considered a failure and __getattr__ is invoked.

----------
assignee: docs at python
components: Documentation
files: example.py
messages: 105790
nosy: Paul.Davis, docs at python
priority: normal
severity: normal
status: open
title: Documentation for __getattr__
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file17349/example.py

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

From report at bugs.python.org  Sat May 15 06:13:34 2010
From: report at bugs.python.org (Paul Davis)
Date: Sat, 15 May 2010 04:13:34 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1273896813.99.0.937519179401.issue8722@psf.upfronthosting.co.za>


Paul Davis <paul.joseph.davis at gmail.com> added the comment:

I should mention, in example.py, it wasn't immediately clear that "print f.bing" would actually print instead of raising the AttributeError. As in, I had a property raising an unexpected error that happend to be an AttributeError. If its not an attribute error, the error is not swallowed. I can see the obvious argument for "AttributeError means not found", it just wasn't immediately obvious what was going on.

----------

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

From report at bugs.python.org  Sat May 15 14:22:47 2010
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 15 May 2010 12:22:47 +0000
Subject: [docs] [issue8724] bind_and_activate parameter is missed from
	directive
In-Reply-To: <1273926127.04.0.976754673926.issue8724@psf.upfronthosting.co.za>
Message-ID: <1273926167.11.0.988156104857.issue8724@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


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

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

From techtonik at gmail.com  Sun May 16 10:24:14 2010
From: techtonik at gmail.com (techtonik)
Date: Sun, 16 May 2010 11:24:14 +0300
Subject: [docs] Move some modules in the library ToC
In-Reply-To: <4BEDAE46.4050501@netwok.org>
References: <4BEDAE46.4050501@netwok.org>
Message-ID: <AANLkTimHWpTkNZxnVbz8XwslkqYN2Dyrq0_8pNkBBdxV@mail.gmail.com>

On Fri, May 14, 2010 at 11:10 PM, ?ric Araujo <merwok at netwok.org> wrote:
>
> I suggest moving the index entries about argparse, optparse and logging
> from the catch-all and slightly obscure ?Generic Operating System
> Services? heading to ?Program Frameworks?.
>
> I can open a bug and attach a patch if people are +1.

Argparse and optparse are in fact interfaces for OS command line
services. I can't see how could they be used without it. Cmd2 could be
called "Program Framework", but it is not in stdlib as far as I know.
And "Program Framework" sounds too abstract and obscure. Is Django a
"Program Framework", abc module? I would keep it low level. Logging is
more development tool than OS. I would prefer something like
"Application Tools" or "Application Units". Wherever they are, I never
knew where - the only logical layout I can remember was in Python
Cookbook.

-- 
anatoly t.

From report at bugs.python.org  Sun May 16 16:16:30 2010
From: report at bugs.python.org (Dave Abrahams)
Date: Sun, 16 May 2010 14:16:30 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1274019390.25.0.838979515547.issue8557@psf.upfronthosting.co.za>


Dave Abrahams <dave at boostpro.com> added the comment:

New data point: in some contexts on Windows (not sure of the exact cause but I was dealing with multiple drives), even this workaround isn't enough.  I ended up having to do something like this (i.e. manually search the path) on win32:


    def full_executable_path(invoked, environ):

        if os.path.splitext(invoked)[1]:
            return invoked
        
        explicit_dir = os.path.dirname(invoked)

        if explicit_dir:
            path = [ explicit_dir ]
        else:
            path = environ.get('PATH').split(os.path.pathsep)

        extensions = environ.get(
            'PATHEXT',
            # Use *something* in case the environment variable is
            # empty.  These come from my machine's defaults
            '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1'
            ).split(os.path.pathsep)

        for dir in path:
            for ext in extensions:
                full_path = os.path.join(dir, invoked+ext)
                if os.path.exists( full_path ):
                    return full_path

        return invoked # Not found; invoking it will likely fail

    class Popen(subprocess.Popen):
        def __init__(
            self, args, bufsize=0, executable=None,
            stdin=None, stdout=None, stderr=None,
            preexec_fn=None, close_fds=False, shell=False, 
            cwd=None, env=None, 
            *args_, **kw):

            if executable is None and not shell:
                executable = full_executable_path(args[0], env or os.environ)

            super(Popen,self).__init__(
                args, bufsize, executable, stdin, stdout, stderr, 
                preexec_fn, close_fds, shell, cwd, env, *args_, **kw)

----------

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

From report at bugs.python.org  Sun May 16 21:23:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 16 May 2010 19:23:07 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1274037787.83.0.251276375314.issue6916@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/issue6916>
_______________________________________

From songofacandy at gmail.com  Thu May 13 04:49:48 2010
From: songofacandy at gmail.com (INADA Naoki)
Date: Thu, 13 May 2010 11:49:48 +0900
Subject: [docs] Typo in urllib2
Message-ID: <AANLkTimQ3sA5eOKliFEYHDCE2Qb7gj1dqHiwYyXtanep@mail.gmail.com>

I've found typo in urllib2. But bugs.python.org is down now.

http://docs.python.org/dev/library/urllib2.html#urllib2.OpenerDirector.open

-(if not specified, the global default timeout setting will be usedi).
+(if not specified, the global default timeout setting will be used).

# extra 'i'


-- 
INADA Naoki  <songofacandy at gmail.com>

From Denis.Gorbachev at trueoffice.ru  Thu May 13 14:14:52 2010
From: Denis.Gorbachev at trueoffice.ru (=?UTF-8?B?0JTQtdC90LjRgSDQk9C+0YDQsdCw0YfQtdCy?=)
Date: Thu, 13 May 2010 16:14:52 +0400
Subject: [docs] A documentation glitch
Message-ID: <AANLkTikyfmgZ441HyJTBdEe56lU26tkp2DFeJmo9Lgbe@mail.gmail.com>

Page in question:
http://docs.python.org/py3k/tutorial/datastructures.html#sets

>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']

>>> fruit = set(basket)               # create a set without duplicates

Should be

>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']

>>> fruit = set(*fruit*)               # create a set without duplicates

as the intention is to show how to create a set without duplicates from a list.

-- 
????? ????????,
????????? ?????? Web-?????????? ??? <<???????>>
http://www.trueoffice.ru/
+7 929 619-35-88
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100513/08b97c3f/attachment-0001.html>

From George.Komorowski at energyeast.com  Thu May 13 17:12:17 2010
From: George.Komorowski at energyeast.com (Komorowski, George)
Date: Thu, 13 May 2010 11:12:17 -0400
Subject: [docs] Bad link in document
Message-ID: <246941143BE97547ACBA665190BC74FD1F63269E4D@EEROCH1CMS2.Energyeast.net>

The link to the Apple website is broken. The current PDF file at Apple website has 2009 in file name

the Apple Publications Style Guide wherever

Documenting Python
Release 3.1.2
Georg Brandl
March 20, 2010
[cid:image001.jpg at 01CAF28D.27E6D430]

George Komorowski
IT Service Desk

Iberdrola USA Management Corporation
400 West Ave, Rochester, NY 14611
800-646-3850 Service Desk
585-771-4374 Direct
George.Komorowski at EnergyEast.com


[cid:image002.jpg at 01CAF28D.27E6D430]


In the interest of the environment,
please print only if necessary and recycle.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100513/04d7a3b7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 34818 bytes
Desc: image001.jpg
URL: <http://mail.python.org/pipermail/docs/attachments/20100513/04d7a3b7/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 930 bytes
Desc: image002.jpg
URL: <http://mail.python.org/pipermail/docs/attachments/20100513/04d7a3b7/attachment-0003.jpg>

From andrewtrusty at gmail.com  Fri May 14 03:33:49 2010
From: andrewtrusty at gmail.com (Andrew Trusty)
Date: Thu, 13 May 2010 21:33:49 -0400
Subject: [docs] Python 2.6.5 threading.Event.wait()
Message-ID: <o2iaed5e73f1005131833rb9d1be00tc6d8478f467796ee@mail.gmail.com>

Just spent a couple hours debugging some code because the
threading.Event.wait() documentation said it returned the internal
flag when it always returns None.  I just noticed that there is an
addendum that says this was behavior that was changed in 2.7 but since
these are the 2.6.5 docs it would be a lot less confusing if it first
said that it always returns None and then said that in 2.7 it will
return the internal flag.

http://docs.python.org/library/threading.html#threading.Event.wait

Andrew

From summer at js.id.au  Sat May 15 18:40:14 2010
From: summer at js.id.au (John Summerfield)
Date: Sun, 16 May 2010 00:40:14 +0800
Subject: [docs] cursing curses in python 3.1
Message-ID: <4BEECE6E.7080403@js.id.au>

First, we will deal with spammers. You do not have permission to store 
this email in a public space unless my email address is expunged.

I am learning Python, and my references are Mark Summerfield's book on 
Python 3.0 and what I can find on the Internet.

I know little C, and have no prior experience of curses. I do remember 
Turbo Pascal, with Turbo Vision, fondly, it allowed one to write 
text-based applications with hot keys, buttons, menus etc, and all with 
the use of the mouse.

I am finding the documentation I find (when google turns up the right 
release - it tends to find earlier releases, even at python.org) is 
incomplete and/or lacks clarity regarding the use of the mouse.

I am using Python 3.1 on Debian Still In Development, on a Linux console 
and but for my wish to use the mouse, it would be in screen. I'm also 
using gpm.

There might be room for argument as to whether any of these problems 
might be to do with the python/curses rather than its documentation.

Here is the reference document:
http://docs.python.org/py3k/library/curses.html


The first problems I had is that, when I enabled the mouse using 
curses.mousemask(), I could not see what mask to use so I tried -1. This 
did not work, so I hunted further and eventually hit upon 
ALL_MOUSE_EVENTS. That didn't work differently.

What happened is that my first getch() returned curses.KEY_MOUSE. When I 
used curses.getmouse() to find what happened, it raised an exception.

I don't know what exception it raised, so I cannot selectively catch it. 
It might be curses.error, I hit on that after reading some source code 
(really!) and guessing. Anyway, that's what I'm catching.

The error message being returned is ERR. I don't have the foggiest idea 
what that means (except something didn't work), and the documentation 
does not help me resolve the problem.

Eventually, I tried it directly on a console and discovered, on a Linux 
console, it works. For diagnostic purposes, connected to localhost using 
ssh. It doesn't work through ssh either.

I then tried to find a method to see whether I have a working mouse 
(curses.has_mouse() perhaps?)

The crude hack I implemented is to, first, enable mouse events as above, 
and then if that errors, I disable them again.

I would like to see the documentation updated to reflect the 
circumstances where curses' mouse support does not work, and the 
recommended way to discover whether there is a functional mouse at all.

Had getch() not returned KEY_MOUSE, I would hardly have been better off, 
I would have clicked the mouse and had nothing happen. Which leads me to 
the next problem.

Having sorted that our, and having debugging messages popping out 
whenever I clicked the mouse, I set about creating some code to 
distinguish mouse events.

Of course, the first thing I wanted was code that would correctly 
identify when I clicked a button, and which one it was. The first part 
is easy, in fact, I already had that working. The second part was not. I 
printed out, in hex, the button state, but with no documentation that I 
could find, it was difficult matching the values I saw printed with the 
names in the web page.

I clicked the mouse buttons, repeatedly, and saw the events being 
reported by my debugging code. However, the names I found, such as 
BUTTON1_CLICKED did not match what I saw with my eyes. More debugging 
code, and I find matches with PRESS and RELEASE. Never a CLICK.

This behaviour needs to be documented, as does the question of how it 
works in, say, xterm. Is it different? I don't have X installed on Sid, 
nor python3 on anything that has.

The binary values of the constants' names also need to be documented; if 
they vary between platforms (I think I read that they do), then in the 
packaged documentation.


I also had some difficulty with curses windows on my Linux console. I 
discovered there were some things I needed to do before I could define a 
scrollable area or scroll the screen. I am not sure that all of the 
things I did are necessary.

I would like to see the page improved with examples of the calls needed 
to prepare a screen for curses, for creating windows, for scrolling 
areas of the windows, and of the use of the mouse. I don't propose 
turning the page into a tutorial, just some basic examples (similar to 
those in the man pages for mawk and gawk) would have saved me hours of 
time and frustration.

-- 
John Summerfield


From report at bugs.python.org  Mon May 17 19:59:02 2010
From: report at bugs.python.org (Patrick Sabin)
Date: Mon, 17 May 2010 17:59:02 +0000
Subject: [docs] [issue8742] broken asdl link in Parser/asdl.py
In-Reply-To: <1274119142.14.0.911032413553.issue8742@psf.upfronthosting.co.za>
Message-ID: <1274119142.14.0.911032413553.issue8742@psf.upfronthosting.co.za>


New submission from Patrick Sabin <patricksabin at gmx.at>:

The link:
http://www.cs.princeton.edu/~danwang/Papers/dsl97/dsl97-abstract.html
in the file Parser/asdl.py seems to be broken. When I tried to open it I got a page with: "Sorry, the page you requested couldn't be found". It seems to me that this is a permanent issue and therefore the link should be removed as there is another link, that works.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 105923
nosy: docs at python, pyfex
priority: normal
severity: normal
status: open
title: broken asdl link in Parser/asdl.py

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

From report at bugs.python.org  Mon May 17 20:01:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 May 2010 18:01:11 +0000
Subject: [docs] [issue8742] broken asdl link in Parser/asdl.py
In-Reply-To: <1274119142.14.0.911032413553.issue8742@psf.upfronthosting.co.za>
Message-ID: <1274119271.16.0.439040936967.issue8742@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/issue8742>
_______________________________________

From report at bugs.python.org  Tue May 18 03:26:26 2010
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 18 May 2010 01:26:26 +0000
Subject: [docs] [issue8744] Maybe typo in doc
In-Reply-To: <1274145985.81.0.735711702514.issue8744@psf.upfronthosting.co.za>
Message-ID: <1274145985.81.0.735711702514.issue8744@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/dev/library/test.html#test.test_support.captured_stdout

"This is a context manager than runs the with statement body using a StringIO.StringIO object as sys.stdout."

I think "than" is typo of "that".

----------
assignee: docs at python
components: Documentation
messages: 105946
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Maybe typo in doc
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue May 18 05:29:14 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 03:29:14 +0000
Subject: [docs] [issue8744] Maybe typo in doc
In-Reply-To: <1274145985.81.0.735711702514.issue8744@psf.upfronthosting.co.za>
Message-ID: <20100518032902.GA2282@remy>


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

Fixed it in revision 81279 and other branches.

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

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

From report at bugs.python.org  Tue May 18 05:29:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 03:29:55 +0000
Subject: [docs] [issue8744] Maybe typo in doc
In-Reply-To: <1274145985.81.0.735711702514.issue8744@psf.upfronthosting.co.za>
Message-ID: <1274153395.26.0.116634586426.issue8744@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


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

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

From report at bugs.python.org  Tue May 18 05:38:49 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 03:38:49 +0000
Subject: [docs] [issue8619] Doc bug for urllib.request._urlopener in Python
	3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1274153928.76.0.330353932072.issue8619@psf.upfronthosting.co.za>


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

The functionality provided by urllib.request._urlopener can be accomplished in a more natural way using build_opener. Historically, _urlopener was there for urllib and build_opener style came in urllib2.

So, I think, this can be safely be removed from the docs considering David's suggestion that its better not to advertise _methods in the docs.

----------

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

From report at bugs.python.org  Tue May 18 05:56:07 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 03:56:07 +0000
Subject: [docs] [issue8619] Doc bug for urllib.request._urlopener in Python
	3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1274154967.69.0.985592909328.issue8619@psf.upfronthosting.co.za>


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

Actually, I see certain use-cases of _urlopener in py3k. Most visible one being urllib.request.urlretrieve and also URLOpener.open which is different from build_opener way of doing things.

- But still, public exposure of overriding globals to can be removed. There is no harm in the functionality. In py3k, users should resort to build_opener style of doing than use FancyURLOpener or URLOpener which are present for backward compatibility reasons only.

----------

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

From report at bugs.python.org  Tue May 18 06:07:12 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 04:07:12 +0000
Subject: [docs] [issue8619] Doc bug for urllib.request._urlopener in Python
	3.1+
In-Reply-To: <1273030983.81.0.163471104029.issue8619@psf.upfronthosting.co.za>
Message-ID: <1274155632.35.0.125267964152.issue8619@psf.upfronthosting.co.za>


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

Removed in r81283 and r81284.
With respect to the technical details of exposing this functionality for _urlretrieve and URLOpener.
- users can still do it.
- There is a better way, if the other global _opener be served for the same purpose, so that build_opener can be used. There is TODO mentioned in the code, let me see if it can be accomplished without any problem.

----------

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

From report at bugs.python.org  Tue May 18 15:45:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 18 May 2010 13:45:55 +0000
Subject: [docs] [issue8742] broken asdl link in Parser/asdl.py
In-Reply-To: <1274119142.14.0.911032413553.issue8742@psf.upfronthosting.co.za>
Message-ID: <1274190355.47.0.343554353542.issue8742@psf.upfronthosting.co.za>


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

Here is the proper link:
http://www.cs.princeton.edu/research/techreps/TR-554-97

Fixed those references in the code too.

----------
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed May 19 06:18:29 2010
From: report at bugs.python.org (Evelyn Mitchell)
Date: Wed, 19 May 2010 04:18:29 +0000
Subject: [docs] [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1274242708.86.0.829513650778.issue8707@psf.upfronthosting.co.za>


Evelyn Mitchell <efm-pythonbugs at tummy.com> added the comment:

Fixed for 3.2 branch.

----------
keywords: +patch
nosy: +efm
Added file: http://bugs.python.org/file17394/telnetlib3.2.diff

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

From report at bugs.python.org  Wed May 19 06:19:31 2010
From: report at bugs.python.org (Evelyn Mitchell)
Date: Wed, 19 May 2010 04:19:31 +0000
Subject: [docs] [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1274242771.9.0.358507681754.issue8707@psf.upfronthosting.co.za>


Evelyn Mitchell <efm-pythonbugs at tummy.com> added the comment:

Fixed for 2.6 branch

----------
Added file: http://bugs.python.org/file17395/telnetlib2.6.diff

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

From report at bugs.python.org  Wed May 19 06:20:10 2010
From: report at bugs.python.org (Evelyn Mitchell)
Date: Wed, 19 May 2010 04:20:10 +0000
Subject: [docs] [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1274242810.49.0.852876607497.issue8707@psf.upfronthosting.co.za>


Evelyn Mitchell <efm-pythonbugs at tummy.com> added the comment:

Fixed for 2.7 branch

----------
Added file: http://bugs.python.org/file17396/telnetlib2.7.diff

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

From report at bugs.python.org  Wed May 19 06:20:47 2010
From: report at bugs.python.org (Evelyn Mitchell)
Date: Wed, 19 May 2010 04:20:47 +0000
Subject: [docs] [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1274242847.1.0.969098530855.issue8707@psf.upfronthosting.co.za>


Evelyn Mitchell <efm-pythonbugs at tummy.com> added the comment:

Fixed for 3.1 branch

----------
Added file: http://bugs.python.org/file17397/telnetlib3.1.diff

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

From report at bugs.python.org  Thu May 20 23:51:43 2010
From: report at bugs.python.org (Terrence Cole)
Date: Thu, 20 May 2010 21:51:43 +0000
Subject: [docs] [issue8778] typo in docs for
	symtable.SymbolTable.has_import_star
In-Reply-To: <1274392302.58.0.224644067181.issue8778@psf.upfronthosting.co.za>
Message-ID: <1274392302.58.0.224644067181.issue8778@psf.upfronthosting.co.za>


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

The documentation for symtable.SymbolTable [http://docs.python.org/py3k/library/symtable.html] lists the function has_import_start.  This should be has_import_star, as listed in help(symtable.SymbolTable).

I've attached a patch, although it would probably be faster for a committer to just remove the 't' themselves.

----------
assignee: docs at python
components: Documentation
files: fix-has-import-star-doc.diff
keywords: patch
messages: 106194
nosy: docs at python, terrence
priority: normal
severity: normal
status: open
title: typo in docs for symtable.SymbolTable.has_import_star
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17420/fix-has-import-star-doc.diff

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

From report at bugs.python.org  Fri May 21 00:24:04 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 20 May 2010 22:24:04 +0000
Subject: [docs] [issue8778] typo in docs for
	symtable.SymbolTable.has_import_star
In-Reply-To: <1274392302.58.0.224644067181.issue8778@psf.upfronthosting.co.za>
Message-ID: <1274394244.55.0.243007806647.issue8778@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thanks. Fixed in r81385.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri May 21 22:09:38 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 21 May 2010 20:09:38 +0000
Subject: [docs] [issue8783] The external link to a "Hash Collision FAQ"
	points to	some company's homepage
In-Reply-To: <1274472578.65.0.146372643456.issue8783@psf.upfronthosting.co.za>
Message-ID: <1274472578.65.0.146372643456.issue8783@psf.upfronthosting.co.za>


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

At the bottom of the documentation for hashlib, there's a link to
http://www.cryptography.com/cnews/hash.html

which the hashlib documentation describes as "Hash Collision FAQ with information on which algorithms have known issues and what that means regarding their use."

However, the page at that link is identical to http://www.cryptography.com/

which is just the homepage of some company that happens to deal with cryptography.  If they do in fact host a Hash Collision FAQ, I couldn't find it. :-(

Googling for "Hash Collision FAQ" (with quotes) mostly turns up references to the Python documentation, so I'm guessing the intended document no longer exists.

The following wikipedia link might be an OK substitute, although it makes for pretty dense reading.
http://en.wikipedia.org/wiki/Cryptographic_hash_function#Cryptographic_hash_algorithms

----------
assignee: docs at python
components: Documentation
messages: 106259
nosy: docs at python, stutzbach
priority: normal
severity: normal
status: open
title: The external link to a "Hash Collision FAQ" points to some company's homepage

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

From report at bugs.python.org  Fri May 21 22:25:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 20:25:50 +0000
Subject: [docs] [issue8783] The external link to a "Hash Collision FAQ"
	points to	some company's homepage
In-Reply-To: <1274472578.65.0.146372643456.issue8783@psf.upfronthosting.co.za>
Message-ID: <1274473550.7.0.695224394923.issue8783@psf.upfronthosting.co.za>


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

The FAQ can still be found in the internet archive, http://web.archive.org/web/20070928160638/http://www.cryptography.com/cnews/hash.html

but of course this is not a good link, especially because it's not updated.  I've added the link to the wikipedia article, as you suggested, in r81404.  It should be a good starting point for further research.

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

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

From report at bugs.python.org  Fri May 21 22:36:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 20:36:37 +0000
Subject: [docs] [issue8694] python3 FAQ mentions unicode()
In-Reply-To: <1273644871.8.0.754393677422.issue8694@psf.upfronthosting.co.za>
Message-ID: <1274474196.85.0.450034618478.issue8694@psf.upfronthosting.co.za>


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

This was due to a review of the programming FAQ not yet having been merged to the 3.1 branch.  Now fixed in r81407.

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

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

From report at bugs.python.org  Fri May 21 22:39:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 20:39:55 +0000
Subject: [docs] [issue8691] Doc: left alignment is not the default for
	numbers
In-Reply-To: <1273609278.89.0.493567914757.issue8691@psf.upfronthosting.co.za>
Message-ID: <1274474395.68.0.778262574436.issue8691@psf.upfronthosting.co.za>


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

Eric should know the exact semantics best.

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

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

From georg at python.org  Fri May 21 22:41:38 2010
From: georg at python.org (Georg Brandl)
Date: Fri, 21 May 2010 22:41:38 +0200
Subject: [docs] Typo in callable doc
In-Reply-To: <4BED8374.6050800@netwok.org>
References: <4BED8374.6050800@netwok.org>
Message-ID: <4BF6F002.6070000@python.org>

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

Am 14.05.2010 19:08, schrieb ?ric Araujo:
> Hello
> 
> Revision 77096 fixed a bug in Doc/library/2to3.rst by changing
> ?hasattr(x, "__call_")? to ?isinstance(x, collections.Callable)?.
> However, in the 2.6 documentation still visible at docs.python.org, the
> incorrect ?__call_? is still present.

Fixed to __call__ for now.  Don't know if Benjamin will the fix for the
fixer to 2.6.

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

iEYEARECAAYFAkv28AEACgkQN9GcIYhpnLCf5gCfewMk1lKXZZh2AwtRSGrF+WjZ
Mm4An11DDWWIlHh51Cj4+G5vvcPDmmu5
=kAEr
-----END PGP SIGNATURE-----

From georg at python.org  Fri May 21 22:45:21 2010
From: georg at python.org (Georg Brandl)
Date: Fri, 21 May 2010 22:45:21 +0200
Subject: [docs] A documentation glitch
In-Reply-To: <AANLkTikyfmgZ441HyJTBdEe56lU26tkp2DFeJmo9Lgbe@mail.gmail.com>
References: <AANLkTikyfmgZ441HyJTBdEe56lU26tkp2DFeJmo9Lgbe@mail.gmail.com>
Message-ID: <4BF6F0E1.70502@python.org>

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

Am 13.05.2010 14:14, schrieb ????? ????????:
> Page in question:
> http://docs.python.org/py3k/tutorial/datastructures.html#sets
> 
>>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']
> 
> 
> 
>>>> fruit = set(basket)               # create a set without duplicates
> 
> 
> Should be
> 
>>>> fruit = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']
> 
> 
> 
>>>> fruit = set(*fruit*)               # create a set without duplicates
> 
> 
> as the intention is to show how to create a set without duplicates from a list.

Dear Denis,

Thanks for the report, that example should now be clearer.

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

iEYEARECAAYFAkv28OAACgkQN9GcIYhpnLCMqgCdGaNrMuOKhKsF4gLGLyg+0gCA
J+kAoInYQAj7daNFzDdYlmIqVuI8sHfp
=4PK+
-----END PGP SIGNATURE-----

From georg at python.org  Fri May 21 22:50:13 2010
From: georg at python.org (Georg Brandl)
Date: Fri, 21 May 2010 22:50:13 +0200
Subject: [docs] Python 2.6.5 threading.Event.wait()
In-Reply-To: <o2iaed5e73f1005131833rb9d1be00tc6d8478f467796ee@mail.gmail.com>
References: <o2iaed5e73f1005131833rb9d1be00tc6d8478f467796ee@mail.gmail.com>
Message-ID: <4BF6F205.1010904@python.org>

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

Am 14.05.2010 03:33, schrieb Andrew Trusty:
> Just spent a couple hours debugging some code because the
> threading.Event.wait() documentation said it returned the internal
> flag when it always returns None.  I just noticed that there is an
> addendum that says this was behavior that was changed in 2.7 but since
> these are the 2.6.5 docs it would be a lot less confusing if it first
> said that it always returns None and then said that in 2.7 it will
> return the internal flag.
> 
> http://docs.python.org/library/threading.html#threading.Event.wait

Hi Andrew,

thanks for the report; this is now fixed in the 2.6 docs.  Apparently
a bad merge was the reason for this to appear in the 2.6 docs.

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

iEYEARECAAYFAkv28gUACgkQN9GcIYhpnLBOXACgnClAoYC7E9y8j8DyfEmT8MU/
6LoAn0DYTWS37MtEWh45ZTVDDcRp9c/W
=NXXk
-----END PGP SIGNATURE-----

From georg at python.org  Fri May 21 22:51:19 2010
From: georg at python.org (Georg Brandl)
Date: Fri, 21 May 2010 22:51:19 +0200
Subject: [docs] Bad link in document
In-Reply-To: <246941143BE97547ACBA665190BC74FD1F63269E4D@EEROCH1CMS2.Energyeast.net>
References: <246941143BE97547ACBA665190BC74FD1F63269E4D@EEROCH1CMS2.Energyeast.net>
Message-ID: <4BF6F247.1080501@python.org>

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

Dear George,

thanks for the report; the link is already fixed in the current
version of the docs (also online at docs.python.org/3.1).

regards,
Georg

Am 13.05.2010 17:12, schrieb Komorowski, George:
> The link to the Apple website is broken. The current PDF file at Apple
> website has 2009 in file name
> 
>  
> 
> the Apple Publications Style Guide wherever
> 
>  
> 
> *Documenting Python*
> 
> *Release 3.1.2*
> 
> *Georg Brandl*
> 
> March 20, 2010
> 
> George Komorowski 
> IT Service Desk
> 
> Iberdrola USA Management Corporation
> 400 West Ave, Rochester, NY 14611
> 800-646-3850 Service Desk
> 585-771-4374 Direct 
> George.Komorowski at EnergyEast.com
> 
> 
> 	
> 
> 
> In the interest of the environment,
> please print only if necessary and recycle.
> 
> 
>  
> 
> 
> 
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs

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

iEYEARECAAYFAkv28kcACgkQN9GcIYhpnLBjMgCgnDD7+SHaM29iFnZpTjKIy4En
iygAn16MpwyaF1U4n/LPi4KqQRvQSt8b
=ViUP
-----END PGP SIGNATURE-----

From mhobbs at alvenda.com  Mon May 17 18:49:21 2010
From: mhobbs at alvenda.com (Mike Hobbs)
Date: Mon, 17 May 2010 11:49:21 -0500
Subject: [docs] Incorrect information for multiprocessing.Semaphore
Message-ID: <1274114961.2984.12.camel@mhobbs>

There's a Note on the documentation for multiprocessing.Semaphore that says that sem_timedwait is unsupported on OS/X and that any timeout argument provided to acquire() will be ignored. I checked the Modules/_multiprocessing/semaphore.c code on the 2.6, 3.0, and 3.1 branches and I see that the module will fallback to sem_timedwait_save() if sem_timedwait is not available. That is, it will not ignore the timeout, but will instead emulate a timed wait using a sleep loop.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100517/9b30405c/attachment.html>

From viktor.viktorov at verizon.net  Tue May 18 06:16:54 2010
From: viktor.viktorov at verizon.net (Viktor Viktorov)
Date: Tue, 18 May 2010 00:16:54 -0400
Subject: [docs] Python Documentation Typo
Message-ID: <E835CEDFF61A4ECBBA6949A806597947@oldPC>

Hello,There is a typo in the documentation at http://docs.python.org/py3k/library/urllib.request.html:>>> import urllib.request
>>> f = urllib.request.urlopen('http://www.python.org/')
>>> print(fp.read(100).decode('utf-8'))
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtm
Should be>>> import urllib.request
>>> f = urllib.request.urlopen('http://www.python.org/')
>>> print(f.read(100).decode('utf-8'))         ^^^
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtm
Cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100518/e3c24880/attachment.html>

From jelte at isc.org  Tue May 18 17:27:56 2010
From: jelte at isc.org (Jelte Jansen)
Date: Tue, 18 May 2010 17:27:56 +0200
Subject: [docs] missing documentation on tempfile.NamedTempFile
Message-ID: <4BF2B1FC.70203@isc.org>

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


Hi,

in the docs for python 3.1.2, the argument list for
tempfile.NamedTemporaryFile()
is incomplete on
http://docs.python.org/py3k/library/tempfile.html

It does not mention the encoding and newline arguments.

I haven't checked the other functions there but I assume this is not the
only one (nor have I checked other versions, sorry).

I found this out because I got quite unexpected errors when not using
named parameters, which I know I should, but I was trying to find out
why something else didn't work for me.

On a related note, another nice addition would be to mention that if the
prefix parameter is absolute, dir is ignored :)

Thanks,

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvysfwACgkQ4nZCKsdOncX8owCg1wpMi3XSrSiHxWA8zDqvZGqx
5nAAn3kZ8y0vL1Eprh+0yyIgLYRbTb+S
=FFMD
-----END PGP SIGNATURE-----

From perona at caltech.edu  Thu May 20 17:49:15 2010
From: perona at caltech.edu (Pietro Perona)
Date: Thu, 20 May 2010 08:49:15 -0700
Subject: [docs] no success in downloading python documentation
Message-ID: <90897D39-D030-49D0-9F2F-6BDACEEFBC35@caltech.edu>

I clicked on the download links and got this error message. P.

Not Found

The requested URL /ftp/python/doc/current/python-2.6.4-docs-pdf-letter.zip was not found on this server.

Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_ssl/2.2.9 OpenSSL/0.9.8g mod_wsgi/2.5 Python/2.5.2 Server at docs.python.org Port 80
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100520/9795fdf9/attachment.html>

From georg at python.org  Fri May 21 22:52:17 2010
From: georg at python.org (Georg Brandl)
Date: Fri, 21 May 2010 22:52:17 +0200
Subject: [docs] Typo in urllib2
In-Reply-To: <AANLkTimQ3sA5eOKliFEYHDCE2Qb7gj1dqHiwYyXtanep@mail.gmail.com>
References: <AANLkTimQ3sA5eOKliFEYHDCE2Qb7gj1dqHiwYyXtanep@mail.gmail.com>
Message-ID: <4BF6F281.3020605@python.org>

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

Am 13.05.2010 04:49, schrieb INADA Naoki:
> I've found typo in urllib2. But bugs.python.org is down now.
> 
> http://docs.python.org/dev/library/urllib2.html#urllib2.OpenerDirector.open
> 
> -(if not specified, the global default timeout setting will be usedi).
> +(if not specified, the global default timeout setting will be used).
> 
> # extra 'i'

Thanks, fixed in r81415 (and will be merged to other branches).

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

iEYEARECAAYFAkv28oEACgkQN9GcIYhpnLAvIgCfX7HGkktFFEqNSEhLrlUQbts8
A00AoLCm03/0PbX8mLvSh3uVO9svYUaa
=GflV
-----END PGP SIGNATURE-----

From report at bugs.python.org  Fri May 21 22:58:56 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 20:58:56 +0000
Subject: [docs] [issue8724] bind_and_activate parameter is missed from
	directive
In-Reply-To: <1273926127.04.0.976754673926.issue8724@psf.upfronthosting.co.za>
Message-ID: <1274475536.42.0.241376283556.issue8724@psf.upfronthosting.co.za>


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

Thanks, fixed in r81419.

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

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

From georg at python.org  Fri May 21 23:02:00 2010
From: georg at python.org (Georg Brandl)
Date: Fri, 21 May 2010 23:02:00 +0200
Subject: [docs] Python Documentation Typo
In-Reply-To: <E835CEDFF61A4ECBBA6949A806597947@oldPC>
References: <E835CEDFF61A4ECBBA6949A806597947@oldPC>
Message-ID: <4BF6F4C8.2040400@python.org>

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

Am 18.05.2010 06:16, schrieb Viktor Viktorov:
> Hello,
> 
> There is a typo in the documentation at http://docs.python.org/py3k/library/urllib.request.html:
> 
>>>> import urllib.request
>>>> f = urllib.request.urlopen('http://www.python.org/')
>>>> print(fp.read(100).decode('utf-8'))
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtm
> 
> Should be
> 
>>>> import urllib.request
>>>> f = urllib.request.urlopen('http://www.python.org/')
>>>> print(*f.*read(100).decode('utf-8'))
> 
>          ^^^
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtm

Hi Viktor,

thanks for the report, this is fixed now in Subversion.

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

iEYEARECAAYFAkv29McACgkQN9GcIYhpnLDEfwCfYmenA9W3Wf6mI8gU4zn7C6kT
kLMAn2dBuPcN5x85Pj/Vmnot9+HWw6zz
=e0Jb
-----END PGP SIGNATURE-----

From report at bugs.python.org  Fri May 21 23:30:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 21:30:58 +0000
Subject: [docs] [issue8707] Duplicated document in telnetlib.
In-Reply-To: <1273793790.89.0.952480751284.issue8707@psf.upfronthosting.co.za>
Message-ID: <1274477458.0.0.707563232343.issue8707@psf.upfronthosting.co.za>


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

Thanks, fixed in r81431.

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

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

From georg at python.org  Fri May 21 23:32:00 2010
From: georg at python.org (Georg Brandl)
Date: Fri, 21 May 2010 23:32:00 +0200
Subject: [docs] missing documentation on tempfile.NamedTempFile
In-Reply-To: <4BF2B1FC.70203@isc.org>
References: <4BF2B1FC.70203@isc.org>
Message-ID: <4BF6FBD0.3050505@python.org>

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

Am 18.05.2010 17:27, schrieb Jelte Jansen:
> 
> Hi,
> 
> in the docs for python 3.1.2, the argument list for
> tempfile.NamedTemporaryFile()
> is incomplete on
> http://docs.python.org/py3k/library/tempfile.html
> 
> It does not mention the encoding and newline arguments.

Dear Jelte,

thanks for the report; this is now fixed in Subversion (for TemporaryFile
and SpooledTemporaryFile as well) and will appear online shortly.

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

iEYEARECAAYFAkv2+88ACgkQN9GcIYhpnLCoMQCfSzx4XH8cp9GS0lQu2NkWV0Bn
2u8AnRU4Lxb9bXg9RfoPuhKbthh2ggHg
=9GPQ
-----END PGP SIGNATURE-----

From georg at python.org  Fri May 21 23:37:41 2010
From: georg at python.org (Georg Brandl)
Date: Fri, 21 May 2010 23:37:41 +0200
Subject: [docs] no success in downloading python documentation
In-Reply-To: <90897D39-D030-49D0-9F2F-6BDACEEFBC35@caltech.edu>
References: <90897D39-D030-49D0-9F2F-6BDACEEFBC35@caltech.edu>
Message-ID: <4BF6FD25.2010308@python.org>

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

Am 20.05.2010 17:49, schrieb Pietro Perona:
> I clicked on the download links and got this error message. P.
> 
> 
>   Not Found
> 
> The requested URL
> /ftp/python/doc/current/python-2.6.4-docs-pdf-letter.zip was not found
> on this server.

Hi Pietro,

may I ask where you found these links?  The current download page for
the 2.6 docs (http://docs.python.org/download.html) shouldn't refer to
this location anymore.

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

iEYEARECAAYFAkv2/SUACgkQN9GcIYhpnLBbagCfYTDRMKHRJ0/4v+cSKqPLUHUz
Jn4AnilqS8CdbkfQA+CEEeXHYQs5+uE1
=2S8z
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sat May 22 00:03:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 21 May 2010 22:03:46 +0000
Subject: [docs] [issue8709] mention explicitly Windows support for os.devnull
In-Reply-To: <1273822995.3.0.430966516538.issue8709@psf.upfronthosting.co.za>
Message-ID: <1274479426.19.0.715739790278.issue8709@psf.upfronthosting.co.za>


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

Thanks, applied in r81450.

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

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

From georg at python.org  Sat May 22 00:15:54 2010
From: georg at python.org (Georg Brandl)
Date: Sat, 22 May 2010 00:15:54 +0200
Subject: [docs] Incorrect information for multiprocessing.Semaphore
In-Reply-To: <1274114961.2984.12.camel@mhobbs>
References: <1274114961.2984.12.camel@mhobbs>
Message-ID: <4BF7061A.8050007@python.org>

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

Am 17.05.2010 18:49, schrieb Mike Hobbs:
> There's a Note on the documentation for multiprocessing.Semaphore that
> says that sem_timedwait is unsupported on OS/X and that any timeout
> argument provided to acquire() will be ignored. I checked the
> Modules/_multiprocessing/semaphore.c code on the 2.6, 3.0, and 3.1
> branches and I see that the module will fallback to sem_timedwait_save()
> if sem_timedwait is not available. That is, it will not ignore the
> timeout, but will instead emulate a timed wait using a sleep loop.

Hi Mike,

thanks for the report; this is now corrected in Subversion and should
be online soon.

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

iEYEARECAAYFAkv3BhoACgkQN9GcIYhpnLD1sgCeLTYRW1o3rWtR9x2kJb6FLuF7
8HkAoKtMzUX4+xkHdCLuQ97374fSz+HM
=yXTn
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sat May 22 10:03:34 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sat, 22 May 2010 08:03:34 +0000
Subject: [docs] [issue8785] findall() and finditer() docs misleading
In-Reply-To: <1274515414.72.0.273770511107.issue8785@psf.upfronthosting.co.za>
Message-ID: <1274515414.72.0.273770511107.issue8785@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hfuerstenau at gmx.net>:

The docs for the RegexpObject methods findall and finditer are misleading: They are said to behave the same way as the respective functions, but in fact the parameter semantics are different.

----------
assignee: docs at python
components: Documentation
messages: 106286
nosy: docs at python, hagen
priority: normal
severity: normal
status: open
title: findall() and finditer() docs misleading
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat May 22 10:19:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 22 May 2010 08:19:02 +0000
Subject: [docs] [issue8785] findall() and finditer() docs misleading
In-Reply-To: <1274515414.72.0.273770511107.issue8785@psf.upfronthosting.co.za>
Message-ID: <1274516342.25.0.0753830077475.issue8785@psf.upfronthosting.co.za>


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

Thanks, fixed in r81463.

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

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

From report at bugs.python.org  Sat May 22 17:43:03 2010
From: report at bugs.python.org (Jeroen Habraken)
Date: Sat, 22 May 2010 15:43:03 +0000
Subject: [docs] [issue8788] urllib.urlencode documentation unclear on doseq
In-Reply-To: <1274542983.4.0.702068503568.issue8788@psf.upfronthosting.co.za>
Message-ID: <1274542983.4.0.702068503568.issue8788@psf.upfronthosting.co.za>


New submission from Jeroen Habraken <vexocide at gmail.com>:

The urllib.urlencode documentation is unclear with regard to the 'doseq' option. In my opinion it does not clearly state what its functionality is.

----------
assignee: docs at python
components: Documentation
messages: 106311
nosy: VeXocide, docs at python
priority: normal
severity: normal
status: open
title: urllib.urlencode documentation unclear on doseq

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

From report at bugs.python.org  Sat May 22 17:50:22 2010
From: report at bugs.python.org (Jeroen Habraken)
Date: Sat, 22 May 2010 15:50:22 +0000
Subject: [docs] [issue8788] urllib.urlencode documentation unclear on doseq
In-Reply-To: <1274542983.4.0.702068503568.issue8788@psf.upfronthosting.co.za>
Message-ID: <1274543422.75.0.68264476492.issue8788@psf.upfronthosting.co.za>


Jeroen Habraken <vexocide at gmail.com> added the comment:

An elaboration as requested on IRC: It appears to make claims about 'the sequence', but doesn't make clear that 'doseq' matters when *v* is a sequence. It is easy to assume it refers to the query sequence, which is of course always a sequence.

----------

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

From report at bugs.python.org  Mon May 24 18:20:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 May 2010 16:20:21 +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: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>From <http://docs.python.org/dev/py3k/library/datetime.html#datetime.tzinfo.utcoffset>:

"""
tzinfo.utcoffset(self, dt)

    Return offset of local time from UTC, in minutes east of UTC. 
"""

This suggests that the return value is an integer representing the number of minutes.  It is later explained that in fact "the value returned must be a timedelta object specifying a whole number of minutes", but many users won't read past the first sentence.

I suggest s/in minutes east of UTC/as a timedelta object/.  I think "east of UTC" is redundant given the next sentence, "If local time is west of UTC, this should be negative", but that can also be reworded for clarity as "The offset for timezones west of UTC is negative, and for those east of UTC is positive."

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 106371
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: TZ offset description is unclear in docs
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon May 24 21:57:09 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 24 May 2010 19:57:09 +0000
Subject: [docs] [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>


New submission from Shashwat Anand <anand.shashwat at gmail.com>:

The docs of sqlite3 for python 3.0 and 3.1 seems to be written for python 2.6 and hence wrong at many places.
like, 
>>> for member in r: print member 

However the docs for sqlite3 in py3k trunk seems fine. The sqlite3 doc in py3k trunk should be used in these places.

http://docs.python.org/release/3.0.1/library/sqlite3.html
http://docs.python.org/release/3.1/library/sqlite3.html

----------
assignee: docs at python
components: Documentation
files: sqlite.rst.patch
keywords: patch
messages: 106382
nosy: docs at python, georg.brandl, ghaering, l0nwlf
priority: normal
severity: normal
status: open
title: fixing sqlite3 docs for py3k
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file17451/sqlite.rst.patch

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

From report at bugs.python.org  Tue May 25 01:30:57 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 24 May 2010 23:30:57 +0000
Subject: [docs] [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274743857.89.0.177420455837.issue8811@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/issue8811>
_______________________________________

From report at bugs.python.org  Tue May 25 01:37:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 24 May 2010 23:37:59 +0000
Subject: [docs] [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274744279.3.0.468048498712.issue8811@psf.upfronthosting.co.za>


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

Hmm, the patch mostly doesn't apply for me on the 3.1 branch.  (Note that 3.0 docs aren't maintained anymore, just like 3.0 itself.)

----------

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

From report at bugs.python.org  Tue May 25 01:39:14 2010
From: report at bugs.python.org (David Antliff)
Date: Mon, 24 May 2010 23:39:14 +0000
Subject: [docs] [issue8562] hasattr(open,
	'newlines') example gives incorrect results from  PEP0278
In-Reply-To: <1272483941.45.0.330180944367.issue8562@psf.upfronthosting.co.za>
Message-ID: <1274744354.95.0.373755170477.issue8562@psf.upfronthosting.co.za>


Changes by David Antliff <david.antliff at gmail.com>:


----------
nosy: +David.Antliff

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

From report at bugs.python.org  Tue May 25 01:57:26 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Mon, 24 May 2010 23:57:26 +0000
Subject: [docs] [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274745445.86.0.157647642215.issue8811@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

ok,
I think a few example codes are wrongly mentioned as if it were 2.x docs, however those examples at http://docs.python.org/dev/py3k/library/sqlite3 works correctly.
Do by 'mostly', do you mean I should submit another patch with only those wrong examples rectified ?

----------

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

From report at bugs.python.org  Tue May 25 16:32:31 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 14:32:31 +0000
Subject: [docs] [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1274797951.34.0.596520057816.issue8653@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

Maybe he's referring to the fact that 'default_scheme' is referenced in the docs but in fact the parameter name is 'scheme'?

----------
nosy: +adamnelson

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

From report at bugs.python.org  Tue May 25 17:37:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 May 2010 15:37:23 +0000
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when using
	scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274801843.47.0.255591080902.issue8818@psf.upfronthosting.co.za>


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

The keyword in the code is 'scheme'.  I've updated the docs accordingly in r81521 and r81522.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue May 25 18:53:56 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 16:53:56 +0000
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when using
	scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274806436.49.0.402113211118.issue8818@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

Great, thanks.

However urlsplit and urlparse still take what one would expect to be recognized as the netloc and assigns it to the 'path' key.  If that is by design perhaps we should at least warn people?

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

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

From report at bugs.python.org  Tue May 25 18:55:57 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 16:55:57 +0000
Subject: [docs] [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1274806557.49.0.494685632834.issue8653@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

The default_scheme issue I brought up has been fixed in #8818

----------

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

From report at bugs.python.org  Tue May 25 19:33:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 May 2010 17:33:01 +0000
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when using
	scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274808781.61.0.211580216214.issue8818@psf.upfronthosting.co.za>


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

I've added Senthil as nosy to double check me, but my understanding is that the scheme is just the part up to the colon.  If you want to have a netloc in the URL, you have to precede it with a '//'.  Otherwise there's no netloc.

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

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

From report at bugs.python.org  Tue May 25 19:41:54 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 17:41:54 +0000
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when using
	scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274809314.18.0.171067848435.issue8818@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

Ok, you're right:

>>> urlsplit('cnn.com')
SplitResult(scheme='', netloc='', path='cnn.com', query='', fragment='')
>>> urlsplit('//cnn.com')
SplitResult(scheme='', netloc='cnn.com', path='', query='', fragment='')
>>> 

Although I see that nowhere in the documentation.  It seems to me that in the scenario most people are dealing with, where they are getting 'cnn.com' or 'http://cnn.com' but don't know which ahead of time, this will be useless.  I don't see who would ever have '//cnn.com' without constructing that string specifically for urlsplit.

I would propose that '/whatever' becomes the path because it starts with slash, otherwise, it becomes the netloc and everything after the first slash becomes the path.

----------

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

From fdrake at acm.org  Tue May 25 19:53:02 2010
From: fdrake at acm.org (Fred Drake)
Date: Tue, 25 May 2010 13:53:02 -0400
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when
	using scheme
In-Reply-To: <1274809314.18.0.171067848435.issue8818@psf.upfronthosting.co.za>
References: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za> 
	<1274809314.18.0.171067848435.issue8818@psf.upfronthosting.co.za>
Message-ID: <AANLkTikSEnDuwp3WH4wWMJ76bCptrApdFTR6M3vlTVQh@mail.gmail.com>

On Tue, May 25, 2010 at 1:41 PM, AdamN <report at bugs.python.org> wrote:
> Although I see that nowhere in the documentation.

It needn't be in the urlparse documentation; the RFCs on URL syntax
apply here.  None of what's going on with the urlparse module is
Python specific, as far as the URL interpretation is concerned.

>?It seems to me that in the scenario most people are dealing with, where
> they are getting 'cnn.com' or 'http://cnn.com' but don't know which ahead
> of time, this will be useless. ?I don't see who would ever have '//cnn.com'
> without constructing that string specifically for urlsplit.

'cnn.com' isn't a URL, and there's no need for urlparse to handle it
direectly.  That just complicates things.

Doing something above and beyond what the RFCs specify means you need
to really think about the heuristics you're applying.  If there's a
useful set of heuristics that folks can agree on, that's a good case
for a new module distributed on PyPI.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From report at bugs.python.org  Tue May 25 20:04:40 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 18:04:40 +0000
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when using
	scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274810680.56.0.771700938441.issue8818@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

I appreciate what you're saying but nobody, I guarantee nobody, is using the '//cnn.com' semantics.

Anyway, in RFC 3986 in the Syntax Components section, you'll see that the '://' is not part of scheme or netloc.  I could imagine urlsplit() failing if the url was not prepended by '//' or 'scheme://', but why would being prepended with nothing cause urlsplit() to presume it's a path?

Can we at least document this?

----------

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

From fdrake at acm.org  Tue May 25 20:15:43 2010
From: fdrake at acm.org (Fred Drake)
Date: Tue, 25 May 2010 14:15:43 -0400
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when
	using scheme
In-Reply-To: <1274810680.56.0.771700938441.issue8818@psf.upfronthosting.co.za>
References: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za> 
	<1274810680.56.0.771700938441.issue8818@psf.upfronthosting.co.za>
Message-ID: <AANLkTineEPaLMV6vH1QLbKKnqQBtilx4LXcmXAvsbAx9@mail.gmail.com>

The module is documented as supporting "Relative Uniform Resource
Locators", in which a value with a non-rooted path is supported using
simply "non/rooted/path".

See the third paragraph in the Python 2.6 documentation, starting "The
module has been designed".

From report at bugs.python.org  Tue May 25 20:26:16 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 18:26:16 +0000
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when using
	scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274811976.7.0.294620734563.issue8818@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

I think I misspoke before.  What I'm referring to is when somebody uses the 'scheme' parameter:

urlsplit('cnn.com',scheme='http')

Is there no way that we can document that this won't work the way that people think it will?  Is it really reasonable for a high-level language to expect people to have read a 100 page RFC in order to know that regular expressions will have to be used for this type of situation?

----------

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

From report at bugs.python.org  Tue May 25 20:42:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 May 2010 18:42:00 +0000
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when using
	scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274812920.28.0.329238711356.issue8818@psf.upfronthosting.co.za>


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

How would you expect urlsplit to differentiate between a relative path and a path with a netloc?  I would think that most people would expect the semantics the module provides without reading any additional documentation.  I certainly did, to the point where when reading your example I didn't even notice that there was any problem report other than the misnaming of the scheme keyword :)

You could suggest a clarification to the docs if you like.

----------

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

From report at bugs.python.org  Tue May 25 21:03:40 2010
From: report at bugs.python.org (AdamN)
Date: Tue, 25 May 2010 19:03:40 +0000
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when using
	scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1274814220.77.0.00373456358677.issue8818@psf.upfronthosting.co.za>


AdamN <adam at varud.com> added the comment:

I would say right under:

urlparse.urlparse(urlstring[, default_scheme[, allow_fragments]])?

Put:

urlstring is a pseudo-url.  If the string has a scheme, it will be interpreted as a scheme, followed by a path, querystring and fragment.  If it is prepended with a double-slash '//', it will be interpreted as a netloc followed by a path, querystring and fragment.  Otherwise, it will be interpreted as a path followed by a querystring and fragment.

I'm still confused about when anybody would use a relative path with a default scheme and no netloc but I'll leave that decision to you guys.  

Thanks,
Adam

----------

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

From report at bugs.python.org  Tue May 25 21:09:42 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 25 May 2010 19:09:42 +0000
Subject: [docs] [issue8818] urlsplit and urlparse add extra slash when using
	scheme
In-Reply-To: <1274814220.77.0.00373456358677.issue8818@psf.upfronthosting.co.za>
Message-ID: <AANLkTikGdat3qGrNjip84ygyzDjNjQ179qtOVRlO9df5@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Tue, May 25, 2010 at 3:03 PM, AdamN <report at bugs.python.org> wrote:
> I'm still confused about when anybody would use a relative path with a default scheme and no netloc but I'll leave that decision to you guys.

The strings are not pseudo-URLs, they're relative references, as documented.

This is used all the time in HREF and SRC attributes in web pages,
which is exactly the use case for urlparse.urljoin().

----------

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

From report at bugs.python.org  Wed May 26 14:07:28 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 26 May 2010 12:07:28 +0000
Subject: [docs] [issue8822] datetime naive and aware types should have a
	well-defined	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

'naive' and 'aware' are key datetime types - they need a proper definition and anchor for crossrefences. If you take a look at http://docs.python.org/library/datetime.html - the definition of distinction between them is too vague and this seeds of uncertainty grow through the rest of the doc. It is not said how to make non-naive object, how to detect if object of naive or aware. All this stuff is very important for troubleshooting datetims issues in Python projects. It needs a proper documentation.

----------
assignee: docs at python
components: Documentation
messages: 106524
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: datetime naive and aware types should have a well-defined definition that can be cross-referenced

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

From report at bugs.python.org  Wed May 26 19:36:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 May 2010 17:36:48 +0000
Subject: [docs] [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>


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

This doc improvement suggestion is inspired by #991196 (and subsequent duplicates) and the current discussion on py-dev in the thread
  'variable name resolution in exec is incorrect'
(which is not a correct claim). I believe there is consensus that the doc for exec needs improving.

My suggestion (which others may amend) is that the following paragraph (from the 3.x builtin functions exec entry)

"In all cases, if the optional parts are omitted, the code is executed in the current scope. If only globals is provided, it must be a dictionary, which will be used for both the global and the local variables. If globals  and locals are given, they are used for the global and local variables, respectively. If provided, locals can be any mapping object."

have these two sentences added:

"If only globals is provided or if onedict is provided as both globals and locals, the code is executed in a new top-level scope. If different objects are given as globals and locals, the code is executed as if it were in a class statement in a new top-level scope."

----------
assignee: docs at python
components: Documentation
messages: 106552
nosy: docs at python, tjreedy
priority: normal
severity: normal
status: open
title: Improve documentation of exec
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed May 26 19:52:45 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 26 May 2010 17:52:45 +0000
Subject: [docs] [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1274896365.44.0.690368816474.issue8824@psf.upfronthosting.co.za>


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

To be super-clear, consider adding one more sentence, something like

"The result for code with def statements or lambda expressions may be different than it would be if the implied context were a function rather than a class."

----------

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

From report at bugs.python.org  Thu May 27 00:14:22 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Wed, 26 May 2010 22:14:22 +0000
Subject: [docs] [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1274912062.49.0.620920881627.issue8811@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


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

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

From report at bugs.python.org  Thu May 27 02:05:33 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 27 May 2010 00:05:33 +0000
Subject: [docs] [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1274918733.12.0.975625724508.issue8824@psf.upfronthosting.co.za>


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


----------
nosy: +ncoghlan

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

From report at bugs.python.org  Thu May 27 18:36:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 May 2010 16:36:28 +0000
Subject: [docs] [issue8822] datetime naive and aware types should have a
	well-defined	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1274978188.43.0.456864011237.issue8822@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky
stage:  -> needs patch
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu May 27 20:09:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 27 May 2010 18:09:09 +0000
Subject: [docs] [issue8822] datetime naive and aware types should have a
	well-defined	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1274983749.17.0.480328978139.issue8822@psf.upfronthosting.co.za>


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

> 'naive' and 'aware' are key datetime types - they need a proper
> definition and anchor for crossrefences.

The definition is given in the introductory section:
"""
There are two kinds of date and time objects: ?naive? and ?aware?. This distinction refers to whether the object has any notion of time zone, daylight saving time, or other kind of algorithmic or political time adjustment. 
"""

I am not sure what you propose to add to this.  Do you wan't to dedicate a separate subsection to naive and aware time and datetime? I feel that would be an overkill.  Would simply adding index entries for naive and aware time/datetime objects be enough?

> It is not said how to make non-naive object, 

This may be due to the fact that there is no concrete tzinfo implementation in stdlib.  See issue 5094.

I think it can be added in datetime constructor section that providing a tzinfo argument results in an aware object.  this is already so for datetime.fromtimestamp.

> how to detect if object of naive or aware.

This is already clear IMO:

"""
An object d of type time or datetime may be naive or aware. d is aware if d.tzinfo is not None and d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None, or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns None, d is naive.
"""

----------

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

From report at bugs.python.org  Thu May 27 22:46:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 27 May 2010 20:46:21 +0000
Subject: [docs] [issue8834] Define order of Misc/ACKS entries
In-Reply-To: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>
Message-ID: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

This is a semi-serious feature request following a brief discussion on #python-dev IRC.

Brett Cannon pointed out on python-checkins list [1] that the names should be alphabetized.  However, given that the names are international, it is not obvious what it means.

I propose to add a comment at the top of Misc/ACKS that the list is maintained in "rough alphabetical order" but not define it any further.

[1] http://mail.python.org/pipermail/python-checkins/2010-May/093650.html

----------
assignee: docs at python
components: Documentation
messages: 106615
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Define order of Misc/ACKS entries
type: feature request

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

From report at bugs.python.org  Thu May 27 22:48:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 27 May 2010 20:48:29 +0000
Subject: [docs] [issue8834] Define order of Misc/ACKS entries
In-Reply-To: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>
Message-ID: <1274993309.65.0.122561437769.issue8834@psf.upfronthosting.co.za>


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


----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file17475/issue8834.diff

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

From report at bugs.python.org  Fri May 28 00:26:16 2010
From: report at bugs.python.org (Anthony Foglia)
Date: Thu, 27 May 2010 22:26:16 +0000
Subject: [docs] [issue8836] Conflicting default values of parameter to
	__import__
In-Reply-To: <1274999176.58.0.342464262777.issue8836@psf.upfronthosting.co.za>
Message-ID: <1274999176.58.0.342464262777.issue8836@psf.upfronthosting.co.za>


New submission from Anthony Foglia <afoglia at gmail.com>:

Looking at the documentation for the __import__ builtin, the default value of the level parameter is unclear.  Two different values are mentioned.  The function signature is written:

__import__(name, globals={}, locals={}, fromlist=[], level=-1)

But the third paragraph begins: "level specifies whether to use absolute or relative imports. 0 (the default) means only perform absolute imports."

So which is it, -1 or 0?

I'm guessing 0.  If -1 is still a valid value, it needs to be described.

----------
assignee: docs at python
components: Documentation
messages: 106621
nosy: afoglia, docs at python
priority: normal
severity: normal
status: open
title: Conflicting default values of parameter to __import__
versions: Python 3.1

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

From report at bugs.python.org  Fri May 28 00:32:51 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 27 May 2010 22:32:51 +0000
Subject: [docs] [issue8836] Conflicting default values of parameter to
	__import__
In-Reply-To: <1274999176.58.0.342464262777.issue8836@psf.upfronthosting.co.za>
Message-ID: <1274999570.93.0.270829216463.issue8836@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r81572.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri May 28 01:36:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 May 2010 23:36:22 +0000
Subject: [docs] [issue8834] Define order of Misc/ACKS entries
In-Reply-To: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>
Message-ID: <1275003382.5.0.95661876265.issue8834@psf.upfronthosting.co.za>


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

Looks good to me.

----------
nosy: +pitrou
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From mark at qtrac.eu  Fri May 28 09:52:57 2010
From: mark at qtrac.eu (Mark Summerfield)
Date: Fri, 28 May 2010 08:52:57 +0100
Subject: [docs] clarification needed for multiprocessing.Process.join()
	method
Message-ID: <201005280852.57829.mark@qtrac.eu>

Hi,

The multiprocessing.Process.join() method has a timeout argument but
doesn't specify the units. My guess is that the units are seconds. It
would be helpful to (1) specify the units and (2) if the units are
seconds, specify whether floating-point values are accepted. For
example:

    If timeout is None then the process will block the calling thread
    until the process terminates. Otherwise the process will block for
    at most timeout seconds (which can be fractional, e.g., 0.5), or
    until the process terminates, whichever occurs first.

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
        "Programming in Python 3 (Second Edition)" - ISBN 0321680561

From report at bugs.python.org  Fri May 28 19:43:10 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 May 2010 17:43:10 +0000
Subject: [docs] [issue8834] Define order of Misc/ACKS entries
In-Reply-To: <1274993181.13.0.347164864235.issue8834@psf.upfronthosting.co.za>
Message-ID: <1275068590.32.0.305694115287.issue8834@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

LGTM as well.

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

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

From report at bugs.python.org  Sat May 29 06:38:22 2010
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Sat, 29 May 2010 04:38:22 +0000
Subject: [docs] [issue8851] pkgutil document needs more markups
In-Reply-To: <1275107900.09.0.840689685245.issue8851@psf.upfronthosting.co.za>
Message-ID: <1275107900.09.0.840689685245.issue8851@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi <mft at users.sourceforge.net>:

The library reference of pkgutil is only sparsely marked up.

The attached patch is against 2.6 version, because I'm currently working with 2.6.  Since a part of markups (namely :pep:'s) has already been done for 3.2 version, the patch cannot be applied directly to that version, and I haven't checked the versions in between.

----------
assignee: docs at python
components: Documentation
files: pkgutil.diff
keywords: patch
messages: 106708
nosy: docs at python, mft
priority: normal
severity: normal
status: open
title: pkgutil document needs more markups
versions: Python 2.6
Added file: http://bugs.python.org/file17492/pkgutil.diff

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

From report at bugs.python.org  Sat May 29 10:49:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 29 May 2010 08:49:20 +0000
Subject: [docs] [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1275122960.46.0.190959525977.issue8811@psf.upfronthosting.co.za>


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

Well, if I try applying your patch to 3.1 it fails.  It would be nice to have one that applies flawlessly :)

----------

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

From report at bugs.python.org  Sat May 29 13:47:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 May 2010 11:47:01 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275133621.61.0.036888523613.issue8840@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: io.StringIO: truncate+print disabled in 3.1.2 -> truncate() semantics changed in 3.1.2
versions: +Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat May 29 13:56:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 May 2010 11:56:20 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275134180.24.0.505928753974.issue8840@psf.upfronthosting.co.za>


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

How about reusing the documentation of legacy file objects:

?Truncate the file?s size. If the optional size argument is present, the file is truncated to (at most) that size. The size defaults to the current position. The current file position is not changed. Note that if a specified size exceeds the file?s current size, the result is platform-dependent: possibilities include that the file may remain unchanged, increase to the specified size as if zero-filled, or increase to the specified size with undefined new content.?

http://docs.python.org/library/stdtypes.html#file.truncate

----------

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

From report at bugs.python.org  Sat May 29 14:09:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 May 2010 12:09:23 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275134963.21.0.924770990676.issue8840@psf.upfronthosting.co.za>


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

I've committed a doc update (a mix of the legacy truncate() doc and Pascal's proposal) in r81594.

----------

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

From report at bugs.python.org  Sat May 29 18:47:16 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 29 May 2010 16:47:16 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1275151636.48.0.965093881733.issue8840@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Good B-)

Woudl it be necessary to update the docstrings too ?

----------

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

From report at bugs.python.org  Sat May 29 20:56:56 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 29 May 2010 18:56:56 +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: <1275159415.88.0.346745518392.issue8810@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

In this case, the docs.python.org link you point to seems to be correct, saying that it returns a timedelta.  It is the docstring that says it's minutes east of UTC.

I've attached a patch which changes this wording to:

timedelta() showing offset from UTC, with negative for West of UTC

----------
keywords: +patch
nosy: +jafo
Added file: http://bugs.python.org/file17495/python-utcoffsetdoc.patch

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

From report at bugs.python.org  Sat May 29 21:09:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 19:09:37 +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: <1275160177.47.0.73477997632.issue8810@psf.upfronthosting.co.za>


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

I?m not sure about the ?with negative? wording.

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

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

From report at bugs.python.org  Sat May 29 21:36:28 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 29 May 2010 19:36:28 +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: <1275161788.82.0.0379341156545.issue8810@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Alternately, here is a patch that just takes the docs.python.org description.

----------
Added file: http://bugs.python.org/file17496/python-utcoffsetdoc2.patch

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

From report at bugs.python.org  Sat May 29 21:37:56 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 29 May 2010 19:37:56 +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: <1275161876.01.0.883720329765.issue8810@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Then how about:

timedelta() showing offset from UTC, negative values indicating West of UTC

?

----------

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

From report at bugs.python.org  Sat May 29 21:43:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 19:43:35 +0000
Subject: [docs] [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1275161876.01.0.883720329765.issue8810@psf.upfronthosting.co.za>
Message-ID: <4C016E64.2080301@netwok.org>


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

> timedelta() showing offset from UTC, negative values indicating West of UTC

+1 for the last one.

Micro nit: I would not put parentheses when referring to the type (we
talk about ?a list?, not ?a list()?).

Micro nit: Some languages use case to distinguish direction vs. region,
e.g. in French we have ?ouest? and ?Ouest?. Does that apply to English?

----------

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

From report at bugs.python.org  Sat May 29 22:00:02 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Sat, 29 May 2010 20:00:02 +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: <1275163202.32.0.769928574948.issue8810@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

I'm fine without ().

I thought the direction was generally initial-capped, but I may be wrong there.  Let's go with "west".

----------

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

From report at bugs.python.org  Sat May 29 22:49:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 20:49:39 +0000
Subject: [docs] [issue8481] doc: ctypes no need to explicitly allocate
	writable	memory with Structure
In-Reply-To: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>
Message-ID: <1275166179.04.0.984566818108.issue8481@psf.upfronthosting.co.za>


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


----------
assignee: theller -> flox
nosy: +docs at python, flox -theller
priority: normal -> 

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

From report at bugs.python.org  Sat May 29 22:51:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 29 May 2010 20:51:09 +0000
Subject: [docs] [issue8481] doc: ctypes no need to explicitly allocate
	writable	memory with Structure
In-Reply-To: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>
Message-ID: <1275166269.7.0.961212558837.issue8481@psf.upfronthosting.co.za>


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


----------
assignee: flox -> theller
nosy: +theller -flox
priority:  -> normal

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

From report at bugs.python.org  Sun May 30 02:53:54 2010
From: report at bugs.python.org (Longpoke)
Date: Sun, 30 May 2010 00:53:54 +0000
Subject: [docs] [issue8855] Shelve documentation lacks security warning
In-Reply-To: <1275180833.97.0.966181786946.issue8855@psf.upfronthosting.co.za>
Message-ID: <1275180833.97.0.966181786946.issue8855@psf.upfronthosting.co.za>


New submission from Longpoke <longpoke at gmail.com>:

Loading a shelve can cause arbitrary code to be executed [1] and other black magic (because it's backed by Pickle). Shouldn't there be a big fat warning at the top of the shelve documentation page?

Unless you're like me and assume anything to do with serialization in any language is insecure until proved otherwise, you aren't going to intuitively think there is anything wrong with "unshelving" untrusted data (unless you already know that Pickle is insecure).

1. http://nadiana.com/python-pickle-insecure#comment-261

----------
assignee: docs at python
components: Documentation
messages: 106746
nosy: docs at python, q94IjzUfnNoyv4c75mMw
priority: normal
severity: normal
status: open
title: Shelve documentation lacks security warning

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

From Raphael.Mankin at rbs.com  Wed May 26 10:49:08 2010
From: Raphael.Mankin at rbs.com (Raphael.Mankin at rbs.com)
Date: Wed, 26 May 2010 09:49:08 +0100
Subject: [docs] Bug in documentation of os.mkdir()
Message-ID: <3FD061693071E948A07F24D7CFEF9CC701AE101878@LONMC01040.rbsres07.net>

The web page http://docs.python.org/library/os.html#file-object-creation does not specify what os.mkdir() does if the directory already exists. Makedirs() does, but mkdir() does not.

***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. 
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. 
Authorised and regulated by the Financial Services Authority. The
Royal Bank of Scotland N.V. is authorised and regulated by the 
De Nederlandsche Bank and has its seat at Amsterdam, the 
Netherlands, and is registered in the Commercial Register under 
number 33002587. Registered Office: Gustav Mahlerlaan 10, 
Amsterdam, The Netherlands. The Royal Bank of Scotland N.V. and 
The Royal Bank of Scotland plc are authorised to act as agent for each 
other in certain jurisdictions.
 
This e-mail message is confidential and for use by the addressee only.
If the message is received by anyone other than the addressee, please 
return the message to the sender by replying to it and then delete the 
message from your computer. Internet e-mails are not necessarily 
secure. The Royal Bank of Scotland plc and The Royal Bank of Scotland 
N.V. including its affiliates ("RBS group") does not accept responsibility 
for changes made to this message after it was sent. 

Whilst all reasonable care has been taken to avoid the transmission of 
viruses, it is the responsibility of the recipient to ensure that the onward
transmission, opening or use of this message and any attachments will 
not adversely affect its systems or data. No responsibility is accepted 
by the RBS group in this regard and the recipient should carry out such 
virus and other checks as it considers appropriate. 

Visit our website at www.rbs.com

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


From creinman at gmail.com  Wed May 26 21:48:13 2010
From: creinman at gmail.com (Charles Reinman)
Date: Wed, 26 May 2010 15:48:13 -0400
Subject: [docs] Small documentation typo
Message-ID: <AANLkTin_YHcehIP-ymGdh-vs5gnn2C6ASXVa_u6_EgxO@mail.gmail.com>

In the sentence:

?Private? instance variables that cannot be accessed except from inside an
> object, don?t exist in Python.


The comma is extraneous and should be removed.

http://docs.python.org/tutorial/classes.html#private-variables

Thanks,
- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100526/bfc78549/attachment-0001.html>