[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Irit Katriel added the comment: This seems complete, can it be closed? -- nosy: +iritkatriel ___ Python tracker ___ ___

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Brian Curtin added the comment: New changeset 3cd5e8e83c9785d9f505138903c7a50dc964101e by Brian Curtin (Miss Islington (bot)) in branch '3.6': bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Brian Curtin added the comment: New changeset b0b8f9bd4e6f78ac7383b4e56cfb6cbacc77da89 by Brian Curtin (Miss Islington (bot)) in branch '3.7': bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Change by miss-islington : -- pull_requests: +9029 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Brian Curtin added the comment: New changeset e45473e3ca31e5b78dc85cab575f5bb60d5b7f8f by Brian Curtin (Zackery Spytz) in branch 'master': bpo-27351: Fix ConfigParser.read() documentation and docstring (GH-8123)

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Change by miss-islington : -- pull_requests: +9030 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Change by Zackery Spytz : -- nosy: +ZackerySpytz versions: +Python 3.7, Python 3.8 -Python 3.5 ___ Python tracker ___ ___

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Change by Zackery Spytz : -- keywords: +patch pull_requests: +7771 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Terry J. Reedy added the comment: Doing what the doc says is not a bug. The doc being obsolete in saying 'list' (which was once true) instead of the now correct 'iterable' is. The 3.6 ConfigParser.__doc___ also says 'list', so both docstrings and docs for all current versions should be fixed.

[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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Łukasz Langa added the comment: Thanks for your report, Rich. configparser is one of the oldest libraries in the standard library. Its behavior might sometimes not be intuitive to newcomers but is burdened by years of backwards compatibility. Changing the behavior now to raise a type error

[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

[issue27351] Unexpected ConfigParser.read() behavior when passed fileobject

Xiang Zhang added the comment: The doc tells ConfigParser.read accepts a filename or a list of filenames. Why do you pass it fileobject? If you want to use fileobject, why not read_file? -- nosy: +lukasz.langa, xiang.zhang ___ Python tracker

[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()