New submission from Craig McQueen <python(a)craig.mcqueen.id.au>:
I have just been trying to figure out how string interpolation works for "%s", when Unicode strings are involved. It seems it's a bit complicated, but the Python documentation doesn't really describe it. It just says %s "converts any Python object using str()".
Here is what I have found (I think), and it could be worth improving the documentation of this somehow.
Example 1:
"%s" % test_object
>From what I can tell, in this case:
1. test_object.__str__() is called.
2. If test_object.__str__() returns a string object, then that is substituted.
3. If test_object.__str__() returns a Unicode object (for some reason), then test_object.__unicode__() is called, then _that_ is substituted instead. The output string is turned into Unicode. This behaviour is surprising.
[Note that the call to test_object.__str__() is not the same as str(test_object), because the former can return a Unicode object without causing an error, while the latter, if it gets a Unicode object, will then try to encode('ascii') to a string, possibly generating a UnicodeEncodeError exception.]
Example 2:
u"%s" % test_object
In this case:
1. test_object.__unicode__() is called, if it exists, and the result is substituted. The output string is Unicode.
2. If test_object.__unicode__() doesn't exist, then test_object.__str__() is called instead, converted to Unicode, and substituted. The output string is Unicode.
Example 3:
"%s %s" % (u'unicode', test_object)
In this case:
1. The first substitution causes the output string to be Unicode.
2. It seems that (1) causes the second substitution to follow the same rules as Example 2. This is a little surprising.
----------
assignee: docs@python
components: Documentation
messages: 109516
nosy: cmcqueen1975, docs@python
priority: normal
severity: normal
status: open
title: Improve docs for string interpolation "%s" re Unicode strings
versions: Python 2.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue9196>
_______________________________________
New submission from anatoly techtonik <techtonik(a)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@python
components: Documentation
messages: 107321
nosy: docs@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(a)bugs.python.org>
<http://bugs.python.org/issue8940>
_______________________________________
New submission from Terry J. Reedy <tjreedy(a)udel.edu>:
This doc improvement suggestion is inspired by #991196 (and subsequent duplicates) and the current discussion on py-dev in the thread
'variable name resolution in exec is incorrect'
(which is not a correct claim). I believe there is consensus that the doc for exec needs improving.
My suggestion (which others may amend) is that the following paragraph (from the 3.x builtin functions exec entry)
"In all cases, if the optional parts are omitted, the code is executed in the current scope. If only globals is provided, it must be a dictionary, which will be used for both the global and the local variables. If globals and locals are given, they are used for the global and local variables, respectively. If provided, locals can be any mapping object."
have these two sentences added:
"If only globals is provided or if onedict is provided as both globals and locals, the code is executed in a new top-level scope. If different objects are given as globals and locals, the code is executed as if it were in a class statement in a new top-level scope."
----------
assignee: docs@python
components: Documentation
messages: 106552
nosy: docs@python, tjreedy
priority: normal
severity: normal
status: open
title: Improve documentation of exec
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue8824>
_______________________________________
New submission from pengyu.ut <pengyu.ut(a)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@python
components: Documentation
messages: 108334
nosy: docs@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(a)bugs.python.org>
<http://bugs.python.org/issue9056>
_______________________________________
New submission from Alexander Belopolsky <belopolsky(a)users.sourceforge.net>:
I am opening this to supersede issue7229. See discussion following msg107148.
In many places offsets representing the difference between local time and UTC are described as minutes or seconds east or west of UTC. This is not correct because UTC is not a place and minutes and seconds don't measure distance in this context. Replacing UTC with the Prime Meridian will not fix that because some regions in the western hemisphere use positive offsets from UTC. or example, Madrid is at 3° 42' West, but uses Central European Time which is UTC+1.
I believe geographical references in the python documentation are irrelevant. What users are interested in is how to convert local time to UTC and UTC to local time rather than what is the sign of time.timezone in Madrid.
I suggest the following wording for time.timezone description:
time.timezone: The number of seconds one must add to the local time to arrive at UTC.
Similarly, tzinfo.utcoffset() can be defined as "Returns timedelta one must add to UTC to arrive at local time."
----------
assignee: docs@python
components: Documentation
keywords: easy
messages: 110774
nosy: belopolsky, docs@python
priority: normal
severity: normal
stage: needs patch
status: open
title: Don't use east/west of UTC in date/time documentation
type: feature request
versions: Python 3.2
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________
New submission from Jay T <jaytula(a)gmail.com>:
I want to create a custom interactive shell where I continually do
parse_args. Like the following:
parser = argparse.ArgumentParser()
command = raw_input()
while(True):
args = parser.parse_args(shlex.split(command))
# Do some magic stuff
command = raw_input()
The problem is that if I give it invalid input, it errors and exits
with a help message.
I learned from argparse-users group that you can override the exit method like the following:
class MyParser(ArgumentParser):
def exit(self, status=0, message=None):
# do whatever you want here
I would be nice to have this usage documented perhaps along with best practices for doing help messages in this scenario.
----------
assignee: docs@python
components: Documentation
messages: 117287
nosy: docs@python, jayt
priority: normal
severity: normal
status: open
title: Documentation for argparse interactive use
type: feature request
versions: Python 2.7
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________
New submission from Nick Coghlan <ncoghlan(a)gmail.com>:
There are currently undocumented PyEval_Call* equivalents to a number of the PyObject_Call* functions.
Since there are resources out there on the web that direct people to use the currently undocumented PyEval functions, it would be good to document those properly, and recommend people typically use the PyObject_Call* variants instead (as the latter include all the stack and interpreter state integrity protection code, while the PyEval variants assume that has all already been handled).
----------
assignee: docs@python
components: Documentation
keywords: easy
messages: 128248
nosy: docs@python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Document PyEval_Call* functions
versions: Python 2.7, Python 3.2, Python 3.3
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue11165>
_______________________________________
New submission from Éric Araujo <merwok(a)netwok.org>:
A patch made for #2504 revealed a bug in gettext.rst, and I’ve found a number of other things to change in the file. This is the first patch of a series of two or three.
Barry, as the original author of the module and doc, I’d like your opinion on points 3, a, and b particularly.
Patch is also uploaded to Rietveld for greater convenience: http://codereview.appspot.com/3333042/ (upload.py rocks)
Summary:
1) Markup: Use modern class/method directives combo (yay DRY). Mark up variable parts in :file: constructs (e.g. :file:`{domain}.mo` will cause the HTML output to use var to indicate replaceable text). Also change some ``gettext`` to :program:`gettext` for consistency.
2) Fix a typo in lngettext doc (originally included in patch by Franz Glasner for #2504).
3) I had started to remove information about private attributes (_info, _charset), advertising public getter methods instead. Then I read the description of NullTranslations and realized the information was needed for subclasses. I’ve reverted my removals, but I still think the private attributes should be listed in a specific section for people writing subclasses and not in the rest of the text. If you’re okay, I’ll make a second patch.
4) Assorted wording changes, missing periods and hyphens, and other very small touch-ups: Turned a broken bare link into a working link with nice text; used the with statement in an example (we all love the with statement!); used two spaces after periods throughout (hello Fred Drake).
Final note: lines have not been rewrapped, for diff clarity. When I commit part or all of this patch, I’ll make another commit to rewrap.
Not addressed:
a) The current docs is currently POSIX-specific.
b) The docs take great care to explain that Unicode strings will be returned in different places, but this should not be so accented in 3.x docs IMO. I would just put a note somewhere near the top that all strings are str and remove the redundant sentences. Following that line of thought, I could group all l*gettext variants at the end of the list of methods, explaining that regular usage should just be happy with str objects and that l*gettext are available if people really want bytes.
c) The file uses “built-in namespace” and “builtins namespace”, sometimes in neighbor paragraphs. :mod:`builtins` is not used, even in explanations of the install function/method. I don’t know if I should change that.
d) Some capitalization patterns look strange to me: I have seen “I18N” and “L10N” in upper case nowhere else. Similarly, lower-case “id” looks stranger than “ID”. The latter is used for example in official GNU gettext docs. Am I going into foolish consistency territory or not?
Thanks in advance for reviews and opinions.
----------
assignee: eric.araujo
components: Documentation
files: gettext-docs-1.diff
keywords: needs review, patch
messages: 122420
nosy: barry, docs@python, eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Enhancements to gettext docs
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19819/gettext-docs-1.diff
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue10536>
_______________________________________
New submission from Luke Plant <L.Plant.98(a)cantab.net>:
Docs for SimpleCookie, BaseCookie.value_encode and BaseCookie.value_decode are obviously incorrect. Attempt at patch attached.
The error has existed in every Python version I've seen, I've tagged the ones I believe can receive fixes, sorry if I've made a mistake.
Thanks.
----------
assignee: docs@python
components: Documentation
files: http_cookies_doc_corrections.diff
keywords: patch
messages: 126962
nosy: docs@python, spookylukey
priority: normal
severity: normal
status: open
title: Various obvious errors in cookies documentation
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file20507/http_cookies_doc_corrections.diff
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue11001>
_______________________________________
New submission from Jyrki Pulliainen <jyrki(a)dywypi.org>:
In threading module, the Lock.acquire documentation is misleading. The signature suggests that the blocking can be given as a keyword argument but that would lead to an TypeError, as thread.lock.acquire does not accept keyword arguments.
The signature in documentation should be formatted as in thread.lock.acquire.
----------
assignee: docs@python
components: Documentation
messages: 124861
nosy: Jyrki.Pulliainen, docs@python
priority: normal
severity: normal
status: open
title: Lock.acquire documentation is misleading
versions: Python 2.7, Python 3.1
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue10789>
_______________________________________