Larry Hastings <[email protected]> added the comment:
> I think that !f is not needed. You can use repr by default only when
> no format spec is specified, and add explicit !r if you want to use
> repr with the format spec.
Actually that's how !d worked. We changed the behavior because it was too
"magical". We need to keep the f-strings format spec simple so it was easier
to remember. I for one already have difficulty remembering how f-string
formatting works, I don't want to make add even more complications.
In the current proposal, the special syntax must be specified in a particular
order, and the order is easy to remember because information always flows from
left-to-right. The "=" must come before the "!" and/or the ":", and the "!"
must come before the ":". Like so:
f'{foo
=
!s
:20}'
Modification information strictly flows from left to right:
* The = changes the "conversion function" to repr, but then you can override
the conversion function with !.
* The : format spec runs __format__ on the stuff to its left; if you're using
the "format" conversion function, it applies the spec directly, otherwise it
calls format with that spec to the output (the string) you got from the
conversion function.
If we made the default conversion function when using = dependent on the
presence or absence of the format spec, now we have information flowing to the
left, all the way from the end to the beginning. Eric and I agree: this is too
magical and too hard to remember. We want to keep it simple.
(True story: Eric had the !d implementation already done and ready for checkin.
When he changed it to this = syntax he actually mostly *threw out* code,
because this way is simpler and more regular. Hopefully you're thinking "well
THAT sounds nice!"--we agree.)
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue36817>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
