Mailman 3 August 2014 - docs

[issue13553] Tkinter Tk args and Gnome Shell application name
by Terry J. Reedy Aug. 5, 2014

Aug. 5, 2014

Terry J. Reedy added the comment: The resolution of this issue should be to properly document the Tk class. The 3.4 docs currently say: "class tkinter.Tk(screenName=None, baseName=None, className='Tk', useTk=1) The Tk class is instantiated without arguments. This creates a toplevel widget of Tk which usually is the main window of an application. Each instance has its own associated Tcl interpreter." The signature is incomplete -- see below. The first sentence is wrong; there are arguments, they just all happen to have defaults. The next sentence should be something like "Return a toplevel Tk widget, which is usually the main window of an application." Tk.__doc__ is 'Toplevel widget of Tk which represents mostly the main window\n of an application. It has an associated Tcl interpreter.' This is probably ok. Tk.__init__ signature and Tk,__init__.__doc__ are __init__(self, screenName=None, baseName=None, className='Tk', useTk=1, sync=0, use=None) "Return a new Toplevel widget on screen SCREENNAME. A new Tcl interpreter will be created. BASENAME will be used for the identification of the profile file (see readprofile). It is constructed from sys.argv[0] without extensions if None is given. CLASSNAME is the name of the widget class." "Toplevel" should be "toplevel" as in : Tk is not a subclass of Toplevel. Rather Toplevel is similar to Tk but with the BaseWidget signature. The argument list needs to be completed and perhaps a bit more said about the one documented. Does 'screen' apply to anything other than X11? Could it be used on Windows to put the window on a secondary screen? Is Gnome the only user framework that uses classname? ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, serhiy.storchaka, terry.reedy stage: -> needs patch title: Tkinter doesn't set proper application name in Gnome Shell -> Tkinter Tk args and Gnome Shell application name versions: +Python 3.4, Python 3.5 -Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13553> _______________________________________

1 0

[issue22142] PEP 465 operators not described in lexical_analysis
by Antoine Pitrou Aug. 5, 2014

Aug. 5, 2014

Changes by Antoine Pitrou <pitrou(a)free.fr>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22142> _______________________________________

1 0

[issue21972] Bugs in the lexer and parser documentation
by François-René Rideau Aug. 5, 2014

Aug. 5, 2014

New submission from François-René Rideau: The lexer documentation says that the u prefix works on strings since 3.3, but doesn't explain what or how, which is all the more problematic since it explicitly mentions difference from the behavior documented in Python 2. It also doesn't specify the ELLIPSIS token or the <> future token mentioned in the grammar (that should probably be removed, for PEP 401 is a joke — unless that's intentional, in which case a smiley might be useful). https://docs.python.org/3.5/reference/lexical_analysis.html ---------- assignee: docs@python components: Documentation messages: 222906 nosy: François-René.Rideau, docs@python priority: normal severity: normal status: open title: Bugs in the lexer and parser documentation type: behavior versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21972> _______________________________________

4 8

[issue21928] Incorrect reference to partial() in functools.wraps documentation
by Dustin Oprea Aug. 5, 2014

Aug. 5, 2014

New submission from Dustin Oprea: functools.wraps docs say "This is a convenience function for invoking partial(update_wrapper, wrapped=wrapped, assigned=assigned, updated=updated) as a function decorator when defining a wrapper function." The referenced function should be update_wrapper(), not partial(). ---------- assignee: docs@python components: Documentation messages: 222426 nosy: Dustin.Oprea, docs@python priority: normal severity: normal status: open title: Incorrect reference to partial() in functools.wraps documentation versions: Python 2.7, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21928> _______________________________________

4 4

[issue15759] "make suspicious" doesn't display instructions in case of failure
by Ezio Melotti Aug. 5, 2014

Aug. 5, 2014

New submission from Ezio Melotti: I was running "make suspicious" in Doc/ and this was the output after finding 3 suspicious markups: writing output... [ 52%] library/inspect WARNING: [library/inspect:437] ":int" found in ">>> def foo(a, *, b:int, **kwargs):" WARNING: [library/inspect:437] ":int" found in "'(a, *, b:int, **kwargs)'" WARNING: [library/inspect:437] ":int" found in "'b:int'" writing output... [100%] whatsnew/index build finished with problems, 3 warnings. make: *** [build] Error 1 After figuring out how to mark these as false positives and adding the relevant entries to susp-ignored.csv, I ran "make suspicious" again, and got this useful message at the end: writing output... [100%] whatsnew/index build succeeded. Suspicious check complete; look for any errors in the above output or in build/suspicious /suspicious.csv. If all issues are false positives, append that file to tools/sphinxext/susp-ignored.csv. The problem is that this message should be displayed when there are failures, but it's not. Attached an attempt to fix the Makefile to avoid exiting in case of failures when the builder is "suspicious". Given that I'm not really familiar with makefiles, it probably doesn't make much sense. ---------- assignee: docs@python components: Documentation files: issue15759.diff keywords: patch messages: 168842 nosy: docs@python, eric.araujo, ezio.melotti, georg.brandl priority: normal severity: normal stage: patch review status: open title: "make suspicious" doesn't display instructions in case of failure type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file26956/issue15759.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15759> _______________________________________

5 15

[issue18069] Subprocess picks the wrong executable on Windows
by Ezio Melotti Aug. 4, 2014

Aug. 4, 2014

Changes by Ezio Melotti <ezio.melotti(a)gmail.com>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python stage: -> needs patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18069> _______________________________________

1 0

[issue19055] Regular expressions: * does not match as many repetitions as possible.
by Ezio Melotti Aug. 4, 2014

Aug. 4, 2014

Ezio Melotti added the comment: I agree. ---------- resolution: -> works for me stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19055> _______________________________________

1 0

[issue18034] Last two entries in the programming FAQ are out of date (import related)
by R. David Murray Aug. 4, 2014

Aug. 4, 2014

New submission from R. David Murray: The second to last talks about the __import__ quirk with out calling __import__ out as deprecated. The last uses the imp module for reload. ---------- assignee: docs@python components: Documentation messages: 189827 nosy: brett.cannon, docs@python, eric.snow, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Last two entries in the programming FAQ are out of date (import related) type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18034> _______________________________________

5 8

[BUG] In python Array module
by rashid bhat Aug. 4, 2014

Aug. 4, 2014

Hello The array object on assignment does not create a new object instead it creates a reference to the assigned object ( As expected it should create a new object). Following code would be enough to prove it *import array* *foo = array.array("c", "hello")* bar = foo bar[0] = "\x00" print foo[0] gives "\x00" output while it should be hello -- Regards Raashid Bhat

2 1

[issue20402] List comprehensions should be noted in for loop documentation
by Rob Lanphier Aug. 4, 2014

Aug. 4, 2014

New submission from Rob Lanphier: The current list comprehension documentation is difficult to find for someone who doesn't know what a list comprehension is. Example of this problem: http://www.reddit.com/r/learnprogramming/comments/1w6slm/different_kind_of_… Since list comprehensions are a riff off of "for" loop syntax, they should at least be noted and linked to from section 4.2 ("for statements" section) and quite possibly 5.6 ("Looping constructs") ---------- assignee: docs@python components: Documentation messages: 209380 nosy: docs@python, robla priority: normal severity: normal status: open title: List comprehensions should be noted in for loop documentation type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20402> _______________________________________

5 7