Mailman 3 November 2012 - docs

[issue16404] Uses of PyLong_FromLong that don't check for errors
by Andrew Svetlov Nov. 15, 2012

Nov. 15, 2012

Changes by Andrew Svetlov <andrew.svetlov(a)gmail.com>: ---------- nosy: +asvetlov _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16404> _______________________________________

1 0

[issue16144] misleading sentence in reference/import
by Manuel Pégourié-Gonnard Nov. 15, 2012

Nov. 15, 2012

New submission from Manuel Pégourié-Gonnard: I find the following sentences, from import.rst, section "Finders and loaders", misleading: "Python includes a number of default finders and importers. One knows how to locate frozen modules, and another knows how to locate built-in modules." in that one may think frozen comes before built-in, while the converse is true. Attached is a patch with a hopefully clearer version. While at it, the patch also turns into links the references to PEPs in the introduction. ---------- assignee: docs@python components: Documentation files: import-doc-fixes.patch keywords: patch messages: 172105 nosy: docs@python, mpg priority: normal severity: normal status: open title: misleading sentence in reference/import versions: Python 3.4 Added file: http://bugs.python.org/file27436/import-doc-fixes.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16144> _______________________________________

5 5

Possible bug in zipfile when opening zip file from external drive
by Nick Weppenaar Nov. 15, 2012

Nov. 15, 2012

Hello. I would like to report a possible bug. I'm using zipfile to extract files from a zip repository. When I try to open the zip repository, I hit an error message from lines 173-174 in zipfile.py: if diskno != 0 or disks != 1: raise BadZipfile("zipfiles that span multiple disks are not supported") The problem is that it's not a multi-disk zipfile. When I try to open it with anything else (7-zip, windows), it works fine. I think the problem could be that the zipfile was created on an external harddrive and hits a snag on the first part of the check. I don't know exactly what diskno is, but I guess that it relates to the order of the disk in the system. Anyway, it I comment out those two lines, zipfile extracts the files without any problems. My suggestion is to separate out the two checks and make sure that zipfiles created on external drives (if that's the cause of the problem) can be extracted. Thank you. Nick Weppenaar

1 0

Re: [docs] Backport set and dictionary comprehensions in tutorial to 2.7 (issue 16470)
by ezio.melotti＠gmail.com Nov. 15, 2012

Nov. 15, 2012

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… File Doc/tutorial/datastructures.rst (right): http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… Doc/tutorial/datastructures.rst:520: Like :ref:`for lists <tut-listcomps>`, there is a set comprehension syntax:: Whoever commits the patch can take care of it, just make sure to add a comment about it on the tracker. http://bugs.python.org/review/16470/

1 0

Re: [docs] Backport set and dictionary comprehensions in tutorial to 2.7 (issue 16470)
by fossilet＠users.sourceforge.net Nov. 15, 2012

Nov. 15, 2012

http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… File Doc/tutorial/datastructures.rst (right): http://bugs.python.org/review/16470/diff/6577/Doc/tutorial/datastructures.r… Doc/tutorial/datastructures.rst:520: Like :ref:`for lists <tut-listcomps>`, there is a set comprehension syntax:: Sounds good. Will this rephrasing also be applied to 3.x? On 2012/11/14 09:32:19, ezio.melotti wrote: > The first part of the sentence doesn't sound too good to me. > Maybe it could be rephrased to something like "Similarly to list comprehensions, > set comprehensions are also supported::" http://bugs.python.org/review/16470/

1 0

[issue16418] argparse with many choices can generate absurdly long usage message
by Terry J. Reedy Nov. 14, 2012

Nov. 14, 2012

Terry J. Reedy added the comment: I see that in #16468, Chris proposes that existing versions should let the TypeError propagate, possibly with an improved error message, and call the use of repr for non-iterables a new feature (partly on the basis that more fixes than this are needed to use them). ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16418> _______________________________________

1 0

[issue16418] argparse with many choices can generate absurdly long usage message
by Terry J. Reedy Nov. 14, 2012

Nov. 14, 2012

Terry J. Reedy added the comment: I agree that my extreme, strawman-ish, proposal, was, well, too extreme. Here is a more realistic proposal similar to David's. if isinstance(choices, range) and len(choices) > 50: choice_txt = range_rep(choices) # details to be determined try: choice_txt = <iterated version of choices as now> except TypeError: # because choices not iterable choice_txt = repr(choices) # can be anything for custom class Then display help or error message. If someone passes a non-(x)range iterable with 1000s of choices, I am willing to say they deserve what they asked for, once that the docs make clearer that such collections will be displayed in full. Any iterable container too large to display in full can be wrapped as a non-iterable container. ('Container' means that 'in' works.) class NonIterableContainer: def __init__(self, container, description): self.container = container self.description = description def __repr__(self): return self.description def __contains__(self, item): return item in self.container The description could point one to a file or doc that has an explicit list. If such a listing enumerates the items, the program arg could instead be an int in the appropriate range. Then the program would look up the actual arg. Ranges *are* special because items from any finite enumerated collection can be replaced, for input, by the corresponding int in the enumerated range. They are therefore worth special attention in help and error displays. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16418> _______________________________________

1 0

[issue16418] argparse with many choices can generate absurdly long usage message
by Chris Jerdonek Nov. 14, 2012

Nov. 14, 2012

Chris Jerdonek added the comment: For maintenance releases, I think I would favor abbreviating the list only if it is "lossless" (e.g. for xrange objects). I think I would also be okay with abbreviating for arbitrary xranges -- in particular for arbitrary steps. For example, for xrange(0, 50, 3), I think something like the following might be better: "0, 3, 6, 9, ... 45, 48" (we could also include a difference hint). ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16418> _______________________________________

1 0

[issue16418] argparse with many choices can generate absurdly long usage message
by R. David Murray Nov. 14, 2012

Nov. 14, 2012

R. David Murray added the comment: I agree with Chris that using the repr in the general case would be a regression in usability for the end user (and certainly not suitable for a maintenance release). Here is some brainstorming: We could "special case" this via duck typing. If the object that represents the choices has 'start' and 'stop' attributes, use those to generate a message. ("from {start} up to but not including {stop}"). [*] If it doesn't, or it also has a 'step' that is not 1, check the len, generate the list if it is less than, say, 50, and if it is more give up and use the repr. If there is no len, do the expansion (which is what happens now) and throw it away in favor of the repr if there are more than 50 elements. If there is no iter, use the repr. Then as an enhancement we can also look for a special attribute (values_description?) that gives the entire text to use in the parenthesis in the help phrase to provide a way to customize the help text in 3.4+. [*] Or, at the risk of being too clever, if there is a 'step' use the message above and if there isn't a step attribute at all use "between {start} and {stop}. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16418> _______________________________________

1 0

[issue16378] venv.EnvBuilder docstring inconsistencies
by Bradley Froehle Nov. 14, 2012

Nov. 14, 2012

New submission from Bradley Froehle: Consider the docstring for venv.EnvBuilder:: By default, the builder makes the system (global) site-packages dir available to the created environment. By default, the creation process uses symlinks wherever possible. It seems to suggest that the `system_site_packages` and `symlink` parameters both default to True, even though the default values for each are False. The docstring for venv.create is similarly misleading. ---------- assignee: docs@python components: Documentation messages: 174388 nosy: bfroehle, docs@python priority: normal severity: normal status: open title: venv.EnvBuilder docstring inconsistencies versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16378> _______________________________________

3 2