[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators
Change by Rich rauenzahn : -- nosy: +rrauenza ___ Python tracker <https://bugs.python.org/issue43833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject
Rich Rauenzahn added the comment: Thank you, lukasz. That's the answer I anticipated -- I can appreciate the backwards compatibility aspect very much. Regarding the docs, the docs say: "Attempt to read and parse a list of filenames, returning a list of filenames which were successfully parsed." I don't know if the convention in the docs is that list always means *list*, but it could be changed to be iterable since that is the implementation. That fileobjects are also iterables could be pointed out here, but I think anyone making this mistake isn't going to make the mistake from misreading the docs, it's from skipping the docs and assuming read() is consistent with write(). -- ___ Python tracker <http://bugs.python.org/issue27351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject
Rich Rauenzahn added the comment: Given that write() accepts a fileobject, but read() accepts a list of strings or a string (and readfp() is the one that accepts a fileobject instead), this seems like it could be a common enough error that just iterating over the fileobject could be undesirable and an exception might be thrown instead. I'm throwing this out here to see if the library maintainers were aware of this odd edge case. -- ___ Python tracker <http://bugs.python.org/issue27351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject
New submission from Rich Rauenzahn:
This came up on StackOverflow: http://stackoverflow.com/a/37903779/2077386
I wanted to bring it to your attention in case it hasn't been notice before.
It turns out that if you pass a fileobject (i.e.,
ConfigParser().read(open("foo"))) ConfigParser.read() will look at the
argument, see it isn't a basestring, and then will iterate over it.
fileobjects are iterables.
This results in iterating over the contents of the file 'foo'. It then
attempts to open a file named after every line read from 'foo'.
For example, I made a file foo and filled it with a-g, each letter per line.
strace shows:
open("foo", O_RDONLY) = 3
open("a\n", O_RDONLY) = -1 ENOENT (No such file or directory)
open("b\n", O_RDONLY) = -1 ENOENT (No such file or directory)
open("c\n", O_RDONLY) = -1 ENOENT (No such file or directory)
open("d\n", O_RDONLY) = -1 ENOENT (No such file or directory)
open("e\n", O_RDONLY) = -1 ENOENT (No such file or directory)
open("f\n", O_RDONLY) = -1 ENOENT (No such file or directory)
open("g\n", O_RDONLY) = -1 ENOENT (No such file or directory)
...and since the API is designed to ignore files it can't open, it just ignores
the open errors.
I wonder if this fileobject case ought to be checked for when checking the
arguments passed into ConfigParser.read().
Thank you.
--
components: Library (Lib)
messages: 268838
nosy: Rich.Rauenzahn
priority: normal
severity: normal
status: open
title: Unexpected ConfigParser.read() behavior when passed fileobject
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue27351>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14146] IDLE: source line in editor doesn't highlight when debugging
Rich Rauenzahn added the comment: Yes, the source box was checkmarked. Not the first one to encounter this as well: http://python.6.n6.nabble.com/IDLE-not-highlighting-current-line-while-debugging-on-Win-td2113345.html -- ___ Python tracker <http://bugs.python.org/issue14146> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14146] IDLE: source line in editor doesn't highlight when debugging
New submission from Rich Rauenzahn : Using 64bit python for windows downloaded from python.org on 64bit windows 7. Python Version 3.2.2 Tk version 8.5 IDLE version 3.2.2 When stepping through code the corresponding line in the editor does not highlight with the code steps. The windows does update the contents, so it appears to be tracking, but just fails to highlight the line. Double clicking on the line in the debugger will go ahead and highlight it. My settings are all default, and I've double checked the color schemes in the "highlighting" dialog. -- components: IDLE messages: 154533 nosy: Rich.Rauenzahn priority: normal severity: normal status: open title: IDLE: source line in editor doesn't highlight when debugging type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue14146> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
