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 documen
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 solut
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
&
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
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
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
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.h
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
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/issu
Changes by Eric O. LEBIGOT :
--
assignee: -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python
___
Python tracker
<http://bugs.python.org/issu
Changes by Eric O. LEBIGOT :
--
title: Document order-preserving dictionary output -> Document order-preserving
dictionary output in son
___
Python tracker
<http://bugs.python.org/issu
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 sav
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 no
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
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
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
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 empt
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 i
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&
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)
___
P
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
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.
22 matches
Mail list logo