[issue34203] documentation: recommend Python 3 over 2 in faq
abcdef added the comment: Thank you. I understand this is fixed now and I'm marking the ticket as closed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34203] documentation: recommend Python 3 over 2 in faq
New submission from abcdef : FAQ "How stable is Python" https://docs.python.org/3/faq/general.html#how-stable-is-python; states "There are two recommended production-ready versions at this point in time, because at the moment there are two branches of stable releases: 2.x and 3.x. Python 3.x may be less useful than 2.x, since currently there is more third party software available for Python 2 than for Python 3. Python 2 code will generally not run unchanged in Python 3." According to git blame, this is from 2009. Could we change this to recommend Python 3 over Python 2 now? -- assignee: docs@python components: Documentation messages: 322273 nosy: abcdef, docs@python priority: normal severity: normal status: open title: documentation: recommend Python 3 over 2 in faq versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32142] heapq.heappop - documentation misleading or doesn't work
abcdef <x...@mailinator.com> added the comment: > Perhaps heappop could say that the heap invariant is maintained if the heap > is properly sorted before the heappop invocation. Honestly I like this wording less. "Properly sorted" would suggest sorted in the sense of heap.sort() [as the docs refer to this earlier], but the array doesn't have to be sorted; it's enough if it's a heap. The function always maintains the invariant - this means that if the invariant is true as a precondition, it will be true as a postcondition. Maybe you have a different idea? -- nosy: +abcdef ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32142> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32133] documentation: numbers module nitpick
New submission from abcdef <x...@mailinator.com>: Documentation of the numbers module: https://docs.python.org/3/library/numbers.html states "None of the types defined in this module can be instantiated." This is true for Complex, Real, Rational, Integral but not for Number: >>> numbers.Number() >>> numbers.Real() Traceback (most recent call last): File "", line 1, in TypeError: Can't instantiate abstract class Real... Since Number doesn't have any abstract methods, the correct fix seems to be changing the documentation. I would try to convey something like this: "The types defined in this module can be used for subclassing and checking whether a specific class is in the numeric hierarchy; they are not used directly for instantiation. For this, you can use types such as `complex` or `fractions.Fraction`". -- assignee: docs@python components: Documentation messages: 306970 nosy: abcdef, docs@python priority: normal severity: normal status: open title: documentation: numbers module nitpick type: enhancement versions: Python 2.7, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20735] Documentation: mark stringprep as deprecated
New submission from abcdef: This is a nitpick, but the documentation is not clear whether the stringprep module is deprecated or not. It is listed as Deprecated on http://docs.python.org/3.3/py-modindex.html#cap-s but there's no information on http://docs.python.org/3.3/library/stringprep.html. Contrast with http://docs.python.org/3.3/library/optparse.html which has a clear warning. -- assignee: docs@python components: Documentation messages: 211964 nosy: abcdef, docs@python priority: normal severity: normal status: open title: Documentation: mark stringprep as deprecated type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20735 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17920] Documentation: complete ordering should be total ordering
New submission from abcdef: The set documentation [http://docs.python.org/3.4/library/stdtypes.html] states The subset and equality comparisons do not generalize to a complete ordering function. For example, any two disjoint sets are not equal and are not subsets of each other... Could complete ordering be changed to total ordering? This is the correct mathematical terminology. A total ordering is one where every pair is comparable. A complete ordering is one where each bounded subset has a supremum/infimum (for example, reals form a complete ordered field). This can be verified at Wikipedia [http://en.wikipedia.org/wiki/Total_order] and essentially every set theory book. -- assignee: docs@python components: Documentation messages: 188585 nosy: abcdef, docs@python priority: normal severity: normal status: open title: Documentation: complete ordering should be total ordering type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17920] Documentation: complete ordering should be total ordering
abcdef added the comment: Another small thing: For example, any two disjoint sets are not equal and are not subsets of each other, so all of the following return False: ab, a==b, or ab. It should be any two nonempty disjoint sets. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16380] true/proper subset
New submission from abcdef: The documentation http://docs.python.org/2.7/library/stdtypes.html#set-types-set-frozenset http://docs.python.org/3/library/stdtypes.html#set-types-set-frozenset of for sets uses true subset and true superset. The correct termininology is proper subset and proper superset, as evidenced by Google searches http://google.com/search?q=true subset http://google.com/search?q=proper subset and most set theory books. -- assignee: docs@python components: Documentation messages: 174410 nosy: abcdef, docs@python priority: normal severity: normal status: open title: true/proper subset type: enhancement versions: Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16380 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
