[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-07 Thread Eric V. Smith
Eric V. Smith added the comment: After discussing this with Guido, we're going to go with a tweaked version of the '=' version of this in issue36817. So, I'm going to close this and continue the discussion there. -- resolution: -> rejected stage: patch review -> resolved status:

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-06 Thread Eric V. Smith
Eric V. Smith added the comment: See issue36817 for an alternative proposal. -- ___ Python tracker ___ ___ Python-bugs-list

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-05 Thread Eric V. Smith
Change by Eric V. Smith : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-04 Thread Eric V. Smith
Eric V. Smith added the comment: And for those who *really* want to be able to apply a format spec to the result of the entire !d expression, you can always use nested f-strings: >>> for x in [3.1415, 0.5772156649, 100]: ... print(f'{f"{x!d:.1f}":*^20}') ... ***x=3.1

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-04 Thread Eric V. Smith
Eric V. Smith added the comment: Serhiy's point about how special this is is very valid. It's so special that I can't figure out where to document it. f-strings are really only documented in Doc/reference/lexical_analysis.rst, and !d details, especially the format/repr distinction, seems

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-03 Thread Steven D'Aprano
Steven D'Aprano added the comment: > Steven: We shouldn't block this immediately useful feature from going > in for f-strings on waiting for some much broader first class access > to expressions feature. !d would be practical today. I hear you, and after giving it much more thought I

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-03 Thread Eric V. Smith
Eric V. Smith added the comment: != would be my preference, but it can't work. f'{0!=1}' is already legal. I'm not crazy about !!. I think that will be too confusing. -- ___ Python tracker

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-03 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: This conversion is very special. For all other conversions {value:!c:format_spec} is equivalent to format(conv(value), format_spec), but not this conversion. It is also specific for f-strings, and is not particularly useful in format strings. Would not

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-03 Thread Eric V. Smith
Eric V. Smith added the comment: The most recent version of the patch implements the conditional repr/format behavior. I'm pretty happy with it. Other than docs, I think this is done. I'm going to discuss it with a few more people at PyCon, then commit it. There's a slight optimization I'm

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Paul Moore
Paul Moore added the comment: > So the question is: how do you get repr by default, but allow the format spec? > > The only thing I've come up with is: > - f"{expr!d}" expands to f"expr={repr(expr)}", but > - f"{expr!d:spec} expands to f"expr={format(expr, spec)}" > > I think this is the most

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Eric V. Smith
Eric V. Smith added the comment: Re: format specs and what they apply to. The problem is that you want f"{expr!d}" to expand to f"expr={repr(expr)}". And I think you want that because it's the most useful behavior for strings. Without the repr it's not very useful for strings. But you want

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Paul Moore
Paul Moore added the comment: +1 from me. It's something I'd find useful, and it's a natural extension of the f-string syntax. > I can't decide if I'm going to allow a format specifier. The only useful interpretation IMO would be for {expr!d:fmt} to expand to expr={expr:fmt}. If you're not

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Gregory P. Smith
Gregory P. Smith added the comment: regarding issue28307 - It is not always correct to convert a %d %u %i used to render v into f'{int(v)}'. That'd lose the TypeError when v is not an integer. If you are looking at making internal private conversions for the purposes of that issue, I think

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: To implement converting printf-style string formatting into f-string expressions (see issue28307) I need to add new convertors: 'd': int(x) where x is a number, used for %d, %u, %i 'i': operator.index(i), used for %x, %o, %b 'f': float(x) where x is a

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Eric V. Smith
Change by Eric V. Smith : -- keywords: +patch pull_requests: +12976 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Karthikeyan Singaravelan
Karthikeyan Singaravelan added the comment: !d sounds good and makes teaching easier. Adding additional symbol sort of clutters the experience in f'{name!!}'. I think it will be a good thing to have it in 3.8 since it serves one of the common things in debugging f'name = {name}' and perhaps

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Gregory P. Smith
Gregory P. Smith added the comment: hallway conversation with Eric: neither of us have immediately good thoughts on a spelling other than !d for this. !! or != seem esoteric and/or unparseable, using a capital letter like !D could be new and odd and might be useful to differentiate types

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Gregory P. Smith
Gregory P. Smith added the comment: Steven: We shouldn't block this immediately useful feature from going in for f-strings on waiting for some much broader first class access to expressions feature. !d would be practical today. -- ___ Python

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Gregory P. Smith
Gregory P. Smith added the comment: for reference, the discourse thread: https://discuss.python.org/t/f-string-debug-conversion/99/14 -- nosy: +gregory.p.smith ___ Python tracker

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Karthikeyan Singaravelan
Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Andy Dirnberger
Change by Andy Dirnberger : -- nosy: +dirn ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Eric V. Smith
Eric V. Smith added the comment: I support a general mechanism. But I think that if it's much more than the 2 characters that this would take, then I don't want to use it for f-strings. The whole point here (as with all f-string features) is a concise way to get the string you're after.

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Steven D'Aprano
Steven D'Aprano added the comment: On Thu, May 02, 2019 at 11:40:45AM +, Eric V. Smith wrote: > > New submission from Eric V. Smith : > > I originally propsed this here: > https://mail.python.org/pipermail/python-ideas/2018-October/053956.html, and > there has also been some discussion

[issue36774] f-strings: Add a !d conversion for ease of debugging

2019-05-02 Thread Eric V. Smith
New submission from Eric V. Smith : I originally propsed this here: https://mail.python.org/pipermail/python-ideas/2018-October/053956.html, and there has also been some discussion on discourse. The proposal is to add a !d "type conversion" to f-strings, to make for simpler "print-based