[issue38385] statistics: incorrect documentation
New submission from Eric O. LEBIGOT : The documentation for the statistics package indicates that many of its functions (like median()) accept iterators. They seem to actually accept something more convenient, namely iterables. Thus, iterator could probably be usefully replaced by iterable on many of the functions (when applicable, which I would expect is everywhere). -- assignee: docs@python components: Documentation messages: 354043 nosy: docs@python, lebigot priority: normal severity: normal status: open title: statistics: incorrect documentation versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30550] Document order-preserving dictionary output in json
Eric O. LEBIGOT added the comment: The essence of the original post is simply to document any order-preserving properties of the Python to JSON and JSON to Python transformation for mappings. This way users can rely on it. This is for instance useful if a program modifies JSON created by a user and wants to preserve the user ordering. -- ___ Python tracker <https://bugs.python.org/issue30550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30550] Document order-preserving dictionary output in json
Eric O. LEBIGOT added the comment: Kyle, what you're saying is correct but is unfortunately unrelated to any of the points in the original issue. In fact, the JSON encoder does preserve whatever order the dictionary elements are in, and it would be useful to document this. Thus, if a user gives an OrderedDict (or a dict with a known order, in Python 3.7+), it is useful that he know that the order of its elements will not be changed upon transformation into JSON. -- ___ Python tracker <https://bugs.python.org/issue30550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30550] Document order-preserving dictionary output in son
Changes by Eric O. LEBIGOT : -- title: Document order-preserving dictionary output -> Document order-preserving dictionary output in son ___ Python tracker <http://bugs.python.org/issue30550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30550] Document order-preserving dictionary output in json
Changes by Eric O. LEBIGOT : -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python ___ Python tracker <http://bugs.python.org/issue30550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30550] Document order-preserving dictionary output in json
Changes by Eric O. LEBIGOT : -- title: Document order-preserving dictionary output in son -> Document order-preserving dictionary output in json ___ Python tracker <http://bugs.python.org/issue30550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30550] Document order-preserving dictionary output
New submission from Eric O. LEBIGOT: The JSON encoder for dictionaries preserves the order of the items in a dictionary: it would be useful to document this behavior, so that users can rely on it. While JSON itself does not have ordered key/value pairs, this feature can be useful (for modifying the original JSON document while maintaining as much of it untouched, for manipulating our own extension of JSON with ordered dictionaries, etc.). The documentation could also usefully mention that _reading_ sets of key/value pairs can also be done in an order-preserving way with `object_pairs_hook=OrderedDict`. Reference: the json module does not alter the order of the dictionary items upon encoding: https://github.com/python/cpython/blob/aacd53f6cb96fe8c4fe9ce894f22e25f356a97c3/Lib/json/encoder.py#L355. -- components: Library (Lib) messages: 295001 nosy: lebigot priority: normal severity: normal status: open title: Document order-preserving dictionary output type: enhancement versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30217] Missing entry for the tilde (~) operator in the Index
New submission from Eric O. LEBIGOT: The index (https://docs.python.org/3.6/genindex-Symbols.html) is missing an entry for the tilde operator ~ (there is also no entry under "tilde"). A relevant pointer could be to object.__invert__ (https://docs.python.org/3.6/reference/datamodel.html#object.__invert__). -- assignee: docs@python components: Documentation messages: 292641 nosy: docs@python, lebigot priority: normal severity: normal status: open title: Missing entry for the tilde (~) operator in the Index type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue30217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24658] open().write() fails on 2 GB+ data (OS X)
Eric O. LEBIGOT added the comment: I see, thanks. This sounds good to me too: no need for a warning or exception, indeed, since file.write() should work and the behavior of os.write() is documented. -- ___ Python tracker <http://bugs.python.org/issue24658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24658] open().write() fails on 2 GB+ data (OS X)
Eric O. LEBIGOT added the comment: Thank you for looking into this, Ronald. What does your patch do, exactly? does it only limit the returned byte count, or does it really limit the size of the data written by truncating it? In any case, it would be very useful to have a warning from the Python interpreter. If the data is truncated, I would even prefer an explicit exception (e.g. "data too big for this platform (>= 2 GB)"), along with an explicit mention of it in the documentation. What do you think? -- ___ Python tracker <http://bugs.python.org/issue24658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24658] open().write() fails on 2 GB+ data (OS X)
Eric O. LEBIGOT added the comment: PS: I should have written "2 GB" bytearray (so this looks like a signed 32 bit integer issue). -- title: open().write() fails on 4 GB+ data (OS X) -> open().write() fails on 2 GB+ data (OS X) ___ Python tracker <http://bugs.python.org/issue24658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24658] open().write() fails on 4 GB+ data (OS X)
New submission from Eric O. LEBIGOT:
On OS X, the Homebrew and MacPorts versions of Python 3.4.3 raise an exception
when writing a 4 GB bytearray:
>>> open('/dev/null', 'wb').write(bytearray(2**31-1))
2147483647
>>> open('/dev/null', 'wb').write(bytearray(2**31))
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 22] Invalid argument
This has an impact on pickle, in particular
(http://stackoverflow.com/questions/31468117/python-3-can-pickle-handle-byte-objects-larger-than-4gb).
--
components: Interpreter Core
messages: 246878
nosy: lebigot
priority: normal
severity: normal
status: open
title: open().write() fails on 4 GB+ data (OS X)
type: behavior
versions: Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue24658>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23164] "pydoc filter" documentation restrictive
New submission from Eric O. LEBIGOT: The pydoc documentation for filter reads: filter(function or None, sequence) -> list, tuple, or string Return those items of sequence for which function(item) is true. If function is None, return the items that are true. If sequence is a tuple or string, return the same type, else return a list. It would be nicer to know (e.g. when offline and with no local access to the HTML documentation) that filter() can actually be used more generally with an iterable: filter(function or None, **iterable**) -> list, tuple, or string Return those items of **iterable** for which… -- assignee: docs@python components: Documentation messages: 233416 nosy: docs@python, lebigot priority: normal severity: normal status: open title: "pydoc filter" documentation restrictive type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue23164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21195] None float format: incomplete documentation
Eric O. LEBIGOT added the comment: The Python 2.7 goes even as far as to say that format(1e10, ' ') should give "the same as" format(1e10, ' g') (not something "similar to g"), which is obviously incorrect. If the Python 3.4 documentation for the empty presentation type of floats were used in the Python 2.7 documentation, it would be closer to the real behavior of Python 2.7, so that would be an improvement. Now, the real question is whether the Python 3.4 documentation applies exactly to Python 2.7, here, or whether improving the Python 2.7 documentation would require a different description. -- ___ Python tracker <http://bugs.python.org/issue21195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21195] None float format: incomplete documentation
Eric O. LEBIGOT added the comment: These examples are good. I am confused, though, about "The SO question is asking about an empty "presentation type", which is indeed similar to 'g' for floats.": the question is actually about why the '' format gives a result that differs from the 'g' format despite the Python 2.7 documentation saying that a "None" format type is "The same as 'g'.". Both the SO question and your examples show that the Python 2.7 documentation is incorrect, unless the other commenters and I were missing something… Clarifying the documentation would in any case be useful, as the comments to the SO question show… -- ___ Python tracker <http://bugs.python.org/issue21195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21195] None float format: incomplete documentation
New submission from Eric O. LEBIGOT: The documentation for a None (empty) format for floats indicates that it is equivalent to the g format. This does not appear to be correct (http://stackoverflow.com/questions/16525924/precise-definition-of-float-string-formatting). The Python 3.4 documentation (https://docs.python.org/3.4/library/string.html#format-specification-mini-language) seems to be much closer to what Python 2.7 does. It would be useful to have a more correct documentation for the effect of a None format for floats in Python 2.7 (maybe by copying the Python 3.4 documentation if it applies). -- assignee: docs@python components: Documentation messages: 215871 nosy: docs@python, lebigot priority: normal severity: normal status: open title: None float format: incomplete documentation type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21195> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12982] Document that importing .pyo files needs python -O
Eric O. LEBIGOT added the comment: Thank you for this lucid account of the situation, Terry. As for where in the documentation something additional could be said about .pyo files and the -O option, I must say that it is already mentioned in some relevant places (http://docs.python.org/tutorial/modules.html#compiled-python-files), However, I can see one other place where some additional information would be useful: in the documentation for the -O option itself (http://docs.python.org/using/cmdline.html#miscellaneous-options). The current documentation only mentions the .pyo-producing effect of -O. Mentioning there that -O is *required* for interpreting .pyo files would be useful. Thanks! -- ___ Python tracker <http://bugs.python.org/issue12982> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12982] Document that importing .pyo files needs python -O
Eric O. LEBIGOT added the comment: Terry, it seems that the doc I was quoting is for version 1.5.1 (http://docs.python.org/release/1.5.1p1/tut/node43.html). I can't find it in more recent versions of the doc. I should not have quoted an obsolete version of the documentation—I'm not sure how this happened. :) I am not fully sure why -O is essentially required for running .pyo files: why not have the Python interpreter handle everything automatically based on the extension? -- ___ Python tracker <http://bugs.python.org/issue12982> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12982] Document that importing .pyo files needs python -O
Eric O. LEBIGOT added the comment: Hi Michael, Thank you for your message. You are mentioning the suggestion of "the other Eric" (Araujo). My suggestion was to rename your .pyo files as .pyc files; it is hackish (according to a previous post from Eric Araujo), but might save you some trouble, on the short term, as .pyc do not need -O. Best wishes, EOL On Jun 12, 2012, at 21:25, Michael Herrmann wrote: > > Michael Herrmann added the comment: > > Hi Eric, > > thank you for your quick reply. I'm not the first one who encounters this > problem and in my opinion it is simply counter-intuitive that you cannot read > a mixture of .pyo and .pyc files. That is why I think that my proposed change > is valuable. In the meantime, I will follow your suggestion and try to use > the imp-module to load the .pyo-files myself. Thank you! > > Best regards, > Michael > > -- > > ___ > Python tracker > <http://bugs.python.org/issue12982> > ___ -- ___ Python tracker <http://bugs.python.org/issue12982> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12982] .pyo file cannot be imported
Eric O. LEBIGOT added the comment: Indeed. Thanks. I wish it had been in the documentation. :) This is yet another reason for me to check how I can submit patches to the doc. :) I also found out that renaming the .pyo file as .pyc makes Python happy upon import. That's the solution I chose, because I don't want users to have to type "python -O" when calling programs compiled with -O or -OO. -- ___ Python tracker <http://bugs.python.org/issue12982> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12982] .pyo file cannot be imported
New submission from Eric O. LEBIGOT : When creating a .pyo file (either with -O or -OO) and removing any .pyc or .py original file, import complains with "No module called ". The import does work with .pyc files. I'm not sure that this is the correct behavior, as the documentation does not seem to make any difference between .pyc and .pyo files on this point: "It is possible to have a file called spam.pyc (or spam.pyo when -O is used) without a file spam.py for the same module. This can be used to distribute a library of Python code in a form that is moderately hard to reverse engineer." -- components: Interpreter Core messages: 144049 nosy: lebigot priority: normal severity: normal status: open title: .pyo file cannot be imported type: compile error versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12982> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1653416] OS X print >> f, "Hello" produces no error on read-only f: normal?
Changes by Eric O. LEBIGOT : -- title: OS X print >> f, "Hello" produces no error: normal? -> OS X print >> f, "Hello" produces no error on read-only f: normal? ___ Python tracker <http://bugs.python.org/issue1653416> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
