[issue45704] string.Formatter.parse does not handle auto-numbered positional fields

2021-11-05 Thread Eric V. Smith
Eric V. Smith added the comment: That is, return field_name as an int if it's an int, otherwise as a string. -- ___ Python tracker ___

[issue45704] string.Formatter.parse does not handle auto-numbered positional fields

2021-11-05 Thread Eric V. Smith
Eric V. Smith added the comment: I think your code is rational. But since string.Formatter gets such little use, I'm not sure it's worth adding this to the stdlib. On the other hand, it could be used internal to string.Formatter. We'd need to pick a better name, though. And maybe it should

[issue45704] string.Formatter.parse does not handle auto-numbered positional fields

2021-11-05 Thread Sascha Desch
Sascha Desch added the comment: That definition of `.parse()` definitely makes sense. Do you then think this is out of scope for `Formatter` in general or just for `.parse()`?. Just for reference, this is what I currently use to get automatic numbering to work for my use case. ``` def

[issue45704] string.Formatter.parse does not handle auto-numbered positional fields

2021-11-04 Thread Eric V. Smith
Eric V. Smith added the comment: The more I think about this, the more I think it's not .parse's job to fill in the field numbers, it's the job of whoever is calling it. Just as it's not .parse's job to give you an error if you switch back and forth between numbered and un-numbered fields.

[issue45704] string.Formatter.parse does not handle auto-numbered positional fields

2021-11-03 Thread Sascha Desch
Sascha Desch added the comment: Another thing that occurred to me is the question of what `.parse()` should do when a mix of auto-numbered and manually numbered fields is supplied e.g. `{}{1}`. As of now `.parse()` happily processes such inputs and some other piece of code deals with this

[issue45704] string.Formatter.parse does not handle auto-numbered positional fields

2021-11-03 Thread Eric V. Smith
Eric V. Smith added the comment: > Side note: It's a somewhat weird that `.get_field` expects a string while > `.get_value` expects an int for positional arguments. .parse is just concerned with parsing, so it works on and returns strings. .get_field takes strings because it is the thing

[issue45704] string.Formatter.parse does not handle auto-numbered positional fields

2021-11-03 Thread Sascha Desch
Sascha Desch added the comment: Yes it should return a string containing the index of the positional argument i.e. `"0"` so that it is compatible with `.get_field()`. Side note: It's a somewhat weird that `.get_field` expects a string while `.get_value` expects an int for positional

[issue45704] string.Formatter.parse does not handle auto-numbered positional fields

2021-11-03 Thread Eric V. Smith
Eric V. Smith added the comment: For reference, the documentation is at https://docs.python.org/3/library/string.html#custom-string-formatting I guess in your example it should return: [('hello ', '0', '', None)] -- nosy: +eric.smith ___ Python

[issue45704] string.Formatter.parse does not handle auto-numbered positional fields

2021-11-03 Thread Sascha Desch
New submission from Sascha Desch : It appears when adding auto-numbered positional fields in python 3.1 `Formatter.parse` was not updated to handle them and currently returns an empty string as the field name. ``` list(Formatter().parse('hello {}')) # [('hello ', '', '', None)] ``` This