Mailman 3 August 2012 - docs

[issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call
by Aaron Staley 26 Aug '19

26 Aug '19

New submission from Aaron Staley: The documentation for __new__ at http://docs.python.org/reference/datamodel.html#object.__new__ is: """ object.__new__(cls[, ...]) Called to create a new instance of class cls. __new__() is a static method (special-cased so you need not declare it as such) that takes the class of which an instance was requested as its first argument. The remaining arguments are those passed to the object constructor expression (the call to the class). The return value of __new__() should be the new object instance (usually an instance of cls). Typical implementations create a new instance of the class by invoking the superclass’s __new__() method using super(currentclass, cls).__new__(cls[, ...]) with appropriate arguments and then modifying the newly-created instance as necessary before returning it. If __new__() returns an instance of cls, then the new instance’s __init__() method will be invoked like __init__(self[, ...]), where self is the new instance and the remaining arguments are the same as were passed to __new__(). If __new__() does not return an instance of cls, then the new instance’s __init__() method will not be invoked. __new__() is intended mainly to allow subclasses of immutable types (like int, str, or tuple) to customize instance creation. It is also commonly overridden in custom metaclasses in order to customize class creation. """ The problem is in this line: "If __new__() returns an instance of cls, then the new instance’s __init__() method will be invoked like __init__(self[, ...]), where self is the new instance and the remaining arguments are the same as were passed to __new__()." This is only true in the context of a constructor. In particular, directly calling cls.__new__(cls) will NOT call __init__. If I define a class: class C(object): def __new__(*args, **kwargs): print 'new', args, kwargs return object.__new__(*args,**kwargs) def __init__(self): print 'init' C() will result in __new__ and __init__ being both executed, but C.__new__(C) will only create the instance of C; it will not call __init__! The original documentation described in http://bugs.python.org/issue1123716 was more correct: "__new__ must return an object... If you return an existing object, the constructor call will still call its __init__ method unless the object is an instance of a different class..." That is __init__ is only being called in the context of an external constructor call. Proposed phrasing: "If __new__() is invoked during object construction (cls()) and it returns an instance of cls, then the new instance’s __init__() method will be invoked like __init__(self[, ...]), where self is the new instance and the remaining arguments are the same as were passed to the object constructor." ---------- assignee: docs@python components: Documentation messages: 167267 nosy: Aaron.Staley, docs@python priority: normal severity: normal status: open title: Documentation incorrectly suggests __init__ called after direct __new__ call versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15542> _______________________________________

6 9

[issue14112] tutorial intro talks of "shallow copy" concept without explanation
by Tshepang Lekhonkhobe 24 Aug '19

24 Aug '19

New submission from Tshepang Lekhonkhobe <tshepang(a)gmail.com>: Relevant line: http://hg.python.org/cpython/file/e2eccc906354/Doc/tutorial/introduction.rs… When the concept is introduced, it appears like there's an assumption that the reader would know what it means. I'm curious if it's that common a term that it should be taken for granted, or if it deserves a definition. ---------- assignee: docs@python components: Documentation messages: 154151 nosy: docs@python, tshepang priority: normal severity: normal status: open title: tutorial intro talks of "shallow copy" concept without explanation versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14112> _______________________________________

10 22

[issue12634] Random Remarks in class documentation
by Ashutosh Swain 23 Aug '19

23 Aug '19

New submission from Ashutosh Swain <ats.engg(a)gmail.com>: URL: http://docs.python.org/tutorial/classes.html section: 9.4 Random Remarks The first sentense is bit confusing: "Data attributes override method attributes with the same name" Is it possible to change the sentense something like this: "Data attributes set through instance override method attributes with the same name" ---------- assignee: docs@python components: Documentation messages: 141073 nosy: ats.engg, docs@python priority: normal severity: normal status: open title: Random Remarks in class documentation type: feature request versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12634> _______________________________________

9 18

[issue14050] Tutorial, list.sort() and items comparability
by Sandro Tosi 22 Aug '19

22 Aug '19

New submission from Sandro Tosi <sandro.tosi(a)gmail.com>: I'm providing patches for what reported at http://mail.python.org/pipermail/docs/2012-February/007481.html . I'm not sure on wording or even if we want them in the tutorial section, but I think it would be nice to have it documented nonetheless. ---------- assignee: docs@python components: Documentation files: list_sort-py27.diff keywords: patch messages: 153648 nosy: docs@python, sandro.tosi priority: normal severity: normal stage: patch review status: open title: Tutorial, list.sort() and items comparability versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file24557/list_sort-py27.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14050> _______________________________________

9 20

[issue11165] Document PyEval_Call* functions
by Nick Coghlan 08 Aug '19

08 Aug '19

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> _______________________________________

9 12

[issue13127] xml.dom.Attr.name is not labeled as read-only
by Dillon Amburgey 13 Jul '19

13 Jul '19

New submission from Dillon Amburgey <dillona(a)dillona.com>: http://docs.python.org/library/xml.dom.html#dom-attr-objects does not label the name attribute as read-only (like localName) even though it is. ---------- assignee: docs@python components: Documentation messages: 145155 nosy: dillona, docs@python priority: normal severity: normal status: open title: xml.dom.Attr.name is not labeled as read-only _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13127> _______________________________________

8 10

[issue12217] Cross-link docs for faulthandler, traceback and pdb
by Éric Araujo 13 Jul '19

13 Jul '19

New submission from Éric Araujo <merwok(a)netwok.org>: haypo suggested linking between traceback.print_tb and faulthandler.dump_traceback(). See also links between pdb and faulthandler could also be nice, if they explain briefly how the modules differ. ---------- assignee: docs@python components: Documentation keywords: easy messages: 137298 nosy: docs@python, eric.araujo, haypo priority: normal severity: normal stage: needs patch status: open title: Cross-link docs for faulthandler, traceback and pdb versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12217> _______________________________________

4 5

[issue15629] Run doctests in Doc/*.rst as part of regrtest
by Chris Jerdonek 24 Jun '19

24 Jun '19

New submission from Chris Jerdonek: This issue is to start running (at least some of) the doctests in the Doc/ folder's *.rst files as part of regrtest. We will need a whitelist mechanism to tell regrtest which files to process since currently many doctests are not runnable (e.g. some kind of "doctest-safe" marker that can go in a file as suggested by Nick). See also the discussion thread started here: http://mail.python.org/pipermail/python-dev/2012-August/121304.html ---------- assignee: docs@python components: Documentation messages: 168036 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: Run doctests in Doc/*.rst as part of regrtest type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15629> _______________________________________

15 41

[issue13286] PEP 3151 breaks backward compatibility: it should be documented
by STINNER Victor 13 May '19

13 May '19

New submission from STINNER Victor <victor.stinner(a)haypocalc.com>: The following example works on Python 2.7 and 3.2, but fails on Python 3.3: ----------- import errno import os try: os.rmdir("testdir") except: pass os.mkdir("testdir") try: try: os.mkdir("testdir") except IOError as exc: # If can't get proper access, then just forget about writing # the data. if exc.errno == errno.EACCES: pass else: raise except OSError as exc: # Probably another Python process already created the dir. if exc.errno == errno.EEXIST: pass else: raise except Exception: print("PEP 3151 broke backward compatibility on such pattern!") ----------- I noticed the problem while reading the changeset e4d44c2e8e81. ---------- assignee: docs@python components: Documentation messages: 146562 nosy: docs@python, flox, haypo, pitrou priority: normal severity: normal status: open title: PEP 3151 breaks backward compatibility: it should be documented versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13286> _______________________________________

5 8

[issue10536] Enhancements to gettext docs
by Éric Araujo 09 May '19

09 May '19

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> _______________________________________

8 17