[issue43336] document whether io.TextIOBase.readline(size>0) will always read the full newline

Christoph Anton Mitterer added the comment: I guess that the translation from CRLF to LF simply happens before the size restriction is enforced (which is good so, btw), so effectively it: will not *read* at most size characters from the stream, but *return* at most size characters from it

[issue43337] export the set newline value on TextIOBase/TextIOWrapper

New submission from Christoph Anton Mitterer : Hey. It seems there is no way to determine the newline value (None, '', \n, \r, \r\n) of a given text stream. .newlines rather gives the newlines that have been encountered so far. Just like .encoding and .errors this would be quite

[issue43336] document whether io.TextIOBase.readline(size>0) will always read the full newline

Christoph Anton Mitterer added the comment: "a n > 0size" should have read "a size > 0" -- ___ Python tracker <https://bugs.python.org/issue43336> ___ ___

[issue43336] document whether io.TextIOBase.readline(size>0) will always read the full newline

New submission from Christoph Anton Mitterer : Hey. It would be nice if the following behaviour could be definitely clarified: When reading from a text stream with readline(size) with a n > 0size it says: "If size is specified, at most size characters will be read." Also, dep

[issue1152248] Add support for reading records with arbitrary separators to the standard IO stack

Christoph Anton Mitterer added the comment: btw, just something for the record: I think the example given in msg109117 above is wrong: Depending on the read size it will produce different results, given how split() works: Imagine a byte sequence: >>> b"\0foo\0barbaz\0\0ab

[issue1152248] Add support for reading records with arbitrary separators to the standard IO stack

Christoph Anton Mitterer added the comment: Oh, what a pity,... Seemed like a pretty common use case, which is unnecessarily prone to buggy or inefficient (user-)implementations. -- ___ Python tracker <https://bugs.python.org/issue1152

[issue1152248] Add support for reading records with arbitrary separators to the standard IO stack

Christoph Anton Mitterer added the comment: Just wondered whether this is still being considered? Cheers, Chris. -- nosy: +calestyo ___ Python tracker <https://bugs.python.org/issue1152

[issue43259] argparse: allow add_mutually_exclusive_group on add_argument_group

Christoph Anton Mitterer added the comment: Well but if that's anyway one of its actual major use cases, wouldn't it make sense to properly support it? Especially when one has a large set of identical options (which is then even more likely to also include mutually exclusive on

[issue43259] argparse: allow add_mutually_exclusive_group on add_argument_group

Change by Christoph Anton Mitterer : Added file: https://bugs.python.org/file49822/test-no-parent.py ___ Python tracker <https://bugs.python.org/issue43259> ___ ___ Pytho

[issue43259] argparse: allow add_mutually_exclusive_group on add_argument_group

Christoph Anton Mitterer added the comment: Okay the problem seems to be that I didn't give you the exact details on what I do. Actually, the group (which then contains the mutually exclusive group) is contained in a "shared" parent parser, which I then use in the subparse

[issue43259] argparse: allow add_mutually_exclusive_group on add_argument_group

New submission from Christoph Anton Mitterer : Hey. AFAIU, the sole purpose of ArgumentParser.add_argument_group() is for the grouping within the help output. It would be nice, if one could create a mutually exclusive group (with ArgumentParser.add_mutually_exclusive_group) from/within such

[issue39617] max_workers argument to concurrent.futures.ProcessPoolExecutor is not flexible enough

Change by Christoph Anton Mitterer : -- nosy: +calestyo ___ Python tracker <https://bugs.python.org/issue39617> ___ ___ Python-bugs-list mailing list Unsub

[issue29447] Add/check os.PathLike support for the tempfile module's 'dir' arguments

Change by Christoph Anton Mitterer : -- nosy: +calestyo ___ Python tracker <https://bugs.python.org/issue29447> ___ ___ Python-bugs-list mailing list Unsub

[issue11354] argparse: nargs could accept range of options count

Christoph Anton Mitterer added the comment: Next to code readability, there's IMO one could reason to properly support this would be a clean and easy way to get proper help strings for such options. Of course I can do something like: parser = argparse.ArgumentParser() parser.add_arg