Re: Proposal to format Django using black

> > 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. Wouldn't it have

Re: Proposal to format Django using black

On Thursday, May 2, 2019 at 6:15:50 PM UTC+2, matthew.pava wrote: > > Just a thought: If Django were to adopt black (and I'm not saying it > should), shouldn't it wait until it is out of the beta classification? > Please read the dep:

RE: Proposal to format Django using black

: Thursday, May 2, 2019 11:06 AM To: Django developers Subject: Re: Proposal to format Django using black The primary author of Black, Łukasz Langa, just announced that Black was moved under the PSF umbrella: https://twitter.com/llanga/status/1123980466292445190 I updated the link in the DEP-8

Re: Proposal to format Django using black

The primary author of Black, Łukasz Langa, just announced that Black was moved under the PSF umbrella: https://twitter.com/llanga/status/1123980466292445190 I updated the link in the DEP-8 accordingly to https://github.com/python/black/ /Markus On Wed, May 1, 2019, at 2:32 AM, Andrew Godwin

Re: Proposal to format Django using black

Hi all, As per the DEP process, I have merged DEP 8, Formatting Code With Black, into the DEP repo as a draft. This doesn't mean it's decided yet - any DEP that meets quality requirements gets merged as a draft - but it means that we're one step closer to doing so. What follows is further

Re: Proposal to format Django using black

Well, this thread is a very good example of Parkinson's law of triviality . –– Jacob -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from

Re: Proposal to format Django using black

So this thread just passed the 100 message mark... I wish we could redirect some of that energy to things that actually matter to end users... Anyway, I updated DEP 8 to account for all comments made so far. Thanks everyone who provided feedback! -- Aymeric. -- You received this message

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

 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: >

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

> On 14 Apr 2019, at 15:10, Josh Smeaton 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' > ] >

Re: Proposal to format Django using black

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?

Re: Proposal to format Django using black

I'm writing a DEP. -- Aymeric. > On 25 Apr 2019, at 13:30, Josh Smeaton 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,

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

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

Re: Proposal to format Django using black

> 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

Re: Proposal to format Django using black

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,

Re: Proposal to format Django using black

On Fri, Apr 19, 2019 at 6:33 PM Mariusz Felisiak 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

Re: Proposal to format Django using black

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 wrote: > > On Wednesday, April 24, 2019 at 1:25:55 PM UTC+2, Josh Smeaton wrote: >> >> Black does

Re: Proposal to format Django using black

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 --

Re: Proposal to format Django using black

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. On Wed, 24 Apr 2019 at 20:22, Rene Fleschenberg wrote: > Hi > > > The arguments against a particular code style will never stop. In this

Re: Proposal to format Django using black

Hi > The arguments against a particular code style will never stop. In this > case it's a big advantage to choose a tool developed by others which > does not allow any bikeshedding. > Will black really stop the arguments (which are not bikeshedding, IMO -- readability counts)? Or will they just

Re: Proposal to format Django using black

On Wed, Apr 24, 2019 at 9:06 AM Carlton Gibson wrote: > On Wednesday, 24 April 2019 08:58:57 UTC+2, Josh Smeaton wrote: >> >> lots of bikeshedding >> > > Yeah.  > > But we've already got a style guide, so **IF** we can get a YAPF config to > work to that then hopefully the arguments against

Re: Proposal to format Django using black

On Wednesday, 24 April 2019 08:58:57 UTC+2, Josh Smeaton wrote: > > lots of bikeshedding > Yeah.  But we've already got a style guide, so **IF** we can get a YAPF config to work to that then hopefully the arguments against using a formatter here would be moot. (Note that **IF** — I only said

Re: Proposal to format Django using black

FWIW, I'd be opposed to YAPF at all, but especially over Black. The community (that is, large projects that aren't Django) are standardising around Black - a single unambiguous format style. Having a slightly different format to everybody else I see as backwards. Contributors would also likely

Re: Proposal to format Django using black

Thanks for the YAPF suggestion (and sample config!) I'll have a go with this this week. (If we can get auto-formatting, just on diffs(?), that matches the existing style...) On Monday, 22 April 2019 20:10:41 UTC+2, thinkwel...@gmail.com wrote: > > I wonder if there's a middle ground between

Re: Proposal to format Django using black

On projects I've been working on I started using "prettier" fro JavaScript and it made a huge difference to code consistency across the team, which was great, but my favourite benefit (that I'm not sure I've seen mentioned much here) is I can write code faster if I don't have to format it. Being

Re: Proposal to format Django using black

I wonder if there's a middle ground between minimizing code churn and having a standardized formatter. Our team recently switched to yapf after carefully configuring a .style.yapf file that's included in the root directory of every new repo. Once that config file is done, the workflow for yapf

Re: Proposal to format Django using black

> > > I'm just saying that if "As contributor, I can haz automatic code > formatter to lower the barrier" is precisely the story you want to solve, > then black may not be the only solution you want to consider deeply ;) > > Jamie, sure, I wasn't responding directly to you about this, more to

Re: Proposal to format Django using black

On maandag 22 april 2019 10:57:19 CEST Nick Sarbicki wrote: > Consistency in the end is the most important thing (even PEP8 agrees > there). Not sure where you got that impression: https://pep8.org/#a-foolish-consistency-is-the-hobgoblin-of-little-minds Pep8 clearly states consistency is less

Re: Proposal to format Django using black

Thanks for sharing some of your insight. On Mon, Apr 22, 2019 at 10:57 AM Nick Sarbicki wrote: > Even moreso if it lowers the barrier to entry (I don't think anyone is > saying it raises it?). > I'm just saying that if "As contributor, I can haz automatic code formatter to lower the barrier"

Re: Proposal to format Django using black

I'm still quite strongly in support of black. I find it's very nice to read a codebase that has strong consistency (which is historically usually the work of pedantic but very necessary reviews). It's even nicer to go between multiple codebases which are all consistent with each other. PEP8 and

Re: Proposal to format Django using black

Just note that the coala python package ( https://coala.io ) seems to be the alternative to black that will let you make some compromises, might be worth considering as well. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to

Re: Proposal to format Django using black

Le samedi 20 avril 2019 09:11:24 UTC+2, Carlton Gibson a écrit : > > > > On Friday, 19 April 2019 20:33:13 UTC+2, Mariusz Felisiak wrote: >> >> >> I don't think that our code style is any barrier for newcomers. ...we've >> never blocked any patch due to stylistic nitpicks. I also don't believe

Re: Proposal to format Django using black

On Friday, 19 April 2019 20:33:13 UTC+2, Mariusz Felisiak wrote: > > > I don't think that our code style is any barrier for newcomers. ...we've > never blocked any patch due to stylistic nitpicks. I also don't believe > that it will increase the number of contributors, if I would like to >

Re: Proposal to format Django using black

I share the opinion of Mariusz Felisiak, Luke Plant and Claude Paroz, and believe that it is a bad idea to do this in an automatic way without the possibility to interfere manually. - Jacob -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Proposal to format Django using black

I'm against adopting black to Django. I don't like style proposed by black (some of rules make code less readable) and in the same time I really enjoy Django's style, but that's of course my subjective opinion. I don't think that our code style is any barrier for newcomers. Just like Tim I

Re: Proposal to format Django using black

I must admit I'm rather pleased by Luke's proposal. Let's keep our current isort/flake8 checks and relax other policies (considering the committer can always minor edit patches, as Tim did in the past). I'm always a bit suspicious of tools that decide the formatting for me. Claude -- You

Re: Proposal to format Django using black

Hi Tim, I didn't mean to imply the original decisions were foolish, in their context. Reading it again, my language in the email was too strong - it was directed at myself as much as anyone else, because I'm also the kind of person who loves getting everything

Re: Proposal to format Django using black

FWIW, I like that we have high standards for concise and readable comments with proper grammar, especially because I myself often need a little extra push in that department. And I'm not easily convinced by the arguments that sound a whole lot like "I've written the code and don't have time to

Re: Proposal to format Django using black

I'm sorry for establishing some (foolish?) guidelines that discouraged some people from contributing. I didn't establish those guidelines merely to be pedantic, but perhaps I'm too much of a perfectionist at times. After GitHub allowed mergers to amend pull requests, I often made cosmetic

Re: Proposal to format Django using black

Hi all, An alternative solution to the problem of nit-picky, formatting related PR reviews is simple: let's not do that. We already have an automated code formatting enforcer, flake8. Let's simply drop the requirement on fixing anything that flake8

Re: Proposal to format Django using black

Well let me add my two cents here since I was also in the group in DCEU that talked about the usage of black. Personally I don't like to contribute to Django. And this is why: Day one: I'll make the fix/patch and create PR Day two (or four or five depending how busy reviewers are): I missed a

Re: Proposal to format Django using black

Le 17/4/19 à 2:33, Dan Davis a écrit : +1 isort -1 black I think that codestyle checkers are better, because you teach yourself proper style for python. I'm in a team in which we've enforced Black a bit more than a year ago, and I can tell you that now, everyone code in a blackish style

Re: Proposal to format Django using black

> One thing we have not considered here is that after running black on Django a huge portion of our outstanding merge requests will have conflicts, some of which might be tricky to rebase. I’m not sure there is much we can do about that though. With a little bit of git-foo, this is actually not

Re: Proposal to format Django using black

I would be +1 for Black. I think it makes a lot of sense for a project like Django, and it does seem that a non trivial amount of both contributor and reviewer time is spent on formatting fixes. The choice of double quotes by default used to annoy me, but after using black for a while I think

Re: Proposal to format Django using black

Hi Dan, On 19-04-16 20:33:29, Dan Davis wrote: >+1 isort >-1 black > >I think that codestyle checkers are better, because you teach yourself >proper style for python. I appreciate this argument, but: As Django community our primary concern in this discussion has to be the impact black would have

Re: Proposal to format Django using black

After dozens of mails it's clear that this is certainly a controversial topic -- especially, as always, string quoting. I think there is an overwhelming benefit in adopting black and not deviating from the defaults even if the only benefit of this is just never having to discuss these choices

Re: Proposal to format Django using black

+1 isort -1 black I think that codestyle checkers are better, because you teach yourself proper style for python. On Tue, Apr 16, 2019 at 8:17 PM Josh Smeaton wrote: > We aren't talking about code minifiers though, are we? We're talking about > a very specific tool with very specific rules. No

Re: Proposal to format Django using black

We aren't talking about code minifiers though, are we? We're talking about a very specific tool with very specific rules. No one will ever agree on one specific code style, which is why subjectivity is anti-productive. Black chooses a specific set of rules and removes ambiguity. Some choices

Re: Proposal to format Django using black

Yeah, it's very common to confuse style with formatting. Not having to think is a productivity win when and only when you don't care about your product's quality (in which case I'd suggest using generators and stop thinking about code altogether). Language is a communication tool, a programming

Re: Proposal to format Django using black

Ivan, what you’re talking about is subjective code formatting, and lends itself to extreme bikeshedding and little consensus. Django already has a formatting standard that mergers try to enforce at review and commit time. But it’s time consuming, prone to missing things, and requires lots of back

Re: Proposal to format Django using black

My two cents: black's mostly ok but I'm against any auto-formatting. Code style is much more than whitespace arrangement, it requires looking, creative thinking, judging, and sometimes actually compromising rules and looks for readability while the usual attitude with such tools is "I have this

Re: Proposal to format Django using black

I feel like it would be worse as it would break formatting changes across multiple commits, creating an inconsistent formatting code base and generating large unrelated changes diff when altering a still untouched file which would make the review harder. Cheers, Simon Le mardi 16 avril 2019

Re: Proposal to format Django using black

> This would address the problem of some pull requests not being merged > for a long period, because of minor formatting issues. > We don't have such PRs. If PRs have tests, docs (when required) and solutions are of good quality we would fix minor formatting issues before merge. It never

Re: Proposal to format Django using black

To address some of Curtis Maloney's concerns: > > 1. automated code formatting will be a great boon - reduce work, lower > barrier for new committers, reduce work for the fellows, etc. > > 2. there are issues with git history in doing "the great commit". > > 3. there are issues with black's

Re: Proposal to format Django using black

Am 14.04.19 um 12:15 schrieb Florian Apolloner: > Hi Christian, > > I think you are making a good argument here. On one hand short-comings > in our tool chain should not block us from making changes. On the > other hand, we do have to live with them -- so having at least some > technical solution

Re: Proposal to format Django using black

Hi Emil, this would only affect Django 3.0 which supports only python3.6 -- as such you couldn't even run Django on those systems anyways. Cheers, Florian On Tuesday, April 16, 2019 at 10:12:20 AM UTC+2, Emil Madsen wrote: > > Hello, > > I'm not sure if it's relevant for the discussion, but

Re: Proposal to format Django using black

Hello, I'm not sure if it's relevant for the discussion, but black requires python 3.6.0+. Several Linux distros does not ship 3.6.0+ yet, including, but not limited to: * Debian Stretch (current LTS) * FreeBSD 12 (current release) * Ubuntu 16.04 Xenial (previous LTS) * Linux Mint 18.1

Re: Proposal to format Django using black

Florian, This option turns off *all* string normalization and not only quote normalization. We wanted to still have prefixes stripping because of our usage of __future__.unicode_literals for example. Cheers, Simon Le lundi 15 avril 2019 04:12:13 UTC-4, Florian Apolloner a écrit : > > Hi

Re: Proposal to format Django using black

Another plus one for Black, without getting too into the weeds. I think the time is will save likely outweigh the valid concerns posted here. I've used Black extensively on several projects, and much like f-strings, the last Pink Floyd album, and broccoli, have found I really like something I

Re: Proposal to format Django using black

Hi Ned. > Try the latest black.  A multi-line lists with comments on each line is > not converted to a one-line list.  The lined-up indentation of the > comments is lost :(, but it's still multi-line. Hmmm, I tried commit cea13f4 (current master at the time of this writing). It turned l = [

Re: Proposal to format Django using black

On 4/15/19 7:13 AM, René Fleschenberg wrote: Hi HMS = "%H:%M:%S"  # 14:30:59 HMSF = ".." HM = ".." TIME_INPUT_FORMATS  = [HMS, HMSF, HM] Just my two cents: This particular rule is the main reason why I personally have not adopted black yet. I really find the one-item-per-line style *much*

Re: Proposal to format Django using black

Hi > HMS = "%H:%M:%S"  # 14:30:59 > HMSF = ".."  > HM = ".." > TIME_INPUT_FORMATS  = [HMS, HMSF, HM] Just my two cents: This particular rule is the main reason why I personally have not adopted black yet. I really find the one-item-per-line style *much* more readable in many cases. In

Re: Proposal to format Django using black

Yes, let’s not discuss the tools choice in quotes, that’s for another place. To provide some information though, black will not convert single quote strings if the string itself contains a double quote. It won’t escape the character, it’ll use single quotes. On Mon, 15 Apr 2019 at 18:48, Kye

Re: Proposal to format Django using black

This is something discussed af length on the black issue tracker and not something the author wishes to change. On Mon, 15 Apr 2019 at 4:47 pm, Dmitriy Sintsov wrote: > Why can't it use mixed quotes, single quotes for all strings except the > strings that contain single quote characters? I

Re: Proposal to format Django using black

Why can't it use mixed quotes, single quotes for all strings except the strings that contain single quote characters? I think mixed syntax of strings is made in various programming languages so both single and double quotes can be used inside strings not having to use ugly backslash escaping.

Re: Proposal to format Django using black

Hi, as Adam points out 1.0 is on it's way. My mails were written with that knowledge and assumption, sorry for not making this clear. I did actually had in mind to wait till it is out of beta -- which is most likely before we finished our discussions :D Cheers, Florian On Monday, April 15,

Re: Proposal to format Django using black

Hi Simon, On Monday, April 15, 2019 at 1:02:49 AM UTC+2, charettes wrote: > > and there's no way to turn off only this form of string normalization, > it's all or nothing. > So the black --help output lists: -S, --skip-string-normalization Don't normalize string quotes or prefixes. Or does

Re: Proposal to format Django using black

Lukasz Langa, the developer, said he will tag the first non-beta version in "Early April." https://twitter.com/llanga/status/1106247623802060802 There won't be any significant changes when it leaves beta afaiu. On Mon, 15 Apr 2019 at 08:40, Scot Hacker wrote: > Just bringing this up for the

Re: Proposal to format Django using black

Just bringing this up for the sake of thoroughness: NOTE: This is a beta product *Black* is already successfully used by several projects, small and big. It also sports a decent test suite. However, it is still very new. Things will probably be wonky for a while. This is made explicit by the

Re: Proposal to format Django using black

I was and and I'm still bugged by how black decided to go for double quotes instead of single ones. Even if it's backed some valid arguments it left all the projects following PEP 8's recommendations over the years with this git blaming loss trade off. From past experimentation with large'ish

Re: Proposal to format Django using black

On Sun, Apr 14, 2019 at 3:11 AM Nick Sarbicki wrote: > Just going to say that one of the main frustration points I've had when > making a contribution is having to fix small formatting errors (often minor > things in docstrings which aren't _always_ consistent). > I constantly need to be

Re: Proposal to format Django using black

On Sun, Apr 14, 2019 at 1:06 PM Florian Apolloner wrote: > This is imo not something that scales well. Also it is not something I want > to pay our fellows for, I rather have them use their time on something else. > It is true that it is probably easier and faster to just fix code instead of >

Re: Proposal to format Django using black

Hello, I'm strongly in favor of adopting black with the default options. In my opinion, it's the first Python code formatter that passes the bar of "on average, does better than any single programmer". Trying to enforce something else manually is a waste of energy that produces worse results.

Re: Proposal to format Django using black

> 2. there are issues with git history in doing "the great commit". Tools make a real difference here. I know everyone has their preferred tools and workflows, but there are tools that let one move through iterations of git blame. This is something I do quite frequently. Just one example, in

Re: Proposal to format Django using black

Agree with Florian that the progressive rollout is more trouble than it's worth. Tangling up feature changes with whole file formatting will make it harder to review changes, but will also be more difficult to use tools like git blame. As for disagreeing with some of Blacks choices - you learn

Re: Proposal to format Django using black

Hi, On Sunday, April 14, 2019 at 10:22:46 AM UTC+2, Curtis Maloney wrote: > > Can such a tool be automated into, say, github in a way that doesn't > create extra commit noise? > Probably, but after blacking (is that even a word ;)) the codebase once there shouldn't be much commit noise. I

Re: Proposal to format Django using black

We've used Black for the Channels/ASGI projects for about the last year, and I have nothing but good opinions on it from that perspective. It's made pull requests much easier to get formatted, because fixing it is just a case of running a single command (and if you do the right pre-commit hook,

Re: Proposal to format Django using black

Hi Christian, I think you are making a good argument here. On one hand short-comings in our tool chain should not block us from making changes. On the other hand, we do have to live with them -- so having at least some technical solution towards the "git blame" issue is needed. I guess the

Re: Proposal to format Django using black

On Saturday, April 13, 2019 at 10:21:48 PM UTC+2, James Bennett wrote: > > But we already have and enforce a style guide, and some parts of it are > things Black can't auto-enforce. > We do? I mean sure, we do have a styleguide, but enforcing it? It all depends on how well our fellows

Re: Proposal to format Django using black

Hi, On Sunday, April 14, 2019 at 1:04:22 AM UTC+2, Berker Peksağ wrote: > > I always do it to not bother > contributors with these changes, especially if they are new to the > project. > This is imo not something that scales well. Also it is not something I want to pay our fellows for, I

Re: Proposal to format Django using black

Hi > 2. there are issues with git history in doing "the great commit". While I don't have much experience neither in Python/Django nor in git, maybe a view fom "outside" may add something useful to the discussion. I'm just seeing that discussion is separated between on the one hand "black is

Re: Proposal to format Django using black

So to summarise the discussion so far: 1. automated code formatting will be a great boon - reduce work, lower barrier for new committers, reduce work for the fellows, etc. 2. there are issues with git history in doing "the great commit". 3. there are issues with black's formatting choices.

Re: Proposal to format Django using black

Just going to say that one of the main frustration points I've had when making a contribution is having to fix small formatting errors (often minor things in docstrings which aren't _always_ consistent). It produces a lot of inertia and can stop PRs from getting merged for extended periods of

Re: Proposal to format Django using black

On Sun, Apr 14, 2019 at 1:34 AM Carlton Gibson wrote: > > We spend a lot of time spotting small formatting errors and then asking for > those to be fixed and then waiting for an update. This wastes reviewer time > and slows down the feedback cycle. Many pull requests drag out because of it.

Re: Proposal to format Django using black

We spend a lot of time spotting small formatting errors and then asking for those to be fixed and then waiting for an update. This wastes reviewer time and slows down the feedback cycle. Many pull requests drag out because of it. For this reason I would be 100% behind adopting black, and applying

Re: Proposal to format Django using black

On Saturday, April 13, 2019 at 8:23:13 PM UTC+2, Adam Johnson wrote: > > I’d like to see gradual roll out (one module at a time? One rule at a > time?) to spread the work of reformatting all the in-flight patches. > My thoughts initially. But then I realized that it would be easier for tooling

Re: Proposal to format Django using black

On Sat, Apr 13, 2019 at 1:18 PM Florian Apolloner wrote: > Maybe, but I think the benefits outweigh the costs -- and I also do not > think that it is unnecessary. Our goal has always been to make contributing > easier, well nowadays black is in the position to do just that. > I feel like Black

Re: Proposal to format Django using black

Hi, On Saturday, April 13, 2019 at 9:41:38 PM UTC+2, Berker Peksağ wrote: > > I came here to say exactly this. Django's codebase is already pretty > consistent with its own style and I think having a usable "git blame" > is much more important than starting to use a new code formatter. I am

Re: Proposal to format Django using black

On Sat, Apr 13, 2019 at 9:19 PM Tobias McNulty wrote: > Overall, the main downside I see is the large, fairly useless changeset this > would create and the impact it would have, such as reduced utility of `git > blame` for some portion of the code for the foreseeable future and > interruption

Re: Proposal to format Django using black

On Sat, Apr 13, 2019 at 11:35 AM Herman S wrote: > 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

  1   2   >