Mailman 3 - docs - python.org

Sphinx indexing
by anatoly techtonik 06 Jun '10

06 Jun '10

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.

1 0

[issue8890] Modules have dangerous examples in documentation
by Henri Salo 05 Jun '10

05 Jun '10

Henri Salo <henri(a)nerv.fi> added the comment: No it does not. http://www.owasp.org/index.php/Insecure_Temporary_File ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8890> _______________________________________

1 0

[issue8909] mention bitmap size for bdist_wininst
by anatoly techtonik 05 Jun '10

05 Jun '10

Changes by anatoly techtonik <techtonik(a)gmail.com>: ---------- nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8909> _______________________________________

1 0

[issue7229] Manual entry for time.daylight can be misleading
by anatoly techtonik 05 Jun '10

05 Jun '10

anatoly techtonik <techtonik(a)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(a)bugs.python.org> <http://bugs.python.org/issue7229> _______________________________________

2 2

[issue7229] Manual entry for time.daylight can be misleading
by Alexander Belopolsky 05 Jun '10

05 Jun '10

Alexander Belopolsky <belopolsky(a)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(a)bugs.python.org> <http://bugs.python.org/issue7229> _______________________________________

1 0

[issue8151] [patch] convenience links for subprocess.call()
by Georg Brandl 05 Jun '10

05 Jun '10

Georg Brandl <georg(a)python.org> added the comment: Already done AFAICS. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8151> _______________________________________

1 0

[issue1635217] Add example of distutils setup() with "requires" argument
by anatoly techtonik 05 Jun '10

05 Jun '10

anatoly techtonik <techtonik(a)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@python versions: +Python 2.7, Python 3.3 -Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1635217> _______________________________________

1 0

[issue8519] [patch] doc: termios and ioctl reference links
by anatoly techtonik 05 Jun '10

05 Jun '10

Changes by anatoly techtonik <techtonik(a)gmail.com>: ---------- nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8519> _______________________________________

1 0

[issue8151] [patch] convenience links for subprocess.call()
by anatoly techtonik 05 Jun '10

05 Jun '10

anatoly techtonik <techtonik(a)gmail.com> added the comment: easy, just waits to be ported ---------- nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8151> _______________________________________

1 0

[issue7229] Manual entry for time.daylight can be misleading
by R. David Murray 05 Jun '10

05 Jun '10

Changes by R. David Murray <rdmurray(a)bitdance.com>: ---------- title: [PATCH] Manual entry for time.daylight can be misleading -> Manual entry for time.daylight can be misleading _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue7229> _______________________________________

1 0