[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 (with any newlines translated before, and thus more characters read from the stream than returned) -- ___ Python tracker <https://bugs.python.org/issue43336> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 useful for anything that gets a stream and operates on it, possibly needing to know which newlines it will see when reading from the stream. One example would be, after line = stream.readline(4096+n) one want's to know whether actually a full line of 4096 characters has been read. Putting aside newline="", for simplicity here, n already depends on whether newline was None, \n, \r or \r\n, as would any check like line.endswith(foo). Maybe some attribute, that indicates the most recently read newline in newline="" mode, would be helpful, too. Cheers, Chris. -- components: IO messages: 387767 nosy: calestyo priority: normal severity: normal status: open title: export the set newline value on TextIOBase/TextIOWrapper type: enhancement ___ Python tracker <https://bugs.python.org/issue43337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, depending on the settings of newlines of the stream, \r\n would be converted to \n. It's not definitely clear whether a string like "abc\r\n" read with a size of = 4 will return "abc\n" (which it seems to do, in other words, it reads actually 5 characters, but sill returns only 4), or whether it returns "abc\r". Cheers, Chris. -- assignee: docs@python components: Documentation messages: 387758 nosy: calestyo, docs@python priority: normal severity: normal status: open title: document whether io.TextIOBase.readline(size>0) will always read the full newline ___ Python tracker <https://bugs.python.org/issue43336> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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\0abcd".split(b"\0") [b'', b'foo', b'barbaz', b'', b'abcd'] Now the same sequence, however with a different read size (here a shorter one): >>> b"\0foo\0barbaz\0".split(b"\0") [b'', b'foo', b'barbaz', b''] >>> b"\0abcd".split(b"\0") [b'', b'abcd'] => it's the same bytes, but in the 2nd case one get's an extra b''. -- ___ Python tracker <https://bugs.python.org/issue1152248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue1152248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue1152248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ones) such a feature seems to be pretty useful to prevent bloated code by copy large number of lines of identical argument parsing code. argparse is really nice and powerful,... and enables people to make clean argparsing code, but it seems a few quite features which are quite often asked for miss, like e.g. #11354 or that one can arbitrarily group mutually exclusive options like: --foo --bar --baz <(mutually exclusive> Anyway, feel free to close if you don't like supporting mutually exclusive groups with parents. Cheers, Chris. -- ___ Python tracker <https://bugs.python.org/issue43259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 subparsers. If I leave out the parent parser, then it works as you say. I'll attach exact code (with which I can reproduce it). -- Added file: https://bugs.python.org/file49821/test.py ___ Python tracker <https://bugs.python.org/issue43259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 a "normal" group,
so that the mutually exclusive arguments are listed within the group, but are
still, mutually exclusive.
Right now when doing something like:
parser = argparse.ArgumentParser()
parser_group = parser.add_argument_group("INPUT OPTIONS")
parser_group_mutually_exclusive =
parser_group.add_mutually_exclusive_group(required=False)
parser_group_mutually_exclusive.add_argument("--from-args")
parser_group_mutually_exclusive.add_argument("--from-files")
parser_group_mutually_exclusive.add_argument("--from-stdin")
parser_group.add_argument("-0", help="null delimited pathnames")
it works, but the mutually exclusive options are note printed within the "INPUT
OPTIONS", but rather at the normal "optional arguments:" section of the help.
The above example also kinda shows what this could be used for:
- one might have e.g. a group for input options, and amongst that the mutually
exclusive "--from-*" which specify the source of the input.
Cheers,
Chris.
--
components: Library (Lib)
messages: 387278
nosy: calestyo
priority: normal
severity: normal
status: open
title: argparse: allow add_mutually_exclusive_group on add_argument_group
type: enhancement
___
Python tracker
<https://bugs.python.org/issue43259>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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_argument("--foo", nargs="+", help="Mae govannen", metavar=("bar",
"baz"))
args = parser.parse_args()
and later check that, say, only 2 arguments are allowed.
But the help text will be an ugly:
>$ python3 f.py --help
>usage: f.py [-h] [--foo bar [baz ...]]
>
>optional arguments:
> -h, --help show this help message and exit
> --foo bar [baz ...] Mae govannen
indicating that >1 options were allowed.
--
nosy: +calestyo
___
Python tracker
<https://bugs.python.org/issue11354>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
