From report at bugs.python.org  Tue Jun  1 00:20:16 2010
From: report at bugs.python.org (Christian Schubert)
Date: Mon, 31 May 2010 22:20:16 +0000
Subject: [docs] [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>


New submission from Christian Schubert <bugs at apexo.de>:

invoking select.poll.poll() concurrently from multiple threads frequently yields garbage in one thread:

while poll_poll in thread 1 is parsing its result, another thread 2 calling poll may overwrite revents; assuming poll_result was 1 in thread 1 and thread 2 managed to clear all revents before thread 1 started scanning ufds, thread 1 would iterate straight through all ufds, past its bounds (no bound checks there), and return the first out-of-bounds entry that happens to have revents != 0

this issue needs at least documentation (although bounds-checking to prevent garbage in the result wouldn't hurt)

also, since there doesn't seem to be any locking w/ regards to ufds, it might be possible to corrupt python's heap, by concurrently invoking poll_register and poll_poll. poll_register could move the ufds array to another location while resizing it and poll_poll would subsequently overwrite memory that is not allocated anymore or allocated by someone else (did not test that)

python 2.5.5

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 106815
nosy: apexo, docs at python
priority: normal
severity: normal
status: open
title: select.poll is not thread safe
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Jun  1 00:24:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 31 May 2010 22:24:10 +0000
Subject: [docs] [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1275344649.95.0.716754337947.issue8865@psf.upfronthosting.co.za>


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

Do you have a script that reproduces it?

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

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

From report at bugs.python.org  Tue Jun  1 08:35:23 2010
From: report at bugs.python.org (Christian Schubert)
Date: Tue, 01 Jun 2010 06:35:23 +0000
Subject: [docs] [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1275374122.79.0.768137848872.issue8865@psf.upfronthosting.co.za>


Christian Schubert <bugs at apexo.de> added the comment:

okay, I've managed to put together a script that fairly consistently reproduces the problem on my (core2 duo 2,something GHz) machine

some parameters (sleep times) are randomized in each iteration, the script runs for 30 iterations, each for 1 second, and counts the number of events where the fd looks bogus (max 1 per iteration); some other events (fd correct, revents bogus are also reported, but not counted)

example output:
poll returned [(-3, 65535)], we were looking for fd 3
poll returned [(-3, 65535)], we were looking for fd 3
poll returned [(-3, 65535)], we were looking for fd 3
poll returned [(-3, 65535)], we were looking for fd 3
poll returned [(-3, 65535)], we were looking for fd 3
poll returned [(-1, 65535)], we were looking for fd 3
poll returned [(-1, 65535)], we were looking for fd 3
poll returned [(-1627358347, 60497)], we were looking for fd 3
should not get here; poll returned [(3, 0)]
poll returned [(-3, 65535)], we were looking for fd 3
9 events in 30 iterations

----------
Added file: http://bugs.python.org/file17510/select_threads.py

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

From report at bugs.python.org  Tue Jun  1 09:09:28 2010
From: report at bugs.python.org (Christian Schubert)
Date: Tue, 01 Jun 2010 07:09:28 +0000
Subject: [docs] [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1275376168.66.0.275641078025.issue8865@psf.upfronthosting.co.za>


Christian Schubert <bugs at apexo.de> added the comment:

the other issue (poll_register freeing data structures that poll_poll currently uses) can be reproduced by the attached script (at least I can)

depending on the parameters/circumstances it either segfaults or prints garbage results from poll, e.g. [(1684955474, 28192)]; the expected result would be [(3, 1)]

----------
Added file: http://bugs.python.org/file17511/concurrent_poll_and_register.py

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

From report at bugs.python.org  Wed Jun  2 01:45:43 2010
From: report at bugs.python.org (Yaniv Aknin)
Date: Tue, 01 Jun 2010 23:45:43 +0000
Subject: [docs] [issue8874] py3k documentation mentions deprecated opcode
	LOAD_LOCALS
In-Reply-To: <1275435943.68.0.198055718764.issue8874@psf.upfronthosting.co.za>
Message-ID: <1275435943.68.0.198055718764.issue8874@psf.upfronthosting.co.za>


New submission from Yaniv Aknin <yaniv.aknin at gmail.com>:

The documentation of the dis module mentions LOAD_LOCALS, which used to exist in Python 2.x and I believe was removed from py3k (doesn't appear in recent Include/opcode.h).

The exact offending section is: http://docs.python.org/py3k/library/dis.html#opcode-LOAD_LOCALS
I think it should just be edited out.

----------
assignee: docs at python
components: Documentation
messages: 106869
nosy: Yaniv.Aknin, docs at python
priority: normal
severity: normal
status: open
title: py3k documentation mentions deprecated opcode LOAD_LOCALS
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun  2 04:31:52 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 02 Jun 2010 02:31:52 +0000
Subject: [docs] [issue8788] urllib.urlencode documentation unclear on doseq
In-Reply-To: <1274542983.4.0.702068503568.issue8788@psf.upfronthosting.co.za>
Message-ID: <1275445912.19.0.752031506174.issue8788@psf.upfronthosting.co.za>


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

Agree to your concern that doseq parameter is not properly explained.
Fixed in r81645, r81646, r81647 and r81648.

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

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

From report at bugs.python.org  Wed Jun  2 04:45:31 2010
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 02 Jun 2010 02:45:31 +0000
Subject: [docs] [issue8875] XML-RPC improvement is described twice.
In-Reply-To: <1275446731.65.0.0364952757342.issue8875@psf.upfronthosting.co.za>
Message-ID: <1275446731.65.0.0364952757342.issue8875@psf.upfronthosting.co.za>


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

http://docs.python.org/dev/whatsnew/2.7.html#new-and-improved-modules

"The XML-RPC client and server, provided by..." appears twice.

----------
assignee: docs at python
components: Documentation
messages: 106875
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: XML-RPC improvement is described twice.
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  2 04:53:23 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jun 2010 02:53:23 +0000
Subject: [docs] [issue8875] XML-RPC improvement is described twice.
In-Reply-To: <1275446731.65.0.0364952757342.issue8875@psf.upfronthosting.co.za>
Message-ID: <1275447203.29.0.597072619765.issue8875@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jun  2 20:10:32 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jun 2010 18:10:32 +0000
Subject: [docs] [issue8874] py3k documentation mentions deprecated opcode
	LOAD_LOCALS
In-Reply-To: <1275435943.68.0.198055718764.issue8874@psf.upfronthosting.co.za>
Message-ID: <1275502232.16.0.0084436930389.issue8874@psf.upfronthosting.co.za>


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

Thanks. Removed in r81656.

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

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

From report at bugs.python.org  Thu Jun  3 13:49:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 11:49:59 +0000
Subject: [docs] [issue8888] Promote SafeConfigParser and warn about
	ConfigParser
In-Reply-To: <1275565799.83.0.624762218664.issue8888@psf.upfronthosting.co.za>
Message-ID: <1275565799.83.0.624762218664.issue8888@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Problems like #8880 could be prevented with a deprecation notice for the ConfigParser class, in favor of SafeConfigParser. (Not sure if R.?David Murray meant just a recommendation or a real deprecation.)

----------
assignee: docs at python
components: Documentation
messages: 106943
nosy: docs at python, merwok, r.david.murray
priority: normal
severity: normal
status: open
title: Promote SafeConfigParser and warn about ConfigParser
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Jun  3 23:36:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 21:36:22 +0000
Subject: [docs] [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275600982.49.0.783731612309.issue8890@psf.upfronthosting.co.za>


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

Would you be kind enough to provide a doc patch that would advertise using the tempfile module?

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

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

From report at bugs.python.org  Thu Jun  3 23:51:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 03 Jun 2010 21:51:01 +0000
Subject: [docs] [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275601861.59.0.287825433162.issue8890@psf.upfronthosting.co.za>


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

import logging
- LOG_FILENAME = '/tmp/logging_example.out'
+ LOG_FILENAME = 'example.log'
  logging.basicConfig(filename=LOG_FILENAME,level=logging.DEBUG)
  logging.debug('This message should go to the log file')

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

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

From report at bugs.python.org  Thu Jun  3 23:55:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 21:55:39 +0000
Subject: [docs] [issue8890] Module logging has dangerous examples
In-Reply-To: <1275601861.59.0.287825433162.issue8890@psf.upfronthosting.co.za>
Message-ID: <4C0824CE.9070903@netwok.org>


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

Nice, this example doesn?t require explaining tempfile and is shorter.
Add a notice before the code that you need to be in a directory with
write rights for this to work and I?m +1.

----------

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

From report at bugs.python.org  Fri Jun  4 00:35:39 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 03 Jun 2010 22:35:39 +0000
Subject: [docs] [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275604538.96.0.0575340356178.issue8890@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Documenation fix checked into trunk (r81680).

----------
assignee: docs at python -> vinay.sajip
nosy: +vinay.sajip
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Jun  4 00:39:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 03 Jun 2010 22:39:36 +0000
Subject: [docs] [issue8890] Module logging has dangerous examples
In-Reply-To: <1275604538.96.0.0575340356178.issue8890@psf.upfronthosting.co.za>
Message-ID: <4C082F23.1030001@netwok.org>


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

Thanks Vinay. You miss a closing paren in your commit.

----------

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

From report at bugs.python.org  Fri Jun  4 03:54:55 2010
From: report at bugs.python.org (Sean Reifschneider)
Date: Fri, 04 Jun 2010 01:54:55 +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: <1275616495.58.0.114875625102.issue8810@psf.upfronthosting.co.za>


Sean Reifschneider <jafo at tummy.com> added the comment:

Committed to 2.7 in 81681 and 3.x in 81682.

----------
keywords: +needs review -patch
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

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

From report at bugs.python.org  Fri Jun  4 05:31:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 03:31:23 +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: <1275622282.74.0.878800728613.issue8810@psf.upfronthosting.co.za>


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

> In this case, the docs.python.org link you point to seems
> to be correct, saying that it returns a timedelta.

This issue is specifically about ReST documentation, not the docstring. I explained in the opening comment that '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.'  Ironically, you not noticing that reaffirms my proposition that "many users won't read past the first sentence." :-)

Also, the documentation for tzinfo.dst is similarly unclear with ReST text slightly better than docstring.

Finally, please use rNNNNN form for revisions in commit comments.  These are converted to hyperlinks by the tracker.  For example, your commit comment would become:

  Committed to 2.7 in r81681 and 3.x in r81682.

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

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

From report at bugs.python.org  Fri Jun  4 05:31:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 03:31:45 +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: <1275622305.67.0.686830895195.issue8810@psf.upfronthosting.co.za>


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


----------
stage: committed/rejected -> needs patch

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

From report at bugs.python.org  Fri Jun  4 05:32:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 03:32:15 +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: <1275622335.21.0.247615935342.issue8810@psf.upfronthosting.co.za>


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


----------
resolution: accepted -> 

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

From report at bugs.python.org  Fri Jun  4 06:02:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 04:02:29 +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: <1275624149.41.0.782796304632.issue8810@psf.upfronthosting.co.za>


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

Sean,

It looks like you committed your first patch rather than your second.  Is that what you intended?

Also in msg106734, you agree to change "West" to "west", but committed "West."  Note that "west" is correct.  In English, the West means the western part of the world while western direction is the west.

Pedantically, the UTC is not a location, so you cannot say "to the west of UTC".  Instead, you should say "to the west of the Greenwich Meridian."

Note how RFC 3339 defines the offset:

"""
   Numeric offsets are calculated as "local time minus UTC".  So the
   equivalent time in UTC can be determined by subtracting the offset
   from the local time.
"""

I think this is preferable because there are locations such as Spain to the west of Greenwich which use UTC+1.

----------

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

From report at bugs.python.org  Fri Jun  4 09:33:44 2010
From: report at bugs.python.org (Henri Salo)
Date: Fri, 04 Jun 2010 07:33:44 +0000
Subject: [docs] [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275636824.25.0.706057119852.issue8890@psf.upfronthosting.co.za>


Henri Salo <henri at nerv.fi> added the comment:

Please note that there is other similar examples as well. Even on the same page.

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

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

From report at bugs.python.org  Fri Jun  4 10:04:33 2010
From: report at bugs.python.org (Henri Salo)
Date: Fri, 04 Jun 2010 08:04:33 +0000
Subject: [docs] [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275638673.08.0.351919550327.issue8890@psf.upfronthosting.co.za>


Henri Salo <henri at nerv.fi> added the comment:

We should review all of these:

install/index.rst:   python setup.py build --build-base=/tmp/pybuild/foo-1.0
install/index.rst:   python setup.py install --install-base=/tmp
install/index.rst:would install pure modules to :file:`{/tmp/python/lib}` in the first case, and
install/index.rst:to :file:`{/tmp/lib}` in the second case.  (For the second case, you probably
install/index.rst:want to supply an installation base of :file:`/tmp/python`.)
library/pipes.rst:   >>> f=t.open('/tmp/1', 'w')
library/pipes.rst:   >>> open('/tmp/1').read()
library/mailcap.rst:   >>> mailcap.findmatch(d, 'video/mpeg', filename='/tmp/tmp1223')
library/mailcap.rst:   ('xmpeg /tmp/tmp1223', {'view': 'xmpeg %s'})
library/logging.rst:   LOG_FILENAME = '/tmp/logging_rotatingfile_example.out'
library/logging.rst:   /tmp/logging_rotatingfile_example.out
library/logging.rst:   /tmp/logging_rotatingfile_example.out.1
library/logging.rst:   /tmp/logging_rotatingfile_example.out.2
library/logging.rst:   /tmp/logging_rotatingfile_example.out.3
library/logging.rst:   /tmp/logging_rotatingfile_example.out.4
library/logging.rst:   /tmp/logging_rotatingfile_example.out.5
library/logging.rst:The most current file is always :file:`/tmp/logging_rotatingfile_example.out`,
library/logging.rst:                       filename='/tmp/myapp.log',
library/logging.rst:which results in output (written to ``/tmp/myapp.log``) which should look
library/atexit.rst:       _count = int(open("/tmp/counter").read())
library/atexit.rst:       open("/tmp/counter", "w").write("%d" % _count)
library/imghdr.rst:   >>> imghdr.what('/tmp/bass.gif')
library/tempfile.rst:         '/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-/tmpG7V1Y0'
library/tempfile.rst:      * On all other platforms, the directories :file:`/tmp`, :file:`/var/tmp`, and
library/tempfile.rst:        :file:`/usr/tmp`, in that order.
library/posixfile.rst:   file = posixfile.open('/tmp/test', 'w')
library/cgi.rst:   cgitb.enable(display=0, logdir="/tmp")
library/optparse.rst:   prog -v --report /tmp/report.txt foo bar
library/optparse.rst:takes one argument, ``"/tmp/report.txt"`` is an option argument.  ``"foo"`` and
library/rexec.rst:   :file:`/tmp` or uploading it to the :file:`/incoming` directory of your public
library/rexec.rst::file:`/tmp` to be written, we can subclass the :class:`RExec` class::
library/rexec.rst:               # check filename : must begin with /tmp/
library/rexec.rst:               if file[:5]!='/tmp/':
library/rexec.rst:                   raise IOError("can't write outside /tmp")
library/rexec.rst:called :file:`/tmp/foo/../bar`.  To fix this, the :meth:`r_open` method would
library/rexec.rst:have to simplify the filename to :file:`/tmp/bar`, which would require splitting
library/compiler.rst::file:`/tmp/doublelib.py`.  ::
library/compiler.rst:   >>> mod = compiler.parseFile("/tmp/doublelib.py")
library/zipimport.rst:subdirectory.  For example, the path :file:`/tmp/example.zip/lib/` would only
library/zipimport.rst:   $ unzip -l /tmp/example.zip
library/zipimport.rst:   Archive:  /tmp/example.zip
library/zipimport.rst:   >>> sys.path.insert(0, '/tmp/example.zip')  # Add .zip file to front of path
library/zipimport.rst:   '/tmp/example.zip/jwzthreading.py'
library/trace.rst:   # make a report, placing output in /tmp
library/trace.rst:   r.write_results(show_missing=True, coverdir="/tmp")
library/nntplib.rst:   >>> f = open('/tmp/article')
library/bsddb.rst:   >>> db = bsddb.btopen('/tmp/spam.db', 'c')
library/sqlite3.rst::file:`/tmp/example` file::
library/sqlite3.rst:   conn = sqlite3.connect('/tmp/example')
tutorial/inputoutput.rst:   >>> f = open('/tmp/workfile', 'w')
tutorial/inputoutput.rst:   <open file '/tmp/workfile', mode 'w' at 80a0960>
tutorial/inputoutput.rst:   >>> f = open('/tmp/workfile', 'r+')
tutorial/inputoutput.rst:    >>> with open('/tmp/workfile', 'r') as f:
whatsnew/2.3.rst:   amk at nyman:~/src/python$ unzip -l /tmp/example.zip
whatsnew/2.3.rst:   Archive:  /tmp/example.zip
whatsnew/2.3.rst:   >>> sys.path.insert(0, '/tmp/example.zip')  # Add .zip file to front of path
whatsnew/2.3.rst:   '/tmp/example.zip/jwzthreading.py'
whatsnew/2.3.rst:subdirectory; for example, the path :file:`/tmp/example.zip/lib/` would only
whatsnew/2.3.rst:     >>> os.stat("/tmp").st_mtime
whatsnew/2.3.rst:     >>> os.stat("/tmp").st_mtime
whatsnew/2.0.rst:   output = UTF8_streamwriter( open( '/tmp/output', 'wb') )
whatsnew/2.0.rst:   input = UTF8_streamreader( open( '/tmp/output', 'rb') )
whatsnew/2.6.rst:      shutil.copytree('Doc/library', '/tmp/library',
whatsnew/2.6.rst:    # to the /tmp directory.
whatsnew/2.6.rst:    z.extract('Python/sysmodule.c', '/tmp')
whatsnew/2.6.rst:    plistlib.writePlist(data_struct, '/tmp/customizations.plist')
whatsnew/2.6.rst:    new_struct = plistlib.readPlist('/tmp/customizations.plist')
whatsnew/2.7.rst:    -> ./python.exe argparse-example.py -v -o /tmp/output -C 4 file1 file2
whatsnew/2.7.rst:    {'output': '/tmp/output',
whatsnew/2.4.rst:   sts = subprocess.call(['dpkg', '-i', '/tmp/new-package.deb'])
whatsnew/2.4.rst:   sts = subprocess.call('dpkg -i /tmp/new-package.deb', shell=True)
whatsnew/2.5.rst:     dest = mailbox.mbox('/tmp/mbox')
whatsnew/2.5.rst::file:`/tmp/example` file::
whatsnew/2.5.rst:   conn = sqlite3.connect('/tmp/example')

I can't change the status of resolution.

----------

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

From report at bugs.python.org  Fri Jun  4 13:26:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 11:26:47 +0000
Subject: [docs] [issue8895] newline vs. newlines in io module
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275650807.34.0.596598824542.issue8895@psf.upfronthosting.co.za>


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

Thanks for the report. Could you check the docs for 3.1 and 3.x trunk (py3k) too?

----------
assignee:  -> docs at python
components: +Documentation -IO
nosy: +docs at python, merwok
stage:  -> needs patch
title: newline arg/attribute in the module io -> newline vs. newlines in io module

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

From report at bugs.python.org  Fri Jun  4 13:49:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 11:49:43 +0000
Subject: [docs] [issue8895] newline vs. newlines in io module
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275652183.03.0.628521298561.issue8895@psf.upfronthosting.co.za>


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

This is as documented:

   http://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines

The keyword argument is named 'newline', the attribute is named 'newlines'.  The attribute does not record what was passed to the newline argument, rather it records what newlines have been actually encountered.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Fri Jun  4 15:44:44 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 04 Jun 2010 13:44:44 +0000
Subject: [docs] [issue8895] newline vs. newlines in io module
In-Reply-To: <1275652183.03.0.628521298561.issue8895@psf.upfronthosting.co.za>
Message-ID: <AANLkTikEexfbK9Itb9sGWfm6cFG2nlckBrnf2EWAmibT@mail.gmail.com>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

2010/6/4 R. David Murray <report at bugs.python.org>

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> This is as documented:
>
>   http://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines
>
> The keyword argument is named 'newline', the attribute is named 'newlines'.
>  The attribute does not record what was passed to the newline argument,
> rather it records what newlines have been actually encountered.
>

Ok, I see. I read, reread the doc prior posting, and, in my mind, it is not
obvious to understand this subtle difference from the doc.
Sorry for the noise.
Regards.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8895>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">2010/6/4 R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
This is as documented:<br>
<br>
 ?? <a href="http://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines" target="_blank">http://docs.python.org/dev/3.0/library/io.html#io.TextIOBase.newlines</a><br>
<br>
The keyword argument is named &#39;newline&#39;, the attribute is named &#39;newlines&#39;. ??The attribute does not record what was passed to the newline argument, rather it records what newlines have been actually encountered.<br>
</blockquote></div><br>Ok, I see. I read, reread the doc prior posting, and, in my mind, it is not obvious to understand this subtle difference from the doc.<br>Sorry for the noise.<br>Regards.<br><br>

From report at bugs.python.org  Fri Jun  4 15:45:14 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 04 Jun 2010 13:45:14 +0000
Subject: [docs] [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275659114.21.0.816534772477.issue8890@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Other logging cases contained /tmp/ has now been removed, the missing parenthesis added and the result checked in to trunk (r81684). 

I'll keep the issue open for the cases which remain in the other documentation. but remove myself from the assigned-to and change the resolution to "accepted".

----------
assignee: vinay.sajip -> 
resolution: fixed -> accepted

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

From report at bugs.python.org  Fri Jun  4 15:47:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 13:47:27 +0000
Subject: [docs] [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275659247.19.0.912264654272.issue8890@psf.upfronthosting.co.za>


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

Thanks for the listing Henri. Not all of these examples have to be changed; I?ll review them in some days if you want.

----------

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

From report at bugs.python.org  Fri Jun  4 15:48:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 13:48:44 +0000
Subject: [docs] [issue8895] newline vs. newlines in io module
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275659324.69.0.207644095438.issue8895@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file17549/unnamed

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

From report at bugs.python.org  Fri Jun  4 15:49:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 04 Jun 2010 13:49:11 +0000
Subject: [docs] [issue8895] newline vs. newlines in io module
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275659351.45.0.959470544624.issue8895@psf.upfronthosting.co.za>


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

Could you think of a way to improve the docs on that point?

----------

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

From report at bugs.python.org  Fri Jun  4 16:56:01 2010
From: report at bugs.python.org (Henri Salo)
Date: Fri, 04 Jun 2010 14:56:01 +0000
Subject: [docs] [issue8890] Module logging has dangerous examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275663361.68.0.865498164227.issue8890@psf.upfronthosting.co.za>


Henri Salo <henri at nerv.fi> added the comment:

Please review the changes for the quality of the documentation. There probably is still more places to change. References can be made to: <http://docs.python.org/library/tempfile.html#tempfile.mkstemp>

----------

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

From report at bugs.python.org  Fri Jun  4 16:56:21 2010
From: report at bugs.python.org (Henri Salo)
Date: Fri, 04 Jun 2010 14:56:21 +0000
Subject: [docs] [issue8890] Modules have dangerous examples in documentation
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275663381.59.0.226272013143.issue8890@psf.upfronthosting.co.za>


Changes by Henri Salo <henri at nerv.fi>:


----------
title: Module logging has dangerous examples -> Modules have dangerous examples in documentation

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

From report at bugs.python.org  Fri Jun  4 19:45:54 2010
From: report at bugs.python.org (Jean-Michel Fauth)
Date: Fri, 04 Jun 2010 17:45:54 +0000
Subject: [docs] [issue8895] newline vs. newlines in io module
In-Reply-To: <1275659351.45.0.959470544624.issue8895@psf.upfronthosting.co.za>
Message-ID: <AANLkTimsgmkbzdOEfpJ0DDDk_G8IKxYmLERZXDBZAf6V@mail.gmail.com>


Jean-Michel Fauth <wxjmfauth at gmail.com> added the comment:

2010/6/4 ??ric Araujo <report at bugs.python.org>

>
> ??ric Araujo <merwok at netwok.org> added the comment:
>
> Could you think of a way to improve the docs on that point?
>
> ----------
>
> Quick and dirty answer.

I have ~10 years experience with Python and it seems
to me the io module is technically excellent.

However, I have found it is not so obvious to
understand the usage of all these arguments,
errors, encoding, line_buffering, ... in the
class constructors and methods like io.open().

The doc describes what these arguments are,
their states, but not too much how to use
them.

As an exemple, I read some time ago on the c.l.p
mailing list, somebody complaining about the "encoding"
argument of the class TextIOWrapper. He defined an
"encoding='utf-8'" in the ctor and did not
understand why his "text" was not automagically
encoded. Answer: the encoding arg is only a kind
of information and does not do anything.

BTW, it was only when I read that post, I understand
a little bit more.

Regards.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8895>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">2010/6/4 ??ric Araujo <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<br>
Could you think of a way to improve the docs on that point?<br>
<br>
----------<br>
<div><div></div><div class="h5"><br></div></div></blockquote></div>Quick and dirty answer.<br><br>I have ~10 years experience with Python and it seems<br>to me the io module is technically excellent.<br><br>However, I have found it is not so obvious to<br>
understand the usage of all these arguments,<br>errors, encoding, line_buffering, ... in the <br>class constructors and methods like io.open().<br><br>The doc describes what these arguments are,<br>their states, but not too much how to use<br>
them.<br><br>As an exemple, I read some time ago on the c.l.p<br>mailing list, somebody complaining about the &quot;encoding&quot;<br>argument of the class TextIOWrapper. He defined an <br>&quot;encoding=&#39;utf-8&#39;&quot; in the ctor and did not<br>
understand why his &quot;text&quot; was not automagically<br>encoded. Answer: the encoding arg is only a kind<br>of information and does not do anything.<br><br>BTW, it was only when I read that post, I understand<br>a little bit more.<br>
<br>Regards.<br><br>

From report at bugs.python.org  Fri Jun  4 20:33:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jun 2010 18:33:37 +0000
Subject: [docs] [issue8895] newline vs. newlines in io module
In-Reply-To: <1275642358.27.0.48977523408.issue8895@psf.upfronthosting.co.za>
Message-ID: <1275676417.55.0.138666859023.issue8895@psf.upfronthosting.co.za>


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

This is off topic for this issue, but what you just reported makes no sense to me.  TextIOWrapper calls the encoder corresponding to the specified encoding in its write method.

That said, it is true that the IO docs are currently a class reference and not a user reference, and this should be fixed.  There may even already be an open issue for this.

----------

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

From report at bugs.python.org  Fri Jun  4 21:47:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 19:47:17 +0000
Subject: [docs] [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The time.struct_time class is missing class and field docstrings: 

>>> time.struct_time.__doc__ is None
True
>>> time.struct_time.tm_year.__doc__ is None
True

This is significant because it is not obvious that field values are different from those of C language struct tm fields with the same names. (While module level docstring describes the timetuple, it does not list the names of the struct_time fields or mentions struct_time.)

With the attached patch,

>>> from time import *
>>> localtime()
time.struct_time(tm_year=2010, tm_mon=6, tm_mday=4, tm_hour=15, tm_min=27, tm_sec=15, tm_wday=4, tm_yday=155, tm_isdst=1)
>>> help(_)
Help on struct_time object:

time.struct_time = class struct_time(__builtin__.object)
 |  The time value as returned by gmtime(), localtime(), and strptime(), and accepted
 |  by asctime(), mktime() and strftime(), may be considered as a sequence of 9 integers.
 |  Note that several fields' values are not the same as those defined by the C language
 |  standard for struct tm.  For example, the value of tm_year is the actual year, not
 |  year - 1900.   See individual fields' descriptions for details.
...
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  tm_hour
 |      hours, range [0 - 23]
 |  
 |  tm_isdst
 |      1 if summer time is in effect, 0 if not, and -1 if cannot be determined
 |  
 |  tm_mday
 |      day of month, range [1 - 31]
 |  
 |  tm_min
 |      minutes, range [0 - 59]
 |  
 |  tm_mon
 |      month of year, range [1 - 12]
 |  
 |  tm_sec
 |      seconds, range [0 - 61])
 |  
 |  tm_wday
 |      day of week, range [0,6], Monday is 0
 |  
 |  tm_yday
 |      day of year, range [1,366]
 |  
 |  tm_year
 |      year, for example, 1993
 |  
 |  ----------------------------------------------------------------------

----------
assignee: belopolsky
components: Documentation
files: struct_time_doc.diff
keywords: easy, patch
messages: 107089
nosy: belopolsky, docs at python, mark.dickinson
priority: normal
severity: normal
stage: commit review
status: open
title: Add docstrings to time.struct_time
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17556/struct_time_doc.diff

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

From report at bugs.python.org  Fri Jun  4 22:21:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Jun 2010 20:21:50 +0000
Subject: [docs] [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275682909.91.0.0503379518119.issue8899@psf.upfronthosting.co.za>


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

Patch review: 
* Quite a few lines are pretty long.  Please stay below 80 chars/line.
* There are trailing spaces in two member docs.
* The range notation is inconsistent.  [first, last] or [first, last+1) is what we generally use.
* "if cannot be determined" does not sound grammatical, maybe just "unknown" is better.
* Between "strftime()" and "may be considered" the sentence should be split.

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

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

From report at bugs.python.org  Fri Jun  4 22:46:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 20:46:33 +0000
Subject: [docs] [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275684392.15.0.2895195253.issue8899@psf.upfronthosting.co.za>


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

Please see fixes in issue8899.diff.

* Quite a few lines are pretty long.  Please stay below 80 chars/line.

Fixed.

* There are trailing spaces in two member docs.

Fixed.

* The range notation is inconsistent.  [first, last] or [first, last+1) is what we generally use.

Fixed in docstrings and time.rst.

* "if cannot be determined" does not sound grammatical, maybe just "unknown" is better.

Fixed.  POSIX spec uses "if the information is not available", but I like 

* Between "strftime()" and "may be considered" the sentence should be split.

Fixed in docstrings and time.rst.

----------
Added file: http://bugs.python.org/file17557/issue8899.diff

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

From report at bugs.python.org  Fri Jun  4 23:09:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 04 Jun 2010 21:09:11 +0000
Subject: [docs] [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275685751.29.0.0815406834185.issue8899@psf.upfronthosting.co.za>


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

The first change in time.rst is not needed; there the sentence is not a direct description of struct_time.  The rest is good to commit.

----------

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

From report at bugs.python.org  Sat Jun  5 00:26:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Jun 2010 22:26:24 +0000
Subject: [docs] [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275690384.22.0.189133005284.issue8899@psf.upfronthosting.co.za>


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


----------
resolution:  -> accepted

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

From report at bugs.python.org  Sat Jun  5 01:16:23 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jun 2010 23:16:23 +0000
Subject: [docs] [issue8890] Modules have dangerous examples in documentation
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275693382.92.0.586800244335.issue8890@psf.upfronthosting.co.za>


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

Henri, the owasp link you gave in your opening post now gives Bad Title error msg.

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

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

From report at bugs.python.org  Sat Jun  5 12:30:48 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 10:30:48 +0000
Subject: [docs] [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

It would be helpful to have examples how to patch docs in some place like 
http://docs.python.org/bugs.html

For example, in CHM version of 2.6.5 manual open() anchor points to reference/datamodel.html#index-844 and to tutorial/inputoutput.html#index-1080 but not to library/functions.html#open

----------
assignee: docs at python
components: Documentation
messages: 107127
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: quick example how to fix docs

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

From report at bugs.python.org  Sat Jun  5 17:13:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 15:13:30 +0000
Subject: [docs] [issue8899] Add docstrings to time.struct_time
In-Reply-To: <1275680837.43.0.377357755743.issue8899@psf.upfronthosting.co.za>
Message-ID: <1275750810.75.0.240447112795.issue8899@psf.upfronthosting.co.za>


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

Committed in r81756 (trunk) and r81757 (py3k).

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

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

From report at bugs.python.org  Sat Jun  5 17:40:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 15:40:26 +0000
Subject: [docs] [issue8907] time module documentation differs in trunk and
	py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1275752426.53.0.823315242158.issue8907@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jun  5 17:48:31 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 15:48:31 +0000
Subject: [docs] [issue7229] [PATCH] Manual entry for time.daylight can be
	misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1275752911.34.0.233075830294.issue7229@psf.upfronthosting.co.za>


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

issue8907 seems related.

----------
nosy: +belopolsky, docs at python

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

From report at bugs.python.org  Sat Jun  5 17:52:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 05 Jun 2010 15:52:27 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1275753147.6.0.120916771899.issue7229@psf.upfronthosting.co.za>


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


----------
title: [PATCH] Manual entry for time.daylight can be misleading -> Manual entry for time.daylight can be misleading

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

From report at bugs.python.org  Sat Jun  5 17:58:03 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 15:58:03 +0000
Subject: [docs] [issue8151] [patch] convenience links for subprocess.call()
In-Reply-To: <1268692197.73.0.576136858806.issue8151@psf.upfronthosting.co.za>
Message-ID: <1275753483.32.0.176403402181.issue8151@psf.upfronthosting.co.za>


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

easy, just waits to be ported

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

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

From report at bugs.python.org  Sat Jun  5 18:04:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 16:04:10 +0000
Subject: [docs] [issue8519] [patch] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1275753850.96.0.835770564249.issue8519@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jun  5 18:10:24 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 16:10:24 +0000
Subject: [docs] [issue1635217] Add example of distutils setup() with
	"requires"	argument
Message-ID: <1275754223.84.0.844192580409.issue1635217@psf.upfronthosting.co.za>


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

Neal, why a piece from issue1635217#msg31028 doesn't qualify as an example?

It seems that this issue may become obsolete with new packaging guide coming up.

----------
components: +Distutils, Distutils2
nosy: +docs at python
versions: +Python 2.7, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Sat Jun  5 18:15:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Jun 2010 16:15:02 +0000
Subject: [docs] [issue8151] [patch] convenience links for subprocess.call()
In-Reply-To: <1268692197.73.0.576136858806.issue8151@psf.upfronthosting.co.za>
Message-ID: <1275754502.34.0.890225290758.issue8151@psf.upfronthosting.co.za>


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

Already done AFAICS.

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

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

From report at bugs.python.org  Sat Jun  5 18:32:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 16:32:21 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1275755540.13.0.788880042553.issue7229@psf.upfronthosting.co.za>


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

It may be a bit off-topic for this issue, but I don't like that the python manual uses UTC as if it was a geographical location.  UTC is a time scale.  You cannot be to the east or to the west of UTC just as you cannot be to the north of the Gregorian calendar.

Even if we replace UTC with Prime or Greenwich Meridian, the manual would still be incorrect because some regions in the western hemisphere use positive offsets from UTC.  For example, Madrid is at 3? 42' West, but uses Central European Time which is UTC+1.

Since there are no plans to include any kind of geographical database in  the standard library, I think the manual should avoid use of geographical terms.

What I need to know from the manual is how to get local time from utc and daylight savings time from the standard time.

>From the top of my head, I know that localtime = utctime + utcoffset, but I am not sure whether dsttime = stdtime + dst or dsttime = stdtime - dst and the manual, reworded or not, does not immediately help me.

As for the original issue, do we really need time.daylight at all?  ISTM that in timezones without DST, time.altzone = time.timezone, so the software that unconditionally accounts for DST will still work correctly and software that wants to optimize for no DST case can simply chsck time.altzone == time.timezone.

$ TZ=UTC ./python.exe -c "import time; print(time.daylight, time.tzname, (time.timezone, time.altzone))"
0 ('UTC', 'UTC') (0, 0)

In other words, time.daylight is strictly redundant.

----------

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

From report at bugs.python.org  Sat Jun  5 19:24:03 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 17:24:03 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1275758643.04.0.779704816395.issue7229@psf.upfronthosting.co.za>


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

It is too hard to track this issue without quotes from manual. Let's bring context into discussion:

http://docs.python.org/library/time.html#time.altzone
  UTC offset of the local DST timezone if one is defined. Only use this if daylight is nonzero.
http://docs.python.org/library/time.html#time.daylight
  Nonzero if a DST timezone is defined.
http://docs.python.org/library/time.html#time.timezone
  UTC offset of the local (non-DST) timezone


So, to answer a question "What is the current UTC offset?" you need to:
if time.daylight:
  if time.altzone: # using only if defined
     use time.altzone
  else:
     use time.timezone
else:
  use time.timezone


1. Is that really works like described above?
2. Should we at least group these timezone variables?


As for offtopic UTC vs GMT - I doubt there is a way to clearly express that the offset sign of the returned values is negated in comparison with real "UTC offsets" without resorting to some king of alternative east/west scale.

----------

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

From report at bugs.python.org  Sat Jun  5 19:43:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 17:43:59 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1275758643.04.0.779704816395.issue7229@psf.upfronthosting.co.za>
Message-ID: <AANLkTinwNcQDui2LLr5rEPpiuIUCmnVP5T1nrxsMdDIC@mail.gmail.com>


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

On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> As for offtopic UTC vs GMT - I doubt there is a way to clearly express that the offset sign of the
> returned values is negated in comparison with real "UTC offsets" without resorting to some
> king of alternative east/west scale.

Sure there is.  Here is how RFC 3339 handles this:

"""
   Numeric offsets are calculated as "local time minus UTC".  So the
   equivalent time in UTC can be determined by subtracting the offset
   from the local time.
"""

and here is a quote from MacOS man page for tzset:

"""
           offset       Indicates the value one must add to the local
time to arrive at Coor-
                        dinated Universal Time.
"""

No geographic reference needed.  (And the issue is not UTC vs. GMT:
both UTC and GMT are timescales, sometimes even considered the same.
The off-topic issue is UTC vs. Prime Meridian.)

----------

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

From report at bugs.python.org  Sat Jun  5 20:09:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 05 Jun 2010 18:09:47 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1275758643.04.0.779704816395.issue7229@psf.upfronthosting.co.za>
Message-ID: <AANLkTik9KML7e-WizIazDKO7cSSyXgUa4hQ21MS7VmzU@mail.gmail.com>


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

On Sat, Jun 5, 2010 at 1:24 PM, anatoly techtonik
<report at bugs.python.org> wrote:
..
> So, to answer a question "What is the current UTC offset?" you need to:
> if time.daylight:
> ?if time.altzone: # using only if defined
> ? ? use time.altzone
> ?else:
> ? ? use time.timezone
> else:
> ?use time.timezone
>

No, if time.daylight is non-zero, you still need to check the current
value of tm_isdst from localtime().

Here is how bzr reportedly handles this:

def local_time_offset(t=None):
    """Return offset of local zone from GMT, either at present or at time t."""
    # python2.3 localtime() can't take None
    if t is None:
        t = time.time()

    if time.localtime(t).tm_isdst and time.daylight:
        return -time.altzone
    else:
        return -time.timezone

http://blogs.gnome.org/jamesh/2006/12/31/python-timetimezone-timealtzone-edge-case/

> 1. Is that really works like described above?

That works for current time, but subject to race condition twice a
year.  You should get time and dst indormation from the same
localtime() call.  For problems with  arbitrary time t, see the link
above.

> 2. Should we at least group these timezone variables?
>

The come from existing C library practice.  POSIX defines tzname[2],
timezone, and daylight.

http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html

altzone is a popular non-standard addition which is strictly
redundant.  Since POSIX does not define anything about daylight
variable other than it has to be zero when DST is not in effect,
compliant implementations can define is so that altzone = timezone -
daylight.

These variables are already grouped in tzinfo API.  What is missing is
method to get concrete tzinfo implementation in stdlib.  See
issue5094.

----------

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

From report at bugs.python.org  Sat Jun  5 23:41:38 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 05 Jun 2010 21:41:38 +0000
Subject: [docs] [issue8909] mention bitmap size for bdist_wininst
Message-ID: <1275774098.91.0.754190783405.issue8909@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jun  6 01:47:34 2010
From: report at bugs.python.org (Henri Salo)
Date: Sat, 05 Jun 2010 23:47:34 +0000
Subject: [docs] [issue8890] Modules have dangerous examples in documentation
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1275781653.86.0.830705339789.issue8890@psf.upfronthosting.co.za>


Henri Salo <henri at nerv.fi> added the comment:

No it does not.

http://www.owasp.org/index.php/Insecure_Temporary_File

----------

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

From report at bugs.python.org  Sun Jun  6 05:26:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 03:26:20 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Documenting that would help get people using datetime objects with string.format more.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 107179
nosy: brett.cannon, docs at python
priority: low
severity: normal
status: open
title: Document that datetime.__format__ is datetime.strftime
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun  6 07:56:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 05:56:13 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275803772.87.0.206539659524.issue8913@psf.upfronthosting.co.za>


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

I wonder if this is subject to change.  I find it odd that

>>> "{:g}".format(1e3)
'1000'

but one has to use % in

>>> "{:%Y}".format(datetime.now())
'2010'

It is also different from PEP 3101 recommendation:
"""
    An example is the 'datetime' class,
    whose format specifiers might look something like the
    arguments to the strftime() function:

        "Today is: {0:a b d H:M:S Y}".format(datetime.now())
"""
The above, however, should probably be

"Today is: {0:a} {0:b} {0:d} {0:H}:{0:M}:{0:S} {0:Y}".format(datetime.now())

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

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

From techtonik at gmail.com  Sun Jun  6 16:35:51 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 6 Jun 2010 17:35:51 +0300
Subject: [docs] Sphinx indexing
Message-ID: <AANLkTimzzwYuvES6HbfxEpELYZxYSpDrmx0aOr_7A_-O@mail.gmail.com>

I've stumbled upon definition of `open` function in
http://docs.python.org/genindex-O.html
and I wonder - why none of the following entries leads to definition of `open`?

open
   built-in function, [1]

I see that linked paragraphs have explicit `builtin: open` markup, but
can't find their intended
usage in Sphinx documentation. To me the index should look like:

open (built-in function)
   Files
   Reading and Writing Files

or

open (built-in function)
   definition
   [1] Files
   [2] Reading and Writing Files

or

open (built-in function)
   definition
   references [1], [2]

Another issue that paragraph anchors generate links that lead to
paragraph contents while
in most cases it would be more helpful to read paragraph title, which
is scrolled offscreen.
-- 
anatoly t.

From report at bugs.python.org  Sun Jun  6 21:03:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 19:03:55 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>


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

http://docs.python.org/py3k/c-api/arg.html is unclear about what is a "string".

Attached patch:
 - Use directly bytes, bytearray and str types
 - Replace "default encoding" by "``'utf-8'`` encoding"
 - Add bytes and/or bytearray to "... buffer compatible object" because it's not easy to understand what is a buffer compatible object, especially because there are different kind of buffer objects: read-only, read-write, pinned, etc.
 - Fix reST syntax ("..note ::")
 - Fix "es", "es#", "et" and "et#" formats: they doesn't accept "character buffer compatible object" (can someone double check that?)

Py_BuildValue(): I choosed to mark U and U# formats as deprecated alias to s/s# => see issue #8848.

I wrote the patch by reading getargs.c.

----------
assignee: docs at python
components: Documentation, Unicode
files: arg.patch
keywords: patch
messages: 107209
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Improve c-api/arg.rst: use "bytes" or "str" types instead of "string"
versions: Python 3.2
Added file: http://bugs.python.org/file17576/arg.patch

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

From report at bugs.python.org  Sun Jun  6 21:15:20 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jun 2010 19:15:20 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275851720.56.0.383189869494.issue8913@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I don't find it odd at all that you use datetime-specific formats instead of integral formats to get numbers out of a datetime object; they are totally different things. And one of the reasons for __format__ support is to have DSLs such as the one for datetime objects.

As for pulling out individual objects, that just looks ugly, so I wouldn't advocate pulling out individual values and then formatting them individually in the string itself.

----------

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

From report at bugs.python.org  Sun Jun  6 21:40:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 19:40:55 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275853254.94.0.0809272531495.issue8925@psf.upfronthosting.co.za>


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

-   buffer protocol (such as :class:`bytes` or :class:`bytearray` objects).
+   buffer protocol.

Is there a reST construct to use here, say to reference a PEP or point to a glossary entry that defines this protocol?

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

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

From report at bugs.python.org  Sun Jun  6 21:56:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jun 2010 19:56:24 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275854183.95.0.372846050297.issue8925@psf.upfronthosting.co.za>


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

If there is a glossary entry, use :term:`buffer protocol`.  If there is none, write one :)

PEPs are referenced by :pep:`4711`.

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

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

From report at bugs.python.org  Sun Jun  6 22:18:02 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Jun 2010 20:18:02 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275855481.84.0.0594177581524.issue8913@psf.upfronthosting.co.za>


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

I think Alexander's example is best written as:
"Today is: {0:%a %b %d %H:%M:%S %Y}".format(datetime.now())

I agree with Brett that there's nothing unusual about having type-specific formatting languages, and for datetime strftime is the obvious choice. It's a little unfortunate that % is used, as it's mildly confusing with %-formatting, but not much can be done with that issue.

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

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

From report at bugs.python.org  Sun Jun  6 22:19:04 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Jun 2010 20:19:04 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275855544.24.0.613420693819.issue8913@psf.upfronthosting.co.za>


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

This documentation should also be added for datetime.time and datetime.date, in addition to datetime.datetime.

----------

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

From report at bugs.python.org  Sun Jun  6 22:23:45 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Jun 2010 20:23:45 +0000
Subject: [docs] [issue8909] mention bitmap size for bdist_wininst
In-Reply-To: <1275855825.9.0.442655313563.issue8909@psf.upfronthosting.co.za>
Message-ID: <1275855825.9.0.442655313563.issue8909@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

done in r81788, r81789, r81790, r81791

thanks!

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

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

From report at bugs.python.org  Sun Jun  6 23:06:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 06 Jun 2010 21:06:19 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275858379.38.0.138699635554.issue8913@psf.upfronthosting.co.za>


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

The problem I have with strftime %-format codes is that according to BSD manual page they have already ran out of English alphabet and still "there is no conversion specification for the phase of the moon." :-)

On a serious note, there are no codes to format TZ offset hours and minutes separately which precludes specifying an important RFC 3339 format.

I think we should take this opportunity to define a comprehensive mini-language for datetime formatting rather than slavishly reuse strftime.

The new mini-language may end up to be a superset of that for strftime, but I would rather not commit to supporting %-codes indefinitely.

----------

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

From report at bugs.python.org  Sun Jun  6 23:13:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jun 2010 21:13:59 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275858839.36.0.0955816790332.issue8925@psf.upfronthosting.co.za>


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

> Is there a reST construct to use here, say to reference a PEP 
> or point to a glossary entry that defines this protocol?

buffer API ("protocol" ?) is documented in Doc/c-api/buffer.rst. Should I link to this document? How?

----------

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

From report at bugs.python.org  Sun Jun  6 23:29:46 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 06 Jun 2010 21:29:46 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275859786.36.0.500939390115.issue8913@psf.upfronthosting.co.za>


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

Unfortunately I think it's too late to do anything about this. I, for one, have many lines of code in production that use the strftime format specifier for datetime.__format__.

You only option would be to invent a new language that was somehow distinguishable from the strftime specifiers, but I doubt you'd get much support.

I think it's better to extend strftime, and let __format__ benefit from it.

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

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

From report at bugs.python.org  Sun Jun  6 23:38:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 21:38:16 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275860296.02.0.677568046881.issue8925@psf.upfronthosting.co.za>


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

I see that the top section of this file can be referenced though the index entry named ?buffer interface?. Georg, would ?:term:`buffer interface`? work?

Victor, ?protocol? is the named used in Python for what you could call an interface, e.g. the iterator protocol, the sequence protocol,?etc. It?s a documented set of methods, return types and use cases.

----------

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

From report at bugs.python.org  Sun Jun  6 23:42:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 21:42:36 +0000
Subject: [docs] [issue8913] Document that datetime.__format__ is
	datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1275860556.29.0.633089971967.issue8913@psf.upfronthosting.co.za>


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

I think this particular wheel has one very good reinvention as the Locale Data Markup Language specification. Example from the Python Babel package:

>>> format_datetime(dt, "yyyyy.MMMM.dd GGG hh:mm a", locale='en')
u'02007.April.01 AD 03:30 PM'

http://unicode.org/reports/tr35/#Date_Format_Patterns
http://babel.edgewall.org/wiki/Documentation/dates.html#pattern-syntax

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

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

From report at bugs.python.org  Mon Jun  7 00:21:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Jun 2010 22:21:44 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275862904.85.0.533170745092.issue8925@psf.upfronthosting.co.za>


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

The glossary (see docs.python.org/glossary) does not have an entry for "buffer interface" or "buffer protocol".  An index entry just means that some location in the code defines this entry and gets a link back.

Of course, you can also link to the C API section using :ref:`bufferobjects`.

----------

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

From report at bugs.python.org  Mon Jun  7 00:26:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 06 Jun 2010 22:26:31 +0000
Subject: [docs] [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1275863191.75.0.981695971827.issue8904@psf.upfronthosting.co.za>


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

Would the addition of a link to http://www.python.org/dev/patches/ address your request?

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

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

From report at bugs.python.org  Mon Jun  7 02:39:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 07 Jun 2010 00:39:43 +0000
Subject: [docs] [issue8519] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1275871183.79.0.685211925111.issue8519@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
title: [patch] doc: termios and ioctl reference links -> doc: termios and ioctl reference links

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

From report at bugs.python.org  Mon Jun  7 09:32:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 07 Jun 2010 07:32:23 +0000
Subject: [docs] [issue8904] quick example how to fix docs
In-Reply-To: <1275863191.75.0.981695971827.issue8904@psf.upfronthosting.co.za>
Message-ID: <AANLkTimceeN0SzaSPirXDBbGhGai0WaCsSKR9eKIZBA0@mail.gmail.com>


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

On Mon, Jun 7, 2010 at 1:26 AM, ?ric Araujo <report at bugs.python.org> wrote:
>
> Would the addition of a link to http://www.python.org/dev/patches/ address your request?

No. It is not quick. It short only for an experienced developer. The
example (or documentation HowTo) should be user based with explanation
how to checkout, compile and test the changes.

----------

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

From report at bugs.python.org  Mon Jun  7 15:25:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 07 Jun 2010 13:25:02 +0000
Subject: [docs] [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1275917102.74.0.351202377008.issue8904@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I think what you are suggesting is outside of the scope of that document -- it appears that the page intends to be quick and strictly focused on reporting bugs, not fixing them.

----------
nosy: +brian.curtin
status: open -> pending

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

From report at bugs.python.org  Mon Jun  7 15:45:05 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 07 Jun 2010 13:45:05 +0000
Subject: [docs] [issue8875] XML-RPC improvement is described twice.
In-Reply-To: <1275446731.65.0.0364952757342.issue8875@psf.upfronthosting.co.za>
Message-ID: <1275918305.47.0.394499753011.issue8875@psf.upfronthosting.co.za>


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

Fixed in rev81801.  Thanks for your report!

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

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

From report at bugs.python.org  Mon Jun  7 19:10:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 07 Jun 2010 17:10:26 +0000
Subject: [docs] [issue8910] Write a text file explaining why Lib/test/data
	exists
In-Reply-To: <1275793580.19.0.611567237471.issue8910@psf.upfronthosting.co.za>
Message-ID: <1275930625.8.0.110376020589.issue8910@psf.upfronthosting.co.za>


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

Attaching a proposal.

I think the component is a grey area between tests and documentation, so I?d be for including this file in all four branches.

----------
keywords: +needs review, patch
nosy: +docs at python, merwok
Added file: http://bugs.python.org/file17581/README

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

From report at bugs.python.org  Mon Jun  7 23:33:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 21:33:54 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275946434.86.0.499038339355.issue8925@psf.upfronthosting.co.za>


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

Commited to 3.2 (r81811) and 3.1 (r81812). The final patch adds also links to tuple, list, dict, float, complex and int. Replace also long by int (long doesn't exist anymore in Python3).

@merwok: Please open a new issue if you would like to improve the documentation about the buffer protocol.

----------

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

From report at bugs.python.org  Mon Jun  7 23:34:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 21:34:32 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275946472.67.0.135928384248.issue8925@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jun  7 23:43:54 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Jun 2010 21:43:54 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types	instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <4C0D680C.9070101@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner at haypocalc.com>:
> 
> http://docs.python.org/py3k/c-api/arg.html is unclear about what is a "string".
> 
> Attached patch:
>  - Use directly bytes, bytearray and str types
>  - Replace "default encoding" by "``'utf-8'`` encoding"
>  - Add bytes and/or bytearray to "... buffer compatible object" because it's not easy to understand what is a buffer compatible object, especially because there are different kind of buffer objects: read-only, read-write, pinned, etc.
>  - Fix reST syntax ("..note ::")
>  - Fix "es", "es#", "et" and "et#" formats: they doesn't accept "character buffer compatible object" (can someone double check that?)

The character buffer concept is (unfortunately) gone in Python3.

There's no way for a buffer compatible object to tell the
arg parser that it is storing text data. Perhaps we can add something
like that back via the Py_buffer flags for getting buffers.

----------
nosy: +lemburg
title: Improve c-api/arg.rst: use "bytes" or "str" types instead of "string" -> Improve c-api/arg.rst: use "bytes" or "str" types instead	of "string"

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

From report at bugs.python.org  Tue Jun  8 01:04:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jun 2010 23:04:59 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types	instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1275951898.92.0.197760564329.issue8925@psf.upfronthosting.co.za>


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

> There's no way for a buffer compatible object to tell the
> arg parser that it is storing text data.

I think that the buffer protocol targets byte strings/arrays, and that unicode type should be enough.

If applications have to exchange text data, they use utf8, which is a byte string. I don't see the use case. Open a discussion on python-dev if you would like to continue the discussion because this issue is closed.

----------

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

From report at bugs.python.org  Tue Jun  8 07:38:54 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 05:38:54 +0000
Subject: [docs] [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Currently SimpleHTTPServer docs contains phrase "For example usage, see the implementation of the test() function." with no reference where this test() function is located. This is not user friendly.

----------
assignee: docs at python
components: Documentation
messages: 107304
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: SimpleHTTPServer should contain usage example
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Jun  8 15:14:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 08 Jun 2010 13:14:51 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276002891.9.0.884390157954.issue8939@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jun  8 15:23:16 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 08 Jun 2010 13:23:16 +0000
Subject: [docs] [issue8940] *HTTPServer need a summary page with API
	inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

The abundance of methods and hierarchy depth of various servers from "Internet Protocols and Support" section makes it extremely hard to navigate information. You need a strong OOP background to be able to use this doc effectively, as examples are not intuitive otherwise.

Usually you need a decent IDE (such as Eclipse) to get a picture of class hierarchy and a table of all available methods with a mark where they were inherited from.

Such table (at least Class Hierarchy view screenshot from Eclipse) should be available in reference for descendant classes.

----------
assignee: docs at python
components: Documentation
messages: 107321
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: *HTTPServer need a summary page with API inheritance table
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun  8 20:29:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 18:29:14 +0000
Subject: [docs] [issue8907] time module documentation differs in trunk and
	py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1276021754.11.0.911361105469.issue8907@psf.upfronthosting.co.za>


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

There seems to be a few legitimate differences such as "int or long" vs. integer, or parenthesis for print.  Patch is forthcoming.

----------

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

From report at bugs.python.org  Tue Jun  8 20:34:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 18:34:10 +0000
Subject: [docs] [issue8907] time module documentation differs in trunk and
	py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1276022049.91.0.806183097212.issue8907@psf.upfronthosting.co.za>


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

.. also 3.x does not track versionadded from 2.x

----------

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

From report at bugs.python.org  Tue Jun  8 20:39:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Jun 2010 18:39:07 +0000
Subject: [docs] [issue8907] time module documentation differs in trunk and
	py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1276022347.86.0.0506147725704.issue8907@psf.upfronthosting.co.za>


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

r81489 should probably also be svnmerged to py3k before applying this doc change.  (As far as I can tell, this is the only outstanding unmerged trunk change.)

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

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

From report at bugs.python.org  Tue Jun  8 22:25:46 2010
From: report at bugs.python.org (Dave Opstad)
Date: Tue, 08 Jun 2010 20:25:46 +0000
Subject: [docs] [issue8946] PyBuffer_Release signature in 3.1 documentation
	is	incorrect
In-Reply-To: <1276028746.19.0.698782351102.issue8946@psf.upfronthosting.co.za>
Message-ID: <1276028746.19.0.698782351102.issue8946@psf.upfronthosting.co.za>


New submission from Dave Opstad <dave.opstad at monotypeimaging.com>:

According to the 3.1 documentation, the prototype for PyBuffer_Release is:

void PyBuffer_Release(PyObject *obj, Py_buffer *view);

However, abstract.h has this prototype:

PyAPI_FUNC(void) PyBuffer_Release(Py_buffer *view);

The documentation's reference to "obj" should be removed.

----------
assignee: docs at python
components: Documentation
messages: 107342
nosy: docs at python, opstad
priority: normal
severity: normal
status: open
title: PyBuffer_Release signature in 3.1 documentation is incorrect
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Jun  9 00:05:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Jun 2010 22:05:03 +0000
Subject: [docs] [issue8907] time module documentation differs in trunk and
	py3k
In-Reply-To: <1275752348.33.0.507552521147.issue8907@psf.upfronthosting.co.za>
Message-ID: <1276034703.36.0.790370438667.issue8907@psf.upfronthosting.co.za>


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

Merged r81489 to py3k (r81840), but this affects datetime module docs, not time.  On a closer examination, the differences in time.rst are correct.

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

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

From report at bugs.python.org  Wed Jun  9 00:30:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 22:30:42 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276036241.77.0.435177115911.issue8939@psf.upfronthosting.co.za>


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

Big patch:
 - replace Python types by C Python types (eg. str => PyUnicodeObject* and None => Py_None)
 - fix "w" / "w*" / "w#" doc: similar to "y" / "y*" / "y#" (and not "s" / "s*" / "s#")
 - add quotes to the formats, eg. s => "s"
 - use :ctype: to add links to some terms (eg. Py_BEGIN_ALLOW_THREADS) and use a fixed width font
 - replace "the default encoding" by "'utf-8' encoding"
 - replace true by 1, and false by 0 (C API of Python doesn't use stdbool.h but classic int)
 - use a list for the two modes of "es#"
 - Py_BuildValue(), "s" and "s#" formats: specify that the Python object is a str

1 and 0 were formatted with ``1`` and ``0``. I don't understand why, so I removed the italic style.

Sorry for the length of the patch, but it was easy to work on only one aspect.

----------
keywords: +patch
Added file: http://bugs.python.org/file17593/c_api_arg.patch

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

From report at bugs.python.org  Wed Jun  9 00:32:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 08 Jun 2010 22:32:08 +0000
Subject: [docs] [issue8946] PyBuffer_Release signature in 3.1 documentation
	is	incorrect
In-Reply-To: <1276028746.19.0.698782351102.issue8946@psf.upfronthosting.co.za>
Message-ID: <1276036328.31.0.512320980132.issue8946@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r81851 (py3k) and r81852 (release31-maint). Thanks!

----------
assignee: docs at python -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

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

From report at bugs.python.org  Wed Jun  9 00:33:08 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 08 Jun 2010 22:33:08 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276036388.12.0.462033945011.issue8939@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +fdrake

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

From report at bugs.python.org  Wed Jun  9 00:41:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jun 2010 22:41:27 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276036887.74.0.601154262352.issue8939@psf.upfronthosting.co.za>


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

Other changes of the patch:
 - "u#": remove "Non-Unicode objects are handled by interpreting their read-buffer pointer ...", it's no more true
 - "es", "es#": remove "... and objects convertible to Unicode into a character buffer", it's no more true
 - Py_BuildValue(), "K" and "L" formats: specify the name of the C type on Windows (_int64 / unsigned _int64) as done for PyArg_Parse*() long long types

If the patch is too long, I can try to split it into smaller parts.

----------

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

From sherif.nagy at gmail.com  Wed Jun  2 12:37:06 2010
From: sherif.nagy at gmail.com (Sherif Nagy)
Date: Wed, 2 Jun 2010 13:37:06 +0300
Subject: [docs] libvirt docs. not found
Message-ID: <AANLkTik407QJ27LYdyU6e2Y0T_xOJ3pZJ11E1WgvUfNw@mail.gmail.com>

Dear webmaster,

I was trying to access the docs for libvirt module but the URL not found,
any chance or idea where i might find it ?
http://docs.python.org/library/libvirt

Thank You
Regards,
Sherif
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100602/4aa14bdb/attachment-0001.html>

From kens at google.com  Thu Jun  3 06:08:15 2010
From: kens at google.com (Ken Shirriff)
Date: Wed, 2 Jun 2010 21:08:15 -0700
Subject: [docs] Documentation error for conditional expressions?
Message-ID: <AANLkTilM9lMS5whRRZRuRhy8_S4RBQ0vfwMaE-Qeik8m@mail.gmail.com>

The conditional expression documentation says:

conditional_expression ::=  or_test ["if" or_test "else" expression]

I've stared at this and the PEP, and I''m pretty sure that the first
or_test should be an expression, not an or_test.  In an expression
like "x if C else y", x and y are expressions and C is the or_test.

The documentation in question is at
http://docs.python.org/reference/expressions.html#conditional-expressions

Ken

From taleinat at gmail.com  Sat Jun  5 09:35:49 2010
From: taleinat at gmail.com (Tal Einat)
Date: Sat, 5 Jun 2010 10:35:49 +0300
Subject: [docs] How to preview ReST documentation changes?
Message-ID: <AANLkTik0FC0xUv-MH4ttciltFnv8b_hxLgKSM-BCur_D@mail.gmail.com>

I can't seem to find a simple how-to on this anywhere. I just want to make
some changes to the Python docs and view them before submitting a patch.

I understand I need to use Sphinx, but how exactly to do this (including how
to configure it properly for the Python docs format) I just can't tell.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100605/9c6fe702/attachment-0001.html>

From jacko21 at aliceadsl.fr  Mon Jun  7 23:22:06 2010
From: jacko21 at aliceadsl.fr (Jacques)
Date: Mon, 07 Jun 2010 23:22:06 +0200
Subject: [docs] Python documentation : some points requiring attention
In-Reply-To: <4BA5E0B3.4070203@python.org>
References: <4BA553F2.5090106@aliceadsl.fr> <4BA5E0B3.4070203@python.org>
Message-ID: <4C0D62FE.2030605@aliceadsl.fr>



Hi Georg,

Here is a second list of issues found while navigating through the rich 
Python 3.1.1 official documentation.

Hope this would be useful.

With regards.

Jacques DUCASSE
FRANCE

NB : in your reply to my previous email, you say you couldn't find the 
"default ascii encoding" in the HowTo. Here I join a screenshot of this.




Georg Brandl a ?crit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am 21.03.2010 00:02, schrieb Jacques:
>> Hello,
>>
>> First, I want to thank you for the useful and clear documentation of Python.
>>
>> Beeing a fanatic reader of it, sometimes I encounter some mistake (or it 
>> seems to me it is such). If this could bring some help, you will find in 
>> the attached file a list of points requiring attention.
>>
>> All the comments concern the official standard documentation of Python 
>> 3.1.1.
> 
> Hi Jacques,
> 
> thanks for the thorough list of issues!  I'm going to copy them inline here
> and add answers.
> 

[......]

> 
>> How-to Unicode
>> 1.3 Encodings
>> ?For example, Python?s default encoding is the ?ascii? encoding?
>> This was true in the past but, now, it defaults to UTF-8.
> 
> I can't seem to find that sentence in the 3.1 HOWTO text.
> 
> Thanks!
> Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PythonDocErreurs100607.pdf
Type: application/pdf
Size: 40805 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20100607/4c18e4ef/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PythonDocErreurs100607image.doc
Type: application/octet-stream
Size: 161280 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20100607/4c18e4ef/attachment-0001.obj>

From Perseids at lavabit.com  Tue Jun  8 01:03:15 2010
From: Perseids at lavabit.com (Perseids)
Date: Tue, 08 Jun 2010 01:03:15 +0200
Subject: [docs] hmac.digest() return value
Message-ID: <4C0D7AB3.4000309@lavabit.com>

Hi,

I am new to Python 3, but I believe I have found a little error in the 
documentation. The return value of hmac.digest() is a bytes object, and 
not a string. See http://docs.python.org/py3k/library/hmac.html .

Regards
Perseids


From techtonik at gmail.com  Wed Jun  9 09:48:39 2010
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 9 Jun 2010 10:48:39 +0300
Subject: [docs] How to preview ReST documentation changes?
In-Reply-To: <AANLkTik0FC0xUv-MH4ttciltFnv8b_hxLgKSM-BCur_D@mail.gmail.com>
References: <AANLkTik0FC0xUv-MH4ttciltFnv8b_hxLgKSM-BCur_D@mail.gmail.com>
Message-ID: <AANLkTilsj3XQEBcHV-yzIpdgDVQ7WKRHJ9R4w2PmOWsY@mail.gmail.com>

On Sat, Jun 5, 2010 at 10:35 AM, Tal Einat <taleinat at gmail.com> wrote:
> I can't seem to find a simple how-to on this anywhere. I just want to make
> some changes to the Python docs and view them before submitting a patch.
>
> I understand I need to use Sphinx, but how exactly to do this (including how
> to configure it properly for the Python docs format) I just can't tell.

Strange thing. I've filled almost the same proposal
http://bugs.python.org/issue8904 exactly the same day your mail was
written.

-- 
anatoly t.

From report at bugs.python.org  Wed Jun  9 11:06:25 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 09:06:25 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276036241.77.0.435177115911.issue8939@psf.upfronthosting.co.za>
Message-ID: <4C0F598D.4000202@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Big patch:
>  - replace Python types by C Python types (eg. str => PyUnicodeObject* and None => Py_None)

I was thinking of e.g. "PyUnicode", not "PyUnicodeObject*".

>  - add quotes to the formats, eg. s => "s"

Why do you put the parser codes in double quotes ?

>  - use :ctype: to add links to some terms (eg. Py_BEGIN_ALLOW_THREADS) and use a fixed width font
>  - replace "the default encoding" by "'utf-8' encoding"
>  - replace true by 1, and false by 0 (C API of Python doesn't use stdbool.h but classic int)

That's not necessarily correct: true in C means non-zero. Only
false equates to 0. You can however, make that change if the
function actually does always return 1.

In general, most C functions in Python use these integer
return values:

 1  - success
 0  - no success
 -1 - error

Some of them also return a positive integer >1 for success or
a negative integer <-1 for error, but those are exceptions.

----------

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

From report at bugs.python.org  Wed Jun  9 11:28:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 09:28:32 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <4C0F598D.4000202@egenix.com>
Message-ID: <201006091128.23447.victor.stinner@haypocalc.com>


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

Le mercredi 09 juin 2010 11:06:25, vous avez ?crit :
> >  - replace Python types by C Python types (eg. str => PyUnicodeObject*
> >  and None => Py_None)
> 
> I was thinking of e.g. "PyUnicode", not "PyUnicodeObject*".

I don't know PyUnicode, only "unicode" (Python type) or "PyUnicodeObject*" (C 
Python type). :ctype:`PyUnicodeObject*` creates a link in the HTML 
documentation.

> >  - add quotes to the formats, eg. s => "s"
> 
> Why do you put the parser codes in double quotes ?

It's easier to search a format: try to search s or b format in the current 
documentation, you will see :-)

I think that it's also more readable and closer to the "real" source code (eg. 
a call to PyArg_ParseTuple() uses quotes).

> >  - replace true by 1, and false by 0 (C API of Python doesn't use
> >  stdbool.h but classic int)
> 
> That's not necessarily correct: true in C means non-zero. Only
> false equates to 0. You can however, make that change if the
> function actually does always return 1.

There are only 2 possible results: 0 or 1.

----------

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

From report at bugs.python.org  Wed Jun  9 12:04:03 2010
From: report at bugs.python.org (Tal Einat)
Date: Wed, 09 Jun 2010 10:04:03 +0000
Subject: [docs] [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1276077843.6.0.084165816444.issue8904@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

AFAIK submitting patches in general is covered well enough in several places. What I'm missing specifically regarding patches for documentation is instructions on how to preview them before submitting them. Editing reST is easy, but making sure you've done it correctly without knowing how to run it through Sphinx is impossible. I spent quite some time and couldn't figure this one out, and ended up submitting a doc patch without previewing it.

To be specific, http://www.python.org/dev/contributing/ points to http://docs.python.org/dev/documenting/index.html which has quite a bit of information on reST but no information on Sphinx, despite the main page clearly stating:
"This document describes the style guide for our documentation, the custom reStructuredText markup introduced to support Python documentation and how it should be used, as well as the Sphinx build system."

Finally, a simple how-to with concrete, technical steps on how to write, preview and submit a doc patch would really help, especially for those who have never before submitted a patch. A simple video example (e.g. on ShowMeDo) would be fantastic, but even just updated detailed textual instructions would be a great step forward.

----------
nosy: +taleinat
status: pending -> open

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

From report at bugs.python.org  Wed Jun  9 12:34:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jun 2010 10:34:49 +0000
Subject: [docs] [issue8952] Doc/c-api/arg.rst: fix documentation of number
	formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>


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

The documentation of PyArg_Parse*() number formats specify that only int / float / complex are accepted, whereas any int / float / complex compatible object is accepted. "compatible" means that it has an __int__() / __float__() / __complex__() method, or nb_int / nb_float of Py_TYPE(obj)->tp_as_number->nb_int is defined (tp_as_number has no nb_complex).

I suppose that the following paragraph is also outdated:

"It is possible to pass "long" integers (integers whose value exceeds the
 platform's :const:`LONG_MAX`) however no proper range checking is done --- the
 most significant bits are silently truncated when the receiving field is too
 small to receive the value (actually, the semantics are inherited from downcasts
 in C --- your mileage may vary)."

Moreover, "without overflow checking" should be explained (Mark told me that the number is truncated to a power of 2).

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 107379
nosy: docs at python, haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: Doc/c-api/arg.rst: fix documentation of number formats
versions: Python 3.2

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

From report at bugs.python.org  Wed Jun  9 12:47:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Jun 2010 10:47:00 +0000
Subject: [docs] [issue8952] Doc/c-api/arg.rst: fix documentation of number
	formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1276080420.18.0.660421615312.issue8952@psf.upfronthosting.co.za>


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

Yes, most of that paragraph is outdated.

We should check exactly what does happen when the "receiving field is too small" (both in practice and in theory).  In C, downcasting to an unsigned type is well-defined and will always reduce modulo 2**<width_of_type>.  The result of downcasting to a signed type is implementation-defined, however;  do we actually do that anywhere?  If so, it would be nice to fix it.

----------

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

From report at bugs.python.org  Wed Jun  9 12:48:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 09 Jun 2010 10:48:48 +0000
Subject: [docs] [issue8952] Doc/c-api/arg.rst: fix documentation of number
	formats
In-Reply-To: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
Message-ID: <1276080528.52.0.0744371433205.issue8952@psf.upfronthosting.co.za>


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

The other variable of interest here is that some integer formats will accept types with an __index__ method, while others won't.  I'm not sure which types fall into each category, right now.

----------

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

From report at bugs.python.org  Wed Jun  9 12:59:02 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Jun 2010 10:59:02 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <201006091128.23447.victor.stinner@haypocalc.com>
Message-ID: <4C0F73F3.3040609@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> Le mercredi 09 juin 2010 11:06:25, vous avez ?crit :
>>>  - replace Python types by C Python types (eg. str => PyUnicodeObject*
>>>  and None => Py_None)
>>
>> I was thinking of e.g. "PyUnicode", not "PyUnicodeObject*".
> 
> I don't know PyUnicode, only "unicode" (Python type) or "PyUnicodeObject*" (C 
> Python type). :ctype:`PyUnicodeObject*` creates a link in the HTML 
> documentation.

The "PyUnicode" style is just an abbreviated version of the longer
"PyUnicodeObject", that we sometimes use, since writing "Pass
a PyUnicodeObject object to this function" looks a bit silly.

I don't have a strong opinion about this, though. The longer
version is fine as well.

>>>  - add quotes to the formats, eg. s => "s"
>>
>> Why do you put the parser codes in double quotes ?
> 
> It's easier to search a format: try to search s or b format in the current 
> documentation, you will see :-)
> 
> I think that it's also more readable and closer to the "real" source code (eg. 
> a call to PyArg_ParseTuple() uses quotes).

It could lead developers into thinking that they have to use
those quotes in their code.

Perhaps you should add a note about this typographic addition
to docs.

>>>  - replace true by 1, and false by 0 (C API of Python doesn't use
>>>  stdbool.h but classic int)
>>
>> That's not necessarily correct: true in C means non-zero. Only
>> false equates to 0. You can however, make that change if the
>> function actually does always return 1.
> 
> There are only 2 possible results: 0 or 1.

I wouldn't count on this. It may be the case now, but it's both
hard to check by reading the code and knowing that only 1 can
be returned doesn't buy a developer much.

In fact, this has
bitten us before with the cmp() function: users starting writing
code like this because we documented the return codes as -1, 0, 1:

a = b + z * cmp(x, y)

Please use "non-zero" instead.

----------

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

From report at bugs.python.org  Wed Jun  9 14:14:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 09 Jun 2010 12:14:04 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276036241.77.0.435177115911.issue8939@psf.upfronthosting.co.za>
Message-ID: <4C0F8589.6090004@netwok.org>


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

> 1 and 0 were formatted with ``1`` and ``0``. I don't understand why,
> so I removed the italic style.

This reST construct marks up code. Please revert this change. :)

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

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

From report at bugs.python.org  Wed Jun  9 15:07:45 2010
From: report at bugs.python.org (Jean Jordaan)
Date: Wed, 09 Jun 2010 13:07:45 +0000
Subject: [docs] [issue8953] Syntax error
	in	http://docs.python.org/library/decimal.html#recipes
In-Reply-To: <1276088865.47.0.391393017311.issue8953@psf.upfronthosting.co.za>
Message-ID: <1276088865.47.0.391393017311.issue8953@psf.upfronthosting.co.za>


New submission from Jean Jordaan <jean.jordaan at gmail.com>:

http://docs.python.org/library/decimal.html#recipes
has this code: 

    for i in range(places):
        build(next() if digits else '0')

Mismatched parenthesis.

----------
assignee: docs at python
components: Documentation
messages: 107396
nosy: Jean.Jordaan, docs at python
priority: normal
severity: normal
status: open
title: Syntax error in http://docs.python.org/library/decimal.html#recipes
versions: Python 2.6

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

From report at bugs.python.org  Wed Jun  9 15:09:17 2010
From: report at bugs.python.org (Jean Jordaan)
Date: Wed, 09 Jun 2010 13:09:17 +0000
Subject: [docs] [issue8953] Syntax error
	in	http://docs.python.org/library/decimal.html#recipes
In-Reply-To: <1276088865.47.0.391393017311.issue8953@psf.upfronthosting.co.za>
Message-ID: <1276088957.31.0.268229966076.issue8953@psf.upfronthosting.co.za>


Jean Jordaan <jean.jordaan at gmail.com> added the comment:

Aargh, sorry, sent too quick :-(

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

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

From report at bugs.python.org  Wed Jun  9 15:22:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 09 Jun 2010 13:22:02 +0000
Subject: [docs] [issue8953] Syntax error
	in	http://docs.python.org/library/decimal.html#recipes
In-Reply-To: <1276088865.47.0.391393017311.issue8953@psf.upfronthosting.co.za>
Message-ID: <1276089722.49.0.390337458676.issue8953@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


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

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

From report at bugs.python.org  Thu Jun 10 14:49:33 2010
From: report at bugs.python.org (=?utf-8?q?Vojt=C4=9Bch_Rylko?=)
Date: Thu, 10 Jun 2010 12:49:33 +0000
Subject: [docs] [issue8960] 2.6 README
In-Reply-To: <1276174173.81.0.364137552022.issue8960@psf.upfronthosting.co.za>
Message-ID: <1276174173.81.0.364137552022.issue8960@psf.upfronthosting.co.za>


New submission from Vojt?ch Rylko <vojta.rylko at seznam.cz>:

In 2.6 README are this paragraphs from 2.5 README:

A number of features are not supported in Python 2.5 anymore. Some
support code is still present, but will be removed in Python 2.6. 

The following systems are still supported in Python 2.5, but
support will be dropped in 2.6:
- Systems using --with-wctype-functions
- Win9x, WinME

Following Microsoft's closing of Extended Support for
Windows 98/ME (July 11, 2006), Python 2.6 will stop
supporting these platforms.

----------
assignee: docs at python
components: Documentation
messages: 107458
nosy: docs at python, vojta.rylko
priority: normal
severity: normal
status: open
title: 2.6 README
versions: Python 2.6

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

From report at bugs.python.org  Thu Jun 10 18:17:44 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 10 Jun 2010 16:17:44 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276186664.11.0.278787056251.issue8939@psf.upfronthosting.co.za>


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

FWIW, I prefer PyLongObject* over PyLong.  (Though I'm sure I'm guilty of writing PyLong in comments.)

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

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

From report at bugs.python.org  Fri Jun 11 02:27:43 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Fri, 11 Jun 2010 00:27:43 +0000
Subject: [docs] [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>


New submission from Ilya Sandler <ilya.sandler at gmail.com>:

the token module defines constants for token types e.g

 NAME = 1
 NUMBER = 2
 STRING = 3
 NEWLINE = 4

etc.

These constants are very useful for any code which needs to tokenize python source, yet they are not listed in the documentation.


Is this a documentation bug?

----------
assignee: docs at python
components: Documentation
messages: 107509
nosy: docs at python, isandler
priority: normal
severity: normal
status: open
title: token type constants are not documented
versions: Python 3.3

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

From report at bugs.python.org  Fri Jun 11 06:59:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jun 2010 04:59:48 +0000
Subject: [docs] [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276232387.19.0.73185328496.issue8968@psf.upfronthosting.co.za>


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

It is. Constants should be documented in the regular doc, not only by introspection or reading the source. See the doc for tokenize: ?All constants from the token module are also exported from tokenize, as are two additional token type values?.

Thanks for the report. Would you mind writing a patch?

----------
nosy: +merwok
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 3.3

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

From merwok at netwok.org  Fri Jun 11 23:17:01 2010
From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=)
Date: Fri, 11 Jun 2010 23:17:01 +0200
Subject: [docs] Typo in symtable.c
Message-ID: <4C12A7CD.1070905@netwok.org>

Howdy all

Rejected patch for #8977 included one typo fix:

trunk/Python/symtable.c:1398:       operation.  It is diferent than
py3k/Python/symtable.c:1536:       operation.  It is diferent than

Regards


From benjamin at python.org  Fri Jun 11 23:41:12 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 11 Jun 2010 16:41:12 -0500
Subject: [docs] Typo in symtable.c
In-Reply-To: <4C12A7CD.1070905@netwok.org>
References: <4C12A7CD.1070905@netwok.org>
Message-ID: <AANLkTingvOuHihQMaibADqy4lIkru_PLnR7Icxy5y5UB@mail.gmail.com>

Fixed in r81906.

2010/6/11 ?ric Araujo <merwok at netwok.org>:
> Howdy all
>
> Rejected patch for #8977 included one typo fix:
>
> trunk/Python/symtable.c:1398: ? ? ? operation. ?It is diferent than
> py3k/Python/symtable.c:1536: ? ? ? operation. ?It is diferent than
>
> Regards
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



-- 
Regards,
Benjamin

From report at bugs.python.org  Sat Jun 12 01:34:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:34:35 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276299275.01.0.86341177596.issue8939@psf.upfronthosting.co.za>


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

I commited a first part of the patch: r81923 (3.2), r81924 (3.1).

----------

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

From report at bugs.python.org  Sat Jun 12 01:37:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jun 2010 23:37:51 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276299471.66.0.980607607084.issue8939@psf.upfronthosting.co.za>


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

"PyUnicodeObject*" is not the best choice for the description of the function, and I don't really like "PyUnicode". Can't we use C types in the function prototype and Python types in the description?

Example:
-------
s (PyUnicodeObject* or None) [char *]
Convert a null-terminated C string to a Python unicode object using 'utf-8' encoding. If the C string pointer is NULL, None is used.
-----
PyUnicodeObject will be a link to the C type, and unicode a link to the  Python type.

----------

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

From report at bugs.python.org  Sat Jun 12 07:31:03 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sat, 12 Jun 2010 05:31:03 +0000
Subject: [docs] [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276320663.65.0.674162619023.issue8968@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

I'm attaching a documentation patch.

Do note that there is also a bit of code-level inconsistency: a few tokens (COMMENT, NL) are defined in tokenize module which is strange and inconvenient.

Should that be fixed too? (by moving token definitions into token module)

----------
keywords: +patch
Added file: http://bugs.python.org/file17641/token.rst.patch

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

From electroboy455 at gmail.com  Thu Jun 10 07:30:41 2010
From: electroboy455 at gmail.com (Dylan Laufenberg)
Date: Thu, 10 Jun 2010 01:30:41 -0400
Subject: [docs] Bad example in Chapter 3 of Python 2.6.5 Tutorial
Message-ID: <AANLkTilt97Xnl-pDLfEBKXWMEpRiKVtt8dE3tS-X9oru@mail.gmail.com>

Hi there.

This should be easy to fix, and I may be wrong (I'm just learning Python),
but I believe the behavior of negative list (in this case, string) indices
is such that a[-1] returns the *last* element, not the second-last. However,
near the bottom of the Strings section of Chapter 3 of the official tutorial
(link <http://docs.python.org/tutorial/introduction.html#strings>) is a
section and table regarding this, conflicts with itself: the ASCII table
near the very bottom lists the indices wrong!

Thank you for your help, and I do apologize if I am mistaken, but I'm fairly
sure I'm right. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100610/1f019c0d/attachment-0001.html>

From chanh.q.vo at intel.com  Sat Jun 12 02:45:09 2010
From: chanh.q.vo at intel.com (Vo, Chanh Q)
Date: Fri, 11 Jun 2010 18:45:09 -0600
Subject: [docs] Add reference
Message-ID: <62F25A0A9957934B840401BB94DCC468B4157294@rrsmsx502.amr.corp.intel.com>

Hi
In MS visual studio I use add reference to add the COM or API of drivers ... to MS visual studio.
In Python what is the equivalent way to add reference? For example: I have USB GPIB card from National instrument.
I installed visa and IEEE488.2 drivers  that have GPIB driver. Now in Python, how do I used function built in visa or IEEE488.2 to write read instrument that runs on GPIB?
Thanks
Chanh

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

From alexander.belopolsky at gmail.com  Sat Jun 12 05:41:33 2010
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 11 Jun 2010 23:41:33 -0400
Subject: [docs] A suggestion to change decimal module docstring
Message-ID: <AANLkTimwHtvSac3XhUzmsyxTp1_UNvyv5iMIzgnzGpn9@mail.gmail.com>

Not worth a tracker entry, so I am just sending this to docs and Mark.

I find current "(for instance, in binary floating point, 1.00 % 0.1
gives 0.09999999999999995 instead of the expected Decimal("0.00")
returned by decimal floating point)" in the introduction a bit unclear
because neither Decimal class nor it's constructor taking a string has
been introduced by that point.  I think it is better to just use 0.00
for the "expected" value.

From georg at python.org  Sat Jun 12 08:25:03 2010
From: georg at python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 08:25:03 +0200
Subject: [docs] Documentation error for conditional expressions?
In-Reply-To: <AANLkTilM9lMS5whRRZRuRhy8_S4RBQ0vfwMaE-Qeik8m@mail.gmail.com>
References: <AANLkTilM9lMS5whRRZRuRhy8_S4RBQ0vfwMaE-Qeik8m@mail.gmail.com>
Message-ID: <4C13283F.8020300@python.org>

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

Am 03.06.2010 06:08, schrieb Ken Shirriff:
> The conditional expression documentation says:
> 
> conditional_expression ::=  or_test ["if" or_test "else" expression]
> 
> I've stared at this and the PEP, and I''m pretty sure that the first
> or_test should be an expression, not an or_test.  In an expression
> like "x if C else y", x and y are expressions and C is the or_test.
> 
> The documentation in question is at
> http://docs.python.org/reference/expressions.html#conditional-expressions

Hi Ken,

Even if its name may be unfortunate, "or_test" is the correct symbol in
this case; it means that you can write ``a or b if c or d else e`` (course,
this is close to unreadable).

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

iEYEARECAAYFAkwTKD4ACgkQN9GcIYhpnLCY9gCfeFvGgvPi9F1lbGB0lCI0B3OZ
HE8AoJDzL8ODbJgvMlKYRwcK9Ed9E08I
=/1zl
-----END PGP SIGNATURE-----

From georg at python.org  Sat Jun 12 08:25:53 2010
From: georg at python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 08:25:53 +0200
Subject: [docs] Small documentation typo
In-Reply-To: <AANLkTin_YHcehIP-ymGdh-vs5gnn2C6ASXVa_u6_EgxO@mail.gmail.com>
References: <AANLkTin_YHcehIP-ymGdh-vs5gnn2C6ASXVa_u6_EgxO@mail.gmail.com>
Message-ID: <4C132871.8010202@python.org>

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

Am 26.05.2010 21:48, schrieb Charles Reinman:
> 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, fixed in r81931.

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

iEYEARECAAYFAkwTKHEACgkQN9GcIYhpnLCuAQCdGfuO4H0Qt1lCUf6ark8Dg0p2
Lr4An15HPro3SCaGZIMgkMMMuJl3i2nL
=vh2B
-----END PGP SIGNATURE-----

From georg at python.org  Sat Jun 12 08:28:26 2010
From: georg at python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 08:28:26 +0200
Subject: [docs] Bug in documentation of os.mkdir()
In-Reply-To: <3FD061693071E948A07F24D7CFEF9CC701AE101878@LONMC01040.rbsres07.net>
References: <3FD061693071E948A07F24D7CFEF9CC701AE101878@LONMC01040.rbsres07.net>
Message-ID: <4C13290A.8040604@python.org>

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

Am 26.05.2010 10:49, schrieb Raphael.Mankin at rbs.com:
> 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.

Thanks, fixed in r81932 and will appear online soon.

> ***********************************************************************************
> 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
> 
> ***********************************************************************************

No comment...

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

iEYEARECAAYFAkwTKQkACgkQN9GcIYhpnLAMkwCgo6iD4rNORFR6DoiHWXJfiRst
HisAoJNmkepEuu1o1FhA0LZO6njrRle4
=tGt4
-----END PGP SIGNATURE-----

From georg at python.org  Sat Jun 12 08:33:13 2010
From: georg at python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 08:33:13 +0200
Subject: [docs] Bad example in Chapter 3 of Python 2.6.5 Tutorial
In-Reply-To: <AANLkTilt97Xnl-pDLfEBKXWMEpRiKVtt8dE3tS-X9oru@mail.gmail.com>
References: <AANLkTilt97Xnl-pDLfEBKXWMEpRiKVtt8dE3tS-X9oru@mail.gmail.com>
Message-ID: <4C132A29.5060101@python.org>

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

Am 10.06.2010 07:30, schrieb Dylan Laufenberg:
> Hi there.
> 
> This should be easy to fix, and I may be wrong (I'm just learning
> Python), but I believe the behavior of negative list (in this case,
> string) indices is such that a[-1] returns the /last/ element, not the
> second-last. However, near the bottom of the Strings section of Chapter
> 3 of the official tutorial (link
> <http://docs.python.org/tutorial/introduction.html#strings>) is a
> section and table regarding this, conflicts with itself: the ASCII table
> near the very bottom lists the indices wrong!
> 
> Thank you for your help, and I do apologize if I am mistaken, but I'm
> fairly sure I'm right. :)

Hi Dylan,

I'm not sure right now which table you refer to; if it's this one

    +---+---+---+---+---+
    | H | e | l | p | A |
    +---+---+---+---+---+
    0   1   2   3   4   5
   -5  -4  -3  -2  -1


then it is correct; as with the positive indices, the index is placed on the
left of the item it refers to, as you have to give this index as the stop
index if you want your slice to stop before the character (remember this table
is for understanding slice notation).

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

iEYEARECAAYFAkwTKikACgkQN9GcIYhpnLCQHwCfUFxkazcEFlAzjFN4osxHL8S7
15MAnAtwE1U/IAsWWP9SibrVPKrM6t3j
=33GH
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sat Jun 12 08:38:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 06:38:49 +0000
Subject: [docs] [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276324728.98.0.515941323591.issue8968@psf.upfronthosting.co.za>


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

Five comments:

* I would list them all in one directive, like this:

.. data:: FOO
          BAR
          BAZ

  which makes the display more compact.

* There is no description in that directive.  Best move part of the
  description above them in it.

* NL and COMMENT are defined in tokenize because they are neither 
  defined nor used by the Python tokenizer.

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

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

From report at bugs.python.org  Sat Jun 12 08:39:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 06:39:23 +0000
Subject: [docs] [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1276324762.88.0.077563515253.issue8904@psf.upfronthosting.co.za>


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

Hmm, I thought the Doc/README covered this?

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

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

From georg at python.org  Sat Jun 12 08:40:50 2010
From: georg at python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 08:40:50 +0200
Subject: [docs] libvirt docs. not found
In-Reply-To: <AANLkTik407QJ27LYdyU6e2Y0T_xOJ3pZJ11E1WgvUfNw@mail.gmail.com>
References: <AANLkTik407QJ27LYdyU6e2Y0T_xOJ3pZJ11E1WgvUfNw@mail.gmail.com>
Message-ID: <4C132BF2.4080504@python.org>

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

Am 02.06.2010 12:37, schrieb Sherif Nagy:
> Dear webmaster,
> 
> I was trying to access the docs for libvirt module but the URL not
> found, any chance or idea where i might find it ?
> http://docs.python.org/library/libvirt

There is no "libvirt" module in the core Python distribution; I assume
that it is the third-party module described here:

 http://www.libvirt.org/python.html

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

iEYEARECAAYFAkwTK/IACgkQN9GcIYhpnLASQACcClBeEXCEH7nad2Hja0ABkZA1
SLkAn3pd62Vb4t9cbCNYgrOpq6KTv/eW
=EWmG
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sat Jun 12 08:46:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 06:46:48 +0000
Subject: [docs] [issue8960] 2.6 README
In-Reply-To: <1276174173.81.0.364137552022.issue8960@psf.upfronthosting.co.za>
Message-ID: <1276325208.53.0.795811003538.issue8960@psf.upfronthosting.co.za>


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

Fixed in 2.7 r81933, 2.6 r81934.

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

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

From report at bugs.python.org  Sat Jun 12 11:32:15 2010
From: report at bugs.python.org (Tal Einat)
Date: Sat, 12 Jun 2010 09:32:15 +0000
Subject: [docs] [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1276335135.43.0.330341078032.issue8904@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Apparently so. Those instructions are thorough and to the point, just what I was looking for.

Adding a mention of this somewhere obvious, such as the links I mentioned earlier, would be very helpful (this would have save me 30 minutes of futile searching).

----------

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

From dickinsm at gmail.com  Sat Jun 12 11:05:10 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sat, 12 Jun 2010 10:05:10 +0100
Subject: [docs] A suggestion to change decimal module docstring
In-Reply-To: <AANLkTimwHtvSac3XhUzmsyxTp1_UNvyv5iMIzgnzGpn9@mail.gmail.com>
References: <AANLkTimwHtvSac3XhUzmsyxTp1_UNvyv5iMIzgnzGpn9@mail.gmail.com>
Message-ID: <AANLkTin9SUtf1z-bpI3QBLqlbUZDPooTLz5Gv2Q0N1PO@mail.gmail.com>

Suggested replacement text:

[...] expectations that are at odds with binary floating point (for instance,
in binary floating point, 1.00 % 0.1 gives 0.09999999999999995 instead of 0.0;
Decimal('1.00') % Decimal('0.1') returns the expected Decimal('0.00')).


On Sat, Jun 12, 2010 at 4:41 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> Not worth a tracker entry, so I am just sending this to docs and Mark.
>
> I find current "(for instance, in binary floating point, 1.00 % 0.1
> gives 0.09999999999999995 instead of the expected Decimal("0.00")
> returned by decimal floating point)" in the introduction a bit unclear
> because neither Decimal class nor it's constructor taking a string has
> been introduced by that point. ?I think it is better to just use 0.00
> for the "expected" value.
>

From report at bugs.python.org  Sat Jun 12 11:47:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 09:47:26 +0000
Subject: [docs] [issue8904] quick example how to fix docs
In-Reply-To: <1275733848.36.0.713191812865.issue8904@psf.upfronthosting.co.za>
Message-ID: <1276336045.92.0.824171376242.issue8904@psf.upfronthosting.co.za>


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

Agreed.  Added a "building" section to Documenting Python in r81393, will port to the other branches.

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

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

From report at bugs.python.org  Sat Jun 12 15:09:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 13:09:48 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1276348188.27.0.448209602341.issue459007@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jun 12 15:44:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Jun 2010 13:44:30 +0000
Subject: [docs] [issue8982] argparse docs cross reference Namespace as a
	class but	the Namespace class is not documented
In-Reply-To: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>
Message-ID: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

I wanted to find out if Namespace supported lookup by subscripting (args['someopt']), but the docs are silent on what Namespace is.  (The answer, by the way, appears to be "no"; there is a feature request for this in issue 8979).

----------
assignee: bethard
components: Documentation
messages: 107653
nosy: bethard, docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: argparse docs cross reference Namespace as a class but the Namespace class is not documented
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sat Jun 12 17:26:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 15:26:34 +0000
Subject: [docs] [issue8983] Docstrings should refer to help(name),
	not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Inspired by issue issue8973, I did


$ grep -in "see.*\.__doc__" Modules/*.c

Surprisingly, there were not as many results as I feared.

As I explained in the referenced issue,  "See name.__doc__", while technically correct, is not user friendly.  If you copy name.__doc__ to >>> prompt, you get an ugly repr of a multiline string.  I suggest s/name.__doc__/help(struct)/.

Here are the grep results

Modules/_threadmodule.c:904:Create a new lock object.  See LockType.__doc__ for information about locks.");
Modules/pwdmodule.c:103:See pwd.__doc__ for more on password database entries.");
Modules/pwdmodule.c:124:See pwd.__doc__ for more on password database entries.");
Modules/pwdmodule.c:155:See pwd.__doc__ for more on password database entries.");
Modules/spwdmodule.c:111:See spwd.__doc__ for more on shadow password database entries.");
Modules/spwdmodule.c:143:See spwd.__doc__ for more on shadow password database entries.");

----------
assignee: docs at python
components: Documentation
messages: 107661
nosy: belopolsky, docs at python, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Docstrings should refer to help(name), not name.__doc__
type: feature request

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

From report at bugs.python.org  Sat Jun 12 17:32:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 15:32:06 +0000
Subject: [docs] [issue8983] Docstrings should refer to help(name),
	not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276356726.02.0.452933667692.issue8983@psf.upfronthosting.co.za>


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

A couple more:

$ grep -in "see.*\.__doc__" Lib/*.py
Lib/doctest.py:1782:    See doctest.__doc__ for an overview.
Lib/inspect.py:162:    See isfunction.__doc__ for attributes listing."""

an a really problematic

Objects/typeobject.c:5529:           "see x.__class__.__doc__ for signature",

This  affects every class' help and is very confusing when class doecstring does not show the constructor signature.

----------

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

From report at bugs.python.org  Sat Jun 12 18:10:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 16:10:44 +0000
Subject: [docs] [issue8983] Docstrings should refer to help(name),
	not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276359044.02.0.984965472387.issue8983@psf.upfronthosting.co.za>


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

I agree, help(obj) is the better advice.  Would you prepare a patch?

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

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

From report at bugs.python.org  Sat Jun 12 18:15:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 16:15:29 +0000
Subject: [docs] [issue8983] Docstrings should refer to help(name),
	not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276359329.55.0.396762875267.issue8983@psf.upfronthosting.co.za>


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

Will do.

----------
assignee: docs at python -> belopolsky

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

From georg at python.org  Sat Jun 12 18:20:46 2010
From: georg at python.org (Georg Brandl)
Date: Sat, 12 Jun 2010 18:20:46 +0200
Subject: [docs] A suggestion to change decimal module docstring
In-Reply-To: <AANLkTin9SUtf1z-bpI3QBLqlbUZDPooTLz5Gv2Q0N1PO@mail.gmail.com>
References: <AANLkTimwHtvSac3XhUzmsyxTp1_UNvyv5iMIzgnzGpn9@mail.gmail.com>
	<AANLkTin9SUtf1z-bpI3QBLqlbUZDPooTLz5Gv2Q0N1PO@mail.gmail.com>
Message-ID: <4C13B3DE.3060105@python.org>

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

Sounds good... someone please apply.

Georg

Am 12.06.2010 11:05, schrieb Mark Dickinson:
> Suggested replacement text:
> 
> [...] expectations that are at odds with binary floating point (for instance,
> in binary floating point, 1.00 % 0.1 gives 0.09999999999999995 instead of 0.0;
> Decimal('1.00') % Decimal('0.1') returns the expected Decimal('0.00')).
> 
> 
> On Sat, Jun 12, 2010 at 4:41 AM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>> Not worth a tracker entry, so I am just sending this to docs and Mark.
>>
>> I find current "(for instance, in binary floating point, 1.00 % 0.1
>> gives 0.09999999999999995 instead of the expected Decimal("0.00")
>> returned by decimal floating point)" in the introduction a bit unclear
>> because neither Decimal class nor it's constructor taking a string has
>> been introduced by that point.  I think it is better to just use 0.00
>> for the "expected" value.
>>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs

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

iEYEARECAAYFAkwTs90ACgkQN9GcIYhpnLBHywCgqbZEsaaN+yMWNMqWYsICzNFY
HOgAnAotmwuhnYBoOiGxFZIHyIAQI/NF
=OXX9
-----END PGP SIGNATURE-----

From dickinsm at gmail.com  Sat Jun 12 18:38:21 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sat, 12 Jun 2010 17:38:21 +0100
Subject: [docs] A suggestion to change decimal module docstring
In-Reply-To: <4C13B3DE.3060105@python.org>
References: <AANLkTimwHtvSac3XhUzmsyxTp1_UNvyv5iMIzgnzGpn9@mail.gmail.com>
	<AANLkTin9SUtf1z-bpI3QBLqlbUZDPooTLz5Gv2Q0N1PO@mail.gmail.com>
	<4C13B3DE.3060105@python.org>
Message-ID: <AANLkTik5C5H24-PQc_whwFAEcvyzGOSxkljFSgIsIrHF@mail.gmail.com>

Done in r81951.

Mark

On Sat, Jun 12, 2010 at 5:20 PM, Georg Brandl <georg at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sounds good... someone please apply.
>
> Georg
>
> Am 12.06.2010 11:05, schrieb Mark Dickinson:
>> Suggested replacement text:
>>
>> [...] expectations that are at odds with binary floating point (for instance,
>> in binary floating point, 1.00 % 0.1 gives 0.09999999999999995 instead of 0.0;
>> Decimal('1.00') % Decimal('0.1') returns the expected Decimal('0.00')).
>>
>>
>> On Sat, Jun 12, 2010 at 4:41 AM, Alexander Belopolsky
>> <alexander.belopolsky at gmail.com> wrote:
>>> Not worth a tracker entry, so I am just sending this to docs and Mark.
>>>
>>> I find current "(for instance, in binary floating point, 1.00 % 0.1
>>> gives 0.09999999999999995 instead of the expected Decimal("0.00")
>>> returned by decimal floating point)" in the introduction a bit unclear
>>> because neither Decimal class nor it's constructor taking a string has
>>> been introduced by that point. ?I think it is better to just use 0.00
>>> for the "expected" value.
>>>
>> _______________________________________________
>> docs mailing list
>> docs at python.org
>> http://mail.python.org/mailman/listinfo/docs
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.15 (GNU/Linux)
>
> iEYEARECAAYFAkwTs90ACgkQN9GcIYhpnLBHywCgqbZEsaaN+yMWNMqWYsICzNFY
> HOgAnAotmwuhnYBoOiGxFZIHyIAQI/NF
> =OXX9
> -----END PGP SIGNATURE-----
>

From report at bugs.python.org  Sat Jun 12 20:27:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jun 2010 18:27:06 +0000
Subject: [docs] [issue8983] Docstrings should refer to help(name),
	not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276367226.63.0.784666291018.issue8983@psf.upfronthosting.co.za>


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

Attaching issue8983.diff patch.  I am a bit unsure about __init__ docstring change:

1. Are cases when help(type(x)) differs from help(x) important enough to distinguish in docstring?


2. Do we need a default docstring on __init__ at all?  If so, should we keep a reference to class doc which may not be correct?  See issue8973.

3. Why __init__ has a default docstring but __new__ and __del__ don't?

4. There are some other inconsistencies in type docstrings.  E.g., "__subclasschck__ -> check if an class is a subclass" (misspelling and and missing ()).

----------
keywords: +patch
stage: needs patch -> commit review
versions: +Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17647/issue8983.diff

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

From report at bugs.python.org  Sat Jun 12 21:54:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 12 Jun 2010 19:54:59 +0000
Subject: [docs] [issue8983] Docstrings should refer to help(name),
	not name.__doc__
In-Reply-To: <1276356394.26.0.0946047114478.issue8983@psf.upfronthosting.co.za>
Message-ID: <1276372499.2.0.92561270725.issue8983@psf.upfronthosting.co.za>


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

1. For old-style class instances, both help(i) and help(type(i)) give the help for the instance type, which is highly unhelpful IMO. Otherwise it seems than both C class instances and regular Python new-style class instances give the class doc for help(i). Summary: help(x) is good, help(type(x)) unnecessary.

2. 3. Magic methods are documented through docs.python.org and eventually ABCs, not docstrings. I see no reason to make an exception for __init__, except if removing its docstring breaks code.

4. There are actually two typos ;) Regarding parens, I personally think it?s not helpful to always put them, since e.g. ?len()? is not valid, but my choice is not Python?s.

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

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

From report at bugs.python.org  Sat Jun 12 22:34:44 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 12 Jun 2010 20:34:44 +0000
Subject: [docs] [issue8982] argparse docs cross reference Namespace as a
	class but	the Namespace class is not documented
In-Reply-To: <1276350269.78.0.816004374409.issue8982@psf.upfronthosting.co.za>
Message-ID: <1276374884.59.0.853813938643.issue8982@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

That's right, it doesn't support subscripting. The docs are silent on what namespace is mainly because I don't want to commit to anything other than an object with attributes. But that could be made clearer in the docs.

----------
versions: +Python 2.7

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

From report at bugs.python.org  Sun Jun 13 03:22:45 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 13 Jun 2010 01:22:45 +0000
Subject: [docs] [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1276392165.25.0.81201044116.issue8968@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

> * I would list them all in one directive, like this:

Ok, done. Attaching the updated patch


> There is no description in that directive.  Best move part of the
description above them in it.

I am not sure I understand your request. Could you clarify?


>  NL and COMMENT are defined in tokenize because they are neither 
defined nor used by the Python tokenizer.

Oh, I just realized the source of my misunderstanding: token.py captures token types as they are returned by python's own tokenizer. While tokenize module  does its own tokenization and produces results which are a bit different. COMMENT and NL tokens is one of the differences but there is a difference in how the operation tokens are treated. In fact tokenize's docstring explicitly says so.

... It is designed to match the working of the Python tokenizer exactly, except that it produces COMMENT tokens for comments and gives type OP for all operators ...

I think this clarification should go into official docs as well, would you agree?

PS. even with this clarification, I find the situation quite a bit confusing: especially given that tok_name dict from token module does have a name for COMMENT and that name is inserted by tokenize module..  So I still feel that just adding COMMENT and NL to token module (with clarification that they are not generated by the python's own tokenizer) would be a bit cleaner.

----------
Added file: http://bugs.python.org/file17652/token.rst.patch.v2

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

From report at bugs.python.org  Sun Jun 13 10:13:03 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 13 Jun 2010 08:13:03 +0000
Subject: [docs] [issue8940] *HTTPServer need a summary page with API
	inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276416782.89.0.116862060019.issue8940@psf.upfronthosting.co.za>


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

Can you provide a patch?

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

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

From report at bugs.python.org  Sun Jun 13 23:46:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 21:46:52 +0000
Subject: [docs] [issue8350] os.mkdir doc comment is incorrect
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1276465612.22.0.155249317842.issue8350@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jun 14 00:00:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:00:00 +0000
Subject: [docs] [issue8602] documentation of bz2 module mildly erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1276466400.33.0.635854076678.issue8602@psf.upfronthosting.co.za>


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

I?d remove the lines ?Specifically it does not define the :meth:`__enter__` and :meth:`__exit__` methods required by the :keyword:`with` statement?, since they add unnecessary length to a simple note.

Please provide one patch per branch, and diff from the top level of the checkout (see http://www.python.org/dev/patches/). Thanks!

----------
status: pending -> open

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

From report at bugs.python.org  Mon Jun 14 00:01:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:01:18 +0000
Subject: [docs] [issue8602] documentation of bz2 module mildly erroneous
In-Reply-To: <1272870234.45.0.00658969889364.issue8602@psf.upfronthosting.co.za>
Message-ID: <1276466478.09.0.0633210460922.issue8602@psf.upfronthosting.co.za>


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

Also, don?t bother with 3.0: It is not supported by python-dev anymore. Make documentation patches for py3k and trunk, and they?ll be backported to the stable branches 3.1 and 2.6.

----------

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

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


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

Dave, can you explain your problem with a quote or a file name and line number, or directly propose a doc patch?

----------

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

From report at bugs.python.org  Mon Jun 14 00:21:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 13 Jun 2010 22:21:35 +0000
Subject: [docs] [issue8925] Improve c-api/arg.rst: use "bytes" or "str"
	types instead	of "string"
In-Reply-To: <1275851035.31.0.736999556947.issue8925@psf.upfronthosting.co.za>
Message-ID: <1276467695.38.0.385542653494.issue8925@psf.upfronthosting.co.za>


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

haypo, I was not speaking about documenting the buffer protocol in general, but reacting to this specific change in your patch/commit:

-   buffer protocol (such as :class:`bytes` or :class:`bytearray` objects).
+   buffer protocol.

Before the commit, the term ?buffer protocol? was explained by the two examples with links, but now there?s neither link nor example, which is arguably a doc regression <wink>.

----------
title: Improve c-api/arg.rst: use "bytes" or "str" types instead	of "string" -> Improve c-api/arg.rst: use "bytes" or "str" types instead of "string"

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

From report at bugs.python.org  Mon Jun 14 06:58:37 2010
From: report at bugs.python.org (flashk)
Date: Mon, 14 Jun 2010 04:58:37 +0000
Subject: [docs] [issue8993] Small typo in docs for PySys_SetArgv
In-Reply-To: <1276491516.78.0.349550856551.issue8993@psf.upfronthosting.co.za>
Message-ID: <1276491516.78.0.349550856551.issue8993@psf.upfronthosting.co.za>


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

The docs for PySys_SetArgv say:

"This function works like PySys_SetArgv() with updatepath set to 1."

I believe it should be "PySys_SetArgvEx".

I've attached a patch.

----------
assignee: docs at python
components: Documentation
files: init.rst.patch
keywords: patch
messages: 107771
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: Small typo in docs for PySys_SetArgv
versions: Python 2.7
Added file: http://bugs.python.org/file17665/init.rst.patch

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

From report at bugs.python.org  Mon Jun 14 17:09:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Jun 2010 15:09:13 +0000
Subject: [docs] [issue8996] Add a default role to allow writing bare `len`
	instead of	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Following a discussion on IRC:

<birkenfeld> I would even prefer having more of just `object` instead of :func:`object` or :class:`object`

I think it would be feasible to write a reST role that would use inspect or pydoc to find the type. It would not violate ?In the face of ambiguity, refuse the temptation to guess? if it only resolves `somebuiltin` and `some.fully.qualified.name`.

Cons: People unfamiliar with reST might confuse ``code`` with `name`; interpreting the role may prove non-trivial (either requiring importing Python module to introspect them, or keeping a mapping of names?types in some file).

Thoughts?

----------
assignee: docs at python
components: Documentation
messages: 107790
nosy: docs at python, merwok
priority: normal
severity: normal
status: open
title: Add a default role to allow writing bare `len` instead of :func:`len`
type: feature request

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

From report at bugs.python.org  Mon Jun 14 17:56:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Jun 2010 15:56:55 +0000
Subject: [docs] [issue8996] Add a default role to allow writing bare `len`
	instead of	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1276531015.84.0.975704088723.issue8996@psf.upfronthosting.co.za>


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

The type doesn't matter anyway, no need to find it by questionable means.

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

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

From report at bugs.python.org  Mon Jun 14 17:59:12 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 14 Jun 2010 15:59:12 +0000
Subject: [docs] [issue8993] Small typo in docs for PySys_SetArgv
In-Reply-To: <1276491516.78.0.349550856551.issue8993@psf.upfronthosting.co.za>
Message-ID: <1276531152.53.0.501397080258.issue8993@psf.upfronthosting.co.za>


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

Thanks, fixed in r81984.

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

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

From report at bugs.python.org  Tue Jun 15 00:52:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:52:29 +0000
Subject: [docs] [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1276555949.41.0.751009095507.issue8647@psf.upfronthosting.co.za>


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

Can you write a patch?

----------

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

From report at bugs.python.org  Tue Jun 15 00:52:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:52:39 +0000
Subject: [docs] [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1276555959.57.0.591166754427.issue8646@psf.upfronthosting.co.za>


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

Can you write a patch?

----------

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

From report at bugs.python.org  Tue Jun 15 00:53:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jun 2010 22:53:07 +0000
Subject: [docs] [issue8645] PyUnicode_AsEncodedObject is undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1276555987.31.0.26185384657.issue8645@psf.upfronthosting.co.za>


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

Can you write a patch?

See also #8646.

----------

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

From report at bugs.python.org  Tue Jun 15 10:14:56 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 15 Jun 2010 08:14:56 +0000
Subject: [docs] [issue8940] *HTTPServer need a summary page with API
	inheritance table
In-Reply-To: <1276416782.89.0.116862060019.issue8940@psf.upfronthosting.co.za>
Message-ID: <AANLkTinGI_3wL_J_piaOszWRLCvAjcc26ZbOSDCWGGiQ@mail.gmail.com>


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

No.

----------

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

From report at bugs.python.org  Tue Jun 15 11:39:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 15 Jun 2010 09:39:40 +0000
Subject: [docs] [issue8940] *HTTPServer need a summary page with API
	inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276594780.16.0.992225689237.issue8940@psf.upfronthosting.co.za>


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

May I ask why?

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

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

From report at bugs.python.org  Tue Jun 15 12:21:30 2010
From: report at bugs.python.org (Christian Schubert)
Date: Tue, 15 Jun 2010 10:21:30 +0000
Subject: [docs] [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1276597290.26.0.26628872249.issue8865@psf.upfronthosting.co.za>


Christian Schubert <bugs at apexo.de> added the comment:

added a patch which fixes both issues

before releasing the GIL we take a copy of the ufds pointer and its len, erasing the ufds pointer in the poll object (to make sure nobody else fiddles with it); when we're done we either but it back into the object (when it's still NULL) or we free it

the update logic is modified as well, since the uptodate flag is not sufficient anymore, we now count up a tag for each modification of the poll dictionary and remember that tag together with the ufds pointer

the result is:
- for the single-threaded case we do little extra work (moving ufds from/to poll object)
- correct for the multi-threaded case, with slightly higher overhead (one additional call to each of malloc, update_ufd_array, free), probably worse than having one poll object per thread, but not worse than allocating a new poll object each time we want to poll

there still is potential for incorrect poll results (but not for memory corruption): when poll_register/poll_unregister are called exactly 2**32 times (or multiples thereof) while poll_poll is running, it will happily put back its outdated ufds pointer into the poll object when its done, this could be alleviated by changing tag to long long ... which is unlikely to wrap around anytime soon.

----------
keywords: +patch
Added file: http://bugs.python.org/file17675/select.patch

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

From report at bugs.python.org  Tue Jun 15 12:22:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 10:22:26 +0000
Subject: [docs] [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1276597346.54.0.938086969092.issue8865@psf.upfronthosting.co.za>


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


----------
nosy: +exarkun

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

From report at bugs.python.org  Tue Jun 15 14:27:19 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 15 Jun 2010 12:27:19 +0000
Subject: [docs] [issue8940] *HTTPServer need a summary page with API
	inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276604839.04.0.0106682566261.issue8940@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Tue Jun 15 14:50:59 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 15 Jun 2010 12:50:59 +0000
Subject: [docs] [issue8940] *HTTPServer need a summary page with API
	inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276606259.12.0.670961544016.issue8940@psf.upfronthosting.co.za>


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

1. No time
2. Looks complicated

----------

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

From report at bugs.python.org  Tue Jun 15 14:53:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 15 Jun 2010 12:53:22 +0000
Subject: [docs] [issue8940] *HTTPServer need a summary page with API
	inheritance table
In-Reply-To: <1276003396.33.0.469317406109.issue8940@psf.upfronthosting.co.za>
Message-ID: <1276606402.95.0.815046585639.issue8940@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jun 15 15:53:28 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 15 Jun 2010 13:53:28 +0000
Subject: [docs] [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1276610005.15.0.892016347069.issue8647@psf.upfronthosting.co.za>


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

Yes, though it may be a while before I find time to do so.

----------

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

From report at bugs.python.org  Tue Jun 15 15:53:52 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 15 Jun 2010 13:53:52 +0000
Subject: [docs] [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1276610032.69.0.636284698775.issue8646@psf.upfronthosting.co.za>


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

Yes, though it may be a while before I find time to do so.

----------

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

From report at bugs.python.org  Tue Jun 15 15:55:19 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 15 Jun 2010 13:55:19 +0000
Subject: [docs] [issue8645] PyUnicode_AsEncodedObject is undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1276610119.64.0.297746623486.issue8645@psf.upfronthosting.co.za>


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

I'm not really clear on what PyUnicode_AsEncodedObject does (as opposed to PyUnicode_AsEncodedString).  Someone already familiar with those two functions would have a much easier time writing a documentation patch.

----------

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

From report at bugs.python.org  Tue Jun 15 18:22:05 2010
From: report at bugs.python.org (Renato Cunha)
Date: Tue, 15 Jun 2010 16:22:05 +0000
Subject: [docs] [issue9001] PyFile_FromFd wrong documentation
In-Reply-To: <1276618925.14.0.0301082394986.issue9001@psf.upfronthosting.co.za>
Message-ID: <1276618925.14.0.0301082394986.issue9001@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

PyFile_FromFd has a wrong argument cound and, consequently, a wrong description in py3k docs. The "errors" is never mentioned.

----------
assignee: docs at python
components: Documentation
files: correct-py3k-c-api-doc.diff
keywords: patch
messages: 107879
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: PyFile_FromFd wrong documentation
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17677/correct-py3k-c-api-doc.diff

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

From report at bugs.python.org  Tue Jun 15 18:46:57 2010
From: report at bugs.python.org (Renato Cunha)
Date: Tue, 15 Jun 2010 16:46:57 +0000
Subject: [docs] [issue9002] Add a pointer on where to find a better
	description of	PyFile_FromFd arguments
In-Reply-To: <1276620417.22.0.459801828644.issue9002@psf.upfronthosting.co.za>
Message-ID: <1276620417.22.0.459801828644.issue9002@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

Even though the "File Objects" section in py3k documentation makes it clear that the functions there listed are just wrappers over the io module, it took me a bit to find which function PyFile_FromFd was wrapping.

So, what about making it clear that PyFile_FromFd wraps io.open? The attached patch tries to do that. (It assumes that my previous patch, from issue #9001, will get accepted, as it builds on it.)

----------
assignee: docs at python
components: Documentation
files: py3k-pyfile-from-fd-io-module.diff
keywords: patch
messages: 107881
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: Add a pointer on where to find a better description of PyFile_FromFd arguments
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file17678/py3k-pyfile-from-fd-io-module.diff

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

From report at bugs.python.org  Tue Jun 15 18:48:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 15 Jun 2010 16:48:39 +0000
Subject: [docs] [issue9002] Add a pointer on where to find a better
	description of	PyFile_FromFd arguments
In-Reply-To: <1276620417.22.0.459801828644.issue9002@psf.upfronthosting.co.za>
Message-ID: <1276620519.89.0.0175262870358.issue9002@psf.upfronthosting.co.za>


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


----------
dependencies: +PyFile_FromFd wrong documentation
stage:  -> patch review

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

From report at bugs.python.org  Tue Jun 15 19:32:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 17:32:08 +0000
Subject: [docs] [issue9001] PyFile_FromFd wrong documentation
In-Reply-To: <1276618925.14.0.0301082394986.issue9001@psf.upfronthosting.co.za>
Message-ID: <1276623128.81.0.495076709999.issue9001@psf.upfronthosting.co.za>


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

Thank you! This was committed in r82000, and I improved other text a bit in r82001.

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

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

From report at bugs.python.org  Tue Jun 15 19:33:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jun 2010 17:33:17 +0000
Subject: [docs] [issue9002] Add a pointer on where to find a better
	description of	PyFile_FromFd arguments
In-Reply-To: <1276620417.22.0.459801828644.issue9002@psf.upfronthosting.co.za>
Message-ID: <1276623197.47.0.282823628012.issue9002@psf.upfronthosting.co.za>


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

Same resolution as in #9001. Thanks again.

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

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

From report at bugs.python.org  Wed Jun 16 12:12:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 10:12:23 +0000
Subject: [docs] [issue9007] CGIHTTPServer
In-Reply-To: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>
Message-ID: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

CGIHTTPServer only supports Python CGI scripts. That should be reflected in documentation.

----------
assignee: docs at python
components: Documentation
messages: 107911
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: CGIHTTPServer
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun 16 12:12:42 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 16 Jun 2010 10:12:42 +0000
Subject: [docs] [issue9007] CGIHTTPServer supports only Python CGI scripts
In-Reply-To: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>
Message-ID: <1276683162.86.0.258281162112.issue9007@psf.upfronthosting.co.za>


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


----------
title: CGIHTTPServer -> CGIHTTPServer supports only Python CGI scripts

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

From report at bugs.python.org  Wed Jun 16 15:13:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 16 Jun 2010 13:13:36 +0000
Subject: [docs] [issue9007] CGIHTTPServer supports only Python CGI scripts
In-Reply-To: <1276683142.96.0.591092806304.issue9007@psf.upfronthosting.co.za>
Message-ID: <1276694016.03.0.202319265926.issue9007@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority: normal -> low
stage:  -> needs patch
type:  -> behavior
versions:  -Python 3.3

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

From report at bugs.python.org  Wed Jun 16 17:13:18 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Jun 2010 15:13:18 +0000
Subject: [docs] [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1276701197.99.0.661041918162.issue8937@psf.upfronthosting.co.za>


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

Fixed in r82018.

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected

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

From report at bugs.python.org  Wed Jun 16 18:46:24 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 16 Jun 2010 16:46:24 +0000
Subject: [docs] [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1276706784.59.0.279461588047.issue8937@psf.upfronthosting.co.za>


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

Merged into other branches in r82020, r82022 and r82023.

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

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

From report at bugs.python.org  Wed Jun 16 21:58:50 2010
From: report at bugs.python.org (Renato Cunha)
Date: Wed, 16 Jun 2010 19:58:50 +0000
Subject: [docs] [issue9014] Incorrect documentation of the PyObject_HEAD
	macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

PyObject_HEAD's documentation in py3k (http://docs.python.org/dev/py3k/c-api/structures.html#PyObject_HEAD) uses the same content used in the python 2.x's docs which is wrong, as there were some API changes.

PyObject_HEAD is actually defined as

#define PyObject_HEAD PyObject ob_base;

with PyObject defined as

typedef struct _object {
    _PyObject_HEAD_EXTRA
    Py_ssize_t ob_refcnt;
    struct _typeobject *ob_type;
} PyObject;

(The PyTRACE_REFS discussion is still valid, though.)

Additionally, it'd be nice to mention that the Py_REFCNT(ob) and Py_TYPE(ob) macros should be used to access the PyObject members.

----------
assignee: docs at python
components: Documentation
messages: 107953
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: Incorrect documentation of the PyObject_HEAD macro
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 17 02:55:33 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 00:55:33 +0000
Subject: [docs] [issue3874] documentation bug: HTMLParser needs to
	document	unknown_decl
In-Reply-To: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>
Message-ID: <1276736133.13.0.311860455742.issue3874@psf.upfronthosting.co.za>


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

Documentation issues should be component: documentation rather than library. When submitting one, please at least indicate the module or class concerned. I have never heard of 'unknown_decl' function.

Preferably, indicate the specific section you want modified, by version, number and name. Best is to submit a suggested text to be inserted.  You may know better than most issue reviewers what should be said. Someone else will add markup and possibly edit.

If you respond, this will be reopened. Please indicate whether this issue applies to 3.x and add 3.1 and 3.2 if it does.

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

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

From report at bugs.python.org  Thu Jun 17 04:01:07 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 02:01:07 +0000
Subject: [docs] [issue4452] Incorrect docstring of os.setpgrp
In-Reply-To: <1227882211.37.0.737329471777.issue4452@psf.upfronthosting.co.za>
Message-ID: <1276740067.28.0.872477801371.issue4452@psf.upfronthosting.co.za>


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

os.setpgrp is unix only, I am windows only ;-(.
However, the 3.1 manual says "Call the system call setpgrp() or setpgrp(0, 0)() depending on which version is implemented (if any). "

Given the name of the function and the above, I suspect the OP is correct. The change is small enough that I might not bother with 2.6 and 3.1.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, tjreedy
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5, Python 3.0

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

From report at bugs.python.org  Thu Jun 17 09:38:51 2010
From: report at bugs.python.org (Tal Einat)
Date: Thu, 17 Jun 2010 07:38:51 +0000
Subject: [docs] [issue459007] Document sys.path on Windows
Message-ID: <1276760331.4.0.863818606847.issue459007@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Wow, this has been on hold for ages! I know I could have used this information in the past, and several people have asked me about this.

Perhaps there should be a place in the documentations which explains how sys.path is populated, with detailed explanations for different platforms?

With some guidance as per the right place in the docs for this, I'll gladly work on this. Note that I'm not an expert on this issue, I just plan to gather information form several places and write up a single nice documentation page.

----------
nosy: +taleinat

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

From report at bugs.python.org  Thu Jun 17 13:55:44 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 11:55:44 +0000
Subject: [docs] [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1276775744.49.0.973194166053.issue8937@psf.upfronthosting.co.za>


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

Thank you. The wording can surely be improved, but it is much better than nothing. 

I'd reword the first para further:

> The :func:`test` function in the :mod:`SimpleHTTPServer` module is an example of using :class:`SimpleHTTPRequestHandler` with :class:`BaseHTTPServer` class.

BTW, it is still bad, because:
1. I'd assume that test function is described in documentation and not located in module source
2. users usually don't know where to look for the module source - doc should be self-sufficient
3. SimpleHTTPServer.test() is a proxy call for BaseHTTPServer.test()

----------

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

From report at bugs.python.org  Thu Jun 17 14:22:52 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 17 Jun 2010 12:22:52 +0000
Subject: [docs] [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <20100617120956.GA19305@remy>


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

Yes, I felt the same way and that is the reason for providing extra
example snippets in the same Documentation. I hope you checked that
one.

----------

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

From report at bugs.python.org  Thu Jun 17 15:36:58 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 13:36:58 +0000
Subject: [docs] [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1276781818.6.0.117926476667.issue8937@psf.upfronthosting.co.za>


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

The example is really helpful. I was surprised to learn that SimpleHTTPServer can be called from command line with port argument. I thought it is only for testing. Another missed aspect is that it is possible to use SimpleHTTPRequestHandler with TCPServer, so HTTPServer is not required. But now I wonder about compatibility of handlers vs servers.

----------

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

From report at bugs.python.org  Thu Jun 17 18:32:35 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 17 Jun 2010 16:32:35 +0000
Subject: [docs] [issue4452] Incorrect docstring of os.setpgrp
In-Reply-To: <1227882211.37.0.737329471777.issue4452@psf.upfronthosting.co.za>
Message-ID: <1276792355.67.0.614415531659.issue4452@psf.upfronthosting.co.za>


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

Yes, its valid doc change request. Thought it means the same, the minor docstring improvement can be done.

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

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

From report at bugs.python.org  Thu Jun 17 18:53:00 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 17 Jun 2010 16:53:00 +0000
Subject: [docs] [issue4452] Incorrect docstring of os.setpgrp
In-Reply-To: <1227882211.37.0.737329471777.issue4452@psf.upfronthosting.co.za>
Message-ID: <1276793580.21.0.741056786507.issue4452@psf.upfronthosting.co.za>


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

The docstring "Make this process the process group leader" is proper for setpgrp. Fixed in r82047, r82048, r82049 and r82050.

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

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

From report at bugs.python.org  Thu Jun 17 21:33:43 2010
From: report at bugs.python.org (jeff)
Date: Thu, 17 Jun 2010 19:33:43 +0000
Subject: [docs] [issue3874] documentation bug: HTMLParser needs to
	document	unknown_decl
In-Reply-To: <1276736133.13.0.311860455742.issue3874@psf.upfronthosting.co.za>
Message-ID: <AANLkTilwn_Np9AKx4cijzrXBDpNzdRrySMWcihZ2rRCd@mail.gmail.com>


jeff <freyley at gmail.com> added the comment:

On Wed, Jun 16, 2010 at 5:55 PM, Terry J. Reedy <report at bugs.python.org> wrote:
>
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> Documentation issues should be component: documentation rather than library. When submitting one, please at least indicate the module or class concerned. I have never heard of 'unknown_decl' function.

It's your bug tracker. This sort of statement that says that I should
know exactly how you want bugs reported only serves to tell people
like me not to even try. In addition, it's inaccurate in this case, as
the title of the bug is that HTMLParser, which is a module in the
standard library, needs a function documented.

HTMLParser runs over HTML and calls internal functions when certain
events occur. unknown_decl is called when an unknown declaration is
found, and by default, it throws an exception. Thus, to correctly use
HTMLParser, when subclassing it, you need to override unknown_decl if
there are any unknown declarations in your HTML (or if you think there
might be).

> Preferably, indicate the specific section you want modified, by version, number and name. Best is to submit a suggested text to be inserted. ?You may know better than most issue reviewers what should be said. Someone else will add markup and possibly edit.

It's been almost 2 years since I submitted this bug. I don't know if
it applies to Python 3, and at this point I find it difficult to care.

Thanks,

Jeff

----------
status: pending -> open

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

From report at bugs.python.org  Thu Jun 17 21:43:55 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 17 Jun 2010 19:43:55 +0000
Subject: [docs] [issue3874] documentation bug: HTMLParser needs to
	document	unknown_decl
In-Reply-To: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>
Message-ID: <1276803835.36.0.652741706558.issue3874@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


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

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

From report at bugs.python.org  Fri Jun 18 00:30:33 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jun 2010 22:30:33 +0000
Subject: [docs] [issue3874] documentation bug: HTMLParser needs to
	document	unknown_decl
In-Reply-To: <1221515609.61.0.396859142368.issue3874@psf.upfronthosting.co.za>
Message-ID: <1276813832.54.0.751318282558.issue3874@psf.upfronthosting.co.za>


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

I understand that getting no response to a submission is not pleasant. I do not like it either. That is partly why I have started reviewing old issues. In the past couple of weeks, I have gotten old two orphaned patches applied by updating the headers, reading the patch, and adding a first-response approval message that got the attention of someone with code-commit privileges. I hope you agree that late is better than never.

I just discovered the nosy-count box on the search page. 351 open issues with a nosy count of 1 (which means no response unless someone responded and then removed themself) is too many. We need more issue reviewers.

As to your message: this is *our* tracker, not my tracker. My participation is as much voluntary as yours. I hope you do not really give up on improving Python and its documentation.

I did not expect that you *should* have known submission details. That is why I tried to inform you. In particular, when an issue is marked as 'documentation', it is automatically assigned to 'docs at python', a pseudo-user standing in for people who handle doc revisions. Now they will see this issue, whereas they would not have before.

Please excuse me for not remembering the title as I responded to the message. It is best if message text stands alone. Again, I hope you would agree that an somewhat ignorant response may be better than none.

In order for the doc maintainers to add an entry, someone knowledgeable must write it. Your paragraph of explanation is a start, but more editing is needed.

Looking at dir(html.parser.HTMLParser) and help(...), I see that there are several public internal methods. Some have doc strings that show up with help(), some do not. I thing all should. Some are defined on HTMLParser and some inherited from the undocumented (I believe) _markupbase.ParserBase.

I see that there are also several (completely undocumented except fir dir()) private ('_xyz') internal methods. This implies to me that the public internal methods were made public rather than private because there might be reason to override them. If so, perhaps there should be a new subsection on public internal methods to explain what is what with them. What do you think? Document just one, some, or all?

----------

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

From report at bugs.python.org  Fri Jun 18 01:18:33 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 23:18:33 +0000
Subject: [docs] [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

`copy` module covers very important aspect of Python programming. However its documentation doesn't provide any intro or overview of this problem starting right from details. When people meet `copy` construction in the code - the refer to module documentation and its doesn't completely answer two basic questions they have:

1. why copy module is needed (i.e. what's the problem with var assignment)
2. when and where it should be used

----------
assignee: docs at python
components: Documentation
messages: 108069
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: no copy.copy problem description
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Jun 18 01:54:04 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 17 Jun 2010 23:54:04 +0000
Subject: [docs] [issue8937] SimpleHTTPServer should contain usage example
In-Reply-To: <1275975534.8.0.563527396515.issue8937@psf.upfronthosting.co.za>
Message-ID: <1276818844.21.0.930516898599.issue8937@psf.upfronthosting.co.za>


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

And I am not RDM. =)

----------

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

From report at bugs.python.org  Fri Jun 18 01:57:08 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 17 Jun 2010 23:57:08 +0000
Subject: [docs] [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1276819028.36.0.225725811111.issue9021@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Fri Jun 18 10:54:53 2010
From: report at bugs.python.org (Tim Golden)
Date: Fri, 18 Jun 2010 08:54:53 +0000
Subject: [docs] [issue9024] PyDateTime_IMPORT macro incorrectly marked up
In-Reply-To: <4C1B32EB.6020900@timgolden.me.uk>
Message-ID: <1276851293.02.0.934895032776.issue9024@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> patch review
versions: +Python 3.2

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

From report at bugs.python.org  Sat Jun 19 02:06:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 19 Jun 2010 00:06:46 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276906005.74.0.880806301573.issue8939@psf.upfronthosting.co.za>


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

r82084 (in 3.2 and r82085 in 3.1) fixes some of the reported issues.

----------

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

From report at bugs.python.org  Sat Jun 19 21:59:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Jun 2010 19:59:24 +0000
Subject: [docs] [issue5005] 3.0 sqlite doc: most examples refer to pysqlite2,
	use 2.x syntax.
In-Reply-To: <1232406910.8.0.623178386993.issue5005@psf.upfronthosting.co.za>
Message-ID: <1276977563.92.0.524133529679.issue5005@psf.upfronthosting.co.za>


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

This issue is about the examples in 
11.6.1. Module functions and constants.
All 3 points are fixed.
The indentation issue seems to have been fixed by making the blank line completely blank with no spaces. I would have removed it, but cut and paste now works.

I have no idea what Google has to do with this, but thanks for pinging it.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution:  -> fixed
status: open -> closed
type:  -> behavior
versions: +Python 3.1

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

From report at bugs.python.org  Sun Jun 20 00:25:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 19 Jun 2010 22:25:58 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1276986357.93.0.943475968803.issue8939@psf.upfronthosting.co.za>


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

Shouldn?t ?inside a :ctype:`Py_BEGIN_ALLOW_THREADS` block? rather use ?:cmacro:??

----------

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

From report at bugs.python.org  Sun Jun 20 06:30:07 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 20 Jun 2010 04:30:07 +0000
Subject: [docs] [issue8996] Add a default role to allow writing bare `len`
	instead of	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1277008204.22.0.948873360904.issue8996@psf.upfronthosting.co.za>


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

-1 I like how explicit it is now.

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

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

From report at bugs.python.org  Sun Jun 20 10:54:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Jun 2010 08:54:49 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1277024089.4.0.874218336983.issue8939@psf.upfronthosting.co.za>


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

> Shouldn?t ?inside a :ctype:`Py_BEGIN_ALLOW_THREADS` block? rather use ?:cmacro:??

Same remark on IRC: "Taggnostr> haypo, in r82084: "Add :ctype: to Py_BEGIN_ALLOW_THREADS and int", maybe :cfunc: (or :cmacro:)?"

I don't know :cmacro:. I will fix it in my next patch.

----------

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

From report at bugs.python.org  Sun Jun 20 18:40:19 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 20 Jun 2010 16:40:19 +0000
Subject: [docs] [issue8996] Add a default role to allow writing bare `len`
	instead of	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1277052019.12.0.611651299287.issue8996@psf.upfronthosting.co.za>


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

`someref` would be more convenient than :func:`someref` but in case of namespace conflict (for example, as a result of documentation merge it both :func:`someref` and :class:`someref` can appear) - it would be necessary to go through all the links in both sources and update ambiguous references to point to the right type.

But perhaps the biggest problem would be to explain users what happens. Also in the case when you create new :class:`someref` and Sphinx detects conflict.

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

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

From report at bugs.python.org  Sun Jun 20 18:55:06 2010
From: report at bugs.python.org (Jonathan G. Underwood)
Date: Sun, 20 Jun 2010 16:55:06 +0000
Subject: [docs] [issue9037] Add explanation as to how to raise a custom
	exception in	the extending python intermezzo on exceptions
In-Reply-To: <1277052906.52.0.842872873757.issue9037@psf.upfronthosting.co.za>
Message-ID: <1277052906.52.0.842872873757.issue9037@psf.upfronthosting.co.za>


New submission from Jonathan G. Underwood <jonathan.underwood at gmail.com>:

In the documentation section on Extending Python with C or C++ there is an Intermezzo on Errors and Exceptions which shows how to create a custom exception in an extension module. I was just following these instructions for the first time and got to the end and was left wondering how to actually raise the custom exception in my new module, and it wasn't immediately obvious, so I propose to add a brief explanation to the end of that section explaining how. Patch attached.

----------
assignee: docs at python
components: Documentation
files: extending_how_to_raise_exception.patch
keywords: patch
messages: 108239
nosy: docs at python, jonathan.underwood
priority: normal
severity: normal
status: open
title: Add explanation as to how to raise a custom exception in the extending python intermezzo on exceptions
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file17725/extending_how_to_raise_exception.patch

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

From report at bugs.python.org  Mon Jun 21 12:26:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 21 Jun 2010 10:26:45 +0000
Subject: [docs] [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1277116005.13.0.217065803421.issue8340@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jun 21 13:48:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 21 Jun 2010 11:48:47 +0000
Subject: [docs] [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1277120927.52.0.708441639913.issue8340@psf.upfronthosting.co.za>


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

Ideally, there should be documentation of 'bytes' and 'bytearray' in the 'Built-in Types' section of the library manual, too.  (library/stdtypes.rst).

----------

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

From report at bugs.python.org  Mon Jun 21 20:09:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jun 2010 18:09:29 +0000
Subject: [docs] [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1277143769.25.0.90252642362.issue8340@psf.upfronthosting.co.za>


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

'bytes' is an alias for 'str' in 2.x, so it shouldn't be "documented" separately.
As for bytearray, yes, it should be added if not present.

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

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

From report at bugs.python.org  Mon Jun 21 21:13:53 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Jun 2010 19:13:53 +0000
Subject: [docs] [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1277147633.03.0.107110137762.issue9021@psf.upfronthosting.co.za>


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

The intro paragraph currently (3.2a) consists of
"This module provides generic (shallow and deep) copying operations."

This could be expanded to '''
Assignment statements create bindings between a target and an object. They never duplicate or copy an existing object. For collections that are mutable or contain mutable items, a copy is sometimes needed so one can change one copy without changing the other. Sequences can be shallow copied by slicing the entire sequence(s[:]). (See below for the meaning of 'shallow'.) Some objects can be shallow copied with their class constructors (tuple, list, set, dict). This module provides generic shallow *and* deep copying operations. The latter is not otherwise available in an single operation or call.'''

----------
nosy: +tjreedy
versions: +Python 3.1

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

From report at bugs.python.org  Mon Jun 21 21:21:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Jun 2010 19:21:49 +0000
Subject: [docs] [issue9021] no copy.copy problem description
In-Reply-To: <1276816713.34.0.416523004663.issue9021@psf.upfronthosting.co.za>
Message-ID: <1277148108.9.0.805678976256.issue9021@psf.upfronthosting.co.za>


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

Shorter and better version.

Assignment statements create bindings between a target and an object. They never duplicate or copy an existing object. For collections that are mutable or contain mutable items, a copy is sometimes needed so one can change one copy without changing the other. This module provides generic shallow and deep copy operations (explained below). Shallow copies can also be obtained by whole sequence slicing (s[:]) and some class constructors (tuple, list, set, dict).

----------

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

From report at bugs.python.org  Tue Jun 22 05:00:37 2010
From: report at bugs.python.org (pengyu.ut)
Date: Tue, 22 Jun 2010 03:00:37 +0000
Subject: [docs] [issue9056] Adding additional level of bookmarks and section
	numbers	in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>


New submission from pengyu.ut <pengyu.ut at gmail.com>:

Current pdf version of python documents don't have bookmarks for
sussubsection. For example, there is no bookmark for the following
section in python_2.6.5_reference.pdf. Also the bookmarks don't have
section numbers in them. I suggest to include the section numbers.
Could these features be added in future release of python document.

3.4.1 Basic customization

----------
assignee: docs at python
components: Documentation
messages: 108334
nosy: docs at python, pengyu.ut
priority: normal
severity: normal
status: open
title: Adding additional level of bookmarks and section numbers in python pdf documents.
versions: Python 2.6

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

From report at bugs.python.org  Tue Jun 22 12:16:29 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Jun 2010 10:16:29 +0000
Subject: [docs] [issue9021] no copy.copy problem description
In-Reply-To: <1277147633.03.0.107110137762.issue9021@psf.upfronthosting.co.za>
Message-ID: <20100622101034.GA9303@remy>


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

I am +0 on this change. The existing introduction is fine and the
discussion where shallow and deep copy is discussed is more important.

It is okay to assume that the reader is aware of the assignment
operation nature, i.e. it does not create a copy and you need this
module.  

The doc change suggested by Terry could be helpful in the tutorial
where a copy module is mentioned.

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

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

From report at bugs.python.org  Tue Jun 22 13:25:38 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 22 Jun 2010 11:25:38 +0000
Subject: [docs] [issue9056] Adding additional level of bookmarks and section
	numbers	in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <20100622112524.GA12768@remy>


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

You mean "Table of Contents"? The index at the end serves as a
bookmark, right?  Also, Table of Contents might add up couple of more
pages to traverse.

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

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

From report at bugs.python.org  Tue Jun 22 15:41:16 2010
From: report at bugs.python.org (pengyu.ut)
Date: Tue, 22 Jun 2010 13:41:16 +0000
Subject: [docs] [issue9056] Adding additional level of bookmarks and section
	numbers	in python pdf documents.
In-Reply-To: <20100622112524.GA12768@remy>
Message-ID: <AANLkTikoRUWqKeKKk6YOGNge1vFnCMLk-cpicE3kykBq@mail.gmail.com>


pengyu.ut <pengyu.ut at gmail.com> added the comment:

On Tue, Jun 22, 2010 at 6:25 AM, Senthil Kumaran <report at bugs.python.org> wrote:
>
> Senthil Kumaran <orsenthil at gmail.com> added the comment:
>
> You mean "Table of Contents"? The index at the end serves as a
> bookmark, right? ?Also, Table of Contents might add up couple of more
> pages to traverse.

I don't need subsubsections to be in the table of content. But I think
it is making sense to add them in the bookmarks, as the bookmarks can
be folded even if there are many bookmarks for subsubsections. I'm not
refereeing to index.

----------

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

From fdrake at acm.org  Tue Jun 22 16:16:54 2010
From: fdrake at acm.org (Fred Drake)
Date: Tue, 22 Jun 2010 10:16:54 -0400
Subject: [docs] [issue9056] Adding additional level of bookmarks and
	section numbers in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
References: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za> 
	<1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <AANLkTimph8SSXEJ_Zyn2Lof21Oym8dBDQ6JE5FKhcjhu@mail.gmail.com>

On Mon, Jun 21, 2010 at 11:00 PM, pengyu.ut <report at bugs.python.org> wrote:
> Current pdf version of python documents don't have bookmarks for
> sussubsection. For example, there is no bookmark for the following
> section in python_2.6.5_reference.pdf.

This would be nice to have.

> Also the bookmarks don't have
> section numbers in them. I suggest to include the section numbers.

Hmm.  I'm not a huge fan of section numbers, but so long as we use them,
there's some rationale to include them in the PDF bookmarks.  So I guess
that's up to whoever creates the patch.


  -Fred

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

From csimmons0 at gmail.com  Mon Jun 14 09:29:14 2010
From: csimmons0 at gmail.com (Christopher Simmons)
Date: Mon, 14 Jun 2010 00:29:14 -0700
Subject: [docs] sqlite3 documentation
Message-ID: <AANLkTilEIfF3wrXC5qn5sLsva0s25i2qsqHN-wyoEr-v@mail.gmail.com>

I think that documentation should say that sqlite3's
Connection.close() is called when the connection falls out of scope,
in the same way that Python closes files when they fall out of scope.
I tested this behavior using the 'lsof' command to see whether or not
connections were open.

From 2tolik at gmail.com  Tue Jun 15 17:25:40 2010
From: 2tolik at gmail.com (Anatoly Y)
Date: Tue, 15 Jun 2010 18:25:40 +0300
Subject: [docs] Tutorial 4.3 Range, print(range(x)) does return list
Message-ID: <AANLkTin9ESgdayDpupF_5tZ25PqgV6YUmQyyV-9EktoS@mail.gmail.com>

Hi,

http://docs.python.org/dev/py3k/tutorial/controlflow.html#the-range-function

| A strange thing happens if you just print a range:
| >>> print(range(10))
| range(0, 10)
| In many ways the object returned by range() behaves as if it is a
list, but in fact it isn?t.
| It is an object which returns the successive items of the desired
sequence when you iterate over it,
| but it doesn?t really make the list, thus saving space.


^^ This is not true for 3.2.1 and 2.6.4

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit
(Intel)] on win32
>>> print(range(5))
[0, 1, 2, 3, 4]
>>> type(range(5))
<type 'list'>

BR,
AY

From seb.haase at gmail.com  Thu Jun 17 11:31:38 2010
From: seb.haase at gmail.com (Sebastian Haase)
Date: Thu, 17 Jun 2010 11:31:38 +0200
Subject: [docs] whatsnew/3.1.html says: Release:3.2a0
Message-ID: <AANLkTin_b3xlFGw2ZUlVjfCHU_iXf23c2es095-6yibZ@mail.gmail.com>

Hi,

both pages
http://docs.python.org/dev/py3k/whatsnew/3.1.html
and
http://docs.python.org/dev/py3k/whatsnew/3.0.html
show at the top:

Release:	3.2a0
Date:	June 17, 2010

Isn't this a bug ?

Regards,
Sebastian Haase

From greenpickle512 at googlemail.com  Sun Jun 20 22:50:18 2010
From: greenpickle512 at googlemail.com (Greenpickle)
Date: Sun, 20 Jun 2010 21:50:18 +0100
Subject: [docs] bug report: multiprocessing module
Message-ID: <4C1E7F0A.7080606@googlemail.com>

In particular, the section on Windows (16.6.3.2, the version at
http://docs.python.org/library/multiprocessing.html#windows, if there happen to
be others).  It mentions that the 'main module' must be able to be 'safely
imported', but doesn't make it clear that it needs the .py extension, so that
it can be imported at all.

Just thought it might help others where I spent a few minutes trying to work
out what was going wrong.

From kalle at me.com  Mon Jun 21 21:50:32 2010
From: kalle at me.com (Kalle Karjalainen)
Date: Mon, 21 Jun 2010 22:50:32 +0300
Subject: [docs] audioop module documentation bug
Message-ID: <F4922418-A617-4FF0-991E-04F98B7D3B39@me.com>

Hello,

I found a bug in http://docs.python.org/library/audioop.html

In the example method, def mul_stereo(sample, width, lfactor, rfactor), the result of its first two lines:

lsample = audioop.tomono(sample, width, 1, 0)
rsample = audioop.tomono(sample, width, 0, 1)

... is discarded by the following two lines:

lsample = audioop.mul(sample, width, lfactor)
rsample = audioop.mul(sample, width, rfactor)

... resulting in a sample twice as long being returned as is intended, i.e. "slowing down? of the audio.

The fix for the third and fourth lines is:

lsample = audioop.mul(lsample, width, lfactor)
rsample = audioop.mul(rsample, width, rfactor)


Best,
Kalle Karjalainen


From olivier.berten at gmail.com  Tue Jun 22 10:45:36 2010
From: olivier.berten at gmail.com (Olivier BERTEN)
Date: Tue, 22 Jun 2010 10:45:36 +0200
Subject: [docs] Typo in
	http://docs.python.org/distutils/builtdist.html#creating-windows-installers
Message-ID: <AANLkTimbyBNNsVIraneEGjcQxHvjNUCQ_bCitfUFTYlk@mail.gmail.com>

Hi! there's a small typo in "5.3. Creating Windows Installers":
The bitmap size is 152x261 instead of 161

Yours,

Olivier

From olivier.berten at gmail.com  Tue Jun 22 11:15:54 2010
From: olivier.berten at gmail.com (Olivier BERTEN)
Date: Tue, 22 Jun 2010 11:15:54 +0200
Subject: [docs] another one in
	http://docs.python.org/distutils/builtdist.html#the-postinstallation-script
Message-ID: <AANLkTikuW4ugoSFSb8j_jTYtIABNmOgDsGYOBf1_b5MU@mail.gmail.com>

"can be specified which the --install-script option": "which" should be "with"

From Lukas.Petru at seznam.cz  Tue Jun 22 17:48:31 2010
From: Lukas.Petru at seznam.cz (=?us-ascii?Q?Lukas=20Petru?=)
Date: Tue, 22 Jun 2010 17:48:31 +0200 (CEST)
Subject: [docs] bug in documentation - duplicate paragraph
Message-ID: <27185.6268.9483-28869-1372615096-1277221711@seznam.cz>

I have noticed that 
in section 6. Simple statements (http://docs.python.org/py3k/reference/simple_stmts.html)
in subsection 6.2. Assignment statements
there is a duplicate paragraph
"The name is rebound if it was already bound. This may ..."

Hope that helps,
Lukas

From report at bugs.python.org  Tue Jun 22 21:58:11 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 22 Jun 2010 19:58:11 +0000
Subject: [docs] [issue9021] no copy.copy problem description
In-Reply-To: <20100622101034.GA9303@remy>
Message-ID: <AANLkTinGwAeqS3i0Ka7taN2hAEL6iV6SbOq72rG9Ah-z@mail.gmail.com>


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

> The doc change suggested by Terry could be helpful in the tutorial
> where a copy module is mentioned.

Can you post a link to this tutorial here?

----------

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

From report at bugs.python.org  Wed Jun 23 05:13:19 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 23 Jun 2010 03:13:19 +0000
Subject: [docs] [issue9021] no copy.copy problem description
In-Reply-To: <AANLkTinGwAeqS3i0Ka7taN2hAEL6iV6SbOq72rG9Ah-z@mail.gmail.com>
Message-ID: <20100623031307.GA4532@remy>


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

> Can you post a link to this tutorial here?

Section 9.1 and 9.2 of the docs.python.org/tutorial
It may not be as explicit as you might want it to be, but it does sets
up background that assignments do not copy the object.

----------

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

From report at bugs.python.org  Wed Jun 23 17:46:35 2010
From: report at bugs.python.org (Craig Younkins)
Date: Wed, 23 Jun 2010 15:46:35 +0000
Subject: [docs] [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>


New submission from Craig Younkins <cyounkins at gmail.com>:

The method in question: http://docs.python.org/library/cgi.html#cgi.escape
http://svn.python.org/view/python/tags/r265/Lib/cgi.py?view=markup   # at the bottom
http://code.python.org/hg/trunk/file/3be6ff1eebac/Lib/cgi.py#l1031

"Convert the characters '&', '<' and '>' in string s to HTML-safe sequences. Use this if you need to display text that might contain such characters in HTML. If the optional flag quote is true, the quotation mark character ('"') is also translated; this helps for inclusion in an HTML attribute value, as in <A HREF="...">. If the value to be quoted might include single- or double-quote characters, or both, consider using the quoteattr() function in the xml.sax.saxutils module instead."

cgi.escape never escapes single quote characters, which can easily lead to a Cross-Site Scripting (XSS) vulnerability. This seems to be known by many, but a quick search reveals many are using cgi.escape for HTML attribute escaping.

The intended use of this method is unclear to me. Up to and including Mako 0.3.3, this method was the HTML escaping method. Used in this manner, single-quoted attributes with user-supplied data are easily susceptible to cross-site scripting vulnerabilities.

While the documentation says "if the value to be quoted might include single- or double-quote characters... [use the] xml.sax.saxutils module instead," it also implies that this method will make input safe for HTML. Because this method escapes 4 of the 5 key XML characters, it is reasonable to expect some will use it for HTML escaping.

I suggest rewording the documentation for the method making it more clear what it should and should not be used for. I would like to see the method changed to properly escape single-quotes, but if it is not changed, the documentation should explicitly say this method does not make input safe for inclusion in HTML.

This is definitely affecting the security of some Python web applications. I already mentioned Mako, but I've found this type of bug in other frameworks and engines because the creators either called cgi.escape directly or modeled their own after it.

Craig Younkins

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 108457
nosy: Craig.Younkins, docs at python
priority: normal
severity: normal
status: open
title: cgi.escape Can Lead To XSS Vulnerabilities
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun 23 17:47:38 2010
From: report at bugs.python.org (Craig Younkins)
Date: Wed, 23 Jun 2010 15:47:38 +0000
Subject: [docs] [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <1277308058.36.0.247306642605.issue9061@psf.upfronthosting.co.za>


Changes by Craig Younkins <cyounkins at gmail.com>:


----------
type:  -> security

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

From report at bugs.python.org  Wed Jun 23 19:14:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 17:14:47 +0000
Subject: [docs] [issue9063] TZ examples in datetime.rst are incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

With python started at the root of the source tree and TZ=US/Eastern in the environment,

>>> exec(open('Doc/includes/tzinfo-examples.py').read())
>>> import os
>>> os.environ['TZ']
'US/Eastern'
>>> from datetime import *
>>> x = datetime(2010, 11, 7, 5, tzinfo=timezone.utc)
>>> print(x, x.astimezone(Local), x.astimezone(Eastern))
2010-11-07 05:00:00+00:00 2010-11-07 01:00:00-04:00 2010-11-07 01:00:00-05:00
>>> x.astimezone(Local).dst() == x.astimezone(Eastern).dst() 
False

Note that according to my understanding of the long comment at the end of datetimemodule.c, zone conversion from UTC is a well defined operation unless there is a bug in tzinfo subclass implementation.

----------
assignee: docs at python
components: Documentation
messages: 108462
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: TZ examples in datetime.rst are incorrect
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Jun 23 19:37:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 17:37:29 +0000
Subject: [docs] [issue9063] TZ examples in datetime.rst are incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1277314649.67.0.0693015747916.issue9063@psf.upfronthosting.co.za>


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

The result given when Eastern tzinfo object is used is clearly wrong.  The timezone shift should not change the actual time, but

>>> x == x.astimezone(Eastern)
False

while

>>> x == x.astimezone(Local)
True

----------

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

From report at bugs.python.org  Wed Jun 23 20:22:42 2010
From: report at bugs.python.org (Craig Younkins)
Date: Wed, 23 Jun 2010 18:22:42 +0000
Subject: [docs] [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <1277317362.05.0.143587672652.issue9061@psf.upfronthosting.co.za>


Craig Younkins <cyounkins at gmail.com> added the comment:

Proof of concept:
print """<body class='%s'></body>""" % cgi.escape("' onload='alert(1);' bad='")

----------

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

From report at bugs.python.org  Wed Jun 23 20:29:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Jun 2010 18:29:51 +0000
Subject: [docs] [issue9063] TZ examples in datetime.rst are incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1277317791.39.0.255972459527.issue9063@psf.upfronthosting.co.za>


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

Let's establish what is the correct wall clock sequence around EDT to EST transition:

>>> import time
>>> def print_time(s):
...    tt = time.localtime(s)
...    print(time.strftime('%c %z %Z', tt))

x = datetime(2010, 11, 7, 5)
>>> s = (x - datetime(1970, 1, 1))//timedelta(seconds=1)

>>> for i in range(-3600, 5000, 1200):
...   print_time(s + i)
... 
Sun Nov  7 00:00:00 2010 -0400 EDT
Sun Nov  7 00:20:00 2010 -0400 EDT
Sun Nov  7 00:40:00 2010 -0400 EDT
Sun Nov  7 01:00:00 2010 -0400 EDT
Sun Nov  7 01:20:00 2010 -0400 EDT
Sun Nov  7 01:40:00 2010 -0400 EDT
Sun Nov  7 01:00:00 2010 -0500 EST
Sun Nov  7 01:20:00 2010 -0500 EST

However, neither Local nor Eastern tzinfo instance is capable of reproducing this sequence:


>>> for i in range(-3600, 5000, 1200):
...   print(datetime.fromtimestamp(s + i, Eastern).strftime('%c %z %Z'))

Sun Nov  7 00:00:00 2010 -0400 EDT
Sun Nov  7 00:20:00 2010 -0400 EDT
Sun Nov  7 00:40:00 2010 -0400 EDT
Sun Nov  7 01:00:00 2010 -0500 EST
Sun Nov  7 01:20:00 2010 -0500 EST
Sun Nov  7 01:40:00 2010 -0500 EST
Sun Nov  7 01:00:00 2010 -0500 EST
Sun Nov  7 01:20:00 2010 -0500 EST

>>> for i in range(-3600, 5000, 1200):
...   print(datetime.fromtimestamp(s + i, Local).strftime('%c %z %Z'))
 
Sun Nov  7 00:00:00 2010 -0400 EDT
Sun Nov  7 00:20:00 2010 -0400 EDT
Sun Nov  7 00:40:00 2010 -0400 EDT
Sun Nov  7 01:00:00 2010 -0400 EDT
Sun Nov  7 01:20:00 2010 -0400 EDT
Sun Nov  7 01:40:00 2010 -0400 EDT
Sun Nov  7 02:00:00 2010 -0500 EST
Sun Nov  7 02:20:00 2010 -0500 EST

----------

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

From report at bugs.python.org  Wed Jun 23 20:41:40 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 23 Jun 2010 18:41:40 +0000
Subject: [docs] [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <20100623184129.GB2645@remy>


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

On Wed, Jun 23, 2010 at 03:46:35PM +0000, Craig Younkins wrote:
> cgi.escape never escapes single quote characters, which can easily
> lead to a Cross-Site Scripting (XSS) vulnerability. This seems to be
> known by many, but a quick search reveals many are using cgi.escape
> for HTML attribute escaping.

cgi.escape is for HTML attribute escaping only.  I guess, you should
explain or point out to resources where 'single quotes' representation
in a non-entity format in a HTML page has lead to XSS.

> The intended use of this method is unclear to me. 

Escape HTML characters (most commonly), >,<, & and ". And mostly when
constructing responses where these characters are literally required.

> While the documentation says "if the value to be quoted might
> include single- or double-quote characters... [use the]
> xml.sax.saxutils module instead," it also implies that this method
> will make input safe for HTML. Because this method escapes 4 of the

"More suitable" for HTML would be the correct interpretation rather
make the "input safe". You might check the reference documentation
leading to xml.sax.saxutils.

> I suggest rewording the documentation for the method making it more
> clear what it should and should not be used for. 

The very next paragraph seems to address the security considerations
while using the cgi module itself, rather than limiting it to
cgi.escape. It says that:

"To be on the safe side, if you must pass a string gotten from a form
to a shell command, you should make sure the string contains only
alphanumeric characters, dashes, underscores, and periods."

With respect your bug report:

1. Any doc change suggestions you propose?  (After pointing out the
resources requested in first para)

2. If cgi.escape needs to escape single quotes, what should it be as:
lsquo/rsquo (for XHTML) and &#x27; or &#39; for Others?

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

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

From report at bugs.python.org  Wed Jun 23 21:06:01 2010
From: report at bugs.python.org (Craig Younkins)
Date: Wed, 23 Jun 2010 19:06:01 +0000
Subject: [docs] [issue9061] cgi.escape Can Lead To XSS Vulnerabilities
In-Reply-To: <1277307995.11.0.923855376948.issue9061@psf.upfronthosting.co.za>
Message-ID: <1277319961.03.0.841710792659.issue9061@psf.upfronthosting.co.za>


Craig Younkins <cyounkins at gmail.com> added the comment:

> cgi.escape is for HTML attribute escaping only.

It is not safe for HTML attribute escaping because it does not encode single quotes.

> "More suitable" for HTML would be the correct interpretation rather make the "input safe".

"More suitable, but not quite secure"

Regardless of the intended use of this method, many many people are using it for insecure HTML entity escaping.

> you should explain or point out to resources where 
> 'single quotes' representation in a non-entity format 
> in a HTML page has lead to XSS.

print "<body class='%s'></body>" % cgi.escape("' onload='alert(1);' bad='")

> The very next paragraph seems to address the security considerations
> while using the cgi module itself, rather than limiting it to
> cgi.escape. It says that:
> "To be on the safe side, if you must pass a string gotten from a form
> to a shell command, you should make sure the string contains only
> alphanumeric characters, dashes, underscores, and periods."

The security concerns related to output on the web are very different from the concerns related sending user input to a shell command. The needed escaping is completely different. Also, the security advice above is woefully inadequate. 

> Any doc change suggestions you propose?

Convert the characters '&', '<' and '>' in string s to their HTML entity encoded values. If the optional flag quote is true, the double-quotation mark character ('"') is also encoded. Note that the output of this method is not safe to put in an HTML attribute because it does not escape single quotes. If the value to be quoted might include single- or double-quote characters, or both, consider using the quoteattr() function in the xml.sax.saxutils module instead.

> If cgi.escape needs to escape single quotes, what should it be as:
> lsquo/rsquo (for XHTML) and &#x27; or &#39; for Others?

Sorry, I should have included that in the OP. It should escape to &#x27; 
It is also advised to escape the forward slash character ('/') to &#x2F;

See OWASP.org for an explanation of the complexities of the escaping:
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content

----------

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

From report at bugs.python.org  Fri Jun 25 01:35:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 23:35:14 +0000
Subject: [docs] [issue9078] Fix C API documentation of unicode
Message-ID: <1277422514.67.0.469238167235.issue9078@psf.upfronthosting.co.za>


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


----------
assignee: docs at python
components: Documentation, Unicode
files: unicode_doc.patch
keywords: patch
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Fix C API documentation of unicode
versions: Python 3.2
Added file: http://bugs.python.org/file17765/unicode_doc.patch

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

From report at bugs.python.org  Fri Jun 25 01:35:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jun 2010 23:35:54 +0000
Subject: [docs] [issue9078] Fix C API documentation of unicode
In-Reply-To: <1277422554.75.0.295241572037.issue9078@psf.upfronthosting.co.za>
Message-ID: <1277422554.75.0.295241572037.issue9078@psf.upfronthosting.co.za>


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

Attached patch fixes minor bugs in the C API documentation of unicode.

----------

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

From report at bugs.python.org  Fri Jun 25 10:52:38 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Jun 2010 08:52:38 +0000
Subject: [docs] [issue9076] Remove
	PyUnicode_AsDecodedObject/Unicode	and	PyUnicode_AsEncodedObject/Unicode?
In-Reply-To: <1277422131.02.0.354002642954.issue9076@psf.upfronthosting.co.za>
Message-ID: <1277455958.92.0.830585761118.issue9076@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun 25 10:53:09 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 25 Jun 2010 08:53:09 +0000
Subject: [docs] [issue9076] Add C-API documentation
	for	PyUnicode_AsDecodedObject/Unicode
	and	PyUnicode_AsEncodedObject/Unicode
In-Reply-To: <1277422131.02.0.354002642954.issue9076@psf.upfronthosting.co.za>
Message-ID: <1277455989.82.0.575123571897.issue9076@psf.upfronthosting.co.za>


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


----------
title: Remove PyUnicode_AsDecodedObject/Unicode and	PyUnicode_AsEncodedObject/Unicode? -> Add C-API documentation for PyUnicode_AsDecodedObject/Unicode and PyUnicode_AsEncodedObject/Unicode

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

From report at bugs.python.org  Fri Jun 25 14:21:29 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Jun 2010 12:21:29 +0000
Subject: [docs] [issue9078] Fix C API documentation of unicode
In-Reply-To: <1277422554.75.0.295241572037.issue9078@psf.upfronthosting.co.za>
Message-ID: <1277468488.74.0.217382973472.issue9078@psf.upfronthosting.co.za>


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

Looks good to me.

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

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

From report at bugs.python.org  Sat Jun 26 02:50:51 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jun 2010 00:50:51 +0000
Subject: [docs] [issue5212] Incorrect note about md5 in hmac module
	documentation
In-Reply-To: <1234312792.25.0.547667950303.issue5212@psf.upfronthosting.co.za>
Message-ID: <1277513450.92.0.238833844204.issue5212@psf.upfronthosting.co.za>


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

Are you proposing that the note be removed entirely (and ignore the results it is based on) or just reworded? If it were removed, I could imagine complaints. If reword, specifically how?

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

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

From report at bugs.python.org  Sat Jun 26 04:18:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 02:18:28 +0000
Subject: [docs] [issue9024] PyDateTime_IMPORT macro incorrectly marked up
In-Reply-To: <4C1B32EB.6020900@timgolden.me.uk>
Message-ID: <1277518708.2.0.658150330819.issue9024@psf.upfronthosting.co.za>


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

Committed in r82236 - r82239.

----------
nosy: +belopolsky
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jun 26 05:33:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 03:33:08 +0000
Subject: [docs] [issue9024] PyDateTime_IMPORT macro incorrectly marked up
In-Reply-To: <4C1B32EB.6020900@timgolden.me.uk>
Message-ID: <1277523183.43.0.948117992851.issue9024@psf.upfronthosting.co.za>


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

Should also add :cvar: tag to PyDateTimeAPI.

 http://docs.python.org/documenting/markup.html#information-units

Thanks, Ezio.

----------
assignee: docs at python -> belopolsky
status: closed -> open

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

From report at bugs.python.org  Sat Jun 26 12:05:39 2010
From: report at bugs.python.org (John Miller)
Date: Sat, 26 Jun 2010 10:05:39 +0000
Subject: [docs] [issue9086] Wrong linking terminology in windows FAQ
In-Reply-To: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>
Message-ID: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>


New submission from John Miller <gyuval at gmail.com>:

The 'How can I embed Python' section in the 'Python on Windows FAQ' (http://docs.python.org/faq/windows.html) uses wrong terms:
What the FAQ calls static linking and dynamic linking are actally two forms of dynamic linking - load-time dynamic linking and run-time dynamic linking, respectively.
Static linking means something else entirely - linking with a library that itself contains the implementation, i.e. there will be no usage of the DLL at all. Since the FAQ states that pythonNN.lib is just an import lib, static linking isn't really an option with this library.

Also the FAQ states that 'The drawback to dynamic linking is that your app won?t run if pythonNN.dll does not exist on your system'. This is misleading for two reasons:
- If the application uses the DLL, it won't run as expected if the DLL doesn't exist, regardless of how it loads the DLL. 
- Of the two linking options, load-time dynamic linking (what the FAQ refers to as static linking) is actually the one that handles the missing DLL more badly: The app will crash upon loading. If run-time dynamic linking is used, loading of the DLL happens in the application code, and it can handle it however it chooses to - it can inform the user, disable the feature that needs the DLL, etc.

----------
assignee: docs at python
components: Documentation
messages: 108700
nosy: docs at python, john.miller
priority: normal
severity: normal
status: open
title: Wrong linking terminology in windows FAQ
versions: Python 2.6

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

From report at bugs.python.org  Sat Jun 26 12:11:22 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 26 Jun 2010 10:11:22 +0000
Subject: [docs] [issue9086] Wrong linking terminology in windows FAQ
In-Reply-To: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>
Message-ID: <1277547082.49.0.600218965635.issue9086@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

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

From report at bugs.python.org  Sat Jun 26 20:59:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Jun 2010 18:59:56 +0000
Subject: [docs] [issue9024] PyDateTime_IMPORT macro incorrectly marked up
In-Reply-To: <4C1B32EB.6020900@timgolden.me.uk>
Message-ID: <1277578795.84.0.60788678296.issue9024@psf.upfronthosting.co.za>


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

Committed in r82251.  Thanks for the patch, Tim.

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

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

From report at bugs.python.org  Sun Jun 27 02:53:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 00:53:49 +0000
Subject: [docs] [issue9089] PyNumber_Int is still mentioned in number
	protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

See http://docs.python.org/dev/py3k/c-api/number.html#PyNumber_Int

I also noticed some left-over references to intobject in the comments in the py3k tree:

Include/longobject.h:61:/* For use by intobject.c only */
Modules/xxmodule.c:13:   intobject.h for an example. */
Objects/floatobject.c:24:/* Special free list -- see comments for same code in intobject.c. */
Objects/frameobject.c:394:   integers are allocated in a special way -- see intobject.c).  When
PCbuild/pythoncore.vcproj:758:				RelativePath="..\Include\intobject.h"

----------
assignee: docs at python
components: Documentation
messages: 108766
nosy: belopolsky, docs at python, mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: PyNumber_Int is still mentioned in number protocol docs
type: feature request
versions: Python 3.2

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

From contact at johnbokma.com  Wed Jun 23 06:53:38 2010
From: contact at johnbokma.com (John Bokma)
Date: Tue, 22 Jun 2010 23:53:38 -0500
Subject: [docs] Printed docs legitimate?
Message-ID: <4C219352.10407@johnbokma.com>

Hi,

I participate in a Usenet discussion (comp.lang.python) regarding if:

http://www.amazon.com/Python-Reference-Manual-Documentation-Part/dp/1441412697/

is allowed? I think yes.

On top of that, do you know if Python Software Foundation does receive 
1USD donations per sold book per "For each copy sold $1 will be donated 
to the Python Software Foundation by the publisher."

I have been considering to buy those manuals but if this is not in 
agreement with python.org / PSF, let me know.

Thanks for your time,
John

From thomas.oliveira at gmail.com  Thu Jun 24 04:04:42 2010
From: thomas.oliveira at gmail.com (Thomas Oliveira)
Date: Wed, 23 Jun 2010 23:04:42 -0300
Subject: [docs] Question mark in grammar notation
Message-ID: <4C22BD3A.3030206@gmail.com>

Dear Admin,

In http://docs.python.org/py3k/library/string.html#format-string-syntax
a question mark is used at the definition of the grammar for a 
replacement field:

arg_name          ::=  (identifier | integer)?

However, it is not defined in
http://docs.python.org/py3k/reference/introduction.html#notation

Would it be the same as
arg_name          ::=  [identifier | integer]
?

Thank you for your attention,

Thomas Oliveira

From dave000 at hellspark.com  Fri Jun 25 01:54:19 2010
From: dave000 at hellspark.com (dave000)
Date: Thu, 24 Jun 2010 16:54:19 -0700
Subject: [docs] Confusing sentence at
	http://docs.python.org/tutorial/introduction.html#strings
Message-ID: <AANLkTin3cR--qN17R8KBmhPxx92ca-l1Rumx0wxbIIqw@mail.gmail.com>

http://docs.python.org/tutorial/introduction.html#strings

The statement
"Note that newlines still need to be embedded in the string using \n;
the newline following the trailing backslash is discarded. This
example would print the following:"
is confusing with the semicolon in that sentence. I was looking for a
semicolon in the code fragment and thought there was a typo at first.

Perhaps the following would be clearer?
""Note that newlines still need to be embedded in the string using \n
; the newline following the trailing backslash is discarded. This
example would print the following:"

The gray color on the command-line would then have enough white space
to differentiate it from the semicolon.
Or maybe i just need to buy a better monitor! :D

From billzingler at gmail.com  Fri Jun 25 22:24:18 2010
From: billzingler at gmail.com (Bill Zingler)
Date: Fri, 25 Jun 2010 16:24:18 -0400
Subject: [docs] parser library documentation references non-existent
	example.py
Message-ID: <AANLkTinLNlSSG2st_IBAaYwkcHHqtHUldZenWz_ZClew@mail.gmail.com>

Reference: http://docs.python.org/library/parser.html#information-discovery

<http://docs.python.org/library/parser.html>This page says to "See file
example.py" several times, but doesn't provide a link to the file or the
complete text of the file.  It would be really helpful to have example.py.

Thanks,

Bill

-- 
Bill Zingler
Zingler & Associates, Inc.
(443) 822-4857
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20100625/c1a06d3f/attachment-0001.html>

From larryv at MIT.EDU  Sun Jun 27 02:27:52 2010
From: larryv at MIT.EDU (=?iso-8859-1?Q?Lawrence_Vel=E1zquez?=)
Date: Sat, 26 Jun 2010 20:27:52 -0400
Subject: [docs] Bug in Section 4.2
Message-ID: <7FD30D1B-B970-46A9-B205-D901119EF753@mit.edu>

Hi,

The webpage linked to in Section 4.2, "The IDE", doesn't exist anymore. Just a heads up.

http://docs.python.org/py3k/using/mac.html

Larry

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

From report at bugs.python.org  Sun Jun 27 11:50:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jun 2010 09:50:30 +0000
Subject: [docs] [issue9089] PyNumber_Int is still mentioned in number
	protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277632229.69.0.753947672149.issue9089@psf.upfronthosting.co.za>


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

Thanks; I'll fix these.

----------
assignee: docs at python -> mark.dickinson

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

From report at bugs.python.org  Sun Jun 27 12:17:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 10:17:18 +0000
Subject: [docs] [issue9078] Fix C API documentation of unicode
In-Reply-To: <1277422554.75.0.295241572037.issue9078@psf.upfronthosting.co.za>
Message-ID: <1277633838.2.0.234215479252.issue9078@psf.upfronthosting.co.za>


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

Committed as r82262.

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

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

From georg at python.org  Sun Jun 27 12:43:37 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 12:43:37 +0200
Subject: [docs] Fwd:  Printed docs legitimate?
Message-ID: <4C272B59.7090807@python.org>

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

Forwarding to PSF board -- printing and selling *is* allowed, however
I don't know if the $1 donation claim is correct.

Georg

- -------- Original-Nachricht --------
Betreff: [docs] Printed docs legitimate?
Datum: Tue, 22 Jun 2010 23:53:38 -0500
Von: John Bokma <contact at johnbokma.com>
Organisation: Castle Amber
An: docs at python.org

Hi,

I participate in a Usenet discussion (comp.lang.python) regarding if:

http://www.amazon.com/Python-Reference-Manual-Documentation-Part/dp/1441412697/

is allowed? I think yes.

On top of that, do you know if Python Software Foundation does receive
1USD donations per sold book per "For each copy sold $1 will be donated
to the Python Software Foundation by the publisher."

I have been considering to buy those manuals but if this is not in
agreement with python.org / PSF, let me know.

Thanks for your time,
John
_______________________________________________
docs mailing list
docs at python.org
http://mail.python.org/mailman/listinfo/docs

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

iEYEARECAAYFAkwnK1gACgkQN9GcIYhpnLC+TgCgnoAjz3T9A/vyj4cxeYGXoOGt
He8An3Q5Hfyz9Xfp4folCs9dXKWFtp2p
=1sqf
-----END PGP SIGNATURE-----

From georg at python.org  Sun Jun 27 12:46:48 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 12:46:48 +0200
Subject: [docs] Confusing sentence
	at	http://docs.python.org/tutorial/introduction.html#strings
In-Reply-To: <AANLkTin3cR--qN17R8KBmhPxx92ca-l1Rumx0wxbIIqw@mail.gmail.com>
References: <AANLkTin3cR--qN17R8KBmhPxx92ca-l1Rumx0wxbIIqw@mail.gmail.com>
Message-ID: <4C272C18.6080007@python.org>

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

Am 25.06.2010 01:54, schrieb dave000:
> http://docs.python.org/tutorial/introduction.html#strings
> 
> The statement
> "Note that newlines still need to be embedded in the string using \n;
> the newline following the trailing backslash is discarded. This
> example would print the following:"
> is confusing with the semicolon in that sentence. I was looking for a
> semicolon in the code fragment and thought there was a typo at first.
> 
> Perhaps the following would be clearer?
> ""Note that newlines still need to be embedded in the string using \n
> ; the newline following the trailing backslash is discarded. This
> example would print the following:"
> 
> The gray color on the command-line would then have enough white space
> to differentiate it from the semicolon.

I've replaced the semicolon by a dash now, should be easier to read.

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

iEYEARECAAYFAkwnLBgACgkQN9GcIYhpnLDQNQCgmi4YW7erBmnzWVEykJ+Az1au
pJkAn0BzoAL+CmjHhO4gBSPa//TSIpKZ
=+a5+
-----END PGP SIGNATURE-----

From georg at python.org  Sun Jun 27 12:48:09 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 12:48:09 +0200
Subject: [docs] Question mark in grammar notation
In-Reply-To: <4C22BD3A.3030206@gmail.com>
References: <4C22BD3A.3030206@gmail.com>
Message-ID: <4C272C69.3000004@python.org>

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

Am 24.06.2010 04:04, schrieb Thomas Oliveira:
> Dear Admin,
> 
> In http://docs.python.org/py3k/library/string.html#format-string-syntax
> a question mark is used at the definition of the grammar for a 
> replacement field:
> 
> arg_name          ::=  (identifier | integer)?
> 
> However, it is not defined in
> http://docs.python.org/py3k/reference/introduction.html#notation
> 
> Would it be the same as
> arg_name          ::=  [identifier | integer]
> ?

Yes, you are right; the latter should be used.  I've fixed that now.

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

iEYEARECAAYFAkwnLGkACgkQN9GcIYhpnLABmQCcD+T6I7GVpE5JCmmks+yCgBAU
SNIAoJjt5ByeCWuOPdG8GDw5XVoDpPSH
=N9hn
-----END PGP SIGNATURE-----

From georg at python.org  Sun Jun 27 12:50:50 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 12:50:50 +0200
Subject: [docs] Bug in Section 4.2
In-Reply-To: <7FD30D1B-B970-46A9-B205-D901119EF753@mit.edu>
References: <7FD30D1B-B970-46A9-B205-D901119EF753@mit.edu>
Message-ID: <4C272D0A.1090601@python.org>

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

Am 27.06.2010 02:27, schrieb Lawrence Vel?zquez:
> Hi,
> 
> The webpage linked to in Section 4.2, "The IDE", doesn't exist anymore.
> Just a heads up.
> 
> http://docs.python.org/py3k/using/mac.html
> 

Thanks for the report; the page actually still exists, but there
was a tilde missing in our URL.  This is fixed now (and should be
online soon).

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

iEYEARECAAYFAkwnLQoACgkQN9GcIYhpnLDtzwCfYp21cm6gBbDTXqn+9PzpvpUM
z1kAn1LRimiksJfMki2NYCAHfa0gFQzu
=OSnn
-----END PGP SIGNATURE-----

From georg at python.org  Sun Jun 27 12:52:10 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 12:52:10 +0200
Subject: [docs] whatsnew/3.1.html says: Release:3.2a0
In-Reply-To: <AANLkTin_b3xlFGw2ZUlVjfCHU_iXf23c2es095-6yibZ@mail.gmail.com>
References: <AANLkTin_b3xlFGw2ZUlVjfCHU_iXf23c2es095-6yibZ@mail.gmail.com>
Message-ID: <4C272D5A.5010309@python.org>

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

Am 17.06.2010 11:31, schrieb Sebastian Haase:
> Hi,
> 
> both pages
> http://docs.python.org/dev/py3k/whatsnew/3.1.html
> and
> http://docs.python.org/dev/py3k/whatsnew/3.0.html
> show at the top:
> 
> Release:	3.2a0
> Date:	June 17, 2010
> 
> Isn't this a bug ?

Well, it's the 3.1 What's New from the 3.2 documentation,
therefore the "release" field is a bit misleading.  But it
still is correct.

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

iEYEARECAAYFAkwnLVoACgkQN9GcIYhpnLCUnwCfWLdA0n1i21j23Cia/Enpy8l6
FmYAoI/sPG+iH2yzilqIWH/xjMUrgpA4
=+B7e
-----END PGP SIGNATURE-----

From georg at python.org  Sun Jun 27 12:54:06 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 12:54:06 +0200
Subject: [docs] Typo
	in	http://docs.python.org/distutils/builtdist.html#creating-windows-installers
In-Reply-To: <AANLkTimbyBNNsVIraneEGjcQxHvjNUCQ_bCitfUFTYlk@mail.gmail.com>
References: <AANLkTimbyBNNsVIraneEGjcQxHvjNUCQ_bCitfUFTYlk@mail.gmail.com>
Message-ID: <4C272DCE.5080405@python.org>

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

Am 22.06.2010 10:45, schrieb Olivier BERTEN:
> Hi! there's a small typo in "5.3. Creating Windows Installers":
> The bitmap size is 152x261 instead of 161

Thanks, both typos are fixed now.

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

iEYEARECAAYFAkwnLc4ACgkQN9GcIYhpnLC6fQCgl3F3u926YV6u9IRktSVCNxTi
TP0AnA7Ah4I6B8YCcIfmvVHchxcZBGTe
=eBbS
-----END PGP SIGNATURE-----

From georg at python.org  Sun Jun 27 12:56:15 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 12:56:15 +0200
Subject: [docs] bug in documentation - duplicate paragraph
In-Reply-To: <27185.6268.9483-28869-1372615096-1277221711@seznam.cz>
References: <27185.6268.9483-28869-1372615096-1277221711@seznam.cz>
Message-ID: <4C272E4F.3090002@python.org>

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

Am 22.06.2010 17:48, schrieb Lukas Petru:
> I have noticed that 
> in section 6. Simple statements (http://docs.python.org/py3k/reference/simple_stmts.html)
> in subsection 6.2. Assignment statements
> there is a duplicate paragraph
> "The name is rebound if it was already bound. This may ..."

Thanks for the report; this is now fixed in SVN.

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

iEYEARECAAYFAkwnLk8ACgkQN9GcIYhpnLC/HwCfULcaISz5m+A9IOvyJlqM1ToW
QKgAn238jnfUMfCmbYFnP3Yrdk0hv5Cd
=dKX+
-----END PGP SIGNATURE-----

From georg at python.org  Sun Jun 27 12:58:30 2010
From: georg at python.org (Georg Brandl)
Date: Sun, 27 Jun 2010 12:58:30 +0200
Subject: [docs] Tutorial 4.3 Range, print(range(x)) does return list
In-Reply-To: <AANLkTin9ESgdayDpupF_5tZ25PqgV6YUmQyyV-9EktoS@mail.gmail.com>
References: <AANLkTin9ESgdayDpupF_5tZ25PqgV6YUmQyyV-9EktoS@mail.gmail.com>
Message-ID: <4C272ED6.3080503@python.org>

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

Am 15.06.2010 17:25, schrieb Anatoly Y:
> Hi,
> 
> http://docs.python.org/dev/py3k/tutorial/controlflow.html#the-range-function
> 
> | A strange thing happens if you just print a range:
> | >>> print(range(10))
> | range(0, 10)
> | In many ways the object returned by range() behaves as if it is a
> list, but in fact it isn?t.
> | It is an object which returns the successive items of the desired
> sequence when you iterate over it,
> | but it doesn?t really make the list, thus saving space.
> 
> 
> ^^ This is not true for 3.2.1 and 2.6.4
> 
> Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit
> (Intel)] on win32
>>>> print(range(5))
> [0, 1, 2, 3, 4]
>>>> type(range(5))
> <type 'list'>

This is true for 2.6, but you were looking at the 3.x documentation.
Have a look at the tutorial section for 2.x, and you will see that
it documents range() as returning a list.

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

iEYEARECAAYFAkwnLtYACgkQN9GcIYhpnLBZTQCgo2bUDKxQfpw/zIlY4M5qDNcS
icEAnAmkXOhxotcja6gngqgZkxHwspwP
=50zt
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sun Jun 27 19:08:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Jun 2010 17:08:15 +0000
Subject: [docs] [issue9093] Tools/README is out of date
In-Reply-To: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>
Message-ID: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Here is the list of subdirectories in Tools.  Here is the diff between directory listing and readme ('-' means no readme entry, '+' - no tool):

-buildbot
-ccbench
+audiopy
+compiler
 faqwiz
-framer
 freeze
 gdb
 i18n
-iobench
-msi
-pybench
 pynche
 scripts
-ssl
 unicode
 versioncheck
+webchecker
 world

----------
assignee: docs at python
components: Documentation
messages: 108797
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Tools/README is out of date
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Sun Jun 27 19:37:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jun 2010 17:37:39 +0000
Subject: [docs] [issue9089] PyNumber_Int is still mentioned in number
	protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277660259.53.0.485985864456.issue9089@psf.upfronthosting.co.za>


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

Removed PyNumber_Int from docs (and Data/refcounts.dat;  though I suspect that file is far from up-to-date) in r82288.

----------

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

From report at bugs.python.org  Sun Jun 27 20:19:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jun 2010 18:19:48 +0000
Subject: [docs] [issue9089] PyNumber_Int is still mentioned in number
	protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277662788.63.0.137650377988.issue9089@psf.upfronthosting.co.za>


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

References to intobject.h and intobject.c removed in r88289 and r88290.

Thanks!

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

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

From report at bugs.python.org  Sun Jun 27 20:19:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 27 Jun 2010 18:19:59 +0000
Subject: [docs] [issue9089] PyNumber_Int is still mentioned in number
	protocol docs
In-Reply-To: <1277600028.16.0.686508987886.issue9089@psf.upfronthosting.co.za>
Message-ID: <1277662799.84.0.677567410147.issue9089@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> committed/rejected

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

From report at bugs.python.org  Mon Jun 28 16:13:26 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Jun 2010 14:13:26 +0000
Subject: [docs] [issue8653] urlparse.urlparse/urlsplit doc missing
In-Reply-To: <1273257542.33.0.475796266696.issue8653@psf.upfronthosting.co.za>
Message-ID: <1277734406.1.0.6327977902.issue8653@psf.upfronthosting.co.za>


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

Fixed in r82324, r82325, r82326, r82327.
Only the urlunsplit need the docstrings, I added that.

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

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

From report at bugs.python.org  Mon Jun 28 17:37:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 15:37:23 +0000
Subject: [docs] [issue9101] reference json format in file formats chapter
In-Reply-To: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>
Message-ID: <1277739443.04.0.607128047102.issue9101@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Quite often people use .json files for storing configuration. Having a reference to json module from chapter "14. File Formats" would be a good pointer for those looking to .ini alternatives.

----------
assignee: docs at python
components: Documentation
messages: 108833
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: reference json format in file formats chapter
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jun 28 19:25:56 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 17:25:56 +0000
Subject: [docs] [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Pickle warning about insecurity is located only at the second page near the bottom of "Relationship to other Python modules" chapter. For me the proper place for it is the first page of documentation.

----------
assignee: docs at python
components: Documentation
messages: 108847
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: pickle security note should be more prominent
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jun 28 19:34:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Jun 2010 17:34:49 +0000
Subject: [docs] [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1277746489.31.0.303509315992.issue9105@psf.upfronthosting.co.za>


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

See also issue8855.

I believe Anatoly refers to 

http://docs.python.org/py3k/library/pickle.html

I agree, the warning can be moved up so that it is visible on the first page in typical rendering.

Note that there is also

http://docs.python.org/py3k/tutorial/inputoutput.html#the-pickle-module

which contains no warning at all.

----------
keywords: +easy
nosy: +belopolsky
stage:  -> needs patch
type:  -> feature request

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

From report at bugs.python.org  Mon Jun 28 20:28:24 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 18:28:24 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

It seems that left side ToC menu will be more clear without numeric prefixes from chapter on 3-.. nesting levels. How about to remove them?

For example - the ToC menu now starting from root level:

15.6. logging ? Logging facility for Python
    * 15.6.1. Logging tutorial
          o 15.6.1.1. Simple examples
          o 15.6.1.2. Loggers
          o 15.6.1.3. Handlers
          o 15.6.1.4. Formatters
          o 15.6.1.5. Configuring Logging
          o 15.6.1.6. Configuring Logging for a Library
    * 15.6.2. Logging Levels
    * 15.6.3. Useful Handlers
...

will look like:

15.6. logging ? Logging facility for Python
    * 1. Logging tutorial
          o 1.1. Simple examples
          o 1.2. Loggers
          o 1.3. Handlers
          o 1.4. Formatters
          o 1.5. Configuring Logging
          o 1.6. Configuring Logging for a Library
    * 2. Logging Levels
    * 3. Useful Handlers
...

----------
assignee: docs at python
components: Documentation
messages: 108850
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: remove numbers from 3-.. level entries in docs toc
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Jun 28 20:30:16 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 28 Jun 2010 18:30:16 +0000
Subject: [docs] [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1277749816.56.0.221141467649.issue9105@psf.upfronthosting.co.za>


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

Also http://docs.python.org/library/pickle.html

http://docs.python.org/library/logging.html#sending-and-receiving-logging-events-across-a-network
and
http://mail.python.org/pipermail/python-dev/2010-June/101179.html

The link to Nadia blog is also very helpful for investigation of pickle problems http://nadiana.com/python-pickle-insecure

----------

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

From report at bugs.python.org  Mon Jun 28 23:24:49 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 28 Jun 2010 21:24:49 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277760289.42.0.692249910028.issue9106@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jun 29 03:58:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 01:58:37 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277776717.71.0.522009945793.issue9106@psf.upfronthosting.co.za>


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

-1

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

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

From report at bugs.python.org  Tue Jun 29 06:09:50 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 Jun 2010 04:09:50 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277776717.71.0.522009945793.issue9106@psf.upfronthosting.co.za>
Message-ID: <AANLkTilWkZE-tQ03T5ZSRe40AR5TQQ7wAezoGRZbYInZ@mail.gmail.com>


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

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

Why? Do you like wrapped menu entries three lines long?

----------

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

From report at bugs.python.org  Tue Jun 29 07:05:11 2010
From: report at bugs.python.org (.:. brainsik)
Date: Tue, 29 Jun 2010 05:05:11 +0000
Subject: [docs] [issue5212] Incorrect note about md5 in hmac module
	documentation
In-Reply-To: <1234312792.25.0.547667950303.issue5212@psf.upfronthosting.co.za>
Message-ID: <1277787910.47.0.673525513727.issue5212@psf.upfronthosting.co.za>


.:. brainsik <spork-python at theory.org> added the comment:

Since the note is incorrect, it seems like it should be removed. What "results it is based on" are you referring to and what complaints are you concerned about?

----------

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

From report at bugs.python.org  Tue Jun 29 07:10:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 29 Jun 2010 05:10:47 +0000
Subject: [docs] [issue5212] Incorrect note about md5 in hmac module
	documentation
In-Reply-To: <1234312792.25.0.547667950303.issue5212@psf.upfronthosting.co.za>
Message-ID: <1277788247.11.0.670767897689.issue5212@psf.upfronthosting.co.za>


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

The supposed 'known weaknesses'. I have no particular opinion.
Anyway, we have your recommendation: remove the note.
I will let others defend it.

----------

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

From report at bugs.python.org  Tue Jun 29 10:06:50 2010
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 29 Jun 2010 08:06:50 +0000
Subject: [docs] [issue9112] argparse missing documentation for error() method
In-Reply-To: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>
Message-ID: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

The argparse module's ArgumentParser class has an error() method that appears to have the same behavior as the optparse error() method, but this method is not mentioned in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 108896
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: argparse missing documentation for error() method
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Jun 29 10:42:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Jun 2010 08:42:06 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277800926.53.0.712822710533.issue9106@psf.upfronthosting.co.za>


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

This should be taken to the Sphinx tracker, as the feature needs to be implemented first.

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

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

From report at bugs.python.org  Tue Jun 29 12:32:05 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 Jun 2010 10:32:05 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277807524.83.0.456782256145.issue9106@psf.upfronthosting.co.za>


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

http://bitbucket.org/birkenfeld/sphinx/issue/460/strip-section-numbers-from-toc-menu

----------

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

From report at bugs.python.org  Tue Jun 29 14:25:00 2010
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 29 Jun 2010 12:25:00 +0000
Subject: [docs] [issue9114] br"" string literals don't appear to be
	documented
In-Reply-To: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>
Message-ID: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

It appears that br"" (raw bytes) isn't documented, at least not along with string and bytes literals:
http://docs.python.org/py3k/reference/lexical_analysis.html#literals

Yet they are supported:
http://mail.python.org/pipermail/python-ideas/2010-June/007529.html

----------
assignee: docs at python
components: Documentation
messages: 108902
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: br"" string literals don't appear to be documented
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun 29 14:27:49 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Jun 2010 12:27:49 +0000
Subject: [docs] [issue9114] br"" string literals don't appear to be
	documented
In-Reply-To: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>
Message-ID: <1277814469.42.0.645283872676.issue9114@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/issue9114>
_______________________________________

From report at bugs.python.org  Tue Jun 29 15:37:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 13:37:03 +0000
Subject: [docs] [issue9112] argparse missing documentation for error() method
In-Reply-To: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>
Message-ID: <1277818623.12.0.0322747554319.issue9112@psf.upfronthosting.co.za>


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


----------
nosy: +bethard

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

From report at bugs.python.org  Tue Jun 29 15:46:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 13:46:54 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277819214.66.0.562208520926.issue9106@psf.upfronthosting.co.za>


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

If the change is confined to the left menu bar only, I'd be happy to have the numbers go away entirely.  But only putting in partial numbers strikes me as an invitation to confusion.  If other people prefer your scheme that's fine with me.  Almost the only time I look at the left menu bar (except on the front page of docs) is when I want to find the 'show source' link.

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

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

From report at bugs.python.org  Tue Jun 29 16:14:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Jun 2010 14:14:13 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277820853.54.0.943462816907.issue9106@psf.upfronthosting.co.za>


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

+1 for removing numbers.

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

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

From report at bugs.python.org  Tue Jun 29 17:02:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 29 Jun 2010 15:02:44 +0000
Subject: [docs] [issue8939] Use C type names (PyUnicode etc;
	) in the C API docs
In-Reply-To: <1276002876.44.0.334392966089.issue8939@psf.upfronthosting.co.za>
Message-ID: <1277823764.31.0.378600974606.issue8939@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/issue8939>
_______________________________________

From report at bugs.python.org  Tue Jun 29 17:58:12 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Jun 2010 15:58:12 +0000
Subject: [docs] [issue9114] br"" string literals don't appear to be
	documented
In-Reply-To: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>
Message-ID: <1277827092.78.0.325555815367.issue9114@psf.upfronthosting.co.za>


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

Fixed in r82373.

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

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

From report at bugs.python.org  Tue Jun 29 18:07:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 29 Jun 2010 16:07:03 +0000
Subject: [docs] [issue9114] br"" string literals don't appear to be
	documented
In-Reply-To: <1277814300.14.0.365243275067.issue9114@psf.upfronthosting.co.za>
Message-ID: <1277827623.81.0.162949375356.issue9114@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jun 29 18:52:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 16:52:40 +0000
Subject: [docs] [issue9117] class syntax not fully documented in reference
	manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

Looking at:

http://docs.python.org/dev/py3k/reference/compound_stmts.html#class-definitions

I see:

classdef    ::=  [decorators] "class" classname [inheritance] ":" suite
inheritance ::=  "(" [expression_list] ")"
classname   ::=  identifier

this seems to be missing the keyword arguments that are now possible in a classdef (e.g. for specifying a metaclass).  I believe that *args and **kwargs are now also syntactically accepted in a class definition.

----------
assignee: docs at python
components: Documentation
messages: 108917
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: class syntax not fully documented in reference manual
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Jun 29 19:02:05 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 17:02:05 +0000
Subject: [docs] [issue9117] class syntax not fully documented in reference
	manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277830925.75.0.410166084661.issue9117@psf.upfronthosting.co.za>


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

Am working on a patch.

----------

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

From report at bugs.python.org  Tue Jun 29 19:19:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 17:19:44 +0000
Subject: [docs] [issue9117] class syntax not fully documented in reference
	manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277831983.72.0.72413557365.issue9117@psf.upfronthosting.co.za>


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

> I believe that *args and **kwargs are now also syntactically
> accepted in a class definition.

Indeed:

>>> class a: pass
>>> class b: pass
>>> bases = (a, b)
>>> class c(*bases): pass
>>> kwds = {'metaclass':type}
>>> class c(*bases, **kwds): pass

works!

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

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

From report at bugs.python.org  Tue Jun 29 20:03:53 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 18:03:53 +0000
Subject: [docs] [issue9117] class syntax not fully documented in reference
	manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277834633.34.0.837796311989.issue9117@psf.upfronthosting.co.za>


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

It looks like fixing the production list is the easy part (see attached patch):  as far as I can tell, the *syntax* for class definitions is pretty much identical to that for function calls.  (The semantics are different, of course.)  It would be good if someone could check this patch for sanity, though.

The description in that section still needs updating.

----------
keywords: +patch
Added file: http://bugs.python.org/file17802/issue9117.patch

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

From report at bugs.python.org  Tue Jun 29 20:37:39 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Jun 2010 18:37:39 +0000
Subject: [docs] [issue9119] Python download page needs to mention crypto
	code in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

This needs to be done to protect our users (importing crypto code or using it may be illegal in their home country, see http://rechten.uvt.nl/koops/cryptolaw/ for a survey) and to satisfy an attribution requirement in the OpenSSL license and code base:

"""
This product includes cryptographic software written by Eric Young (eay at cryptsoft.com). This product includes software written by Tim Hudson (tjh at cryptsoft.com). This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
"""

----------
assignee: docs at python
components: Build, Documentation
messages: 108929
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: Python download page needs to mention crypto code in Windows installer
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jun 29 20:38:38 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Jun 2010 18:38:38 +0000
Subject: [docs] [issue9119] Python download page needs to mention crypto
	code in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1277836718.55.0.227029795055.issue9119@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

See the OpenSSL license for details on the notice requirement:

http://www.openssl.org/source/license.html

----------

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

From report at bugs.python.org  Tue Jun 29 20:41:36 2010
From: report at bugs.python.org (geremy condra)
Date: Tue, 29 Jun 2010 18:41:36 +0000
Subject: [docs] [issue9119] Python download page needs to mention crypto
	code in	Windows installer
In-Reply-To: <1277836658.93.0.259031299275.issue9119@psf.upfronthosting.co.za>
Message-ID: <1277836896.8.0.0595894592651.issue9119@psf.upfronthosting.co.za>


Changes by geremy condra <debatem1 at gmail.com>:


----------
nosy: +debatem1

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

From report at bugs.python.org  Tue Jun 29 20:47:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Jun 2010 18:47:11 +0000
Subject: [docs] [issue9117] class syntax not fully documented in reference
	manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277837231.79.0.196938146668.issue9117@psf.upfronthosting.co.za>


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

The production looks right to me, but I think it should be broken in two or more lines.  Since it is rendered pre-formatted, long line results in a horizontal scroll bar unless the browser window is extremely wide.

----------

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

From report at bugs.python.org  Tue Jun 29 21:11:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:11:18 +0000
Subject: [docs] [issue9117] class syntax not fully documented in reference
	manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277838678.15.0.603660855603.issue9117@psf.upfronthosting.co.za>


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

Yes, good plan.  I'll do that.

I'm also not sure about the 'comprehension' bit;  it's true that a comprehension is syntactically valid here (e.g., "class A(x for x in range(3))"), but it's also entirely useless:  it has to be the sole argument, so there can't be a metaclass argument, so the metaclass would have to be type.  But type (quite sensibly) won't accept a generator as a base class.

Oh well;  I suppose it doesn't *have* to make sense to be valid syntax...

This still leaves the hard part, which is distilling the essence of PEP 3115 and adding it to the reference manual.

----------

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

From report at bugs.python.org  Tue Jun 29 21:44:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:44:56 +0000
Subject: [docs] [issue9117] class syntax not fully documented in reference
	manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277840696.07.0.447616930054.issue9117@psf.upfronthosting.co.za>


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

Updated patch.  I've reorganized that documentation section a bit, and added a link to PEP 3115.  This isn't ideal, but it's better than nothing.

----------
Added file: http://bugs.python.org/file17805/issue9117_v2.patch

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

From report at bugs.python.org  Tue Jun 29 21:46:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:46:32 +0000
Subject: [docs] [issue9117] class syntax not fully documented in reference
	manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277840791.88.0.649750611462.issue9117@psf.upfronthosting.co.za>


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

And the same patch, but this time *without* the irrelevant audioop changes. :)

----------
Added file: http://bugs.python.org/file17806/issue9117_v2.patch

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

From report at bugs.python.org  Tue Jun 29 21:46:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Jun 2010 19:46:38 +0000
Subject: [docs] [issue9117] class syntax not fully documented in reference
	manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1277840798.29.0.702879438373.issue9117@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file17805/issue9117_v2.patch

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

From report at bugs.python.org  Tue Jun 29 22:41:59 2010
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 29 Jun 2010 20:41:59 +0000
Subject: [docs] [issue9121] Glossary entry for nested scope incorrect
In-Reply-To: <1277844119.14.0.595834938187.issue9121@psf.upfronthosting.co.za>
Message-ID: <1277844119.14.0.595834938187.issue9121@psf.upfronthosting.co.za>


New submission from Ethan Furman <ethan at stoneleaf.us>:

It currently states "Note that nested scopes work only for reference and not for assignment which will always write to the innermost scope."

This should be updated to read, e.g. "Note that unless the new nonlocal keyword is used nested scopes work only for reference and not for assignment which will otherwise write to the innermost scope."

----------
assignee: docs at python
components: Documentation
messages: 108949
nosy: docs at python, stoneleaf
priority: normal
severity: normal
status: open
title: Glossary entry for nested scope incorrect
versions: Python 3.1

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

From report at bugs.python.org  Tue Jun 29 22:55:01 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Jun 2010 20:55:01 +0000
Subject: [docs] [issue9121] Glossary entry for nested scope incorrect
In-Reply-To: <1277844119.14.0.595834938187.issue9121@psf.upfronthosting.co.za>
Message-ID: <1277844901.22.0.78350034001.issue9121@psf.upfronthosting.co.za>


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

Already fixed.

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Tue Jun 29 23:13:01 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 29 Jun 2010 21:13:01 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277845981.45.0.152049104211.issue9106@psf.upfronthosting.co.za>


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

That just proves that side menu is not very useful. When I need to jump to a sibling paragraph I usually click the rightmost entry in top bar. It takes two clicks to get there and one page reload instead of one.

Perhaps the ToC menu could be expanded using JS and some keyboard shortcut for convenience.

----------

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

From report at bugs.python.org  Wed Jun 30 01:16:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jun 2010 23:16:14 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277853374.34.0.768982147547.issue9106@psf.upfronthosting.co.za>


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

No, it just proves that I don't use the side menu.  I use google and the 'find' function of my browser :)

----------

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

From report at bugs.python.org  Wed Jun 30 05:40:38 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 30 Jun 2010 03:40:38 +0000
Subject: [docs] [issue9106] remove numbers from 3-.. level entries in docs
	toc
In-Reply-To: <1277749704.58.0.992065909356.issue9106@psf.upfronthosting.co.za>
Message-ID: <1277869237.54.0.962562726609.issue9106@psf.upfronthosting.co.za>


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

PHP site have a very convenient feature that if you enter http://php.net/some_func - it automatically executes function lookup for you or shows corresponding doc page, i.e. http://php.net/sort

----------

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

From report at bugs.python.org  Wed Jun 30 17:56:47 2010
From: report at bugs.python.org (Benjamin Ryzman)
Date: Wed, 30 Jun 2010 15:56:47 +0000
Subject: [docs] [issue9127] subprocess.Popen.communicate() and SIGCHLD
	handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1277913407.43.0.661212618815.issue9127@psf.upfronthosting.co.za>


Changes by Benjamin Ryzman <benjamin+python at ryzman.fr>:


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

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

From report at bugs.python.org  Wed Jun 30 17:56:59 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 30 Jun 2010 15:56:59 +0000
Subject: [docs] [issue9127] subprocess.Popen.communicate() and SIGCHLD
	handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1277913419.6.0.68704902385.issue9127@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at twistedmatrix.com> added the comment:

You should include all relevant issue materials here, in the Python issue tracker.  This ticket will be useless as soon as pastie.org decides to forget about your paste.

----------
nosy: +exarkun

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

From report at bugs.python.org  Wed Jun 30 17:59:32 2010
From: report at bugs.python.org (Benjamin Ryzman)
Date: Wed, 30 Jun 2010 15:59:32 +0000
Subject: [docs] [issue9127] subprocess.Popen.communicate() and SIGCHLD
	handlers
In-Reply-To: <1277913297.34.0.963310724242.issue9127@psf.upfronthosting.co.za>
Message-ID: <1277913572.34.0.974747400231.issue9127@psf.upfronthosting.co.za>


Benjamin Ryzman <benjamin+python at ryzman.fr> added the comment:

Content of the above pastie:

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> import subprocess
>>> signal.signal(signal.SIGCHLD,signal.SIG_IGN)
0
>>> subprocess.Popen(["echo","blah"], stdout=subprocess.PIPE).communicate()[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/subprocess.py", line 698, in communicate
    self.wait()
  File "/usr/lib/python2.6/subprocess.py", line 1170, in wait
    pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
  File "/usr/lib/python2.6/subprocess.py", line 465, in _eintr_retry_call
    return func(*args)
OSError: [Errno 10] No child processes
>>> oldsignal = signal.signal(signal.SIGCHLD,signal.SIG_DFL)
>>> subprocess.Popen(["echo","blah"], stdout=subprocess.PIPE).communicate()[0]
'blah\n'
>>> signal.signal(signal.SIGCHLD,oldsignal)
0

----------

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

From report at bugs.python.org  Wed Jun 30 21:59:11 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 30 Jun 2010 19:59:11 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>


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

reference/expressions.html#notin reads:

"Mappings (dictionaries) compare equal if and only if their sorted (key, value) lists compare equal. [4] Outcomes other than equality are resolved consistently, but are not otherwise defined. [5]"

However, the last sentence is no longer true.  I suggest changing the last sentence to:

"Comparisons other than equality testing raise a TypeError."

I think the footnote [5] is sufficiently historical that it could be removed as well.  Alternately, it could be updated to read, "In older versions of Python, outcomes other than equality were resolved consistently but were not otherwise defined."

----------
assignee: docs at python
components: Documentation
messages: 109009
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Documentation for comparing dictionaries is out of date
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Jun 30 21:59:27 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 30 Jun 2010 19:59:27 +0000
Subject: [docs] [issue9132] Documentation for comparing dictionaries is out
	of date
In-Reply-To: <1277927951.56.0.908504944608.issue9132@psf.upfronthosting.co.za>
Message-ID: <1277927967.92.0.825811977218.issue9132@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


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

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

From seb.haase at gmail.com  Sun Jun 27 23:05:27 2010
From: seb.haase at gmail.com (Sebastian Haase)
Date: Sun, 27 Jun 2010 23:05:27 +0200
Subject: [docs] whatsnew/3.1.html says: Release:3.2a0
In-Reply-To: <4C272D5A.5010309@python.org>
References: <AANLkTin_b3xlFGw2ZUlVjfCHU_iXf23c2es095-6yibZ@mail.gmail.com> 
	<4C272D5A.5010309@python.org>
Message-ID: <AANLkTinAZAw-8QxARz9YYGmFNFAbhv1pQza7r4T-aEvR@mail.gmail.com>

misleading might be the key....

thanks for looking into this anyway.
(I still find it non-intuitive, why 3.2 would have a "3.1 and/or a 3.0
whats-new-section" ....)
-Sebastian.



On Sun, Jun 27, 2010 at 12:52 PM, Georg Brandl <georg at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 17.06.2010 11:31, schrieb Sebastian Haase:
>> Hi,
>>
>> both pages
>> http://docs.python.org/dev/py3k/whatsnew/3.1.html
>> and
>> http://docs.python.org/dev/py3k/whatsnew/3.0.html
>> show at the top:
>>
>> Release: ? ? ?3.2a0
>> Date: June 17, 2010
>>
>> Isn't this a bug ?
>
> Well, it's the 3.1 What's New from the 3.2 documentation,
> therefore the "release" field is a bit misleading. ?But it
> still is correct.
>
> cheers,
> Georg
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.15 (GNU/Linux)
>
> iEYEARECAAYFAkwnLVoACgkQN9GcIYhpnLCUnwCfWLdA0n1i21j23Cia/Enpy8l6
> FmYAoI/sPG+iH2yzilqIWH/xjMUrgpA4
> =+B7e
> -----END PGP SIGNATURE-----
>

From mathar at strw.leidenuniv.nl  Tue Jun 29 15:02:18 2010
From: mathar at strw.leidenuniv.nl (Richard Mathar)
Date: Tue, 29 Jun 2010 15:02:18 +0200
Subject: [docs] spelling typo in 2to3 module description
Message-ID: <201006291302.o5TD2I1H006688@krypton.strw.leidenuniv.nl>


In http://docs.python.org/library/2to3.html#2to3fixer-long
the name of the fixer "raises" should be "raise" , singular of the word.
-- 
Richard J. Mathar               cell phone (+49) (0) 177 3834227 (E-plus)
Sterrewacht Universiteit Leiden Fax (+31) (0) 71 527 5819
Postbus 9513
2300RA Leiden   E-mail mathar at strw.leidenuniv.nl r.j.mathar at umail.leidenuniv.nl
The Netherlands                 URL http://www.strw.leidenuniv.nl/~mathar
office: Niels Bohrweg 2, 2333 CA Leiden, H104

From jq at qdevelop.de  Wed Jun 30 15:48:32 2010
From: jq at qdevelop.de (Jens Quade)
Date: Wed, 30 Jun 2010 15:48:32 +0200
Subject: [docs] 3.1.2 documentation for dict: iter(d) references to
	iteritems(), but iteritems is no longer documented.
Message-ID: <797AF95F-E5E5-419D-ADC4-8B6646CC4392@qdevelop.de>