Mailman 3 January 2014 - docs

[issue20135] FAQ need list mutation answers
by R. David Murray 16 Jan '14

16 Jan '14

R. David Murray added the comment: Thanks for working on this. Technically, defaults are evaluated when the 'def' statement is executed, which is normally, but not always, at the time that the module is first imported (counterexample: nested function definitions). The answer should also explicitly cover the more common mistake made with default keyword values of passing a mutable object and having it get persistently modified,and the question phrasing should reflect that. The datetime example is a great first example before getting to the more common one, though. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20135> _______________________________________

1 0

[issue20281] time.strftime %z format specifier is the same as %Z
by SilentGhost 16 Jan '14

16 Jan '14

SilentGhost added the comment: Mike, the note is at the very bottom of the page. datetime.strftime produces empty strings with this specifiers for naïve objects, are the object you're testing timezone-aware? ---------- nosy: +SilentGhost _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20281> _______________________________________

1 0

[issue20281] time.strftime %z format specifier is the same as %Z
by Mike Owens 16 Jan '14

16 Jan '14

Mike Owens added the comment: The datetime.strftime function produces no output for %z or %Z. Very irritating. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20281> _______________________________________

1 0

[issue20281] time.strftime %z format specifier is the same as %Z
by Mike Owens 16 Jan '14

16 Jan '14

Mike Owens added the comment: Documentation doesn't have a foot note for either %z or %Z but there is generic footnote talking about C lib behavior and that %z is deprecated. I guess if there were a foot note in the table for %z that would save some time for everyone. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20281> _______________________________________

1 0

[issue20281] time.strftime %z format specifier is the same as %Z
by R. David Murray 16 Jan '14

16 Jan '14

R. David Murray added the comment: Please see the footnote on the 'time' documentation page. It sounds like Windows is treating %z as if was %Z. There should be a reference to that footnote from the %z table entry, so that's a doc bug. Might also be worth explicitly mentioning this weird Windows behavior. FYI, you can use the strftime functionality of the datetime module to get cross platform %z support. ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python, r.david.murray stage: -> needs patch versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20281> _______________________________________

1 0

[issue20135] FAQ need list mutation answers
by Fran Bull 16 Jan '14

16 Jan '14

Fran Bull added the comment: I read the FAQ last night and I couldn't see these answered there either. I would like to try submitting a patch for this one, probably this evening. It will likely be two FAQs in the programming section that go something like: Why does changing one list change another different list? This happens: >>> a = [1, 2, 3] >>> b = a >>> b.append(4) >>> print a [1, 2, 3, 4] because variables are just names for things, in this case 'a' is the list we first defined and then b = a says that 'b' is also a name for that list. They are both the same list. Why are my default args wrong? This happens: >>> from datetime import datetime >>> class A(object): ... def __init__(self, created_time=datetime.now()): ... self.created_time = created_time ... >>> an_a = A() >>> another_a = A() >>> an_a.created_time datetime.datetime(2014, 1, 16, 10, 40, 54, 33283) >>> another_a.created_time datetime.datetime(2014, 1, 16, 10, 40, 54, 33283) because default arguments are evaluated when they're read for the first time by the interpreter. Usually when the class is imported. A good way to get the above to do what you want is to use a default argument of None and check for it, like: >>> class B(object): ... def __init__(self, created_time=None): ... if created_time is None: ... created_time=datetime.now() ... self.created_time = created_time ... >>> a_b = B() >>> another_b = B() >>> a_b.created_time datetime.datetime(2014, 1, 16, 10, 44, 44, 956710) >>> another_b.created_time datetime.datetime(2014, 1, 16, 10, 44, 51, 71311) Feedback appreciated, particularly I'm not sure if this: 'default arguments are evaluated when they're read for the first time by the interpreter' is exactly the right language. I guess I'll look it up. ---------- nosy: +Fran.Bull _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20135> _______________________________________

1 0

[issue6128] Consequences of using Py_TPFLAGS_HAVE_GC are incompletely explained
by Christian Aichinger 16 Jan '14

16 Jan '14

Christian Aichinger added the comment: I concur that this aspect of writing Python types in C/C++ needs better documentation. For a new extension writer (like me), it is not obvious when PyObject_GC_Track/PyObject_GC_UnTrack must be called or not. Similarly, it is not clear from the current documentation how to ensure that memory is allocated with PyObject_GC_New. The gcsupport documentation suffers from being written from the perspective of the GC, instead of the perspective of extension writers. Thus, I've attached a patch that tries to shed some light on how to correctly write types implementing cyclic GC support. I'd appreciate comments/editing suggestions/advice and would welcome the patch to go into Python in some form. I myself consider the change to be trivial, but if necessary I can sign the contributor agreement. -- PS: Informal explanation about what's really going on: The Python GC code deals with memory allocation, not with initialization in any way. For most extension types, allocation is handled by tp_alloc which is called typically called from tp_new (either the default tp_new or your own tp_new handler). The default tp_alloc (PyType_GenericAlloc()) looks at tp_flags, and if Py_TPFLAGS_HAVE_GC is specified, it uses the appropriate GC malloc function and calls _PyObject_GC_TRACK when finished). Thus, if you allocate your memory via tp_alloc, and don't override the tp_alloc handler, you've just fulfilled the GC's constructor requirements. Similarly, the GC doesn't care about object destruction. It cares about freeing memory, that is tp_free, NOT tp_dealloc! Again, if you don't intentionally provide a custom tp_free handler, the default one will take care to obey the GC rules. Thus, most extension writers can get away with 4 simple rules: * Set Py_TPFLAGS_HAVE_GC in tp_flags. * Do not specify tp_alloc or tp_free. * Make sure your object actually allocates it's memory via tp_alloc. Three possibilities to achieve this: + Do not add a tp_new handler, or + Call tp_alloc from your tp_new handler, or + Call a base class's tp_new from your own tp_new handler * Implement tp_traverse and tp_clear. They are usually straight-forward. And if you really do want a custom allocator, you're screwed anyway, as the last part of my patch hints at. Custom memory management is just not compatible with the GC at this point. ---------- keywords: +patch nosy: +Greek0 versions: +Python 3.5 Added file: http://bugs.python.org/file33497/gcsupport-doc.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6128> _______________________________________

1 0

[issue20272] chain.from_iterable in the overview table not linking to the function
by SilentGhost 16 Jan '14

16 Jan '14

New submission from SilentGhost: chain.from_iterable is not linkified in the overview table at the top of the itertools docs. The patch requires reformat of the table. ---------- assignee: docs@python components: Documentation files: linkify.diff keywords: patch messages: 208184 nosy: SilentGhost, docs@python, rhettinger priority: normal severity: normal stage: patch review status: open title: chain.from_iterable in the overview table not linking to the function versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file33484/linkify.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20272> _______________________________________

2 2

[issue20278] Wrong URL to the pysqlite web page
by Richard Philips 16 Jan '14

16 Jan '14

New submission from Richard Philips: The reference to the pysqlite web page on: http://docs.python.org/3.4/library/sqlite3.html should be: https://github.com/ghaering/pysqlite ---------- assignee: docs@python components: Documentation messages: 208261 nosy: Richard.Philips, docs@python priority: normal severity: normal status: open title: Wrong URL to the pysqlite web page versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20278> _______________________________________

3 2

Section 4.7.1
by Doug and Riekie Dorman 15 Jan '14

15 Jan '14

I am having problems with the example in 4.7.1. Attached is code with comments explaining my problems. Doug Dorman

2 1