Mailman 3 March 2011 - docs

argparse doc example not especially helpful
by Tyler J. Barth Aug. 11, 2011

Aug. 11, 2011

I propose an improvement to the documentation for argparse (http://docs.python.org/library/argparse.html) I posit that the example 15.4.1 is not immediately helpful for the majority of people coming to docs.python.org to figure out how to use argparse. Though the use of argparse features to effortlessly sum and max the input integers is clever (and demonstrates many advanced features), I think most people arriving on that page want to know how to do three things: -Read in a file ("input.txt") -Read in a boolean switch ("-bar", use bar mode or not) -Read in a value for a switch ("-foo 6", set variable foo to 6) Of course, by hunting through the rest of the documentation you can learn how to do all of these basic tasks and more (much, much more). The clever sum and max example doesn't help elucidate how to perform these simple parses, and by using advanced features actually confuses new users. "argparse" has much more power than most people need, and I think it is fair to say that it's power obscures how to do the most common tasks. However, because "optparse" is deprecated and we all probably want to discourage people from rolling their own argument parsers every time they make a new simple program, I think there is value in making the "common case" more prominent in the example. It would encourage adoption of argparse so that when users's programs eventually increase in complexity and they do want to expand functionality, they would have the full power of argparse at their disposal. In summary, my suggestion is: -Expand example 15.4.1 to include the most common use cases -Consider splitting the "clever" example into a different section to avoid confusing new users. Sincerely, Tyler Barth

2 1

[issue10741] PyGILState_GetThisThreadState() lacks a doc entry
by Antoine Pitrou Aug. 7, 2011

Aug. 7, 2011

New submission from Antoine Pitrou <pitrou(a)free.fr>: PyGILState_GetThisThreadState() is "documented" in Include/pystate.h but not in the official docs. It should be documented along PyGILState_Ensure() and friends. ---------- assignee: docs@python components: Documentation messages: 124394 nosy: docs@python, haypo, pitrou priority: normal severity: normal status: open title: PyGILState_GetThisThreadState() lacks a doc entry versions: Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10741> _______________________________________

3 3

[issue11047] Bad description for a change
by Oren Held Aug. 6, 2011

Aug. 6, 2011

New submission from Oren Held <oren(a)held.org.il>: In the "what's new in 2.7", there is some mistake in the description of issue 7902. 7902, afaik, disables the fallback to absolute import, when requesting a relative import fails. If I got it right, the description states the opposite. ---------- assignee: docs@python components: Documentation files: whatsnew_issue_7902_fix.patch keywords: patch messages: 127317 nosy: Oren_Held, docs@python priority: normal severity: normal status: open title: Bad description for a change versions: Python 2.7 Added file: http://bugs.python.org/file20577/whatsnew_issue_7902_fix.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11047> _______________________________________

5 4

[issue8982] argparse docs cross reference Namespace as a class but the Namespace class is not documented
by R. David Murray July 29, 2011

July 29, 2011

New submission from R. David Murray <rdmurray(a)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@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(a)bugs.python.org> <http://bugs.python.org/issue8982> _______________________________________

4 9

[issue11669] Clarify Lang Ref "Compound statements" footnote
by Graham Wideman July 21, 2011

July 21, 2011

New submission from Graham Wideman <initcontact(a)grahamwideman.com>: In Language Ref section 7 "Compound Statements": http://docs.python.org/release/3.1.3/reference/compound_stmts.html there's a footnote regarding what happens to unhandled exceptions in a try-except statement: [1] The exception is propagated to the invocation stack only if there is no *finally* clause that negates the exception. This is very unclearly worded, especially since the reader in need of this footnote is probably familiar with the *except* clause being the one to "negate" an exception, and may well think this footnote is in error. This footnote could provide a more convincing explanation: [1] The exception is propagated to the invocation stack unless there is a finally clause which happens to raise another exception. That new exception causes the old exception to be lost. ---------- assignee: docs@python components: Documentation messages: 132072 nosy: docs@python, gwideman priority: normal severity: normal status: open title: Clarify Lang Ref "Compound statements" footnote type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11669> _______________________________________

7 10

[issue11363] Curses - add missing functions to doc
by Sandro Tosi July 21, 2011

July 21, 2011

New submission from Sandro Tosi <sandro.tosi(a)gmail.com>: Following up http://mail.python.org/pipermail/docs/2011-January/002922.html , I did a check on all the documented functions of curses and those available from the module, and wrote a patch to include in the doc the missing ones (text is mainly brought by manpages). IMHO, it should be backported to the currently maintained versions (but I didn't check what's 2.7 status). ---------- assignee: docs@python components: Documentation files: curses_missing_functs-py3k.patch keywords: patch messages: 129791 nosy: docs@python, sandro.tosi priority: low severity: normal stage: patch review status: open title: Curses - add missing functions to doc versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20962/curses_missing_functs-py3k.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11363> _______________________________________

4 9

[issue10403] Use "member" consistently
by Fred L. Drake, Jr. July 17, 2011

July 17, 2011

New submission from Fred L. Drake, Jr. <fdrake(a)acm.org>: Some portions of the documentation are using the term "member" to mean "data attribute". This appears to be an aberration at this time, but occurrences should be identified and corrected, and "Documenting Python" updated to note correct usage. Example use: http://docs.python.org/dev/py3k/library/xmlrpc.client.html#fault-objects http://docs.python.org/dev/py3k/library/urllib.request.html#basehandler-obj… (paragraph starting "The following members and methods should") "Members and methods" should just be "attributes". ---------- assignee: docs@python components: Documentation messages: 121110 nosy: docs@python, fdrake priority: normal severity: normal status: open title: Use "member" consistently _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10403> _______________________________________

9 24

[issue9312] Fix usage of :option: markup in stdlib ReST docs
by Eli Bendersky June 9, 2011

June 9, 2011

New submission from Eli Bendersky <eliben(a)gmail.com>: Due to a discussion on python-dev (Subject: "Markup of command-line options in Python's .rst documentation"), Georg Brandl checked in revision r82961 with a clarification of :option: markup which should only be used for Python interpreter's own flags. However, several modules in stdlib use :option: for their own command-line options, which creates confusion (these options get linked by Sphinx to unrelated Python options). I'm attaching a patch that fixes this issue for these files. The affected files are: Doc/library/idle.rst Doc/library/timeit.rst Doc/library/test.rst Doc/library/doctest.rst Doc/library/unittest.rst Doc/library/pydoc.rst Doc/library/webbrowser.rst Doc/library/compileall.rst Note1: :option: was fixed to `` markup (code snippet) as per the recommendation in the updated documentation guide Note2: I didn't patch trace.rst because it's overgoing a major rehaul (http://bugs.python.org/issue9264) ---------- assignee: docs@python components: Documentation messages: 110862 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: Fix usage of :option: markup in stdlib ReST docs type: behavior versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9312> _______________________________________

6 26

[issue11203] gzip doc is behind
by K Richard Pixley June 9, 2011

June 9, 2011

New submission from K Richard Pixley <rich(a)noir.com>: The documentation for gzip should include the "close" method. It's use in the 2.7 documentation implies it's existence but it should also be stated explicitly that it exists. In the 3.x documentation, the use of "close" not in the examples since the examples use context manager. For 3.x documentation there should be both an explicit mention of the "close" method as well as an explicit mention that GzipFile supports the context manager protocol. Yes, the use of the context manager in the examples implies that this is true but documentation on other modules states so explicitly so this module should too. ---------- assignee: docs@python components: Documentation messages: 128460 nosy: docs@python, teamnoir priority: normal severity: normal status: open title: gzip doc is behind type: feature request versions: Python 2.7, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11203> _______________________________________

4 11

[issue9738] Document the encoding of functions bytes arguments of the C API
by STINNER Victor May 30, 2011

May 30, 2011

New submission from STINNER Victor <victor.stinner(a)haypocalc.com>: Many C functions have bytes argument (char* type) but the encoding is not documented. If would not be a problem if the encoding was always the same, but it is not. Examples: - format of PyUnicode_FromFormat() should be encoded as ISO-8859-1 - filename of PyParser_ASTFromString() should be encoded as utf-8 - filename of PyErr_SetFromErrnoWithFilename() should be encoded to the filesystem encoding (with strict error handler, and not surrogateescape) - 's' argument of PyParser_ASTFromString() should be encoded as utf-8 if PyPARSE_IGNORE_COOKIE flag is set, otherwise the parser checks for #coding:xxx cookie (if there is no cookie, utf-8 is used) Attached patch is a try to document most low level functions. I choosed to add the name of function arguments in the headers because I consider that a header can be used as a quick documentation. I only touched .c files to change argument names. It is hard to get the right encoding, so I cannot ensure that my patch is correct. My patch is just a draft. I don't know if "encoded to utf-8" is the right expression. Or should it be "decoded as utf-8"? ---------- assignee: docs@python components: Documentation, Interpreter Core, Unicode files: encodings.patch keywords: patch messages: 115339 nosy: docs@python, haypo priority: normal severity: normal status: open title: Document the encoding of functions bytes arguments of the C API versions: Python 3.2 Added file: http://bugs.python.org/file18705/encodings.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9738> _______________________________________

5 12

[issue9382] os.popen referenced but not documented in Python 3.x
by Chris Rebert May 30, 2011

May 30, 2011

New submission from Chris Rebert <pybugs(a)rebertia.com>: http://docs.python.org/py3k/library/os.html currently mentions os.popen() in several places. The docs for os.popen() itself say: 'These functions are described in section "File Object Creation"' However, unlike the 2.x version of that section ( http://docs.python.org/library/os.html#file-object-creation ), the os.popen*() family is not documented there [or indeed anywhere] anymore ( http://docs.python.org/py3k/library/os.html#os-newstreams ); the entire section now only documents os.fdopen(). The 2.7 docs say that the os.popen*() family are deprecated, and indeed, of the family, only os.popen() seems to still exist in Python 3.x (at least based on my testing via ideone.com). Thus, from what I can see, one of the following is the case: (A) The entire os.popen*() family is supposed be gone in Python 3.x, so os.popen() should be removed entirely from both the code and the docs. (B) os.popen() is the sole legitimate survivor of its family, and should be properly documented again. (C) os.popen() was left in as a kludge, shouldn't be mentioned in the docs, and possibly should be renamed os._popen() to reflect its status. So, which one of these is it? ---------- assignee: docs@python components: Documentation messages: 111597 nosy: cvrebert, docs@python priority: normal severity: normal status: open title: os.popen referenced but not documented in Python 3.x versions: Python 3.1 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9382> _______________________________________

6 6

MOBI format for DOCs
by Ken Langer May 13, 2011

May 13, 2011

Documentation Support: If possible, could you include the docs in MOBI format? Ken Langer Project Manager - R&D ARKADIN GLOBAL AUDIO & WEB CONFERENCING 150 East Campus View Blvd., Suite 220 * Columbus, OH 43235 United States Direct: (+1) (614)635-5305 * Mobile: (+1) (614)906-0128 * Fax: (+1) (614)841-2455 www.arkadin.com <http://www.arkadin.com> Reduce travel costs, save time, and contribute to a greener world using remote collaboration solutions.

3 5

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
by Devin Jeanpierre April 30, 2011

April 30, 2011

New submission from Devin Jeanpierre <jeanpierreda(a)gmail.com>: PyObject_RichCoareBool is, according to the documentation in trunk (Doc\c-api\object.rst), exactly the same as PyObject_RichCompare, except it 1, 0, or -1 for error, false, and true respectively. However, it differs in behavior by both that, and also by assuming that identity implies equality. This noted in a two year-old ML post (sadly, no bug report was posted as best as I can find): http://mail.python.org/pipermail/python-list/2009-March/1195170.html Ideally PyObject_RichCompareBool should probably be named something else, since it can no longer be used, strictly, as "PyObject_RichCompare, but returning a C bool" (or, rather, a C int). Some suggestions were offered in the mailing list thread above. I'm filing this as a documentation bug because I find that outcome unlikely. At least the documentation should note the difference in behavior, so that people do not accidentally write C code that does not behave as intended. This issue is related to, but different from issue 4296, which objected to the new container behavior created by the change to PyObject_RichCompareBool. My only objection here is that the latter change does not appear to be documented. I would supply a patch for the tests, but PyObject_RichCompareBool is apparently not directly tested anywhere, just tested obliquely through testing the containment operator, and this was changed by the same commit that changed PyObject_RichCompareBool. I don't know how to word the (very small!) change to the docs. ---------- assignee: docs@python components: Documentation messages: 126306 nosy: Devin Jeanpierre, docs@python priority: normal severity: normal status: open title: PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10912> _______________________________________

7 17

Re: [docs] Suggested improvement to turtle module doc
by Alexander Belopolsky April 28, 2011

April 28, 2011

Hi Richard, Thank you for your report. Please take a look at the discussion of various improvements to turtle documentation at <http://bugs.python.org/issue7061>. Please see more answers below. .. > It took me far longer than it should have to figure out how to do the > most basic thing: from an interactive prompt (or elsewhere!) get the > turtle window up and have a controllable turtle. In the end I just > guessed and created a Turtle and it worked - though I still struggle to > see where this is mentioned in the docs. > We have recently added a sidebar to the introduction in the turtle manual that should help newcomers. See <http://docs.python.org/dev/library/turtle.html>. > I believe the docs would benefit greatly from a simple example right at > the top like: > > """ > The easiest method of getting started is to open an interactive prompt > and type: > >>>> from turtle import * >>>> turtle = Turtle() > .. The turtle module provides both procedural and object-oriented interfaces. In my opinion, beginners should start with the procedural interface and this is what is now used in the sidebar. It is unfortunate that the manual uses "turtle" for both the name of the module and the name of the turtle instance used in OO examples. Any suggestions on how to improve this are welcome.

2 1

[issue9724] help('nonlocal') missing
by Cherniavsky Beni April 28, 2011

April 28, 2011

New submission from Cherniavsky Beni <cben(a)users.sf.net>: >>> help('nonlocal') no Python documentation found for 'nonlocal' As a language keyword, it clearly should have documentation. ---------- assignee: docs@python components: Documentation messages: 115266 nosy: cben, docs@python priority: normal severity: normal status: open title: help('nonlocal') missing versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9724> _______________________________________

5 5

[issue9264] trace.py documentation is incomplete
by Eli Bendersky April 27, 2011

April 27, 2011

New submission from Eli Bendersky <eliben(a)gmail.com>: The documentation of the standard 'trace' module (Doc/library/trace.rst) is sorely lacking. Arguments are not explained, some key methods are not documented at all, and the CoverageResults class isn't documented. Usage of these appears in the example but leaves the user confused as the only source of documentation for the example is the source code of the module. I'm attaching a patch that fixes this issue, by providing documentation for the missing parts. The patch was generated vs. the latest SVN trunk. ---------- assignee: docs@python components: Documentation files: tracedoc.3.patch keywords: patch messages: 110344 nosy: docs@python, eli.bendersky, tjreedy priority: normal severity: normal status: open title: trace.py documentation is incomplete type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file18009/tracedoc.3.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9264> _______________________________________

6 35

Wrong API name in Python 3.2 doc Python/C API Reference Manual
by Darke, Clive April 21, 2011

April 21, 2011

Under "Initialization, Finalization, and Threads", "Non-Python created threads": "OS facilities such as posix_atfork() would need to be used " should be: "OS facilities such as pthread_atfork() would need to be used" (So far as I know there is no such function as posix_atfork()) Forgive me if this report is not in the required format. Clive Darke Product Consultant QA Vale House Pynes Hill Exeter Devon EX2 5AZ Email clive.darke(a)qa.com<mailto:clive.darke@qa.com> Web http://www.qa.com/ ________________________________ QA works with organisations to transform performance through learning. We are dedicated to making our clients more successful through the provision of world-class training services. To find out more visit www.qa.com The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. QA Ltd. Rath House, 55-65 Uxbridge Road, Slough, Berkshire,SL1 1SG. QA Ltd. is a company registered in England with company registration number:2413137 Scanned by ICRITICAL

2 2

suggestion for http://docs.python.org/library/unittest.html#unittest.TestCase.assertRaises
by Andrew Hammond April 19, 2011

April 19, 2011

I suggest adding an example of using assertRaises to test a property: class MyObject(object): @property def myProperty(): raise Exception() self.assertRaises(Exception, getattr, myObject, myProperty) Rationale: the naive approach doesn't work and I spent a good half hour figuring that out. Andrew

2 2

Very small bug in python doc
by Hiroshi Araki April 19, 2011

April 19, 2011

At the first line in the section below http://docs.python.org/library/subprocess.html#convenience-functions > This module also defines two shortcut functions: But I can see three functions there, so this must be: > This module also defines three shortcut functions: Thanks,

2 1

documentation error/bug 7.1. Fancier Output Formatting
by Dan Orton April 19, 2011

April 19, 2011

hello, I think I may have found a bug in the documentation under 7.1. Fancier Output Formatting<http://docs.python.org/tutorial/inputoutput.html#fancier-output-formatting> as I am a beginner, I really do not have many ideas on how to fix it. also as this is a simpleton error, there may already be discussion on a fix. *1)* You will see the following code. >>> import math>>> print 'The value of PI is approximately {}.'.format(math.pi)The value of PI is approximately 3.14159265359.>>> print 'The value of PI is approximately {!r}.'.format(math.pi)The value of PI is approximately 3.141592653589793. *2) * When entered into Python, it complains Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> print 'The value of PI is approximately {}.'.format(math.pi) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: zero length field name in format >>> print 'The value of PI is approximately {!r}.'.format(math.pi) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: zero length field name in format >>>

2 1

Please provide Python 2.5.5 documentation
by Ulrik Sverdrup April 19, 2011

April 19, 2011

Hi, My Python2.5 installation (among the various versions installed) provides this link for documentation: FILE /usr/lib/python2.5/socket.py MODULE DOCS http://www.python.org/doc/2.5.5/lib/module-socket.html The above link is not active, there is no documentation for 2.5.5. Please understand that I'm looking for the documentation for 2.5. I also know that 2.5.4 docs are available and I will go there to read them now, but isn't it nice if the URLs in the latest version of 2.5 work? Mvh Ulrik

2 1

bug about syntax of "if-else" statement in the IDLE shell
by Victor Paraschiv April 19, 2011

April 19, 2011

Hello, Several days ago I downloaded Python 3.2, the standard windows installer, for windows vista. Here's the bug: in the Python-command line, the following works: " >>>if 2==2:print('yes') . . . else:print('n') . . . yes " Now, in the Python shell (IDLE-python gui, the standard one included with the installer of python), the only way it works is: >>> if 2==2:print('yes') else:print('n') yes So, it requires me to put "else" unindented. On the other hand, if the "if--else" statement is included in the definition of a function, then it requires that "else" be exactly under "if". This was frustrating, when trying to learn "if-else" statement, because it took me half an hour of experimenting, before I figurred out. Shouldn't it be consistent? Could you please reply me with an explanation, in case I am wrong? Victor

2 1

[issue11300] mmap() large file failures on Mac OS X docfix
by Steffen Daode Nurpmeso April 19, 2011

April 19, 2011

New submission from Steffen Daode Nurpmeso <sdaoden(a)googlemail.com>: Issue 11277 was closed upon the generally accepted conclusion that the failure is that mmap(2) on Mac OS X has a long time known bug (see msg129107, or directly http://lists.apple.com/archives/darwin-development/2003/Jun/msg00141.html). Issue 11277 fixed the problem in the test suite, but it does give end-users no hint that such a problem exists (on the documentation side). And it's my believe that a beginner or even a non-low-level programmer may be lost in an equal situation. (Though one could argue that such a HE should not use mmap(2), but everyone has a first-time somewhen, say.) In addition, there are many people who don't have the chance to work/test on multiple operating systems and/or hardware, and who need the hand of people who are experienced and can give hints on stupidiness or however this word is correctly spelled. (Am i preaching already?) Because Python is expected to be a user-friendly language i do request a documentation patch which gives a hint. I'll apply a patch, but i'm somewhat new to Python and rST etc., so it surely needs a hand. (Maybe even its speech is too aggressive??) ---------- assignee: docs@python components: Documentation files: doc_lib_mmap.patch keywords: patch messages: 129221 nosy: docs@python, sdaoden priority: normal severity: normal status: open title: mmap() large file failures on Mac OS X docfix type: feature request versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20867/doc_lib_mmap.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11300> _______________________________________

1 1

[issue11186] pydoc: HTMLDoc.index() doesn't support PEP 383
by STINNER Victor April 15, 2011

April 15, 2011

New submission from STINNER Victor <victor.stinner(a)haypocalc.com>: If you have an undecodable filenames on UNIX, Python 3 escapes undecodable bytes using surrogates. pydoc: HTMLDoc.index() uses indirectly os.listdir() which does such operation, and later filenames are encoded to UTF-8 (the whole HTML content is encoded to UTF-8). In practice, you cannot import such .py file, you run them using "python script.py", so we can maybe just ignore modules with undecodable filenames. For example: def isUndecodableFilename(filename): return any((0xD800 <= ord(ch) <= 0xDFFF) for ch in filename) Or we can escape the surrogate characters, but I don't know how. Write "\uDC80" in a HTML document is not a good idea, especially in an URL (e.g. Firefox replaces \ by / in URLs). ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 128382 nosy: docs@python, haypo priority: normal severity: normal status: open title: pydoc: HTMLDoc.index() doesn't support PEP 383 versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11186> _______________________________________

3 6

[issue9101] reference json format in file formats chapter
by anatoly techtonik April 14, 2011

April 14, 2011

New submission from anatoly techtonik <techtonik(a)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@python components: Documentation messages: 108833 nosy: docs@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(a)bugs.python.org> <http://bugs.python.org/issue9101> _______________________________________

7 22