Re: Proposal to format Django using black

[Scot Hacker]

 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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.

Re: Fellow Reports - April 2019

[Mariusz Felisiak]

Week ending April 14, 2019.

I was in Copenhagen as a coach at DjangoGirls event and I participated in 
the DjangoCon Europe conference.

*Triaged:*
https://code.djangoproject.com/ticket/30336 - F() expression wrong result 
on postgres JSONField (duplicate)
https://code.djangoproject.com/ticket/30337 - Django Admin - Migrations: 
default value for models.DateTime() with auto_add_now=True (worksforme)
https://code.djangoproject.com/ticket/30341 - Add support for furlongs unit 
to Distance objects. (accepted)
https://code.djangoproject.com/ticket/30343 - Prefetch related is not 
working when used GFK for model that uses UUID field as PK. (accepted)
https://code.djangoproject.com/ticket/30345 - documentation mistake 
(worksforme)
https://code.djangoproject.com/ticket/30346 - InspectDB doesn't test for 
UUID (at least) on PostgreSQL (duplicate)
https://code.djangoproject.com/ticket/30347 - A typo in Aggregation 
document. (accepted) 
https://code.djangoproject.com/ticket/30353 - Recursion Error while running 
tests (invalid)
https://code.djangoproject.com/ticket/30350 - Migration re-add check 
constraint continuously when check condition contains iterator. (accepted)
https://code.djangoproject.com/ticket/30357 - Admin of app does not 
recognize Foreign_key field (needsinfo)
https://code.djangoproject.com/ticket/30358 - Remove redundant assertion 
from django/tests/forms_tests/tests/test_utils.py. (accepted)
https://code.djangoproject.com/ticket/30362 - Partial indexes and check 
constraints crash when inherited from abstract models. (accepted)

*Reviewed/committed:*
https://github.com/django/django/pull/11179 - Fixed #30330 -- Fixed setting 
of primary key to None during fast-delete.
https://github.com/django/django/pull/11098 - Fixed #30266 -- Kept a 
sequence owner when altering an AutoField/BigAutoField on PostgreSQL.
https://github.com/django/django/pull/11186 - Fixed #30321 -- Added example 
of changed_data to forms docs.
https://github.com/django/django/pull/11204 - Fixed #30347 -- Fixed typo in 
docs/topics/db/aggregation.txt.
https://github.com/django/django/pull/11210 - Fixed #25941 -- Improved 
error message for runtests.py when django is not on path.
https://github.com/django/django/pull/11213 - Fixed #30358 -- Removed 
redundant assertion in FormsUtilsTestCase.test_error_dict_copy().
https://github.com/django/django/pull/11214 - Fixed #30350 -- Prevented 
recreation of migration for operations with a range object.

*Authored:*
https://github.com/django/django/pull/11211 - Fixed #30343 -- Fixed 
prefetch_related() for GenericForeignKey when PK of related field is 
UUIDField.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/27c61797-0f03-412f-ae28-337fbf858191%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[charettes]

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 
projects following PEP8's guideline string quotes changes represented well 
over 50% of the diff and there's no way to turn off only this form of 
string normalization, it's all or nothing. At $WORK we even went as far as 
forking the project to switch to use single quotes instead[0]. I understand 
requiring the use of a fork is not a feasible solution for Django but I 
just wished there was an option to stick to single quotes to reduce the 
cost of adoption for such projects without loosing all the other nifty 
string formatting goodies[1] /rant

Even if I don't completely agree with black's formatting choices and the 
sometimes quite unnatural code it generates my past month's usage at work 
and the adoption of the project in the Python ecosystem that made it's way 
in most IDE makes me mostly share the same feeling as Aymeric; it's not 
always pretty but not having to think about it makes it worth it. I suggest 
we stick to disabling string normalization to reduce the noise generated by 
the migration though.

Cheers,
Simon

[0] https://github.com/zapier/black/pull/1
[1] https://github.com/ambv/black#strings

Le dimanche 14 avril 2019 09:40:10 UTC-4, Aymeric Augustin a écrit :
>
> 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.
>
> I like nicely formatted code and I hate some of what black produces, 
> typically on Django model definitions. However, I've seen the benefits of 
> an automated code formatter, even on projects where I write almost all of 
> the code.
>
> I'm positive the benefits will be great on Django, where you can tell when 
> a module was (re)written just by looking at the style. Yes, there are some 
> downsides, but it's clearly a good tradeoff.
>
> Regarding the migration strategy, converting one package at a time sounds 
> good, because then we can proof-read the Big Diff and perhaps tweak the 
> code where the result really hurts the eyes.
>
> Most of Django's style guide will still applies, as it's mostly 
> conventions about naming things, ordering declarations, etc.
>
> Best regards,
>
> -- 
> Aymeric.
>
>
>
> On 13 Apr 2019, at 13:52, Herman S > 
> 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/her

Re: Form builder application

[Michael Thomas]

I don't see how this question related to Django at all specifically - 
building an application like what you want is mainly a front end task, not 
a back end one.

I'd suggest using whatever front end framework your team is already 
familiar with (Eg. Vue, React, Angular, etc..).

>From my experience with similar projects, managing the data is relatively 
trivial in effort compared to the the effort required to make the front end 
useful and error free.

Kind Regards,
Michael Thomas

On Sunday, 14 April 2019 19:56:43 UTC+5:30, Ali A Cetrefli wrote:
>
> Hi
>  We want to develop form builder app like wpforms .
>
> Who has any previous experience?
> Which library is most useful and most rapid way to develop?
> Best regards..
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/d0415dd3-c0e3-42ca-a5e7-10a11964e815%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature Request: Enabling hooking into the autodetector from a third-party app.

[Ian Foote]

Hi Emil,

This is a very interesting idea and I find your use-case compelling. Adding
support for custom triggers to Django itself would resolve your main use
case this time but I also see value in a general solution that enables
Django's third-party ecosystem.

I think the next step is to open a new ticket (or find an existing one).

Ian

On Sun, 14 Apr 2019 at 15:20, Emil Madsen  wrote:

> Hello follow Djangonauts.
>
> I'm writing this post in an attempt to ignite a discussion about the
> autodetector, and how to make it expandable, such that third-party apps can
> generate their custom migrations automatically.
>
> This has previously been discussed here:
> * https://groups.google.com/d/msg/django
> -developers/qRNkReCZiCk/I8dIxxhoBwAJ
> * https://groups.google.com/d/msg/django
> -developers/pbj7U7FBL6Q/eJtRV7QwDwAJ
>
>
> *Motivation:*
>
> My motivation for writing this post is two fold:
>
>1. First, I recently attended DjangoCon Europe 2019, where Carlton
>Gibson had a keynote about contributing back to Django, I want to do
>so, and thus this is my first post on the mailing list.
>2. Secondly, I believe there are various cases where being able to
>expand the automigrator enables libraries to be a lot cleaner. For 
> instance:
>
>
>- Enforcing constriants on data-models, such as it's done with
>unique_together, and CheckConstraints. Currently these are implemented
>directly in Django, but given an expandable autodector they could have
>been implemented as libraries. In the long section at the end of this
>post, I mention a similar case to this, that was my original
>motivation for writing this post.
>- Enabling rebust auditing models via database triggers, by simply
>adding 'audit_trigger = True' to the Meta class of models that should be
>audited, as done by:
>   - https://github.com/carta/postgres_audit_triggers
>- Automatically enabling database extensions, when fields which
>require these extensions are utilized. As an example, utilizing PostGIS or
>HStore currently requires activating their corresponding extensions
>manually using CreateExtension('extension'), which could be automated.
>- Really any case, in which one would like to automatically generate
>migrations, and which cannot be achieved by custom fields.
>
>
> *The proposal:*
>
> Create a plugin system where plugins can register handlers / callbacks to
> be run from within the automigrator. Potentially this could even be
> implemented using the signals mechanism currently in Django, as presented
> in 'Building plugin ecosystems with Django', by Raphael Michel at
> DjangoCon Europe 2019.
>
> I imagine the signal should be fired here:
>
>- https://github.com/django/django/blob/master/django
>/db/migrations/autodetector.py#L192
>
> And that signals handlers should act as combination between the
> 'create_altered_X' and 'generate_altered_X' methods, resulting either to
> calls of 'self.add_operation', or returning a list of operations to add
> to the migrationsfile.
>
> There is an open question with regards to how dependencies and shared
> state should be handled.
> - I do not have enough insight to answer this.
>
> I am very open to other solutions, this is merely what I came up with,
> without having any throughout insight into how Django works internally.
> - I am willing to implement the plugin system, and create a PR for this,
> if a consensus is found.
>
>
> *My personal motivation (long section):*
>
> I have a database design, which includes several data invariants, which I
> want to uphold. I've been able to implement most of these data invariants
> using uniqueness (on fields, unique_together, UniqueConstraint), and
> CheckConstraint.
>
> CheckConstraint is excellent, and I'm very happy that made it to Django
> with 2.2, but for enforcing data invariants it has one major shortcoming. -
> It only operates on a single table.
>
> Currently to implement data invariants across multiple tables, I believe
> the suggestion is to override save methods, or to use save signals.
> - However these signals are not emitted for queryset operations, such as
> bulk_inserts or update s, and as such cannot be used to maintain data
> invariants, without relying on manual procedures that are error-prone, and
> take up review time. On another note, save methods and save signals, also
> do not help if the databsae is accseed outside of the Django ORM.
>
> Thus if you need reliable constraints that work across multiple tables, I
> don't believe that a robust solution is currently in place, thus I've been
> working on a prototype for a library to fulfill this role. The library
> enables very strong data invariant checking by allowing one to write
> database constraint triggers via Querysets.
>
> The envisioned library is very simple, and works as follows (based upon
> the pizza toppings example):
> class Topping(models.Model):
> name = models.CharField(max_length=3

Re: Proposal to format Django using black

[Tobias McNulty]

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 reminded to shorten docstrings and comments (and
sometimes remove "We" from the beginning of such strings). Unfortunately
(though understandably), Black won't help with any of these issues, and
we'll still be left with the same back and forth about grammar, wrapping,
etc. in comments and docstrings. (Again, as of mid-2018 there is
the max-doc-length option for flake8 that could help with this somewhat,
but that change can be made independently.)

I'm not arguing against Black adoption, but I don't think it's going to
eliminate from the review process what may sometimes feel like inertia...

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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAMGFDKSykRi_51ZonvETYX7whWnPmEAVKm76-MxZifeEuqMt-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Form builder application

[Ali A Cetrefli]

Hi
 We want to develop form builder app like wpforms .

Who has any previous experience?
Which library is most useful and most rapid way to develop?
Best regards..

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/4e65fb97-8c6f-4da4-bd7a-982532799979%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Илья]

>From my subjective point of view `one` is more short and concise, but your
points are valid too, so something like `qs.first(ordered=False)` seems to
be a reasonable tradeoff.

I'd say that its arg should be keyword only to be explicit.

And this arg doesn't then need to be added to `last`.

вс, 14 апр. 2019 г., 13:03 Florian Apolloner :

> Hi,
>
> while your arguments for adding `.one` are all good and well, I think
> adding yet another function will add quite some confusion and will make
> arguing harder imo. As a middleground I could imagine adding an
> `ordered=True/False` argument to first to turn off ordering as needed. This
> will also make it easier to argue about it in the docs I think. Would that
> work?
>
> Cheers,
> Florian
>
> --
> 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/azvOPaEElOY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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/2df92ea6-154e-43e2-9988-15af58aecb17%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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAJF%3Dk3%3DHgMhWPO7GQyyau7hTOZLMtf8NDaO3dmRxYQuj3HP5Wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Berker Peksağ]

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 
> back & forth with the contributor, but the main argument for me here is that 
> this is work that shouldn't be needed in the first place.

True, having an automated code formatter would definitely help to save
reviewer a bit time. However, Django has already flake8 checker on
GitHub, which would already help a contributor to fix biggest
inconsistencies in their PR. Note that my point in my earlier email
was that there are more minor details than just cosmetic fixes and
unfortunately you can't automatically fix all of them :) So, a final
round of edits still needed.

I've used git-hyper-blame before. Most of the time you need to
manually collect all "mass cleanup" commits in a file (and you need to
maintain that file separately) It's also not easy to integrate it with
your workflow especially if you're using "git blame" from your IDE of
choice.

--Berker

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAF4280LX-m8PiKC1bEQz%3DX9nS32BZ9Wb0NR1-UUpRY6CLgxqng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Aymeric Augustin]

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.

I like nicely formatted code and I hate some of what black produces, typically 
on Django model definitions. However, I've seen the benefits of an automated 
code formatter, even on projects where I write almost all of the code.

I'm positive the benefits will be great on Django, where you can tell when a 
module was (re)written just by looking at the style. Yes, there are some 
downsides, but it's clearly a good tradeoff.

Regarding the migration strategy, converting one package at a time sounds good, 
because then we can proof-read the Big Diff and perhaps tweak the code where 
the result really hurts the eyes.

Most of Django's style guide will still applies, as it's mostly conventions 
about naming things, ordering declarations, etc.

Best regards,

-- 
Aymeric.



> On 13 Apr 2019, at 13:52, Herman S  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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/DCD30C61-13DD-4EC2-B8B6

Feature Request: Enabling hooking into the autodetector from a third-party app.

[Emil Madsen]

Hello follow Djangonauts.

I'm writing this post in an attempt to ignite a discussion about the 
autodetector, and how to make it expandable, such that third-party apps can 
generate their custom migrations automatically.

This has previously been discussed here:
* https://groups.google.com/d/msg/django-developers/qRNkReCZiCk/I8dIxxhoBwAJ
* https://groups.google.com/d/msg/django-developers/pbj7U7FBL6Q/eJtRV7QwDwAJ


*Motivation:*

My motivation for writing this post is two fold:

   1. First, I recently attended DjangoCon Europe 2019, where Carlton 
   Gibson had a keynote about contributing back to Django, I want to do so, 
   and thus this is my first post on the mailing list.
   2. Secondly, I believe there are various cases where being able to 
   expand the automigrator enables libraries to be a lot cleaner. For instance:
   

   - Enforcing constriants on data-models, such as it's done with 
   unique_together, and CheckConstraints. Currently these are implemented 
   directly in Django, but given an expandable autodector they could have 
   been implemented as libraries. In the long section at the end of this 
   post, I mention a similar case to this, that was my original motivation 
   for writing this post.
   - Enabling rebust auditing models via database triggers, by simply 
   adding 'audit_trigger = True' to the Meta class of models that should be 
   audited, as done by: 
  - https://github.com/carta/postgres_audit_triggers
   - Automatically enabling database extensions, when fields which require 
   these extensions are utilized. As an example, utilizing PostGIS or HStore 
   currently requires activating their corresponding extensions manually using 
   CreateExtension('extension'), which could be automated.
   - Really any case, in which one would like to automatically generate 
   migrations, and which cannot be achieved by custom fields.


*The proposal:*

Create a plugin system where plugins can register handlers / callbacks to 
be run from within the automigrator. Potentially this could even be 
implemented using the signals mechanism currently in Django, as presented 
in 'Building plugin ecosystems with Django', by Raphael Michel at DjangoCon 
Europe 2019.

I imagine the signal should be fired here:

   - https://github.com/django/django/blob/master/django
   /db/migrations/autodetector.py#L192

And that signals handlers should act as combination between the 
'create_altered_X' and 'generate_altered_X' methods, resulting either to 
calls of 'self.add_operation', or returning a list of operations to add to 
the migrationsfile.

There is an open question with regards to how dependencies and shared state 
should be handled.
- I do not have enough insight to answer this.

I am very open to other solutions, this is merely what I came up with, 
without having any throughout insight into how Django works internally.
- I am willing to implement the plugin system, and create a PR for this, if 
a consensus is found.


*My personal motivation (long section):*

I have a database design, which includes several data invariants, which I 
want to uphold. I've been able to implement most of these data invariants 
using uniqueness (on fields, unique_together, UniqueConstraint), and 
CheckConstraint.

CheckConstraint is excellent, and I'm very happy that made it to Django 
with 2.2, but for enforcing data invariants it has one major shortcoming. - 
It only operates on a single table. 

Currently to implement data invariants across multiple tables, I believe 
the suggestion is to override save methods, or to use save signals.
- However these signals are not emitted for queryset operations, such as 
bulk_inserts or update s, and as such cannot be used to maintain data 
invariants, without relying on manual procedures that are error-prone, and 
take up review time. On another note, save methods and save signals, also 
do not help if the databsae is accseed outside of the Django ORM.

Thus if you need reliable constraints that work across multiple tables, I 
don't believe that a robust solution is currently in place, thus I've been 
working on a prototype for a library to fulfill this role. The library 
enables very strong data invariant checking by allowing one to write 
database constraint triggers via Querysets.

The envisioned library is very simple, and works as follows (based upon the 
pizza toppings example):
class Topping(models.Model):
name = models.CharField(max_length=30)

def __str__(self):
return self.name

class PizzaTopping(models.Model):
class Meta:
unique_together = ("pizza", "topping")

pizza = models.ForeignKey('Pizza')
topping = models.ForeignKey('Topping')

class Pizza(models.Model):
name = models.CharField(max_length=30)
toppings = models.ManyToManyField('Topping', through=PizzaTopping) 

def __str__(self):
return self.name

We envision having a data invariant on the number of toppings allowed per 
pizza, a

Re: Proposal to format Django using black

[Jon Dufresne]

> 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 Emacs the vc-annotate command (bound to "C-x v g") shows a view
of git blame. The user can hit "a" to go to the previous diff the line
appeared on which might be more interesting. So one could use this feature
to skip over the Black commit on to a more interesting one. This is just a
single example. Florian's suggested tools may handle this even more
elegantly, but I haven't used them. This only goes to show that the history
and git blame concerns don't need to be a show stopper and can be solved.
The feature people are asking for, "skipping over" git commits in blame,
does exist for some tools. It even exists in GitHub's blame view. The
button is labeled "View blame prior to this change".


On Sun, Apr 14, 2019 at 1:22 AM Curtis Maloney  wrote:

> 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.
>
>
> So to address 1:
>
> I am entirely +1 for automated code formatting to take the work out of
> our hands.
>
> Can such a tool be automated into, say, github in a way that doesn't
> create extra commit noise?
>
> To address 2:
>
> I side with those who favour a progressive solution, whereby new code
> only has the new tool applied.
>
> That said, there might be cause to suggest a deadline [perhaps a N.0
> release?] where all remaining code is "cleaned".
>
> And finally 3:
>
> My perspective on the goal of any code formatting tool is this:
>
> When we as developers approach a piece of code, our goal is the
> understand its intent and its implementation of that intent.
>
> In the process of reaching that, we pass through the stages of (a)
> identifying the relevant code, (b) understanding the action of the code,
> and (c) understanding the intent of the code.
>
> Good code formatting choices will remove or reduce the cognitive load in
> (b) and (c).
>
> 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)
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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
> .
> 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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CADhq2b4Udk1ooc0zdagMPecx-ZGRk%2B01dGCGVr%2BjYOA8vFp8Ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Josh Smeaton]

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 very quickly to 
live with those choices, and forget those choices. Any set of configuration 
we could come up with for an existing tool would likely be bikeshedded to 
death and nothing would eventuate.

For line lengths, projects I work on set Black to 100 columns, but flake8 
line length is capped to 120. This lets some long strings (black doesn't 
break long strings over multiple lines) get past flake8 without being over 
the top.

I'm in favour of using blacks double quotes for strings. I **hated** this 
decision when it was first made, but have seriously come around to it, and 
prefer it aesthetically too. Consistency with other projects (most big 
projects are adopting black) I feel is a good goal. The diff is already 
going to be huge, there's not much value in protecting a few strings.

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.


On Sunday, 14 April 2019 20:20:31 UTC+10, Florian Apolloner wrote:
>
> 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 side with those who favour a progressive solution, whereby new code 
>> only has the new tool applied. 
>>
>
> I think that would make it hard on tools like git-hyper-blame which allow 
> one to skip revisions. Also you cannot just run black over changes, the 
> minimal unit is one file as far as I am aware. Which would make PR very 
> very hard to review because you'd have a bunch of syntax changes next to 
> real changes.
>
> 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. 
>>
>
> Generally I am okay with the way black formats code. But I have to admit 
> that for some very tricky codepaths I tend to turn it off from time to 
> time. That does not happen very often though.
>
> 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. 
>>
>
> Open to suggestions, did you just offer to write one :)
>
> (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) 
>>
>
> We can and should fix those occurrences in our codebase then I guess.
>  
> Cheers,
> Florian
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/8b81a047-babe-42d0-97f5-3af5f6b264fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

[Curtis Maloney]

On 4/13/19 10:22 PM, Markus Holtermann wrote:

Thanks for the proposal, Shai. I quite like it.

As discussed at the DCEU sprints I think I'd like to be able to omit the display form of an item and have it auto 
generated from an item's name, i.e. turning "FOO_BAR" into "Foo Bar" (`key.replace("_", 
" ").title()`)



For reference, this is what my project does ( labeled-enums: 
https://pypi.org/project/labeled-enum/ )



--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/5a5956f5-84ba-1abf-9dbe-56ba1fbe84dc%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Curtis Maloney]

On 4/14/19 8:02 PM, Florian Apolloner wrote:

Hi,

while your arguments for adding `.one` are all good and well, I think 
adding yet another function will add quite some confusion and will make 
arguing harder imo. As a middleground I could imagine adding an 
`ordered=True/False` argument to first to turn off ordering as needed. 
This will also make it easier to argue about it in the docs I think. 
Would that work?




I was thinking the same for most of this thread... I would just 
bike-shed it as, for instance "ensure_ordering=False" or 
"stable_order=False" so you more clearly know what you're asking for.


--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/ffc53023-83d5-b31d-c77e-96b403f69b5a%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Florian Apolloner]

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 side with those who favour a progressive solution, whereby new code 
> only has the new tool applied. 
>

I think that would make it hard on tools like git-hyper-blame which allow 
one to skip revisions. Also you cannot just run black over changes, the 
minimal unit is one file as far as I am aware. Which would make PR very 
very hard to review because you'd have a bunch of syntax changes next to 
real changes.

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

Generally I am okay with the way black formats code. But I have to admit 
that for some very tricky codepaths I tend to turn it off from time to 
time. That does not happen very often though.

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

Open to suggestions, did you just offer to write one :)

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

We can and should fix those occurrences in our codebase then I guess.
 
Cheers,
Florian

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/8a2e84f3-8b1f-45b7-9ae0-4d556e85133a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Andrew Godwin]

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,
you never even get that far).

As for Django, the single biggest problem I can see is the single reformat
commit, but I think this is worth it. We've had a few of those in our
history - and indeed at work - and while it is a bit of a pain, GitHub has
a "see the blame before this commit" button to enable much easier browsing
of files prior to it.

For that reason, I am +1 to using the Black code formatter.

Andrew


On Sun, Apr 14, 2019 at 10:22 AM Curtis Maloney  wrote:

> 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.
>
>
> So to address 1:
>
> I am entirely +1 for automated code formatting to take the work out of
> our hands.
>
> Can such a tool be automated into, say, github in a way that doesn't
> create extra commit noise?
>
> To address 2:
>
> I side with those who favour a progressive solution, whereby new code
> only has the new tool applied.
>
> That said, there might be cause to suggest a deadline [perhaps a N.0
> release?] where all remaining code is "cleaned".
>
> And finally 3:
>
> My perspective on the goal of any code formatting tool is this:
>
> When we as developers approach a piece of code, our goal is the
> understand its intent and its implementation of that intent.
>
> In the process of reaching that, we pass through the stages of (a)
> identifying the relevant code, (b) understanding the action of the code,
> and (c) understanding the intent of the code.
>
> Good code formatting choices will remove or reduce the cognitive load in
> (b) and (c).
>
> 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)
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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
> .
> 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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAFwN1up9ZKUOLQH_N_M3wMB4ffhxcMWoFMtwemwuTUEXKKJucA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[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 
towards the "git blame" issue is needed. I guess the chromium team also 
realized this, which led to the development of tools like git-hyper-blame 
(see 
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
 
-- to be fair I haven't tried it yet).

Cheers,
Florian

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/1e41a332-f147-4c32-aff9-2c8b6bb3af41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Florian Apolloner]

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 (manually) enforce it. So even if there are 
things black cannot auto-enforce, we are currently not enforcing 
__anything__. And even our great fellows do make mistakes from time to 
time, something black could prevent (at least in the areas that it could 
enforce).

Do not get me wrong, I am not trying to bash our fellows here for sometimes 
making mistakes. But arguing that we are already enforcing a styleguide 
seems a bit far stretched, even if our fellows are doing an astonishing job 
there.

Cheers,
Florian

P.S.: I said fellows a few times in this mail, but reviewer/committers 
would probably be better, even though I think that most of the final fixing 
is currently on the fellows. 

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/64862d83-82d5-4af5-aa35-d473f0ba5639%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Florian Apolloner]

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 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 back & forth with the contributor, but the main argument for me 
here is that this is work that shouldn't be needed in the first place.

Cheers,
Florian

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/7b6279fa-1185-45d2-b3d8-bb3f97c00c3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Florian Apolloner]

Hi,

while your arguments for adding `.one` are all good and well, I think 
adding yet another function will add quite some confusion and will make 
arguing harder imo. As a middleground I could imagine adding an 
`ordered=True/False` argument to first to turn off ordering as needed. This 
will also make it easier to argue about it in the docs I think. Would that 
work?

Cheers,
Florian

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/2df92ea6-154e-43e2-9988-15af58aecb17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Christian González]

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 good. It would help Django, newcomers' entry barrier etc." -
and OTOH "black adds a commit to Django that prevents git blame to work
properly."

So, excuse me to blasphemically ask the question: Isn't that a problem
with git? I always asked myself how to properly fix whitespace "bugs"
without destroying the "git blame" history.

What would in my optinion solve that issue, and hence allow black to be
adopted completely in Django without regrets, would be a feature in git
to exclude certain commits, or even chunks, from git blame history. This
could be done by having a .blameignore file like .gitignore, listing
commit hashes that should be ignored in the blame history. So it could
be made clear and configurable per project, and even modified after
committing - because you can't change git history itself - which code
chunks are just "cosmetical" and have not to be treated as real "code".

I knot this has nothing to do with Django itself - but really, NOT
adopting black because of "git blame" creating wrong results would be
the wrong approach IMHO.

If you're not saying that I'm completely insane, or git already has this
feature, or Ii forgot something, I could try and add a git feature
request for that. Even if implemented in 2 years, It could be made sure
later that git blame worked correctly backwards then.

TL;DR: Use black with Django without compromise, fix git.

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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/b689490c-479e-8745-693a-180bdeeed0cd%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.


pEpkey.asc
Description: application/pgp-keys

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[alTus]

Hi. Thank you for that detail response.

It needs to be clarified that I'm not that worried about exception as it 
could seem :)
It was just an answer to those 2 comments to show that their workarounds 
result in different behaviour than proposed `one`.

`get_or_none` would be useful in my opinion too but still it does not 
exactly the same thing because it would still raise MultipleObjectsReturned.

On the other hand, `one` is:
1) totally safe: None for nothing, same as `get` for 1 object, some random 
row if multiple found
2) have the same DB perfomance as `get`
3) has no overhead for exception (can affect performance in long cycles)


воскресенье, 14 апреля 2019 г., 11:23:17 UTC+3 пользователь Shai Berger 
написал:
>
> Hi, 
>
> I agree that first() should imply ordering, and bemoan the decision, 
> made several years ago, that first() should be the answer to all the 
> people asking for get_or_none(). 
>
> That said, get_or_none()'s definition is trivial: 
>
> def get_or_none(qs. *args, **kw): 
> try: 
> return qs.get(*args, **kw) 
> except ObjectDoesNotExist: 
> return None 
>
> and it's not hard to add it as a method on your own querysets or even 
> monkeypatch it into Django's using a descriptor: 
>
> class MonkeyPatcher: 
> def __init__(self, method): 
> self.method = method 
> def __get__(self, instance, cls): 
> return functools.partial(self.method, instance) 
>
> QuerySet.get_or_none = MonkeyPatcher(get_or_none) 
>
> (all above untested, Caveat Lector). 
>
> On a side note, you seem to be very worried about the possibility that 
> an exception will be raised. It may be an issue in terms of flow 
> control, but not in terms of overhead, so including code to handle an 
> exception does solve that issue. 
>
> HTH, 
> Shai. 
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/96a8bb7f-f46f-4124-bf73-b811eb65eaef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Shai Berger]

Hi,

I agree that first() should imply ordering, and bemoan the decision,
made several years ago, that first() should be the answer to all the
people asking for get_or_none().

That said, get_or_none()'s definition is trivial:

def get_or_none(qs. *args, **kw):
try:
return qs.get(*args, **kw)
except ObjectDoesNotExist:
return None

and it's not hard to add it as a method on your own querysets or even
monkeypatch it into Django's using a descriptor:

class MonkeyPatcher:
def __init__(self, method):
self.method = method
def __get__(self, instance, cls):
return functools.partial(self.method, instance)

QuerySet.get_or_none = MonkeyPatcher(get_or_none)

(all above untested, Caveat Lector).

On a side note, you seem to be very worried about the possibility that
an exception will be raised. It may be an issue in terms of flow
control, but not in terms of overhead, so including code to handle an
exception does solve that issue.

HTH,
Shai.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/20190414102259.204174ae.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Curtis Maloney]

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.


So to address 1:

I am entirely +1 for automated code formatting to take the work out of 
our hands.


Can such a tool be automated into, say, github in a way that doesn't 
create extra commit noise?


To address 2:

I side with those who favour a progressive solution, whereby new code 
only has the new tool applied.


That said, there might be cause to suggest a deadline [perhaps a N.0 
release?] where all remaining code is "cleaned".


And finally 3:

My perspective on the goal of any code formatting tool is this:

When we as developers approach a piece of code, our goal is the 
understand its intent and its implementation of that intent.


In the process of reaching that, we pass through the stages of (a) 
identifying the relevant code, (b) understanding the action of the code, 
and (c) understanding the intent of the code.


Good code formatting choices will remove or reduce the cognitive load in 
(b) and (c).


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)


--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Nick Sarbicki]

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 time. So from a new contributor angle I think black is
an obvious choice.

>From a maintainers point of view, git blame is very nice to have and this
would add some complexity. But it's easy to see the full version history of
a file and, let's be honest, not enough people use git bisect.


On Sun, 14 Apr 2019, 00:04 Berker Peksağ,  wrote:

> 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.
>
> But you can now do final edits (cosmetic changes, tweak reST markup
> and documentation) via GitHub UI, right? I always do it to not bother
> contributors with these changes, especially if they are new to the
> project.
>
> --Berker
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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
> .
> 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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAGuvt92sVXVAuTzLW7sQkpkJEdNuamfeQwjwcn2dvFokZDZ7CQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add to QuerySet method `one` that acts as `first` but without ordering

[Илья]

First/last enforces ordering because of its nature and also we can't break
compatibility. And second factor is that qs[0] as I wrote above can raise
exception and also will still have ordering (from model.meta for example).

вс, 14 апр. 2019 г., 0:04 Florian Apolloner :

> On Saturday, April 13, 2019 at 10:58:24 PM UTC+2, alTus wrote:
>>
>> I've posted the source code if `first`. You can see there that if qs is
>> not ordered then ordering by pk is added.
>> It's the main point of this issue btw.
>>
>
> Oh I didn't realize that first enforces ordering. Yet another function is
> not a good idea though I fear. I'd check what the reason for enforcing
> ordering in `.first` are and maybe we can just drop that. qs[0] wouldn't
> enforce ordering either (or does it), so why would first do that…
>
> --
> 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/azvOPaEElOY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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/dbe81ba1-ec80-4e78-b63d-a67bfdfae538%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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAJF%3Dk3m8HzDo1t_nC%3D_pq5FnRqmJxu2kZ4jJdHy7wGOyYrPceA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.