New submission from Dave Abrahams <dave(a)boostpro.com>:
On POSIX systems, the PATH environment variable is always used to
look up directory-less executable names passed as the first argument to Popen(...), but on Windows, PATH is only considered when shell=True is also passed.
Actually I think it may be slightly weirder than that when
shell=False, because the following holds for me:
C:\>rem ##### Prepare minimal PATH #####
C:\>set "PATH=C:\Python26\Scripts;C:\Python26;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem"
C:\>rem ##### Prepare a minimal, clean environment #####
C:\>virtualenv --no-site-packages e:\zzz
New python executable in e:\zzz\Scripts\python.exe
Installing setuptools................done.
C:\>rem ##### Show that shell=True makes the difference in determining whether PATH is respected #####
C:\>python
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'])
<subprocess.Popen object at 0x0000000001DBE080>
>>> C:\Python26\python.exe
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'})
<subprocess.Popen object at 0x0000000001F05A90>
>>> C:\Python26\python.exe
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'}, shell=True)
<subprocess.Popen object at 0x0000000001F05B00>
>>> e:\zzz\Scripts\python.exe
That is, it looks like the environment at the time Python is invoked is what counts unless I pass shell=True. I don't even seem to be able to override this behavior by changing os.environ: you can clear() it and pass env={} and subprocess.Popen(['python']) still succeeds.
This is a very important problem for portable code and one that took me hours to suss out. I think:
a) the current behavior needs to be documented
b) it needs to be fixed if possible
c) otherwise, shell=True should be the default
----------
assignee: docs@python
components: Documentation
messages: 104422
nosy: dabrahams, docs@python
priority: normal
severity: normal
status: open
title: subprocess portability issue
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue8557>
_______________________________________
New submission from Julian <python_org(a)somethinkodd.com>:
Since Python 2.6, httplib has offered a timeout parameter for fetches. As the documentation explains, if this parameter is not provided, it uses the global default.
What the document doesn't explain is httplib builds on top of the socket library. The socket library has a default timeout of None (i.e. forever). This may be an appropriate default for general sockets, but it is a poor default for httplib; typical http clients would use a timeout in the 2-10 second range.
This problem is propagated up to urllib2, which sits on httplib, and further obscures that the default might be unsuitable.
>From an inspection of the manuals, Python 3.0.1 suffers from the same problem except, the names have changed. urllib.response sits on http.client.
I, for one, made a brutal mistake of assuming that the "global default" would be some reasonable default for fetching web pages; I didn't have any specific timeout in mind, and was happy for the library to take care of it. Several million successful http downloads later, my server application thread froze waiting forever when talking to a recalcitrant web-server. I imagine others have fallen for the same trap.
While an ideal solution would be for httplib and http.client to use a more generally acceptable default, I can see it might be far too late to make such a change without breaking existing applications. Failing that, I would recommend that the documentation for httplib, urllib, urllib2, http.client and urllib.request (+ any other similar libraries sitting on socket? FTP, SMTP?) be changed to highlight that the default global timeout, sans deliberate override, is to wait a surprisingly long time.
----------
assignee: docs@python
components: Documentation, Library (Lib)
messages: 104763
nosy: docs@python, oddthinking
priority: normal
severity: normal
status: open
title: Unexpected default timeout in http-client-related libraries
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue8595>
_______________________________________
New submission from anatoly techtonik <techtonik(a)gmail.com>:
'naive' and 'aware' are key datetime types - they need a proper definition and anchor for crossrefences. If you take a look at http://docs.python.org/library/datetime.html - the definition of distinction between them is too vague and this seeds of uncertainty grow through the rest of the doc. It is not said how to make non-naive object, how to detect if object of naive or aware. All this stuff is very important for troubleshooting datetims issues in Python projects. It needs a proper documentation.
----------
assignee: docs@python
components: Documentation
messages: 106524
nosy: docs@python, techtonik
priority: normal
severity: normal
status: open
title: datetime naive and aware types should have a well-defined definition that can be cross-referenced
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue8822>
_______________________________________
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 Paul Davis <paul.joseph.davis(a)gmail.com>:
The docs for __getattr__ in the object model section could be more specific on the behavior when a @property raises an AttributeError and there is a custom __getattr__ defined. Specifically, it wasn't exactly clear that __getattr__ would be invoked after a @property was found and evaluated.
The attached script demonstrates the issue on OS X 10.6, Python 2.6.1
I'm thinking something along the lines of:
If the attribute search encounters an AttributeError (perhaps due to a @property raising the error) the search is considered a failure and __getattr__ is invoked.
----------
assignee: docs@python
components: Documentation
files: example.py
messages: 105790
nosy: Paul.Davis, docs@python
priority: normal
severity: normal
status: open
title: Documentation for __getattr__
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file17349/example.py
_______________________________________
Python tracker <report(a)bugs.python.org>
<http://bugs.python.org/issue8722>
_______________________________________
New submission from Renato Cunha <renato(a)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@python
components: Documentation
messages: 107953
nosy: docs@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(a)bugs.python.org>
<http://bugs.python.org/issue9014>
_______________________________________