Mailman 3 March 2015 - docs

Posible Error en documentación.
by Juan Nadie March 6, 2015

March 6, 2015

Hola, buenas tardes. Solo quiero informarles que en el enlace: https://docs.python.org/3/library/curses.html que corresponde a la entrada 16.10. curses <https://docs.python.org/3/library/curses.html#module-curses> — Terminal handling for character-cell displays el enlace <next> salta a la entrada 16.12. curses.ascii <https://docs.python.org/3/library/curses.ascii.html#module-curses.ascii> — Utilities for ASCII characters cuando yo creo que el enlace debería saltar a la entrada 16.11. curses.textpad <https://docs.python.org/3/library/curses.ascii.html#module-curses.ascii> — Text input widget for curses programs No es nada importante, pero es una forma de colaborar con Vds. para que la documentación este lo más correcta posible. Un cordial saludo.

1 0

suggestion for sections about bitwise operators
by David Hämmerle March 6, 2015

March 6, 2015

Dear sir or madam, I have a short suggestion how to improve the section 5.8 (Python 2.x) and 6.8 (Python 3.x) respectively. These sections only state that the arguments of bitwise operators have to be integers. But these operators obviously also work with boolean values (True/False). It would be nice if the sections explained how the operators behave when one uses only boolean values or when one mixes boolean and integer values. Yours sincerely, David Hämmerle

1 0

[issue19931] namedtuple docstrings are verbose for no added benefit
by Raymond Hettinger March 5, 2015

March 5, 2015

Raymond Hettinger added the comment: I don't think we should strip-out all the docstrings because you're unhappy with automatically (mindlessly) generated documentation. What you really need is more control over the documentation tool (the ability to save how much detail you want, particularly with subclasses of builtins which have a ton of methods with simplistic docstrings and with abstract base classes). The docstring for __repr__ isn't especially useful but it is a key feature of a namedtuple. The docstring for __getnewargs__ is informative especially if you're subclassing a named tuple and need to know what it is used for. The docstring for the individual property attributes doesn't look helpful when you list them all but does add information for one-at-a-time help, such as help(Key.blockscope), or for tooltips. FWIW, there is also a proposal to make it easier to custom the default docstrings for the properties (to turn it into more of a data dictionary). ---------- assignee: docs@python -> rhettinger resolution: -> rejected status: open -> closed versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19931> _______________________________________

1 0

[issue19931] namedtuple docstrings are verbose for no added benefit
by Mark Lawrence March 5, 2015

March 5, 2015

Changes by Mark Lawrence <breamoreboy(a)yahoo.co.uk>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python type: -> enhancement versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19931> _______________________________________

1 0

[issue23580] Amazon.com links
by Edrie Ddrie March 3, 2015

March 3, 2015

New submission from Edrie Ddrie: Keywords: easy Priority: normal ---------- assignee: docs@python components: Documentation messages: 237161 nosy: Edrie Ddrie, docs@python priority: normal severity: normal status: open title: Amazon.com links type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23580> _______________________________________

2 1

[issue17352] Be clear that __prepare__ must be declared as a class method
by Nick Coghlan March 3, 2015

March 3, 2015

Nick Coghlan added the comment: __new__ is a little weird - it's actually special cased as a staticmethod. Your questions is still valid, though. For existing versions, documenting the requirement is the only option. For future versions, we could conceivably implement a "decorate it if it isn't already decorated" fallback, but for backwards compatibility we'd have to avoid double-decorating explicitly decorated implementations. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17352> _______________________________________

1 0

[issue17352] Be clear that __prepare__ must be declared as a class method
by Ethan Furman March 3, 2015

March 3, 2015

Ethan Furman added the comment: Should __prepare__ be special-cased as a classmethod, like __new__ is? Is there any reason to ever have __prepare__ /not/ be a classmethod? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17352> _______________________________________

1 0

Re: [docs] Doc: remove errors about mixed-type comparisons. (issue 12067)
by andreas.r.maier＠gmx.de March 2, 2015

March 2, 2015

Responded to Martin's comments. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py File Lib/test/test_compare.py (right): https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:137: class ComparisonTest2(unittest.TestCase): The new test class I added is really supposed to test everything. The existing test class also compares results to some extent, but does not cover everything. I still did not want to remove it, just in case. I'll change it as follows: ComparisonTest1 -> ComparisonSimpleTest ComparisonTest2 -> ComparisonFullTest to express the expectation for the second test class. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:145: class BaseCompare(object): Will rename to CompBase, to be consistent with the other renamed classes (see comment below). https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:162: Will rename these classes e.g. from Class_eq to CompEq, so their names are PEP-8 compliant. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:328: def assert_insts(self, i1, i2, equal, comp, i1_meth=(), i2_meth=()): Will change name to assert_comparisons, for now. I will split up the two _subtest methods into six, for better identification based on subTest() (I really like that), but if I look at the number of calls to assert_comparisons(), I don't think I'd like to duplicate them. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:340: None means: Equality comparison not supported Agreed. I will remove None from the description and will add an assertion that it is not passed as None. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:347: None means: Order comparison not supported I'll change the description of None to mean "Undefined result", plus I'll add a clarifying note: "Note that the expected results shown above just indicate which order comparison expression evaluates to True; they do not make any statement about whether the ordering is a total ordering." Let me know if you think that does not cover it. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:375: self.assertEqual(i1 == i2, id(i1) == id(i2)) I thought we would have cases where id(i1)-id(i2) needs to be passed for order comparisons, so I wanted it to be consistent with that. However, there are no such cases (the one that existed was in error and was removed), so I think I agree and will change it as you proposed. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:480: self.assert_insts(i1, i2, False, id(i1)-id(i2)) Seems like that's a remainder from earlier versions of the code where I still experimented. Because object types don't have a default order comparison, the assert_insts() method ignores the value anyway and asserts that TypeError is raised. I'll change the value that is passed, to None in both of the cases shown here. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:511: self.assert_insts(insts_a[0], insts_b[0], True, 0, The create_sorted_insts() method ensures that the returned objects are in increasing order of their identities. The only interesting case is where the value is descending between two objects whose identity is ascending. That allows asserting that the order comparison is based on values, not on identities. Now, the flaw in the current code is that it compares always one object of the first list with one object of the second list, so the identity order is arbitrary between them. I will fix that by having an additional loop through the classes with only one list. Also, the existing loop across the classes can be simplified somewhat. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:550: class Class_str(str): Will rename to StrSubclass. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:554: def some_func(self): True. Will be removed. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:569: self.assert_insts(c1, c1, True, 0, Class_str.meth, Class_str.meth) On the empty tuple meths: I wanted to have one place that has the knowledge that there are no meths, instead of repeating that in every invocation of assert_insts(). But I'm ok either way. Let me know which way you would recommend to go. https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:591: i1 = int(10001) Probably. But then would we also change other objects? As it is now, it is at least consistent (across the test functions). https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#ne… Lib/test/test_compare.py:881: def test__internal_is_value_comparable(self): The idea was that "test_" is the common prefix for test functions, and the extra underscore indicates an internal function. I do realize that it is redundant with saying "internal" in the function name. However, while trying to remove the second underscore, I realized something else: The unittest package executes the test functions in alphabetical order of their names. I think it makes sense to execute tests of internal functions first, before they are used in the other real tests. Having two underscores ensures that it is executed first. I will remove the "internal_". https://bugs.python.org/review/12067/

1 0

[issue23561] a little typo in dis.rst; need a non-trivial preceding dot
by Novice Live March 2, 2015

March 2, 2015

New submission from Novice Live: it is likely that the author of dis.rst omitted two non-trivial preceding dots. in the 'Bytecode analysis' section, both :meth:`dis` and :func:`dis` have no preceding dots before 'dis'. the dots may be trivial elsewhere, but they are non-trivial here. otherwise, the hyperlinks will be unexpectedly targeted to the top of the dis module, rather than the corresponding dis method or function. ref. :meth:`.timeit`, where the 'timeit' was preceded by a dot, in timeit.rst. :) ---------- assignee: docs@python components: Documentation files: dis_typo.patch keywords: patch messages: 237039 nosy: docs@python, n0vicelive priority: normal severity: normal status: open title: a little typo in dis.rst; need a non-trivial preceding dot versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38297/dis_typo.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23561> _______________________________________

2 1

[issue23460] Decimals do not obey ':g' exponential notation formatting rules
by Ezio Melotti March 2, 2015

March 2, 2015

Changes by Ezio Melotti <ezio.melotti(a)gmail.com>: ---------- keywords: +easy stage: -> needs patch type: -> enhancement versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23460> _______________________________________

1 0