Hello Matthew,
I understand the suggestion, however, I’m afraid it priorizes the needs of the
wrong audience. Experienced developers or teams who care about docstrings and
pylint can use a custom project template for this use case. Conversely,
newcomers who are still learning Django would
the current
automatically generated comments of "Create your __ here" that are
generated for each file created by manage.py startapp be replaced with
docstrings that follow the PEP 257 convention. The second line of the
specification: All modules should normally have docstring
\\//,
I'm using sphinx to document my Django apps and have an issue with
attribute docstrings.
Right now Django does not make CharFields or BooleanFields top level
attributes like FK's or m2m's. This however makes that Doc processors
cannot see the docstrings of those types.
Is
s for chopping it up are all sub-optimal; increasing the minimum
> width would decrease the number of occasions on which one might need
> to deal with this frustration. Docstrings and comments also find
> themselves cramped for space after a few indentation levels.
Being a dope and
In some cases, yes, this would be the correct thing to do. In other
cases, the line really does make the most sense as one logical unit,
and splitting to get under 80 lines in some of these cases *decreases*
readability.
> > Docstrings and comments also find
> > themselves cramped for space
Tom Tobin wrote:
> I'll accept that I'm an outlier, then; I'm also the only one at work
> who can't stand working with multiple and/or large monitors, and the
> only one who prefers quickly flipping between maximized windows for
> most apps rather than having multiple apps side-by-side. (Yeah, I
On 7/26/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > I find it hard to imagine a programmer these days who is so starved
> > for screen real estate that they couldn't handle a width of, say, 120
> > characters;
>
> Try to imagine a bit harder then. I'm in that position, for example,
> eve
> Are Django committers willing to accept patches that reformat lines within
> 80 characters?
>
> --
> Nicola Larosa -http://www.tekNico.net/
I was curious - being a 80+ line writer myself - how many lines in
trunk were currently longer than 80 chars, so I wrote a short script.
Here's what I got
On Thu, Jul 26, 2007 at 07:19:01PM +0200, Nicola Larosa wrote:
> > People seem to forget that one of the key rules in any coding guidelines
> > is "do what the existing code does" (see, e.g., the second section of
> > PEP 8). Thus, our current standards are in not in conflict with PEP 8 or
> > PEP
Sorry for unintentionally hijacking the thread originally, but Nicola
has some great
arguments in support of the 80 char limit :)
Nicola Larosa wrote
> Displaying the source code on a large screen is only one of its many uses:
> the keyword here is *interoperability*.
>
>
> You want to print
ne is so long, maybe it's doing too many things, and
should be decomposed logically, before recurring to splitting it.
Anyway, parentheses are your friend (even with long strings), but drop the
backslash.
> Docstrings and comments also find
> themselves cramped for space after a
Malcolm Tredinnick wrote:
> That being said, whilst I strongly prefer 80 character limits, I can
> handle lines being longer in circumstances, too, for all the normal
> reasons (some lines just don't break).
All lines break, and most break gracefully, unless there's an assignment
left side longer
On 7/25/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
> Adrian recently corrected some of my docstring additions [1][2], and I
> am posting this to the list so that we can get an official stance on the
> matter. I also suggest we add the decision to the "Coding style"
> section of the "Contributing"
sefulness. There are various naturally occurring bits
> of code that just don't fit onto a single 80-character line, and the
> options for chopping it up are all sub-optimal; increasing the minimum
> width would decrease the number of occasions on which one might need
> to deal wi
On 7/26/07, Andrey Khavryuchenko <[EMAIL PROTECTED]> wrote:
> "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> TT> I find it hard to imagine a programmer these days who is so starved
> TT> for screen real estate that they couldn't handle a width of, say, 120
> TT> characters; I code in Aquamacs Emacs o
On 7/26/07, Andrey Khavryuchenko <[EMAIL PROTECTED]> wrote:
> Well, I'm on my 14" Thinkpad can fit two 80-column emacs windows
> side-by-side... This increases productivity susbtatially and makes me
> dislike lines more than 79 char :)
The same here after:
s/14"/15"/
s/emacs/vim/
;-)
(c)
--
Car
e that just don't fit onto a single 80-character line, and the
> > options for chopping it up are all sub-optimal; increasing the minimum
> > width would decrease the number of occasions on which one might need
> > to deal with this frustration. Docstrings and comments also
"Tom Tobin" <[EMAIL PROTECTED]> wrote:
TT> I find it hard to imagine a programmer these days who is so starved
TT> for screen real estate that they couldn't handle a width of, say, 120
TT> characters; I code in Aquamacs Emacs on a 13" Macbook and a 15"
TT> Macbook Pro, and I come nowhere *nea
options for chopping it up are all sub-optimal; increasing the minimum
> width would decrease the number of occasions on which one might need
> to deal with this frustration. Docstrings and comments also find
> themselves cramped for space after a few indentation levels.
I like to differ o
On 7/26/07, Tom Tobin <[EMAIL PROTECTED]> wrote:
> ... increasing the minimum width would ...
Err, *maximum* width, rather. ^_^
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to
On 7/25/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> Adrian, which BDFL do we follow :)
I'm +1 to Adrian's style (descriptive, rather than prescriptive); it
feels more natural to have the docstring be a description of the given
code rather than a direct "English translation". The code itself i
character line, and the
options for chopping it up are all sub-optimal; increasing the minimum
width would decrease the number of occasions on which one might need
to deal with this frustration. Docstrings and comments also find
themselves cramped for space after a few indentation levels.
I fin
Duc Nguyen wrote:
> On a somewhat related note, is it just me or does no django core developer
> follow the "no line longer than 79 characters" note. I like using emacs
> and I have my frame width set at 80 and it bothers me to no end to have
> to scroll to see every line. Turning on line wrappi
I favor Adrian's style.
On a somewhat related note, is it just me or does no django core developer
follow the "no line longer than 79 characters" note. I like using emacs
and I have my frame width set at 80 and it bothers me to no end to have
to scroll to see every line. Turning on line wrappin
Adrian recently corrected some of my docstring additions [1][2], and I
am posting this to the list so that we can get an official stance on the
matter. I also suggest we add the decision to the "Coding style"
section of the "Contributing" documentation for consistency of future
patches, since
On 10/14/05, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Just submitted a patch that does exactly that.
> http://code.djangoproject.com/ticket/628
As of revision 878, it's an official part of Django. Thanks!
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
On 10/10/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 10/10/05, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I'd like to use doctest for testing my model classes, but the model
> > metaclass overwrites my classes docstrings. Is there any reason
On 10/10/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 10/10/05, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I'd like to use doctest for testing my model classes, but the model
> > metaclass overwrites my classes docstrings. Is there any reason
28 matches
Mail list logo
