Mailman 3 July 2010 - docs

[issue9311] os.access can return bogus values when run as superuser
by R. David Murray July 21, 2010

July 21, 2010

R. David Murray <rdmurray(a)bitdance.com> added the comment: Hmm. The document you quoted said that eaccess doesn't necessarily get this right everywhere either, but it sounds like it would at least fix the problem on FreeBSD...but at the price of no longer being a simple wrapper around access. I'm not sure what I think about that. This may be a question for python-dev. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9311> _______________________________________

1 0

[issue9311] os.access can return bogus values when run as superuser
by Garrett Cooper July 20, 2010

July 20, 2010

Garrett Cooper <yanegomi(a)gmail.com> added the comment: Well, bash screws up in this dept: $ ls -l typescript -rw-r--r-- 1 gcooper gcooper 37875 Jul 12 22:19 typescript $ sudo sh -c 'test -x typescript; echo $?' 1 $ sudo bash -c 'test -x typescript; echo $?' 0 $ csh %if (-x typescript) then if? echo "executable" if? endif % test(1) is a built-in in bash; on FreeBSD/NetBSD(/OpenBSD?) it's a standalone app (which uses eaccess(2)). csh does some tricky code for testing file access in sh.exp.c (see sh_access). perl does some tricky stuff in pp_sys.c (look for pp_ftrread), where it uses eaccess(2) if it's present, else falls back to access(2) to do its bidding. So maybe os.access should use eaccess(2) if it's present on the OS instead of access(2), and note that the item is OS implementation dependent (beware!)? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9311> _______________________________________

1 0

[issue6251] c++ extension module implementation guide/example in extending/embedding documentation
by Mark Lawrence July 20, 2010

July 20, 2010

Changes by Mark Lawrence <breamoreboy(a)yahoo.co.uk>: ---------- assignee: georg.brandl -> docs@python nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6251> _______________________________________

1 0

[issue9311] os.access can return bogus values when run as superuser
by R. David Murray July 20, 2010

July 20, 2010

R. David Murray <rdmurray(a)bitdance.com> added the comment: I'm curious, are the perl and sh functions you say do the right thing wrappers around 'access', or are they some other sort of function? The Python code is just a thin wrapper around the system function, and as such will follow the system function's semantics. I do agree that the FreeBSD interpretation of the semantics of access is...unexpected, as well as unfortunate :) So, a doc note about the superuser X_OK quirk is appropriate. Care to propose a doc patch? Personally I wouldn't include the stat example, but rather simply refer to stat as the portable way to check if the execute bit is set (and then you still have to call os.access to see if the real uid has permission to execute). On the other hand, proposing a portable version of 'access' for inclusion in shutils might be appropriate, if you want to open a new issue for that (preferably with a patch including docs and unit tests :) ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python, r.david.murray stage: -> needs patch versions: +Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9311> _______________________________________

1 0

[issue5901] missing meta-info in documentation pdf
by Mark Lawrence July 20, 2010

July 20, 2010

Changes by Mark Lawrence <breamoreboy(a)yahoo.co.uk>: ---------- assignee: georg.brandl -> docs@python nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue5901> _______________________________________

1 0

[issue2864] etree: Add XPath documentation
by Matt Bone July 20, 2010

July 20, 2010

Matt Bone <thatmattbone(a)gmail.com> added the comment: Here's a patch for 3.2 with some simple examples. They're under the ElementTree findall method. Maybe there should be similar examples for Element's find/findall methods? ---------- keywords: +patch nosy: +mbone Added file: http://bugs.python.org/file18076/xpath_examples.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue2864> _______________________________________

1 0

[issue459007] Document sys.path on Windows
by Éric Araujo July 19, 2010

July 19, 2010

Éric Araujo <merwok(a)netwok.org> added the comment: using/windows.rst seems the best place to add comments from PC/getpathp.c, under the “Finding modules” section. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue459007> _______________________________________

1 0

[issue9304] unreproducible example in the memoryview documentation
by Carl Chenet July 19, 2010

July 19, 2010

New submission from Carl Chenet <chaica(a)ohmytux.com>: Hi, In the current documentation at http://docs.python.org/library/stdtypes.html#memoryview, the first example announces : >>> v = memoryview('abcefg') >>> v[1] 'b' >>> v[-1] 'g' >>> v[1:4] <memory at 0x77ab28> >>> str(v[1:4]) 'bce' Trying to reproduce this example I got : $ python Python 2.7 (r27:82500, Jul 13 2010, 17:48:51) [GCC 4.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> v = memoryview('abcefg') >>> v[1] 'b' >>> v[-1] 'g' >>> v[1:4] <memory at 0xa2a510> >>> str(v[1:4]) '<memory at 0xa2a5a8>' The last line of the example in the documentation is not reproducible. Hope it's only a documentation issue. Bye, Carl Chenet ---------- assignee: docs@python components: Documentation messages: 110766 nosy: chaica_, docs@python priority: normal severity: normal status: open title: unreproducible example in the memoryview documentation versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9304> _______________________________________

3 4

[issue7229] Manual entry for time.daylight can be misleading
by Alexander Belopolsky July 19, 2010

July 19, 2010

Alexander Belopolsky <belopolsky(a)users.sourceforge.net> added the comment: After reading the new wording on a formatted page, I don't like the proposed changes: """ time.altzone When daylight is nonzero, altzone specifies the offset of the local DST timezone, in seconds west of UTC. This is negative if the local DST timezone is east of UTC ... """ In the second sentence, it is not clear whether "this" refers to altzone or daylight. """ time.daylight Whether or not DST is in effect, daylight specifies the DST offset. """ This is simply wrong. time.daylight does not necessarily specify the DST offset (and I think it does not on most systems.) POSIX requires that "The tzset() function also shall set the external variable daylight to 0 if Daylight Savings Time conversions should never be applied for the timezone in use; otherwise, non-zero." [1] This means that a compliant system may store just 0 or 1 in daylight rather than the DST offset. For example, on my OSX system: $ TZ=America/New_York python -c "import time; print(time.daylight)" 1 $ TZ=UTC python -c "import time; print(time.daylight)" 0 $ TZ=EDT python -c "import time; print(time.daylight)" 0 I will think some more on how to improve the current documentation, but at least with respect to time.daylight, current language is better than the proposed change. [1] http://www.opengroup.org/onlinepubs/009695399/functions/tzset.html ---------- superseder: -> Don't use east/west of UTC in date/time documentation _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue7229> _______________________________________

1 0

possible bug in Python tutorial sect 9.9
by Nicholas Cameron July 19, 2010

July 19, 2010

Hi, there is either a bug or scope for some extra clarity in the iterators section of the Python tutorial: http://docs.python.org/tutorial/classes.html#iterators The docs state that the method used to get an iterator for an object is iter() (after the first example in the section), but after the second example, uses __iter__(). I'm new to Python so not sure if either is correct and the other incorrect or if the syntax changes when implementing the method yourself, I guess some clarification would help if it is the latter case. Cheers, Nick

2 1