unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#29003: 25.3; Docstring from PEP 257 is filled incorrectly by Emacs
@ 2017-10-26  2:08 Radon Rosborough
  2017-10-26 19:03 ` Charles A. Roelli
  0 siblings, 1 reply; 6+ messages in thread
From: Radon Rosborough @ 2017-10-26  2:08 UTC (permalink / raw)
  To: 29003

I recently noticed that Emacs fills an example docstring given [1] in
PEP 257 incorrectly. With `python-fill-docstring-style' at its default
value of `pep-257', the following code sample:

    def complex(real=0.0, imag=0.0):
        """Form a complex number.

        Keyword arguments:
        real -- the real part (default 0.0)
        imag -- the imaginary part (default 0.0)
        """
        if imag == 0.0 and real == 0.0:
            return complex_zero
        ...

is filled to:

    def complex(real=0.0, imag=0.0):
        """Form a complex number.

        Keyword arguments: real -- the real part (default 0.0) imag -- the
        imaginary part (default 0.0)

        """
        if imag == 0.0 and real == 0.0:
            return complex_zero
        ...

There are two issues here: the extra newline added, and the unwrapping
of the keyword arguments. The extra newline can be suppressed by
changing the value of `python-fill-docstring-style', but the keyword
argument unwrapping does not appear to be suppressible. This seems
erroneous to me since the value of `python-fill-docstring' would suggest
PEP 257 compliance, i.e. the examples given in PEP 257 should not be a
affected by wrapping. (I also checked out the third-party package
`python-docstring' [2], and it has the same behavior.)





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#29003: 25.3; Docstring from PEP 257 is filled incorrectly by Emacs
  2017-10-26  2:08 bug#29003: 25.3; Docstring from PEP 257 is filled incorrectly by Emacs Radon Rosborough
@ 2017-10-26 19:03 ` Charles A. Roelli
  2017-10-26 19:23   ` Radon Rosborough
  0 siblings, 1 reply; 6+ messages in thread
From: Charles A. Roelli @ 2017-10-26 19:03 UTC (permalink / raw)
  To: Radon Rosborough; +Cc: 29003

>        Keyword arguments:
>        real -- the real part (default 0.0)
>        imag -- the imaginary part (default 0.0)

I think all Emacs fill commands will fill this as one continous line,
unless you make the newlines between these lines "hard", as with M-x
use-hard-newlines (which is actually a minor mode, I think).





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#29003: 25.3; Docstring from PEP 257 is filled incorrectly by Emacs
  2017-10-26 19:03 ` Charles A. Roelli
@ 2017-10-26 19:23   ` Radon Rosborough
  2017-10-26 19:41     ` Charles A. Roelli
  2019-11-11  2:43     ` Stefan Kangas
  0 siblings, 2 replies; 6+ messages in thread
From: Radon Rosborough @ 2017-10-26 19:23 UTC (permalink / raw)
  To: Charles A. Roelli; +Cc: 29003

> I think all Emacs fill commands will fill this as one continous
> line,

As it currently stands, yes. That doesn't have to be the case,
however. For example, package `python-docstring' can understand reST
syntax, so that:

    def example_function():
        """Initialize engine.

        :param holes: Number of holes.
        :param rounds: Number of rounds.
        :param colors: Number of colors.

        :returns: Game engine instance.
        """
        pass

is not modified when filled. The question is whether the example given
by PEP 257 should be considered "standard" syntax for introducing
keyword arguments, and whether such syntax should be supported by
Emacs in a similar way to how `python-docstring' supports reST syntax.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#29003: 25.3; Docstring from PEP 257 is filled incorrectly by Emacs
  2017-10-26 19:23   ` Radon Rosborough
@ 2017-10-26 19:41     ` Charles A. Roelli
  2019-11-11  2:43     ` Stefan Kangas
  1 sibling, 0 replies; 6+ messages in thread
From: Charles A. Roelli @ 2017-10-26 19:41 UTC (permalink / raw)
  To: Radon Rosborough; +Cc: 29003

It would be great if the example given was standard practice, but that
doesn't seem so.  The example also doesn't show how you might document
standard key arguments (without a default), which would be vital in
everyday usage.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#29003: 25.3; Docstring from PEP 257 is filled incorrectly by Emacs
  2017-10-26 19:23   ` Radon Rosborough
  2017-10-26 19:41     ` Charles A. Roelli
@ 2019-11-11  2:43     ` Stefan Kangas
  2021-11-30 14:56       ` bug#29003: [python.el] " Lars Ingebrigtsen
  1 sibling, 1 reply; 6+ messages in thread
From: Stefan Kangas @ 2019-11-11  2:43 UTC (permalink / raw)
  To: Radon Rosborough; +Cc: 29003, Charles A. Roelli

Radon Rosborough <radon.neon@gmail.com> writes:

>> I think all Emacs fill commands will fill this as one continous
>> line,
>
> As it currently stands, yes. That doesn't have to be the case,
> however. For example, package `python-docstring' can understand reST
> syntax, so that:
>
>     def example_function():
>         """Initialize engine.
>
>         :param holes: Number of holes.
>         :param rounds: Number of rounds.
>         :param colors: Number of colors.
>
>         :returns: Game engine instance.
>         """
>         pass
>
> is not modified when filled. The question is whether the example given
> by PEP 257 should be considered "standard" syntax for introducing
> keyword arguments, and whether such syntax should be supported by
> Emacs in a similar way to how `python-docstring' supports reST syntax.

I think this should ideally be supported by Emacs, but it should be
configurable and disabled by default.

Best regards,
Stefan Kangas





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#29003: [python.el] Docstring from PEP 257 is filled incorrectly by Emacs
  2019-11-11  2:43     ` Stefan Kangas
@ 2021-11-30 14:56       ` Lars Ingebrigtsen
  0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-11-30 14:56 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 29003, Radon Rosborough, Charles A. Roelli

Stefan Kangas <stefan@marxist.se> writes:

    > > > def complex(real=0.0, imag=0.0):
    > > >     """Form a complex number.
    > > > 
    > > >     Keyword arguments:
    > > >     real -- the real part (default 0.0)
    > > >     imag -- the imaginary part (default 0.0)
    > > >     """
    > > >     if imag == 0.0 and real == 0.0:
    > > >         return complex_zero
    > > >     ...

[...]

>> is not modified when filled. The question is whether the example given
>> by PEP 257 should be considered "standard" syntax for introducing
>> keyword arguments, and whether such syntax should be supported by
>> Emacs in a similar way to how `python-docstring' supports reST syntax.
>
> I think this should ideally be supported by Emacs, but it should be
> configurable and disabled by default.

I think introducing these kinds of semantics in doc strings is
inherently brittle (unless really well-defined).  For instance,

      If this is a doc string, and then I
      pause -- using a double dash for a
      pause is common -- then we'd be filling
      things differently.

So I don't think changing the pep-257 style would be appropriate, and I
think adding a user option for this wouldn't receive much use.  So I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-11-30 14:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-26  2:08 bug#29003: 25.3; Docstring from PEP 257 is filled incorrectly by Emacs Radon Rosborough
2017-10-26 19:03 ` Charles A. Roelli
2017-10-26 19:23   ` Radon Rosborough
2017-10-26 19:41     ` Charles A. Roelli
2019-11-11  2:43     ` Stefan Kangas
2021-11-30 14:56       ` bug#29003: [python.el] " Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).