Mailman 3 June 2012 - docs

[issue15068] fileinput requires two EOF when reading stdin
by R. David Murray June 15, 2012

June 15, 2012

R. David Murray <rdmurray(a)bitdance.com> added the comment: So the real question is: does readlines block until the byte count is satisified? It might, but the docs for io.IOBase.readlines leave open the possibility that fewer lines will be read, and do not limit that to the EOF case. It's not clear, however, if that is because the non-EOF-short-read case is specifically being allowed for, or if the documenter just didn't consider that case. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________

1 0

[issue15068] fileinput requires two EOF when reading stdin
by R. David Murray June 15, 2012

June 15, 2012

R. David Murray <rdmurray(a)bitdance.com> added the comment: fileinput should work (for some definition of work) for anything that can be opened by name using the open syscall on unix. That includes many more things than files. Named pipes are a particularly interesting example in this context. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________

1 0

[issue15068] fileinput requires two EOF when reading stdin
by Joey Geralnik June 15, 2012

June 15, 2012

Joey Geralnik <jgeralnik(a)gmail.com> added the comment: But this is calling the readlines function, which continually reads from the file until more bytes have been read than the specified argument. >From bz2.readlines: "size can be specified to control the number of lines read: no further lines will be read once the total size of the lines read so far equals or exceeds size." Do other file-like objects interpret this parameter differently? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________

1 0

[issue15068] fileinput requires two EOF when reading stdin
by Arfrever Frehtes Taifersar Arahesis June 14, 2012

June 14, 2012

Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA(a)GMail.Com>: ---------- nosy: +Arfrever _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________

1 0

[issue15068] fileinput requires two EOF when reading stdin
by Antoine Pitrou June 14, 2012

June 14, 2012

Antoine Pitrou <pitrou(a)free.fr> added the comment: It is unlikely to be solvable at the Python level. Witness the raw stream's behaviour (in Python 3): >>> sys.stdin.buffer.raw.read(1000) If you type a letter followed by ^D (Linux) or ^Z (Windows), this returns immediately: >>> sys.stdin.buffer.raw.read(1000) x^Db'x' But since the result is non-empty, the buffering layer will not detect the EOF and will call read() on the raw stream again (as the 1000 bytes are not satisfied). To signal EOF to the buffered stream, you have to type ^D or ^Z *without preceding it with another character*. Try the following: >>> sys.stdin.buffer.read(1000) You'll see that as long as you type a letter before ^D or ^Z, the read() will not return (until you type more than 1000 characters, that is): - ^D alone: returns! - a letter followed by ^D: doesn't return - a letter followed by ^D followed by ^D: returns! - a letter followed by ^D followed by a letter followed by ^D: doesn't return This is all caused by the fact that a C read() on stdin doesn't return until either the end of line or EOF (or the requested bytes number is satisfied). Just experiment with: >>> os.read(0, 1000) That's why I say this is not solvable at the Python level (except perhaps with bizarre ioctl hackery). ---------- nosy: +pitrou _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________

1 0

[issue15068] fileinput requires two EOF when reading stdin
by Serhiy Storchaka June 14, 2012

June 14, 2012

Serhiy Storchaka <storchaka(a)gmail.com> added the comment: Note that in the rare cases, when stdio ends immediately on the limit of the read buffer, just one EOF is sufficient. In particular for read(1) one EOF is sufficient always, and for read(2) it is sufficient in about half of the cases. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________

1 0

[issue15068] fileinput requires two EOF when reading stdin
by R. David Murray June 14, 2012

June 14, 2012

R. David Murray <rdmurray(a)bitdance.com> added the comment: That makes sense. It is a consequence of (a) buffered input and (b) the fact that EOF on stdin doesn't really close it. (And by interactive here I don't just mean Python's interactive prompt, but also the shell). By default fileinput uses readlines with a buffer size, so it suffers from the same issue. It is only the second time that you close stdin that it gets an empty buffer, and so terminates. Anyone want to try to come up with a doc footnote to explain this? ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________

1 0

[issue12982] Document that importing .pyo files needs python -O
by Terry J. Reedy June 14, 2012

June 14, 2012

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: Eric, can you find a place in the current doc where -O and .pyo are mentioned, and where you think a sentence should go. What sentence(s) would you like to see. Other comments: __debug__ is intended to be a process-global compilation value (implemented as a keyword) set on startup >>> __debug__ True >>> __debug__ = False SyntaxError: assignment to keyword The devs are not willing to support having contradictory values in the same process. Indeed, since I posted last night, the pydev discussion has moved to the question of whether -O, __debug__, and .pyo as now defined are worth the nuisance they cause or whether some or all should be deprecated. (Docstring stripping for saving space could then be a separate tool.) --- Python interpreters exist to run Python code. The existence, persistence, and other details of compilation caches are version-dependent implementation details. Being able to execute from such caches without source present is also an implementation detail, and for CPython, it gets secondary support at best. (This is a compromise between full support and no support.) ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________

1 0

[issue12982] Document that importing .pyo files needs python -O
by Ronan Lamy June 14, 2012

June 14, 2012

Ronan Lamy <ronan.lamy(a)gmail.com> added the comment: Doing it at the interpreter level is trivial (cf. patch), except for an annoying bug I noticed (see below). Doing it from user code might require some care to avoid disrupting existing import hooks, but AFAICT something like sys.path_hooks.append(FileFinder.path_hook(['.pyo', SourcelessFileLoader, True])) is supposed to work. The bug is that -O has currently no effect on sourceless imports: it seems that frozen_importlib actually uses freeze-time __debug__ instead of the current interpreter's. ---------- keywords: +patch Added file: http://bugs.python.org/file26008/issue12982.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________

1 0

[issue12982] Document that importing .pyo files needs python -O
by Eric Snow June 14, 2012

June 14, 2012

Eric Snow <ericsnowcurrently(a)gmail.com> added the comment: > 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? In part because it would take work to make it happen and apparently no one feels strongly enough about adding that functionality, or convinced enough that it's appropriate, to do the work. If you're interested a good first step would be to write a PEP 302 metapath hook (finder that gets inserted to sys.metapath) that makes import of .pyo files work even when -O is not used. Maybe you'd also want to have .pyc files work even when -O *is* used. Keep in mind that there may be other reasons why such functionality would not go into the interpreter. However, the beauty of import hooks is that it wouldn't matter once you have yours in hand. ---------- nosy: +eric.snow _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12982> _______________________________________

1 0