Proposal to format Django using black

classic Classic list List threaded Threaded
107 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Josh Smeaton
Whoops, you are correct. 

It did not at the time I added black to my projects, my information was quite out of date. Sorry for the wrong correction! 

On Wed, 24 Apr 2019 at 22:51, Florian Apolloner <[hidden email]> wrote:

On Wednesday, April 24, 2019 at 1:25:55 PM UTC+2, Josh Smeaton wrote:
Black does not support disabling formatting by block with a comment. It removes all choice except for the upfront choices of length and string normalisation. 

It does, "# fmt: off" and "# fmt: on" can be used

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/237eb4ea-72b5-4ba0-a484-ad545d46479c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0dC4iQvbRD_bk7U9bh1C4PG5a8s6f3npAtwkkSQfd_BAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Herman Schistad
In reply to this post by Mariusz Felisiak
On Fri, Apr 19, 2019 at 6:33 PM Mariusz Felisiak
<[hidden email]> wrote:
> I don't think that our code style is any barrier for newcomers.

As a newcomer, I can tell you that it most definitely is a barrier, at
least it is for me – for the reasons laid out in my original email :)

*

From what I can gather the following arguments have been raised against Black:

- I don't like the formatting style (double quotes, white-space, line
length, wrapping, ...)
- It produces one huge diff
- It, in some situations, produces weird formatting (lists with comments, ...)
- It doesn't solve an issue that we currently have

At the end of the day some of these arguments are just personal
opinions and comes down to preference. However a lot of
counter-arguments have been made and I'll just shortly summarize them
here:

* I don't like the formatting style
  We will never collectively agree on "the perfect" formatting and
many do not agree with the *current* formatting. The time spent having
these non value-adding discussions are not worth it, and Black would
eliminate them to
  to a large extent.

* It produces one huge diff
  There are tools to work around this (git-hyper-blame [0]), Github
has a great UI for browsing diffs and it looks like in the future it
will be possible to exclude certain commits from blame history [1].

* It, in some situations, produces weird formatting
  A lot of these can be remedied my using `--target-version=py37` as
the AST does not change in newer versions of Python. Other files (like
settings) can be either disabled from auto-formatting or we can
disable parts of the file with `# fmt: off`.

* It doesn't solve an issue that we currently have
  I, and a lot of people have expressed this too, feel like it
definitely solves a very real problem. Formatting of code delays PRs,
wastes time, makes it harder to contribute as a newcomer, is an extra
cognitive load for all of us, and produces
  loads of wasteful discussions.

I'm sure there are more arguments made too, I'm sorry if I missed
some, but these seem to be repeated most often.

*

I favor adopting the default configuration (88 width, double quotes)
in one go and just be done with it. It's not as scary as it seems and
it really just makes the day a tiny bit easier :-)

What has usually been the process of democratically deciding these
"controversial" topics in the past? From what I gather there is a
clear majority favoring Black, but I'm curious as to when and how we
decide to end the discussion either for or against.

Kind regards,

[0]: https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
[1]: https://public-inbox.org/git/20190410162409.117264-1-brho@.../

--
Herman Schistad

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAN%3DnMTywHoSuccTi4krcXwfKDNu67mg1HKfmqk0LR94vBLFa%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Tobias Kunze-2
On 19-04-25 08:24:34, Herman S wrote:
>From what I gather there is a clear majority favoring Black, […]

Please don't resort to influencing the discussion by way of presenting a
majority opinion like that. People on django-dev are generally good at
not repeating points that have been made already, or cluttering an
ongoing discussion with a lot of "+1", so there is no way to know who is
nodding along with which arguments.

Tobias

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20190425085906.mol7ok72yw2u7f6p%40cordelia.localdomain.
For more options, visit https://groups.google.com/d/optout.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Tom Forbes
so there is no way to know who is nodding along with which arguments.

That somewhat impedes the point of posting this to get consensus, and if you ascribe to that view then all mailing list discussions about project wide changes are somewhat useless, as there could be a silent majority completely against the idea being proposed?

There is a majority of people who have expressed opinions in this thread in favor of black, so he’s not necessarily trying to influence the discussion as much as pointing out a fact.

That’s not to say consensus has been reached though, judging by the number of replies here there are a lot of strong views either way.

Tom

On 25 Apr 2019, at 09:59, Tobias Kunze <[hidden email]> wrote:

On 19-04-25 08:24:34, Herman S wrote:
From what I gather there is a clear majority favoring Black, […]

Please don't resort to influencing the discussion by way of presenting a
majority opinion like that. People on django-dev are generally good at
not repeating points that have been made already, or cluttering an
ongoing discussion with a lot of "+1", so there is no way to know who is
nodding along with which arguments.

Tobias

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20190425085906.mol7ok72yw2u7f6p%40cordelia.localdomain.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/DFCA73FE-5D66-4C1D-B91F-690DD76B71F1%40tomforb.es.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

James Bennett
I like Django's style guide.

I like the *idea* of an autoformatter.

I dislike the particular mostly-unconfigurable style Black enforces, and I find that several of its rules negatively impact code readability.

So I would be -1 on applying it to Django.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-MJqE%2BxmxpBhymxaUz__6V_htE1XA-XRxZH5Uxa3WY_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Josh Smeaton
To answer the question about decision making...

Usually a decision is made if there’s reasonable consensus in the discussion or after a vote. If no clear consensus can be reached with the core team, then a decision can be escalated to the technical board for a vote. 

In the future, if the core team is dissolved in its primary capacity, consensus in the discussion rather than consensus among the core team would be the first step. 

I figure all reasonable arguments have probably been made at this stage. But there are really two questions we should be proposing. 

1. Should Django adopt an autoformatter?
2. If it should, should that autoformatter be black or something else? 

Considering the rather strong views in this thread, I’d probably recommend that a DEP is drafted for each of the above, where opinions and comments can be gathered more formally. 

On Thu, 25 Apr 2019 at 20:15, James Bennett <[hidden email]> wrote:
I like Django's style guide.

I like the *idea* of an autoformatter.

I dislike the particular mostly-unconfigurable style Black enforces, and I find that several of its rules negatively impact code readability.

So I would be -1 on applying it to Django.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-MJqE%2BxmxpBhymxaUz__6V_htE1XA-XRxZH5Uxa3WY_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0f24%3D62%3DBXD-OxgonjGpiJ13W4koaHg%2BbnwPdefzM2Baw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Curtis Maloney-2
In reply to this post by James Bennett
On 4/25/19 8:14 PM, James Bennett wrote:
> I like Django's style guide.
>
> I like the *idea* of an autoformatter.
>
> I dislike the particular mostly-unconfigurable style Black enforces, and
> I find that several of its rules negatively impact code readability.
>
> So I would be -1 on applying it to Django.
>

I think this very clearly sums up what I was going to say on this topic,
if I hadn't already.

I see the benefits [lower barrier to entry, time saving for the Fellows,
etc], but I don't believe Black is the answer.

Specifically because in my own experience with it (as well as
demonstrated in this list) there are cases where its style makes code
significantly harder to read.

And IMHO, the sole purpose of a consistent style (and thus a style
guide) is to reduce the cognitive load of humans parsing code.

--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2e34fd6f-98c7-d34f-630c-b0945d621ec5%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Aymeric Augustin
In reply to this post by Josh Smeaton
I'm writing a DEP.

-- 
Aymeric.



On 25 Apr 2019, at 13:30, Josh Smeaton <[hidden email]> wrote:

To answer the question about decision making...

Usually a decision is made if there’s reasonable consensus in the discussion or after a vote. If no clear consensus can be reached with the core team, then a decision can be escalated to the technical board for a vote. 

In the future, if the core team is dissolved in its primary capacity, consensus in the discussion rather than consensus among the core team would be the first step. 

I figure all reasonable arguments have probably been made at this stage. But there are really two questions we should be proposing. 

1. Should Django adopt an autoformatter?
2. If it should, should that autoformatter be black or something else? 

Considering the rather strong views in this thread, I’d probably recommend that a DEP is drafted for each of the above, where opinions and comments can be gathered more formally. 

On Thu, 25 Apr 2019 at 20:15, James Bennett <[hidden email]> wrote:
I like Django's style guide.

I like the *idea* of an autoformatter.

I dislike the particular mostly-unconfigurable style Black enforces, and I find that several of its rules negatively impact code readability.

So I would be -1 on applying it to Django.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/wK2PzdGNOpQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-MJqE%2BxmxpBhymxaUz__6V_htE1XA-XRxZH5Uxa3WY_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0f24%3D62%3DBXD-OxgonjGpiJ13W4koaHg%2BbnwPdefzM2Baw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1CAC7C71-01C6-4358-96FC-C41B8A1D2BE2%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Max Arnold
Once the DEP is ready, maybe it would make sense to discuss the above-mentioned concerns with Łukasz Langa? Black is quite opinionated, but Django is a well-known project in the Python ecosystem, and its weight could lead to some adjustments (or at least future stability guarantees) in black?

On Saturday, April 27, 2019 at 2:07:00 PM UTC+7, Aymeric Augustin wrote:
I'm writing a DEP.

-- 
Aymeric.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b89bdd3-765f-410e-94fc-c322158773c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Aymeric Augustin
In reply to this post by Josh Smeaton
On 14 Apr 2019, at 15:10, Josh Smeaton <[hidden email]> wrote:

Finally, there are some tricks you pick up if black fights you on some decisions. To use Berkers example:

TIME_INPUT_FORMATS = [ 
    '%H:%M:%S', # '14:30:59' 
    '%H:%M:%S.%f', # '14:30:59.000200' 
    '%H:%M', # '14:30' 


TIME_INPUT_FORMATS = ['%H:%M:%S', '%H:%M:%S.%f', '%H:%M'] # '14:30:59' 
# '14:30:59.000200' # '14:30' 

Break each individual format into its own variable, with appropriate comment, and add the variables to the list.

HMS = "%H:%M:%S"  # 14:30:59
HMSF = ".." 
HM = ".."
TIME_INPUT_FORMATS  = [HMS, HMSF, HM]

Obviously just an example, but something to keep in mind.

FWIW there's also this possibility:

TIME_INPUT_FORMATS = [ 
    # '14:30:59' 
    '%H:%M:%S',
    # '14:30:59.000200'
    '%H:%M:%S.%f',
    # '14:30'
    '%H:%M',
]

-- 
Aymeric.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/37026972-CFCF-45D7-8903-958C31719224%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Aymeric Augustin
In reply to this post by Herman Schistad
Hello,

Here's my attempt at summarizing the conversation in a DEP: https://github.com/django/deps/pull/55.


Please let me know if I missed or represented unfairly some ideas!

Best regards,

-- 
Aymeric.

PS: while I'm eager to listen to feedback and iterate on this draft, I would also prefer if this DEP didn't turn into a novel, so let's avoid going into every detail and trust the implementation team to do a good job — thank you :-)


On 13 Apr 2019, at 13:52, Herman S <[hidden email]> wrote:

Hi.

I propose that Django starts using 'black' [0] to auto-format all Python code.
For those unfamiliar with 'black' I recommend reading the the projects README.
The short version: it aims to reduce bike-shedding and non value-adding
discussions; saving time reviewing code; and making the barrier to entry lower
by taking some uncompromissing choices with regards to formatting.  This is
similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.

Personally I first got involved contributing to Django couple of weeks back,
and from anecdotal experience I can testify to how 'formatting of code' creates
a huge barrier for entry. My PR at the time went multiple times back and forth
tweaking formatting. Before this, I had to research the style used by exploring
the docs at length and reading at least 10-20 different source – and even those
were not always consistent. At the end of the day I felt like almost 50% of the
time I used on the patch was not used on actually solving the issue at hand.
Thinking about code formatting in 2019 is a mental energy better used for other
things, and it feels unnecessary that core developers on Django spend their time
"nit-picking" on these things.

I recently led the efforts to make this change where I work. We have a 200K+
LOC Django code-base with more than 30K commits. Some key take-aways: it has
drastically changed the way we work with code across teams, new engineers are
easier on-boarded, PR are more focused on architectural choices and "naming
things", existing PRs before migration had surprisingly few conflicts and were
easy to fix, hot code paths are already "blameable" and it's easy to blame a
line of code and go past the "black-commit", and lastly the migration went
without any issues or down-time.

I had some really fruitful discussions at DjangoCon Europe this week on this
very topic, and it seems we are not alone in these experiences. I would love to
hear from all of you and hope that we can land on something that will enable
*more* people to easier contribute back to this project.

I've set up how this _could_ look depending on some configurables in Black:

* Default config: https://github.com/hermansc/django/pull/1
* Line length kept at 119: https://github.com/hermansc/django/pull/3
* Line length kept at 119, no string normalization:
https://github.com/hermansc/django/pull/2

Please have a look at the Black documentation. It explains the benefits better
than I possibly could do here.

With kind regards,
Herman Schistad

[0]: https://github.com/ambv/black

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ECC90690-D27E-40D3-B69E-765D988A1690%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Markus Holtermann
👏 Aymeric. Thank you!

On Sun, Apr 28, 2019, at 4:51 PM, Aymeric Augustin wrote:

> Hello,
>
> Here's my attempt at summarizing the conversation in a DEP:
> https://github.com/django/deps/pull/55.
>
> It's easier to read as a rich diff:
> https://github.com/django/deps/pull/55/files?short_path=95a1a7b#diff-95a1a7b430e2608b84f5c834fd6c258c
>
> Please let me know if I missed or represented unfairly some ideas!
>
> Best regards,
>
> --
> Aymeric.
>
> PS: while I'm eager to listen to feedback and iterate on this draft, I
> would also prefer if this DEP didn't turn into a novel, so let's avoid
> going into every detail and trust the implementation team to do a good
> job — thank you :-)
>
>
> > On 13 Apr 2019, at 13:52, Herman S <[hidden email]> wrote:
> >
> > Hi.
> >
> > I propose that Django starts using 'black' [0] to auto-format all Python code.
> > For those unfamiliar with 'black' I recommend reading the the projects README.
> > The short version: it aims to reduce bike-shedding and non value-adding
> > discussions; saving time reviewing code; and making the barrier to entry lower
> > by taking some uncompromissing choices with regards to formatting. This is
> > similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.
> >
> > Personally I first got involved contributing to Django couple of weeks back,
> > and from anecdotal experience I can testify to how 'formatting of code' creates
> > a huge barrier for entry. My PR at the time went multiple times back and forth
> > tweaking formatting. Before this, I had to research the style used by exploring
> > the docs at length and reading at least 10-20 different source – and even those
> > were not always consistent. At the end of the day I felt like almost 50% of the
> > time I used on the patch was not used on actually solving the issue at hand.
> > Thinking about code formatting in 2019 is a mental energy better used for other
> > things, and it feels unnecessary that core developers on Django spend their time
> > "nit-picking" on these things.
> >
> > I recently led the efforts to make this change where I work. We have a 200K+
> > LOC Django code-base with more than 30K commits. Some key take-aways: it has
> > drastically changed the way we work with code across teams, new engineers are
> > easier on-boarded, PR are more focused on architectural choices and "naming
> > things", existing PRs before migration had surprisingly few conflicts and were
> > easy to fix, hot code paths are already "blameable" and it's easy to blame a
> > line of code and go past the "black-commit", and lastly the migration went
> > without any issues or down-time.
> >
> > I had some really fruitful discussions at DjangoCon Europe this week on this
> > very topic, and it seems we are not alone in these experiences. I would love to
> > hear from all of you and hope that we can land on something that will enable
> > *more* people to easier contribute back to this project.
> >
> > I've set up how this _could_ look depending on some configurables in Black:
> >
> > * Default config: https://github.com/hermansc/django/pull/1
> > * Line length kept at 119: https://github.com/hermansc/django/pull/3
> > * Line length kept at 119, no string normalization:
> > https://github.com/hermansc/django/pull/2
> >
> > Please have a look at the Black documentation. It explains the benefits better
> > than I possibly could do here.
> >
> > With kind regards,
> > Herman Schistad
> >
> > [0]: https://github.com/ambv/black
> >
> > --
> > You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> > To post to this group, send email to [hidden email].
> > Visit this group at https://groups.google.com/group/django-developers.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>  --
>  You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
>  To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
>  To post to this group, send email to
> [hidden email].
>  Visit this group at https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ECC90690-D27E-40D3-B69E-765D988A1690%40polytechnique.org <https://groups.google.com/d/msgid/django-developers/ECC90690-D27E-40D3-B69E-765D988A1690%40polytechnique.org?utm_medium=email&utm_source=footer>.
>  For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/30d2e780-316f-44e9-8da0-2b4db46e66b2%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Alexander Hill
In reply to this post by Aymeric Augustin
Hi all,

Could we do the work to make black (or another suitable formatter) apply only to a range of lines? Prettier has this feature[0], which is used by precise-commits[1] in the way we'd want to use it for Django. It takes a range of lines, expands the range to statement boundaries, and formats only those lines. This feels like a solution nearly everyone could agree on and would be an asset to the Django and broader Python community.

From my perspective, the DEP as it stands undervalues blame and Django's commit history. In PyCharm, the date, message and entire diff of the commit responsible for every line is immediately available, in the margin of the editor or with a keyboard shortcut. When it's a trivial to get to, this context is incredibly useful. Plugins for vim and other tools provide similar functionality. GitHub is pretty good in this regard too, but it really shines when integrated into your editor. Like auto-formatting, I think you don't know how good this is until it's part of your workflow.

To address the counter-arguments: the "view blame prior to this change" button in GitHub shows you the blame for the entire file before the specified commit, as opposed to the blame for the file in its current state, disregarding the specified commit. Not bad, but not quite what you want. git-hyper-blame has been raised several times, but it's non-standard, not straightforward to install, and not supported by tooling. A git patch was mentioned that incorporates hyper-blame's functionality into blame[2], which looks like it'll be great, but won't help until it's merged, released, and integrated into tooling.

Django is a mature project, which means that many, many lines have remained unchanged for years, and will continue to be attributed to the black mega-commit for many years to come.

I'm firmly -1 to globally applying black to the codebase until it can be done without breaking blame.

Alex


On Sun, Apr 28, 2019 at 10:51 PM Aymeric Augustin <[hidden email]> wrote:
Hello,

Here's my attempt at summarizing the conversation in a DEP: https://github.com/django/deps/pull/55.


Please let me know if I missed or represented unfairly some ideas!

Best regards,

-- 
Aymeric.

PS: while I'm eager to listen to feedback and iterate on this draft, I would also prefer if this DEP didn't turn into a novel, so let's avoid going into every detail and trust the implementation team to do a good job — thank you :-)


On 13 Apr 2019, at 13:52, Herman S <[hidden email]> wrote:

Hi.

I propose that Django starts using 'black' [0] to auto-format all Python code.
For those unfamiliar with 'black' I recommend reading the the projects README.
The short version: it aims to reduce bike-shedding and non value-adding
discussions; saving time reviewing code; and making the barrier to entry lower
by taking some uncompromissing choices with regards to formatting.  This is
similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.

Personally I first got involved contributing to Django couple of weeks back,
and from anecdotal experience I can testify to how 'formatting of code' creates
a huge barrier for entry. My PR at the time went multiple times back and forth
tweaking formatting. Before this, I had to research the style used by exploring
the docs at length and reading at least 10-20 different source – and even those
were not always consistent. At the end of the day I felt like almost 50% of the
time I used on the patch was not used on actually solving the issue at hand.
Thinking about code formatting in 2019 is a mental energy better used for other
things, and it feels unnecessary that core developers on Django spend their time
"nit-picking" on these things.

I recently led the efforts to make this change where I work. We have a 200K+
LOC Django code-base with more than 30K commits. Some key take-aways: it has
drastically changed the way we work with code across teams, new engineers are
easier on-boarded, PR are more focused on architectural choices and "naming
things", existing PRs before migration had surprisingly few conflicts and were
easy to fix, hot code paths are already "blameable" and it's easy to blame a
line of code and go past the "black-commit", and lastly the migration went
without any issues or down-time.

I had some really fruitful discussions at DjangoCon Europe this week on this
very topic, and it seems we are not alone in these experiences. I would love to
hear from all of you and hope that we can land on something that will enable
*more* people to easier contribute back to this project.

I've set up how this _could_ look depending on some configurables in Black:

* Default config: https://github.com/hermansc/django/pull/1
* Line length kept at 119: https://github.com/hermansc/django/pull/3
* Line length kept at 119, no string normalization:
https://github.com/hermansc/django/pull/2

Please have a look at the Black documentation. It explains the benefits better
than I possibly could do here.

With kind regards,
Herman Schistad

[0]: https://github.com/ambv/black

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ECC90690-D27E-40D3-B69E-765D988A1690%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BKBOKyL3Y3Hd2pFOzq_x%2BwPLKp%3D4%2BGjS9cXJddZQZv8cG-ZuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Aymeric Augustin
Hello Alex,

Could we do the work to make black (or another suitable formatter) apply only to a range of lines? Prettier has this feature[0], which is used by precise-commits[1] in the way we'd want to use it for Django. It takes a range of lines, expands the range to statement boundaries, and formats only those lines. This feels like a solution nearly everyone could agree on and would be an asset to the Django and broader Python community.

Yes, that would alleviate about half of the concerns — the other half being opposition to some style choices made by Black.

The answer to "could we do the work" is pretty much in your hands :-) If you want this to happen, put together a PoC and write DEP 9.

If I see good momentum on a credible alternative, I'm willing to put DEP 8 on standby for a few weeks.

From my perspective, the DEP as it stands undervalues blame and Django's commit history. In PyCharm, the date, message and entire diff of the commit responsible for every line is immediately available, in the margin of the editor or with a keyboard shortcut. When it's a trivial to get to, this context is incredibly useful.

This is a good point.

It's valid insofar as the last commit contains useful information by itself, which requires some luck in my experience with Django.

I triaged a few thousand tickets between 2011 and 2014. Back then many git blame expeditions required jumping through several commits. If I needed git blame to understand the code, often it meant that two different people touched the same piece of code and left an inconsistency, so the last commit by itself wasn't going to give me the answer. I don't think this changed since then.

That said, I don't have the kind of setup you describe, and if I had, I would certainly lean on git blame more heavily.

To address the counter-arguments: the "view blame prior to this change" button in GitHub shows you the blame for the entire file before the specified commit, as opposed to the blame for the file in its current state, disregarding the specified commit. Not bad, but not quite what you want. git-hyper-blame has been raised several times, but it's non-standard, not straightforward to install, and not supported by tooling. A git patch was mentioned that incorporates hyper-blame's functionality into blame[2], which looks like it'll be great, but won't help until it's merged, released, and integrated into tooling.

Yes, let's be honest: DEP 8 doesn't have a much better argument than "oh well we'll survive with the tools we have".

I'm firmly -1 to globally applying black to the codebase until it can be done without breaking blame.

By framing the problem in that way, you imply that git blame currently works and that it will stop working if Black is applied to the codebase. Both are false :-) Rather, we'd be trading one problem for another :

- The current problem is random small reformattings, which I referred to as "a steady stream of pollution" in DEP 8 and which I experienced very regularly when I was an active contributor ; this is not a theoretical issue ;
- The new problem if DEP 8 goes live is the Big Commit ;

I find it easier to determine that a commit isn't significant if the message says "Reformat Django with Black" so the new problem could be easier to deal with than the current problem.

Best regards,

-- 
Aymeric.



On 29 Apr 2019, at 05:11, Alexander Hill <[hidden email]> wrote:

Hi all,

Could we do the work to make black (or another suitable formatter) apply only to a range of lines? Prettier has this feature[0], which is used by precise-commits[1] in the way we'd want to use it for Django. It takes a range of lines, expands the range to statement boundaries, and formats only those lines. This feels like a solution nearly everyone could agree on and would be an asset to the Django and broader Python community.

From my perspective, the DEP as it stands undervalues blame and Django's commit history. In PyCharm, the date, message and entire diff of the commit responsible for every line is immediately available, in the margin of the editor or with a keyboard shortcut. When it's a trivial to get to, this context is incredibly useful. Plugins for vim and other tools provide similar functionality. GitHub is pretty good in this regard too, but it really shines when integrated into your editor. Like auto-formatting, I think you don't know how good this is until it's part of your workflow.

To address the counter-arguments: the "view blame prior to this change" button in GitHub shows you the blame for the entire file before the specified commit, as opposed to the blame for the file in its current state, disregarding the specified commit. Not bad, but not quite what you want. git-hyper-blame has been raised several times, but it's non-standard, not straightforward to install, and not supported by tooling. A git patch was mentioned that incorporates hyper-blame's functionality into blame[2], which looks like it'll be great, but won't help until it's merged, released, and integrated into tooling.

Django is a mature project, which means that many, many lines have remained unchanged for years, and will continue to be attributed to the black mega-commit for many years to come.

I'm firmly -1 to globally applying black to the codebase until it can be done without breaking blame.

Alex


On Sun, Apr 28, 2019 at 10:51 PM Aymeric Augustin <[hidden email]> wrote:
Hello,

Here's my attempt at summarizing the conversation in a DEP: https://github.com/django/deps/pull/55.


Please let me know if I missed or represented unfairly some ideas!

Best regards,

-- 
Aymeric.

PS: while I'm eager to listen to feedback and iterate on this draft, I would also prefer if this DEP didn't turn into a novel, so let's avoid going into every detail and trust the implementation team to do a good job — thank you :-)


On 13 Apr 2019, at 13:52, Herman S <[hidden email]> wrote:

Hi.

I propose that Django starts using 'black' [0] to auto-format all Python code.
For those unfamiliar with 'black' I recommend reading the the projects README.
The short version: it aims to reduce bike-shedding and non value-adding
discussions; saving time reviewing code; and making the barrier to entry lower
by taking some uncompromissing choices with regards to formatting.  This is
similar to tools such as 'gofmt' for Go and 'prettier' for Javascript.

Personally I first got involved contributing to Django couple of weeks back,
and from anecdotal experience I can testify to how 'formatting of code' creates
a huge barrier for entry. My PR at the time went multiple times back and forth
tweaking formatting. Before this, I had to research the style used by exploring
the docs at length and reading at least 10-20 different source – and even those
were not always consistent. At the end of the day I felt like almost 50% of the
time I used on the patch was not used on actually solving the issue at hand.
Thinking about code formatting in 2019 is a mental energy better used for other
things, and it feels unnecessary that core developers on Django spend their time
"nit-picking" on these things.

I recently led the efforts to make this change where I work. We have a 200K+
LOC Django code-base with more than 30K commits. Some key take-aways: it has
drastically changed the way we work with code across teams, new engineers are
easier on-boarded, PR are more focused on architectural choices and "naming
things", existing PRs before migration had surprisingly few conflicts and were
easy to fix, hot code paths are already "blameable" and it's easy to blame a
line of code and go past the "black-commit", and lastly the migration went
without any issues or down-time.

I had some really fruitful discussions at DjangoCon Europe this week on this
very topic, and it seems we are not alone in these experiences. I would love to
hear from all of you and hope that we can land on something that will enable
*more* people to easier contribute back to this project.

I've set up how this _could_ look depending on some configurables in Black:

* Default config: https://github.com/hermansc/django/pull/1
* Line length kept at 119: https://github.com/hermansc/django/pull/3
* Line length kept at 119, no string normalization:
https://github.com/hermansc/django/pull/2

Please have a look at the Black documentation. It explains the benefits better
than I possibly could do here.

With kind regards,
Herman Schistad

[0]: https://github.com/ambv/black

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAN%3DnMTx0EE5WfXuccv_e3MBuCxp9u_pAV_ow5MxNST6MptTDBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ECC90690-D27E-40D3-B69E-765D988A1690%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BKBOKyL3Y3Hd2pFOzq_x%2BwPLKp%3D4%2BGjS9cXJddZQZv8cG-ZuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0D72AAEC-4A7B-472D-B2EC-5F6506722079%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Carlton Gibson-3
In reply to this post by Alexander Hill
Hi Alex. 

So I use git blame on Django a lot: a new ticket comes in, I have no idea at all how to triage it so I need to look at the history to make a sensible decision. I use git blame to find the commit, to find the original ticket, in which there's a discussion, which 🤞 explains why things are as they are. (Mostly...)

But we're already at the the point where more times than not I need to skip multiple commits to get back to the original decision. 

Look at `master` right now. https://github.com/django/django/commits/master
(Screenshot attached) 

The last three commits from this morning are all "tidy-ups" that obscure the history. This is typical. Rarely now is there such a old block that hasn't been adjusted at all. So it's normal to have to jump commits. 

A big Black commit will add to this. (It's the concern I do have.) But it's not a game changer. It's just more of the same. I'm pretty sure it's the motivation needed to up my git blame foo to the next level, at which point I'll likely save time ironically. 

For this reason, weighed against the benefits, I don't think the git history should be a blocker. I hope that makes sense. 

Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/01b0bcb5-3540-455e-b06e-d16ad2ec04d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Screenshot 2019-04-29 09.02.54.png (54K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

pavel.tyslacki
Just short hint about git blame.

Github has functionality to get more deep git blame: https://help.github.com/en/articles/tracking-changes-in-a-file, more over pycharm has similar functionality too (potentially another editors and IDE have too). I suggest that git blame is more tooling issue, not changes approach, because for another refactoring and active development you can have the same issue with git blame.

Regards
Paveł

On Mon, 29 Apr 2019 at 10:12, Carlton Gibson <[hidden email]> wrote:
Hi Alex. 

So I use git blame on Django a lot: a new ticket comes in, I have no idea at all how to triage it so I need to look at the history to make a sensible decision. I use git blame to find the commit, to find the original ticket, in which there's a discussion, which 🤞 explains why things are as they are. (Mostly...)

But we're already at the the point where more times than not I need to skip multiple commits to get back to the original decision. 

(Screenshot attached) 

The last three commits from this morning are all "tidy-ups" that obscure the history. This is typical. Rarely now is there such a old block that hasn't been adjusted at all. So it's normal to have to jump commits. 

A big Black commit will add to this. (It's the concern I do have.) But it's not a game changer. It's just more of the same. I'm pretty sure it's the motivation needed to up my git blame foo to the next level, at which point I'll likely save time ironically. 

For this reason, weighed against the benefits, I don't think the git history should be a blocker. I hope that makes sense. 

Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/01b0bcb5-3540-455e-b06e-d16ad2ec04d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL6gfQZ6eAtHntmPh%3DxR-Raf7ro4wM%3DbCpny7nH_AMmHdj91ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

J. Pic
If you don't want to break git blame then I suppose you could create a branch to replay each commit with black.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op18mCH1Gxjt2%2BKmsBjrq1gxE%2BgUUs8NNu_Y9dRG%3Dbij%3DjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Laurens A. Bosscher
In reply to this post by Carlton Gibson-3
The Chrome team fixed this issue with git-hyper-blame: https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html

That could be a solution that would work for Django. IDE support for git-hyper-blame is lacking (at the moment) but might improve in the future.

Op maandag 29 april 2019 09:12:00 UTC+2 schreef Carlton Gibson:
Hi Alex. 

So I use git blame on Django a lot: a new ticket comes in, I have no idea at all how to triage it so I need to look at the history to make a sensible decision. I use git blame to find the commit, to find the original ticket, in which there's a discussion, which 🤞 explains why things are as they are. (Mostly...)

But we're already at the the point where more times than not I need to skip multiple commits to get back to the original decision. 

Look at `master` right now. <a href="https://github.com/django/django/commits/master" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fcommits%2Fmaster\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG571XYBHon69BsCOVsycpkXtSmow&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fcommits%2Fmaster\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG571XYBHon69BsCOVsycpkXtSmow&#39;;return true;">https://github.com/django/django/commits/master
(Screenshot attached) 

The last three commits from this morning are all "tidy-ups" that obscure the history. This is typical. Rarely now is there such a old block that hasn't been adjusted at all. So it's normal to have to jump commits. 

A big Black commit will add to this. (It's the concern I do have.) But it's not a game changer. It's just more of the same. I'm pretty sure it's the motivation needed to up my git blame foo to the next level, at which point I'll likely save time ironically. 

For this reason, weighed against the benefits, I don't think the git history should be a blocker. I hope that makes sense. 

Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/54da6b8a-fac4-4229-a124-00822d5626cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

J. Pic
Also note that even for people that don't use an IDE, they might like when GitHub's blame feature work, so that would also be a pro for rewriting the git history rather than creating a new commit for the code rewrite.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6Op1_5qkcs-44eSM6CxukDnYdq4VmeCYFDvnoFf7EyOTQTxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to format Django using black

Christian González
In reply to this post by Laurens A. Bosscher

Am 30.04.19 um 14:28 schrieb 'Laurens A. Bosscher' via Django developers
(Contributions to Django itself):
> The Chrome team fixed this issue with
> git-hyper-blame: https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
>
>
> That could be a solution that would work for Django. IDE support for
> git-hyper-blame is lacking (at the moment) but might improve in the
> future.

I made a feature request for git itself, and they told me this is
already in the works *within* git dev:

https://public-inbox.org/git/20190410162409.117264-1-brho@.../

So on the long run, no need for git-hyper-blame.

Christian

--
Dr. Christian González
https://nerdocs.at

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/74e4842c-24fa-6055-2b1e-d70b42153b69%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.

pEpkey.asc (2K) Download Attachment
123456