--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
As expressed at Djangocon Europe, I am hugely in favor for adopting black.
If we choose to do this there are a few things to consider:* Line-length, we probably want to stay at 119 I guess
* String normalization, I'd be in favor of following black defaults here, but I am open to be convinced otherwise
* We will need to adjust the isort configuration ( https://github.com/ambv/black/blob/master/README.md#how-black-wraps-lines )
Tobias McNulty
Chief Executive Officer
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADhq2b4K6ox%3DZ2YPqF%2BWpxGAFkdF1gjViudJ9QhkVn7UKjy%3DRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
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
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.
with a codebase as big as Django, trying to adapt a different style
guide would only cause unnecessary code churn.
The following style is much more readable (and it also makes future
diffs less noisy since we can add new formats without having reformat
code and comments) than black-formatted code:
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.
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.
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/CAF4280J%2B6J1BJAto1MHd8mo5X%2Bm4AohSqS2HQr3yNXh1WOUcRQ%40mail.gmail.com.
I always do it to not bother
contributors with these changes, especially if they are new to the
project.
But we already have and enforce a style guide, and some parts of it are things Black can't auto-enforce.
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/56392596-0246-b62b-4725-628a2b0801ae%40tinbrain.net.
Can such a tool be automated into, say, github in a way that doesn't
create extra commit noise?
I side with those who favour a progressive solution, whereby new code
only has the new tool applied.
In my experience with using black [we use it at work], there are
numerous choices (including those demonstrated in this list already)
where it can significantly _increase_ the cognitive load in simply
parsing the code.
As simple as black can make the job of code formatting, I feel I'd
rather see a different tool that retained the benefits of "trivial code
reformatting", but still allowed us to retain some of Django's existing
code formatting rules.
(An interesting [and defensible] choice, we had a module with a lot of
strings wrapped across lines. black opted to push them onto the same
line, but NOT to merge them. This is because in Python prior to 3.7, it
would have altered the generated AST - one of the guides black uses)
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/56392596-0246-b62b-4725-628a2b0801ae%40tinbrain.net.
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
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).
--Aymeric.
To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/5d71f95a-1a8a-4db4-a2ac-8a59adde1fb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
and there's no way to turn off only this form of string normalization, it's all or nothing.
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 <scot....@gmail.com> wrote:
--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 "Beta" trove classifier, as well as by the "b" in the version number. What this means for you is that until the formatter becomes stable, you should expect some formatting to change in the future. That being said, no drastic stylistic changes are planned, mostly responses to bug reports.Many/most of us use it in production settings already, as the AST check guarantees it isn't going to break anything, but the beta status means you can't always do a simple `pip install black`, and it means that black's formatting choices could change.Does a project as significant as Django want to adopt a beta tool whose "contract" with its users has not yet stabilized?I heart black and would be happy to see it in Django but wonder if we should wait a bit to hit 1.0../s
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 django-d...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/5d71f95a-1a8a-4db4-a2ac-8a59adde1fb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--Adam
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/21ef3344-673b-49af-9cbb-c17bb928ab0b%40googlegroups.com.
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/CANK-ykmWbnCdbnLcj%2B%2BEon5a9ny7W4-AyMAQMHOD%3DdFAMA%2BOoA%40mail.gmail.com.
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.
This would address the problem of some pull requests not being mergedfor a long period, because of minor formatting issues.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0db6YKRAfmZjGbRHXY4kcf5iqULrQ2aVxLxkOTkH%3DUPWg%40mail.gmail.com.
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 language is a tool programmers use to talk to each other, and code passed through autoformatters (especially if author _didn't think_ about style) is harder to understand then written by thinking humans. It's pretty much like trying to stop thinking about style in English -- by using some processor to put your commas and whitespace in place you can generate something that is usually possible to understand, at least for the most part, but that and _good style_ would still be worlds apart (yes, natural languages are different, it's much easier to make things worse there, but it's not any easier to make things better in programming languages).There are situations where compromising style for formatting is acceptable and even a good idea, I don't think here is one of them. Removing a significant expressive tool from a language just to ensure your whitespace is arranged according to some arbitrary rules is about as counter-productive and pointless as it can get. Not because sometimes it produces some bad results but exactly because it prevents humans from thinking and expressing themselves properly. What would you think about some processor renaming all your variables so that you don't have to think about naming them? Must be even better for productivity.Ivan.
To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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 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 django-d...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%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 django-d...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/0fd5f210-1b79-4cce-947e-d8f4e132fd69%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
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
doesn't pick up. A committer can fix up style issues if they want
to, but shouldn't make anyone else do it. This would mean most of
the stuff on our coding
style page should just be delete, or at least not enforced -
by which I mean almost anything that can't be enforced by a tool
(such as isort, flake8, editors via .editorconfig etc.), and has
no non-local effects. (So consistent naming of classes/functions
*should* be enforced, because that affects other people's ability
to use the code). Large parts of that page are just duplicating
of flake8/isort rules anyway. Honestly, does it kill us if someone
writes "we" in a code comment? And black couldn't help with some
of these things anyway. Let's just stop being code review jerks.
I'm kind of ambivalent on black itself. Certainly there are cases where it makes code less readable (a significant sin in my book) e.g. lists that are better displayed vertically, as mentioned already, and there are cases where it makes your diff larger than it needs to be (e.g. when it decides a list is now too long and needs to be re-formatted vertically). If we adopt black we'd have to live with those annoyances. Alternatively, we can live with the annoyance that code formatting is not perfectly consistent and we accept less than 'perfect' PR. But we should just live with those things:
A foolish consistency is the hobgoblin of little minds
And if our consistency requirements are causing problems for people attempting to contribute, they are foolish and should be dropped.
My 2 ¢.
Luke
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAHn91ofkXhofPR_3bjSg2Swei2SyQ_axo6Ymy2dSuKg8G878GA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
--
--Jani TiainenSoftware wizard
Always open for short term jobs or contracts to work with 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 django-d...@googlegroups.com.
Tobias McNulty
Chief Executive Officer
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/06cf99d0-0521-4441-9252-86ef7f779039%40googlegroups.com.
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
consistent, often too much, and that wasn't clear. What I meant to
say was that if it turns out that our guidelines are becoming a
problem, we should drop them, or change how we regard them (e.g.
as guidelines for those who want to go the extra mile, not as
rules that will frustrate contributors).
Your work on the Django code base has been tireless and
fantastic, and along with the other fellows I don't know what we'd
do without you, sorry for not making that clear with my comments.
Thanks,
Luke
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/06cf99d0-0521-4441-9252-86ef7f779039%40googlegroups.com.
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 contribute to any package it wouldn't matter to me.
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 Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/CAC6Op18_ZPJS5pm%3DZ%2B%2B3z3O4NZJydEvF75v-FNkmhQw0xjThYw%40mail.gmail.com.
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" is precisely the story you want to solve, then black may not be the only solution you want to consider deeply ;)
[style]
based_on_style = pep8
column_limit=100
i18n_function_call=['_']
blank_line_before_nested_class_or_def=True
join_multiple_lines=False
indent_dictionary_value=False
coalesce_brackets=True
dedent_closing_brackets=True
align_closing_bracket_with_visual_indent=False
space_between_ending_comma_and_closing_bracket=False
split_complex_comprehension=True
split_before_first_argument=True
split_before_logical_operator=False
split_before_bitwise_operator=False
split_arguments_when_comma_terminated=True
split_before_expression_after_opening_paren=True
split_before_named_assigns=True
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/444c7f75-ddfd-4a56-ab23-bb70dd9d877b%40googlegroups.com.
- YAPF would at times not produce deterministic formatting (formatting the same file the second time with no changes in between would create a different formatting); Black treats this as a bug;
- YAPF would not format all files that use the latest Python 3.6 features (we have a lot of f-strings, there's cases of async generators, complex unpacking in collections and function calls, and so on); Black solves that;
- YAPF is based on a sophisticated algorithm that unwinds the line and applies "penalty points" for things that the user configured they don't like to see. With a bit of dynamic programming magic it arrives at a formatting with the minimal penalty value. This works fine most of the time. When it doesn't, and surprised people ask you to explain, you don't really know why. You might be able to suggest changing the penalty point value of a particular decision from, say, 47 to 48. It might help with this particular situation... but break five others in different places of the codebase.
lots of bikeshedding
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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/954d583a-8dd4-bc83-dad0-a95b165d5546%40fleschenberg.net.
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.
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
On 14 Apr 2019, at 15:10, Josh Smeaton <josh.s...@gmail.com> 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:59HMSF = ".."HM = ".."TIME_INPUT_FORMATS = [HMS, HMSF, HM]
Obviously just an example, but something to keep in mind.
On 13 Apr 2019, at 13:52, Herman S <herman....@gmail.com> 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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ECC90690-D27E-40D3-B69E-765D988A1690%40polytechnique.org.
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.
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.
I'm firmly -1 to globally applying black to the codebase until it can be done without breaking blame.
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.
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
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.