Mailman 3 Have a "j" format option for lists - Python-ideas

newer
Correct way for writing Python...

Have a "j" format option for lists

older
Add an optional type file for Type...

Facundo Batista

9 May 2018 9 May '18

6:09 p.m.

This way, I could do:

...

...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

In this case the join can be made in the format yes, but this proposal would be very useful when the info to format comes inside a structure together with other stuff, like...

...

...
...
info = { ... 'title': "A book", ... 'price': Decimal("2.34"), ... 'authors: ["John", "Mary", "Estela"], ... } ... print("{title!r} (${price}) by {authors:, j}".format(**info)) "A book" ($2.34) by John, Mary, Estela

What do you think? -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista

Show replies by date

Joao S. O. Bueno

9 May 9 May

6:13 p.m.

On 9 May 2018 at 09:39, Facundo Batista wrote:

...

This way, I could do:

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

+1. I bit concerned about the relevant whitespace in there, but just a little bit - it is already inside a string-literal anyway.

...

In this case the join can be made in the format yes, but this proposal would be very useful when the info to format comes inside a structure together with other stuff, like...

...
...
...
info = { ... 'title': "A book", ... 'price': Decimal("2.34"), ... 'authors: ["John", "Mary", "Estela"], ... } ... print("{title!r} (${price}) by {authors:, j}".format(**info)) "A book" ($2.34) by John, Mary, Estela

What do you think?

-- . Facundo

Steven D'Aprano

6:36 p.m.

On Wed, May 09, 2018 at 09:39:08AM -0300, Facundo Batista wrote:

...

This way, I could do:

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

Looks interesting, but I think we need to know the semantics in more detail. For example: - if the items of the list aren't already strings, how are they converted? - do you truly mean lists *only*, or is any iterable acceptible? Here's a tiny proof-of-concept for the feature: import string class Template(string.Formatter): def format_field(self, value, spec): if spec.endswith('j'): value = ', '.join(map(str, value)) spec = spec[:-1] + 's' return super(Template, self).format_field(value, spec) Template().format('{:j} => {:d}', ['alpha', 'beta', 42, 'delta'], 99) # returns 'alpha, beta, 42, delta => 99' -- Steve

Chris Angelico

6:58 p.m.

On Wed, May 9, 2018 at 11:06 PM, Steven D'Aprano wrote:

...

On Wed, May 09, 2018 at 09:39:08AM -0300, Facundo Batista wrote:

...
This way, I could do:

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

Looks interesting, but I think we need to know the semantics in more detail. For example:

- if the items of the list aren't already strings, how are they converted?

I'd expect that they'd be converted using format(), which by default would just call str(). How you'd go about specifying a format string, though, I'm not sure.

...

- do you truly mean lists *only*, or is any iterable acceptible?

...

From the sound of it, this would be a change made to format(), or rather the underlying C level function, PyObject_Format(). If done

With the letter being "j" and the semantics being lifted from str.join(), I would guess the latter. there, it would also automatically apply to f-strings and anything else that calls format(). Perhaps the right way is not a colon marker, but an enhancement to the ! notation? We currently have !s and !r to do str() and repr(), and this could be !j followed by a join string. Combining this with a colon would allow the individual elements to be formatted with the given string, and then joined. For instance: x = [1,2,3] msg = '#{x:3d!j, }#'.format(x=x) # or equivalently msg = f'#{x:3d!j, }#' assert msg == '# 1, 2, 3#' +0.5 on this. I don't currently yearn for it, but I'd probably use it if it were available. ChrisA

Eric V. Smith

7:19 p.m.

On 5/9/18 9:28 AM, Chris Angelico wrote:

...

On Wed, May 9, 2018 at 11:06 PM, Steven D'Aprano wrote:

...
On Wed, May 09, 2018 at 09:39:08AM -0300, Facundo Batista wrote:

...
This way, I could do:

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

Looks interesting, but I think we need to know the semantics in more detail. For example:

- if the items of the list aren't already strings, how are they converted?

I'd expect that they'd be converted using format(), which by default would just call str(). How you'd go about specifying a format string, though, I'm not sure.

...
- do you truly mean lists *only*, or is any iterable acceptible?

With the letter being "j" and the semantics being lifted from str.join(), I would guess the latter.

Since '{:spec}'.format(obj) basically becomes obj.__format__('spec'), this would have to be implemented on a concrete type (in the above example, list).

...

From the sound of it, this would be a change made to format(), or rather the underlying C level function, PyObject_Format(). If done there, it would also automatically apply to f-strings and anything else that calls format(). Perhaps the right way is not a colon marker, but an enhancement to the ! notation? We currently have !s and !r to do str() and repr(), and this could be !j followed by a join string. Combining this with a colon would allow the individual elements to be formatted with the given string, and then joined. For instance:

I would object to changing the format machinery. Any format spec should be interpreted by some object's __format__ method. Eric

...

x = [1,2,3] msg = '#{x:3d!j, }#'.format(x=x) # or equivalently msg = f'#{x:3d!j, }#' assert msg == '# 1, 2, 3#'

+0.5 on this. I don't currently yearn for it, but I'd probably use it if it were available.

ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Paul Moore

7:31 p.m.

On 9 May 2018 at 14:49, Eric V. Smith wrote:

...

On 5/9/18 9:28 AM, Chris Angelico wrote:

...
On Wed, May 9, 2018 at 11:06 PM, Steven D'Aprano wrote:

...
- do you truly mean lists *only*, or is any iterable acceptible?

With the letter being "j" and the semantics being lifted from str.join(), I would guess the latter.

Since '{:spec}'.format(obj) basically becomes obj.__format__('spec'), this would have to be implemented on a concrete type (in the above example, list).

[...]

...

I would object to changing the format machinery. Any format spec should be interpreted by some object's __format__ method.

Agreed. In theory this is a nice idea, but the way formatting is implemented (and the fact that join is a method on strings taking an arbitrary iterable as an argument) means that it's a bad fit for the format mini-language. I don't think the improved convenience is sufficient to warrant the change that would be required in practice. (But if someone found a way to make it work *without* changes to the underlying format machinery, that would be a different matter...) Paul

Eric V. Smith

7:59 p.m.

On 5/9/18 10:01 AM, Paul Moore wrote:

...

On 9 May 2018 at 14:49, Eric V. Smith wrote:

...
I would object to changing the format machinery. Any format spec should be interpreted by some object's __format__ method.

Agreed. In theory this is a nice idea, but the way formatting is implemented (and the fact that join is a method on strings taking an arbitrary iterable as an argument) means that it's a bad fit for the format mini-language.

I don't think the improved convenience is sufficient to warrant the change that would be required in practice. (But if someone found a way to make it work *without* changes to the underlying format machinery, that would be a different matter...)

Well, since you asked, let's combine this with dataclasses, because we can! from dataclasses import dataclass from typing import List @dataclass class Join: o: List[str] # or similar def __format__(self, spec): return spec.join(self.o) l = ['a', 'b'] print('{:, }'.format(Join(l))) print(f'{Join(l):-}') Gives: a, b a-b Eric

Paul Moore

8:11 p.m.

On 9 May 2018 at 15:29, Eric V. Smith wrote:

...

On 5/9/18 10:01 AM, Paul Moore wrote:

...
On 9 May 2018 at 14:49, Eric V. Smith wrote:

...
I would object to changing the format machinery. Any format spec should be interpreted by some object's __format__ method.

Agreed. In theory this is a nice idea, but the way formatting is implemented (and the fact that join is a method on strings taking an arbitrary iterable as an argument) means that it's a bad fit for the format mini-language.

I don't think the improved convenience is sufficient to warrant the change that would be required in practice. (But if someone found a way to make it work *without* changes to the underlying format machinery, that would be a different matter...)

Well, since you asked, let's combine this with dataclasses, because we can!

from dataclasses import dataclass from typing import List

@dataclass class Join: o: List[str] # or similar def __format__(self, spec): return spec.join(self.o)

l = ['a', 'b']

print('{:, }'.format(Join(l))) print(f'{Join(l):-}')

Gives: a, b a-b

:-) Sorry, I should have been clearer. Given that print('{}'.format(', '.join(l))) isn't that difficult, at least for me the attraction of the proposal was the possibility of not having to wrap the argument (whether in a function call, or in a custom class). But the print(f'{Join(l):-}') approach is certainly cleaner looking than print(f'{", ".join(l)}'). Paul

Wolfgang Maier

6:50 p.m.

On 05/09/2018 02:39 PM, Facundo Batista wrote:

...

This way, I could do:

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

In this case the join can be made in the format yes, but this proposal would be very useful when the info to format comes inside a structure together with other stuff, like...

...
...
...
info = { ... 'title': "A book", ... 'price': Decimal("2.34"), ... 'authors: ["John", "Mary", "Estela"], ... } ... print("{title!r} (${price}) by {authors:, j}".format(**info)) "A book" ($2.34) by John, Mary, Estela

What do you think?

For reference (first message of a rather long previous thread): https://mail.python.org/pipermail/python-ideas/2015-September/035787.html

Eric V. Smith

7:12 p.m.

On 5/9/18 8:39 AM, Facundo Batista wrote:

...

This way, I could do:

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

In this case the join can be made in the format yes, but this proposal would be very useful when the info to format comes inside a structure together with other stuff, like...

...
...
...
info = { ... 'title': "A book", ... 'price': Decimal("2.34"), ... 'authors: ["John", "Mary", "Estela"], ... } ... print("{title!r} (${price}) by {authors:, j}".format(**info)) "A book" ($2.34) by John, Mary, Estela

What do you think?

Among other things, I think you should use .format_map(info) instead of .format(**info)! Eric

Rhodri James

10:18 p.m.

On 09/05/18 13:39, Facundo Batista wrote:

...

This way, I could do:

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

In this case the join can be made in the format yes, but this proposal would be very useful when the info to format comes inside a structure together with other stuff, like...

...
...
...
info = { ... 'title': "A book", ... 'price': Decimal("2.34"), ... 'authors: ["John", "Mary", "Estela"], ... } ... print("{title!r} (${price}) by {authors:, j}".format(**info)) "A book" ($2.34) by John, Mary, Estela

What do you think?

-1 until you give me an actual spec rather than a curious example. Sorry if that sounds a bit rude, but I spend most of my time trying to find polite ways to inform people that I'm perfectly capable of implementing the fluffy collection of vague aspirations and inconsistent terminology they have given me, but the results won't be what they expect and probably won't be what they want either. And that's just talking to my boss :-) If you want something specific you'll have to specify it, otherwise you'll get something else. -- Rhodri James *-* Kynesim Ltd

Facundo Batista

10 May 10 May

1:26 a.m.

2018-05-09 13:48 GMT-03:00 Rhodri James :

...

-1 until you give me an actual spec rather than a curious example.

Sorry if that sounds a bit rude, but I spend most of my time trying to find

Be sorry, it was rude. This list is for throwing ideas and see if they gain momentum... if yes, it will be time for a PEP. I know how to do a PEP, believe me. But if we'll be asking for a Spec for every idea we think may be valuable, we'll stall. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista

Steven D'Aprano

6:15 a.m.

On Wed, May 09, 2018 at 04:56:38PM -0300, Facundo Batista wrote:

...

2018-05-09 13:48 GMT-03:00 Rhodri James :

...
-1 until you give me an actual spec rather than a curious example.

Sorry if that sounds a bit rude, but I spend most of my time trying to find

Be sorry, it was rude.

I do not agree that Rhodri's comments were rude. They were frank and honest constructive criticism of the presentation of your idea. I have no patience with hair-trigger accusations of "rudeness" as a debating tactic to curtail criticism, and your response to Rhodri's mild and fair words looks exactly like that. Whether you intended it that way or not, that is what it looks like to me. I too spent some time scratching my head trying to guess what you expect this "j" format code to do, including the fundamental question "why j and not some other letter?". Even after I worked out some of it, I was still left with questions. So I think that Rhodri's criticism is completely valid: your post was vague, with a lack of detail and not even an attempt to provide a partial specification. That doesn't have to be a formal specification, but it should be at least an attempt to say "this is what the format code means", rather than expect people to guess from a single example. (By the way, if you answered my earlier questions, I haven't seen the answer.) Dealing with under-specified, vague instructions, and the invariable failure to guess correctly what was intended, is frustrating, annoying and painful. We should not be surprised that vague proposals can trigger an angry response, but Rhodri's post showed great restraint. It isn't just the waste of time and effort when when we guess wrong, it is also the implied disrespect: "I am too important to bother explaining myself to minions like you. Work out what I mean." If an idea is important enough to post here, we should be willing to spend some time presenting the idea in sufficient detail so that people don't have to guess what we mean. As the Zen says, "Explicit is better than implicit". No, that doesn't mean that we have to write a PEP before posting. There is a middle-ground between giving a single example and expecting people to extrapolate from it, and writing a full PEP. -- Steve

Chris Angelico

6:20 a.m.

On Thu, May 10, 2018 at 10:45 AM, Steven D'Aprano wrote:

...

I too spent some time scratching my head trying to guess what you expect this "j" format code to do, including the fundamental question "why j and not some other letter?".

Interestingly, that question didn't faze me in the slightest. But maybe my instant and automatic "oh you mean join" coloured my expectations elsewhere, and possibly not correctly. ChrisA

Steven D'Aprano

6:32 a.m.

On Thu, May 10, 2018 at 10:50:13AM +1000, Chris Angelico wrote:

...

On Thu, May 10, 2018 at 10:45 AM, Steven D'Aprano wrote:

...
I too spent some time scratching my head trying to guess what you expect this "j" format code to do, including the fundamental question "why j and not some other letter?".

Interestingly, that question didn't faze me in the slightest. But maybe my instant and automatic "oh you mean join" coloured my expectations elsewhere, and possibly not correctly.

Oh, I didn't think of that! I was thinking i, j, k as integers, and thinking "i is used, and j is the next letter". -- Steve

Terry Reedy

7:27 a.m.

On 5/9/2018 9:02 PM, Steven D'Aprano wrote:

...

On Thu, May 10, 2018 at 10:50:13AM +1000, Chris Angelico wrote:

...
On Thu, May 10, 2018 at 10:45 AM, Steven D'Aprano wrote:

...
I too spent some time scratching my head trying to guess what you expect this "j" format code to do, including the fundamental question "why j and not some other letter?".

Interestingly, that question didn't faze me in the slightest. But maybe my instant and automatic "oh you mean join" coloured my expectations elsewhere, and possibly not correctly.

Oh, I didn't think of that! I was thinking i, j, k as integers, and thinking "i is used, and j is the next letter".

I took me several minutes to *guess* that j abbreviated join. It would have been better if it were given in the proposal. -- Terry Jan Reedy

Facundo Batista

6:38 p.m.

2018-05-09 21:45 GMT-03:00 Steven D'Aprano :

...

On Wed, May 09, 2018 at 04:56:38PM -0300, Facundo Batista wrote:

...
2018-05-09 13:48 GMT-03:00 Rhodri James :

...
-1 until you give me an actual spec rather than a curious example.

Sorry if that sounds a bit rude, but I spend most of my time trying to find

Be sorry, it was rude.

I do not agree that Rhodri's comments were rude. They were frank and honest constructive criticism of the presentation of your idea.

I have no patience with hair-trigger accusations of "rudeness" as a debating tactic to curtail criticism, and your response to Rhodri's mild and fair words looks exactly like that. Whether you intended it that way or not, that is what it looks like to me.

I totally apologize if I made you, Rhodri or anybody to feel bad about this. It was not my intention to do that. It felt rude to me and I reacted badly, and too fast. I should have behaved differently, sorry again. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista

Rhodri James

4:32 p.m.

On 09/05/18 20:56, Facundo Batista wrote:

...

2018-05-09 13:48 GMT-03:00 Rhodri James :

...
-1 until you give me an actual spec rather than a curious example.

Sorry if that sounds a bit rude, but I spend most of my time trying to find

Be sorry, it was rude.

On reflection, I'm not sorry at all. It needed to be said, and attempting to deduce a spec from a single example has already caused people to go off in a variety of different directions. If provoking you into being even a bit more specific gets our collective cat herd moving in something more like the same direction, it'll be worth it. In that spirit, and trying not to take this as a challenge to see how rude I can be without actually being rude: ;-) I too didn't equate "j" with "join". I was somewhat expecting "l" for "list" given that "s" for "sequence" is taken. Should I take it that everything from the colon to the "j" is an implicitly delimited string to use for joining? If so, does anything in that string need escaping, like say braces or other "j"s? I'm not sure if format specifiers currently allow arbitrary text (I don't think they do, but I'm not sure), which might make this a more serious undertaking than it first looks. Alternatively, are certain characters forbidden in this implicit join string? I presume also that no other formatting is possible with this specifier: no field widths, no justification, none of the other stuff applicable to strings. I'm not talking about formatting the original strings (or whatever) in the list, that would clearly involve crazy amounts of sub-formatting and look like a complete mess in the code, but I can see a need for formatting the final joined string, and I can't see a way of doing that from what you've given us. I'm not convinced, I admit. Your use case

...

...
...
print("{title!r} (${price}) by {authors:, j}".format(**info)) "A book" ($2.34) by John, Mary, Estela

is moderately compelling, but is starting to look too magic for my tastes. I think it's the implicitly delimited join string; it isn't obvious at first sight that the comma and space aren't independently meaningful in some obscure way, like everything else in that position in a format would be.

...

This list is for throwing ideas and see if they gain momentum... if yes, it will be time for a PEP.

I know how to do a PEP, believe me.

But if we'll be asking for a Spec for every idea we think may be valuable, we'll stall.

Raising the barrier a bit is no bad thing in my opinion; it shouldn't be easy to add things to Python, otherwise we'd have a much uglier language. Regardless, there is a difference between a full-blown PEP and an outline spec. Much as I would like to have every jot and tittle in place for a first draft, I know that's not realistic and I don't expect it. On the other hand, bitter experience has taught me that when the first draft of a proposal is as nebulous as what you gave us, I should walk away from the incipient disaster right now. -- Rhodri James *-* Kynesim Ltd

Eric V. Smith

5:39 p.m.

On 5/10/18 7:02 AM, Rhodri James wrote:

...

If so, does anything in that string need escaping, like say braces or other "j"s? I'm not sure if format specifiers currently allow arbitrary text (I don't think they do, but I'm not sure), which might make this a more serious undertaking than it first looks. Alternatively, are certain characters forbidden in this implicit join string?

A format spec can contain anything. Its interpretation is completely left to the type being formatted. For example, a datetime supports a strftime() string, which can be anything:

...

...
...
'{:today is %Y-%m-%d}'.format(datetime.datetime.now()) 'today is 2018-05-10'

In str.format(), there's a restriction that the format spec can't contain a closing brace }, but that's solely a restriction of the string scanning that's going on, and not a function of the __format__ protocol itself. For example:

...

...
...
format(datetime.datetime.now(), 'today is %Y-%m-%d {tada!}') 'today is 2018-05-10 {tada!}'

I always suggest to people that they don't look at f-strings or str.format() when coming up with examples, but instead use format() or obj.__format__() to more clearly see what's happening. In Facundo's original example: authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) it's best to think of this as: "Authors: " + format(authors, ', j') or the equivalent (in this case): "Authors: " + authors.__format__(', j') authors is a list in this example, so list.__format__() would have to understand the format spec ', j'. Okay, that's probably doable (although I'm not advocating it!). But you really don't want this to work just for lists. What about: def authors1(): yield "John" yield "Mary" yield "Estela" format(authors1(), ', j') How would that work? Would generators grow a __format__()? It's not possible to add this functionality to every iterator past, present, and future. This is why I think a wrapper that adds a __format__(), which itself calls str.join(), is the only way to handle this. This is what I showed in my earlier response as the Join class. And at that point, I don't think it's really worth the hassle over just calling str.join(). Eric

Facundo Batista

6:51 p.m.

2018-05-10 8:02 GMT-03:00 Rhodri James :

...

On 09/05/18 20:56, Facundo Batista wrote:

...
2018-05-09 13:48 GMT-03:00 Rhodri James :

...
-1 until you give me an actual spec rather than a curious example.

Sorry if that sounds a bit rude, but I spend most of my time trying to find

Be sorry, it was rude.

On reflection, I'm not sorry at all. It needed to be said, and attempting to deduce a spec from a single example has already caused people to go off in a variety of different directions. If provoking you into being even a bit more specific gets our collective cat herd moving in something more like the same direction, it'll be worth it.

I apologize if *I* was rude or made feel you badly in any way.

...

I too didn't equate "j" with "join". I was somewhat expecting "l" for "list" given that "s" for "sequence" is taken. Should I take it that everything from the colon to the "j" is an implicitly delimited string to use for joining?

Yes.

...

If so, does anything in that string need escaping, like say braces or other "j"s? I'm not sure if format specifiers currently allow arbitrary text (I don't think they do, but I'm not sure), which might make this a more serious undertaking than it first looks. Alternatively, are certain characters forbidden in this implicit join string?

Don't know. I think I need to read this for ideas: https://mail.python.org/pipermail/python-ideas/2015-September/035789.html

...

I presume also that no other formatting is possible with this specifier: no field widths, no justification, none of the other stuff applicable to strings. I'm not talking about formatting the original strings (or whatever) in the list, that would clearly involve crazy amounts of sub-formatting and look like a complete mess in the code, but I can see a need for formatting the final joined string, and I can't see a way of doing that from what you've given us.

I concur, joining *and* do special formatting for the elements would be a mess. That's way in other mail I said that probably cover the basic case (doing just str()) is better; if you want something more complex you always can do it as a separate step :/ -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista

Ken Kundert

6:52 a.m.

Facundo, I think this is the beginning of a great feature. And it fills a hole in the current string formatting. Specifically, we can carefully control the formatting of the base data types, but not collections. I would like to see you flesh out the idea. In particular, I'd like to see you address cases where: 1. The underlying members in the collection are not strings. Besides the basic types such as numbers, it would also be nice to be able to apply formats recursively so that one can construct a string using the attributes of members that are objects or items or other collections. 2. The ability to handle collections other than simple lists or iterables, such as dictionaries. -Ken On Wed, May 09, 2018 at 09:39:08AM -0300, Facundo Batista wrote:

...

This way, I could do:

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

In this case the join can be made in the format yes, but this proposal would be very useful when the info to format comes inside a structure together with other stuff, like...

...
...
...
info = { ... 'title': "A book", ... 'price': Decimal("2.34"), ... 'authors: ["John", "Mary", "Estela"], ... } ... print("{title!r} (${price}) by {authors:, j}".format(**info)) "A book" ($2.34) by John, Mary, Estela

What do you think?

-- . Facundo

Facundo Batista

6:43 p.m.

...

I would like to see you flesh out the idea. In particular, I'd like to see you address cases where: 1. The underlying members in the collection are not strings. Besides the basic types such as numbers, it would also be nice to be able to apply formats recursively so that one can construct a string using the attributes of members that are objects or items or other collections.

I didn't think about this at the time. I have the feeling (not really well thought yet) that "recursive formatting" will complicate everything too much, that doing str() (as {} defaults to) on every object would fulfill most of the basic cases and keep this simple.

...

2. The ability to handle collections other than simple lists or iterables, such as dictionaries.

Ideally, it will handle *any* iterable. Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista

Chris Angelico

7:04 p.m.

On Thu, May 10, 2018 at 11:13 PM, Facundo Batista wrote:

...

...
I would like to see you flesh out the idea. In particular, I'd like to see you address cases where: 1. The underlying members in the collection are not strings. Besides the basic types such as numbers, it would also be nice to be able to apply formats recursively so that one can construct a string using the attributes of members that are objects or items or other collections.

I didn't think about this at the time. I have the feeling (not really well thought yet) that "recursive formatting" will complicate everything too much, that doing str() (as {} defaults to) on every object would fulfill most of the basic cases and keep this simple.

...
2. The ability to handle collections other than simple lists or iterables, such as dictionaries.

Ideally, it will handle *any* iterable.

If it's to handle arbitrary iterables, it can't be the normal style of "take this string, pass it to the object's __format__ method, and let it interpret it". That's why I suggested a bang notation instead. We have some already:

...

...
...
x = "O'Really?" print(f"!s: {x!s} !r: {x!r}") !s: O'Really? !r: "O'Really?"

Those markers apply to ANY object, and pass it through str() or repr() respectively, before using any provided format string. A "!j" flag could take an iterable, format each element using the given format, and then join them. The letter "j" makes good sense then, as it parallels str.join() - this would be broadly similar to "...".join(format(...) for x in iter). ChrisA

Facundo Batista

9:58 p.m.

2018-05-10 10:34 GMT-03:00 Chris Angelico :

...

...
Ideally, it will handle *any* iterable.

If it's to handle arbitrary iterables, it can't be the normal style of "take this string, pass it to the object's __format__ method, and let it interpret it". That's why I suggested a bang notation instead. We have some already:

Yes, I think it fits better, as it's not just a formatting, it's more an "operation"...

...

A "!j" flag could take an iterable, format each element using the given format, and then join them. The letter "j" makes good sense then, as it

Where would you indicate the separator if we use the bang notation? Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista

Chris Angelico

11:06 p.m.

On Fri, May 11, 2018 at 2:28 AM, Facundo Batista wrote:

...

2018-05-10 10:34 GMT-03:00 Chris Angelico :

...
A "!j" flag could take an iterable, format each element using the given format, and then join them. The letter "j" makes good sense then, as it

Where would you indicate the separator if we use the bang notation?

It's your proposal, you can decide what works best for you. :) I don't think there's anything quite like this, so go ahead and pick whatever you reckon makes the most sense. ChrisA

Eric V. Smith

11 May 11 May

1:26 a.m.

On 5/10/18 12:28 PM, Facundo Batista wrote:

...

2018-05-10 10:34 GMT-03:00 Chris Angelico :

...
...
Ideally, it will handle *any* iterable.

If it's to handle arbitrary iterables, it can't be the normal style of "take this string, pass it to the object's __format__ method, and let it interpret it". That's why I suggested a bang notation instead. We have some already:

Yes, I think it fits better, as it's not just a formatting, it's more an "operation"...

...
A "!j" flag could take an iterable, format each element using the given format, and then join them. The letter "j" makes good sense then, as it

Where would you indicate the separator if we use the bang notation?

You would have to wedge it in before the colon. Something like: f'{lst!j, :20}' But then you couldn't have a colon in the separator. And this would be our first conversion character to be more than a single character. I'm opposed to this proposal. Just call str.join(), or write a helper function or class (depending on what you're trying to do). It's not worth complicating what's already a complicated topic. Eric

David Mertz

1:30 a.m.

-1 on idea. Far too many edge cases that can't be handled... Or absurd complexity added to format mini-language if it tries to handle them (and still fails). On Thu, May 10, 2018, 3:57 PM Eric V. Smith wrote:

...

On 5/10/18 12:28 PM, Facundo Batista wrote:

...
2018-05-10 10:34 GMT-03:00 Chris Angelico :

...
...
Ideally, it will handle *any* iterable.

If it's to handle arbitrary iterables, it can't be the normal style of "take this string, pass it to the object's __format__ method, and let it interpret it". That's why I suggested a bang notation instead. We have some already:

Yes, I think it fits better, as it's not just a formatting, it's more an "operation"...

...
A "!j" flag could take an iterable, format each element using the given format, and then join them. The letter "j" makes good sense then, as it

Where would you indicate the separator if we use the bang notation?

You would have to wedge it in before the colon. Something like:

f'{lst!j, :20}'

But then you couldn't have a colon in the separator. And this would be our first conversion character to be more than a single character.

I'm opposed to this proposal. Just call str.join(), or write a helper function or class (depending on what you're trying to do). It's not worth complicating what's already a complicated topic.

Eric _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Raymond Hettinger

10 May 10 May

9:05 a.m.

On May 9, 2018, at 7:39 AM, Facundo Batista wrote:

...

This way, I could do:

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

...

What do you think?

That is an inspired idea. I like it :-) Raymond

Serhiy Storchaka

11 May 11 May

12:10 a.m.

09.05.18 15:39, Facundo Batista пише:

...

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

In the case of the list of book or article authors it would be better to get "John, Mary and Estela" or "John, Mary, and Estela". In other cases "John, Mary & Estela" can be more appropriate. I mean that in real case you will need to use an external function that implements more complex algorithm for formatting a list.

Antoine Pitrou

27 Jun 27 Jun

2:50 p.m.

On Wed, 9 May 2018 09:39:08 -0300 Facundo Batista wrote:

...

This way, I could do:

...
...
...
authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela'

In this case the join can be made in the format yes, but this proposal would be very useful when the info to format comes inside a structure together with other stuff, like...

...
...
...
info = { ... 'title': "A book", ... 'price': Decimal("2.34"), ... 'authors: ["John", "Mary", "Estela"], ... } ... print("{title!r} (${price}) by {authors:, j}".format(**info)) "A book" ($2.34) by John, Mary, Estela

What do you think?

-1. I hate that the format language is slowly becoming more and more crufty, leading to unreadable code. Yes, typing `", ".join(...)` is more work, but at least the end result is readable. Regards Antoine.

2124

Age (days ago)

2173

Last active (days ago)

List overview

Download

29 comments

14 participants

participants (14)

Antoine Pitrou
Chris Angelico
David Mertz
Eric V. Smith
Facundo Batista
Joao S. O. Bueno
Ken Kundert
Paul Moore
Raymond Hettinger
Rhodri James
Serhiy Storchaka
Steven D'Aprano
Terry Reedy
Wolfgang Maier

Have a "j" format option for lists

tags

participants (14)