Minor inconvenience: f-string not recognized as docstring
Hello, Currently, a f-string is not recognized as a docstring:
class C: f"foo" C.__doc__
This means you need to use a (admittedly easy) workaround:
Shouldn't the former be allowed for convenience? Regards Antoine.
Constant f-strings (those without substitutions) as doc strings used to work, since the compiler turns them into normal strings. I can't find exactly where it was removed, but there was definitely discussion about it. See https://bugs.python.org/issue28739 for at least part of the discussion. Eric On 1/11/2022 8:41 AM, Antoine Pitrou wrote:
I personally think F-strings should not be usable as docstrings. If you want a dynamically calculated docstring you should assign it dynamically, not smuggle it in using a string-like expression. We don't allow "blah {x} blah".format(x=1) as a docstring either, not "foo %s bar" % x. On Tue, Jan 11, 2022 at 8:12 AM Antoine Pitrou <antoine@python.org> wrote:
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Tue, Jan 11, 2022 at 10:29 AM Guido van Rossum <guido@python.org> wrote:
Agreed. If we wanted to remove the wart of constant f-strings happening to work as an implementation detail in this context, that *could* be made into a warning. But that kind of check may be best left to a linter for *all* of these dynamic situations that don't wind up populating __doc__. -gps
On Wed, 12 Jan 2022 at 00:12, Eric V. Smith <eric@trueblade.com> wrote:
Having something that looks like it sets the docstring, but silently doesn't is very surprising, though. Linters can warn about this, but linters are not a universal fix, and this is something that superficially looks entirely reasonable. -- Neil Muller drnlmuller@gmail.com
On Wed, Jan 12, 2022 at 2:58 AM Neil Muller <drnlmuller+python@gmail.com> wrote:
While f-strings in class scope could theoretically be valid docstrings a lot of the time, the equivalent situation for function docstrings is much less positive. A function like this the one below obviously problematic, since the f-string value is not a compile-time constant: def foo(x): f"is this a docstring? x is {x}" I'm pretty sure f-strings cannot be used as docstrings in other contexts because of how broken they'd be in functions. -- Steven Barker
On Thu, 13 Jan 2022 at 02:31, Steven Barker <blckknght@gmail.com> wrote:
I don't have a horse in the race of whether this should be allowed or not for constant f-strings. I do however believe that having something like the example given previously where the code doesn't do what it appears to do, by silently not setting the docstring without giving a warning, is bad behaviour. -- Neil Muller drnlmuller@gmail.com
Guido van Rossum wrote:
Nor, last I checked, even "string1" + "string2", even though the result is a compile-time string in the appropriate location. I think all of these should be allowed, but I'll grant that annotations reduce the need. I'll even admit that scoping issues make the interpolating versions error prone, and the UI to clear that up may be more of a hassle than it is worth. -jJ
Constant f-strings (those without substitutions) as doc strings used to work, since the compiler turns them into normal strings. I can't find exactly where it was removed, but there was definitely discussion about it. See https://bugs.python.org/issue28739 for at least part of the discussion. Eric On 1/11/2022 8:41 AM, Antoine Pitrou wrote:
I personally think F-strings should not be usable as docstrings. If you want a dynamically calculated docstring you should assign it dynamically, not smuggle it in using a string-like expression. We don't allow "blah {x} blah".format(x=1) as a docstring either, not "foo %s bar" % x. On Tue, Jan 11, 2022 at 8:12 AM Antoine Pitrou <antoine@python.org> wrote:
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
On Tue, Jan 11, 2022 at 10:29 AM Guido van Rossum <guido@python.org> wrote:
Agreed. If we wanted to remove the wart of constant f-strings happening to work as an implementation detail in this context, that *could* be made into a warning. But that kind of check may be best left to a linter for *all* of these dynamic situations that don't wind up populating __doc__. -gps
On Wed, 12 Jan 2022 at 00:12, Eric V. Smith <eric@trueblade.com> wrote:
Having something that looks like it sets the docstring, but silently doesn't is very surprising, though. Linters can warn about this, but linters are not a universal fix, and this is something that superficially looks entirely reasonable. -- Neil Muller drnlmuller@gmail.com
On Wed, Jan 12, 2022 at 2:58 AM Neil Muller <drnlmuller+python@gmail.com> wrote:
While f-strings in class scope could theoretically be valid docstrings a lot of the time, the equivalent situation for function docstrings is much less positive. A function like this the one below obviously problematic, since the f-string value is not a compile-time constant: def foo(x): f"is this a docstring? x is {x}" I'm pretty sure f-strings cannot be used as docstrings in other contexts because of how broken they'd be in functions. -- Steven Barker
On Thu, 13 Jan 2022 at 02:31, Steven Barker <blckknght@gmail.com> wrote:
I don't have a horse in the race of whether this should be allowed or not for constant f-strings. I do however believe that having something like the example given previously where the code doesn't do what it appears to do, by silently not setting the docstring without giving a warning, is bad behaviour. -- Neil Muller drnlmuller@gmail.com
Guido van Rossum wrote:
Nor, last I checked, even "string1" + "string2", even though the result is a compile-time string in the appropriate location. I think all of these should be allowed, but I'll grant that annotations reduce the need. I'll even admit that scoping issues make the interpolating versions error prone, and the UI to clear that up may be more of a hassle than it is worth. -jJ
participants (9)
-
Antoine Pitrou -
Brett Cannon -
Eric V. Smith -
Gregory P. Smith -
Guido van Rossum -
Jim J. Jewett -
Neil Muller -
Steve Holden -
Steven Barker