Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

[Sage M.A.]

Hi, Raphael.
Ah, yes, I have seen your project, but I guess I forgot to link it in my 
proposal.
It *is* very interesting, and I believe it will be helpful for anyone who 
wants to implement
this. Let's hope we can make this happen. Thanks for the feedback!

Regards,
Sage

On Tuesday, 16 April 2019 16:44:18 UTC+7, Raphael Michel wrote:
>
> Hi Sage, Hi everyone, 
>
> I lacked the time to read this mailing list in the past months, and 
> someone at DjangoCon Europe just pointed me to this thread, so just for 
> reference, I want to add some prior work that I did to the list: 
>
> At DjangoCon US and thereafter, I developed a third-party 
> implementation that does a little more than the ones that are more 
> well-known and mentioned in the proposal: 
>
> https://github.com/raphaelm/django-jsonfallback 
>
> django-jsonfallback supports native JSON fields on PostgreSQL, MariaDB 
> *and* MySQL (which are quite different in that regard). On all other 
> databases, it falls back to the behaviour of just storing strings in 
> text fields. Therefore, it's still different from what is being 
> proposed here, and also the implementation is quite unclean in the 
> sense that it needs to check for database backends on the level of 
> database fields. When implemented in core, this could be done much more 
> nicely. 
>
> Still, it might be an interesting thing to look at when doing this, if 
> only for the test cases and the weird MySQL/MariaDB things. I'd love to 
> see this in core and are happy to help wherever I can with my expertise. 
>
> Best 
> Raphael 
>
> Am Tue, 2 Apr 2019 04:41:36 -0700 (PDT) 
> schrieb "Sage M.A." >: 
>
> > Hello, everyone! My name is Sage. I'm a 19-year-old computer science 
> > student from Indonesia. I'm planning to join the Google Summer of 
> > Code (GSoC) this year, and I want to contribute to Django. I have 
> > written a draft for my proposal in this gist 
> > . 
> > I have submitted two small patches for Django, and I hope to 
> > contribute more in the future. Feedbacks are much appreciated, thanks! 
> > 
>
>

-- 
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/588ca222-8d7f-4c34-8c4e-cffde8f35b57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Jacob Rief]

To address some of Curtis Maloney's concerns:

>
> 1. automated code formatting will be a great boon - reduce work, lower 
> barrier for new committers, reduce work for the fellows, etc. 
>
> 2. there are issues with git history in doing "the great commit". 
>
> 3. there are issues with black's formatting choices. 
>
>  
How about, instead of reformatting all the code in one big go, discarding 
the "blame"-history,
instead we use a tool which only checks for formatting violations and 
prevents to commit such
code.

Such a tool, for instance is Coala https://coala.io/#/about?lang=Python
This could be added as a Pre-Commit Hook and prevents contributors to 
create non-conformant
branches on GitHub. This would address the problem of some pull requests 
not being merged
for a long period, because of minor formatting issues.

It also would enforce new coding styles over a longer period, keeping code 
annotations until
someone touches a file.

-- 
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/11c2539c-27bb-4ec4-b361-8f5f9a155aa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[charettes]

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

Cheers,
Simon

Le mardi 16 avril 2019 10:37:13 UTC-4, Jacob Rief a écrit :
>
> To address some of Curtis Maloney's concerns:
>
>>
>> 1. automated code formatting will be a great boon - reduce work, lower 
>> barrier for new committers, reduce work for the fellows, etc. 
>>
>> 2. there are issues with git history in doing "the great commit". 
>>
>> 3. there are issues with black's formatting choices. 
>>
>>  
> How about, instead of reformatting all the code in one big go, discarding 
> the "blame"-history,
> instead we use a tool which only checks for formatting violations and 
> prevents to commit such
> code.
>
> Such a tool, for instance is Coala https://coala.io/#/about?lang=Python
> This could be added as a Pre-Commit Hook and prevents contributors to 
> create non-conformant
> branches on GitHub. This would address the problem of some pull requests 
> not being merged
> for a long period, because of minor formatting issues.
>
> It also would enforce new coding styles over a longer period, keeping code 
> annotations until
> someone touches a file.
>

-- 
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/211f3e33-b81d-421f-8609-5fe4d697a52b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: make ForwardManyToOneDescriptor.get_object raise self.RelatedObjectDoesNotExist

[David Beitey]

This continues the discussion from 
https://code.djangoproject.com/ticket/30309.  That issue was a misreporting 
of the core issue which became apparent after further investigation; 
apologies for the noise, I am new to Django.

When a Django model is created with a OneToOneField, or created with a 
ForeignKey with:

on_delete=models.DO_NOTHING, db_constraint=False

If the related model does not exist in the database (eg the remote object 
was removed or does not currently exist), attempting to access a 
relationship on an object will raise a DoesNotExist exception rather than a 
RelatedObjectDoesNotExist exception which is raised if the local field is 
empty.An example traceback looks like this (full traceback at the end 
of this comment ):

  [...]
  File "django/db/models/fields/related_descriptors.py", line 177, in __get__
rel_obj = self.get_object(instance)
  File "django/db/models/fields/related_descriptors.py", line 297, in get_object
return super().get_object(instance)
  File "django/db/models/fields/related_descriptors.py", line 144, in get_object
return qs.get(self.field.get_reverse_related_filter(instance))
  File "django/db/models/query.py", line 399, in get
self.model._meta.object_name
app.models.person.DoesNotExist: Person matching query does not exist.

By comparison, if the local field's value is empty (eg None/NULL, no 
relationship set), then a  RelatedObjectDoesNotExist exception will be raised
instead when attempting to access the relationship.  This has the effect of 
impacting the use of hasattr() if following the one-to-one relationships 
 example
for avoiding exception handling.  In this case, DoesNotExist doesn't inherit 
from AttributeError, so it isn't swallowed with hasattr()
but RelatedObjectDoesNotExist does so it gets swallowed.

In short, it would be more consistent if accessing a non-existent related 
object raised RelatedObjectDoesNotExist.  From Simon Charette's comment 
 on the original 
issue: 

I'd be in favor of making ForwardManyToOneDescriptor.get_object raise 
> self.RelatedObjectDoesNotExist as the current code clearly doesn't take 
> db_constraint=False into account based on ​the heuristic comment there 
> 
> .
>

For context, parts of my database are managed outside of Django and retain 
records of remote object references as the data may return at some point 
(eg a limited view of HR database where staff may or may not have a record 
at a given point in time).  The local side of the relationship continues to 
have a value in case the remote object reappears (eg staff member is now 
employed) so in my context, both a value of NULL or a non-existent foreign 
key are conceptually the same, meaning there's no person object present.

Regards,
David



-- 
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/b377a328-8b91-4cb7-af83-1e96d78ebba7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: make ForwardManyToOneDescriptor.get_object raise self.RelatedObjectDoesNotExist

[charettes]

As I've said on the ticket I think we should make this change as
it's backward compatible and more coherent with the other
RelatedObjectDoesNotExist usages of the related fields API.

Cheers,
Simon

Le mardi 16 avril 2019 07:22:52 UTC-4, David Beitey a écrit :
>
> This continues the discussion from 
> https://code.djangoproject.com/ticket/30309.  That issue was a 
> misreporting of the core issue which became apparent after further 
> investigation; apologies for the noise, I am new to Django.
>
> When a Django model is created with a OneToOneField, or created with a 
> ForeignKey with:
>
> on_delete=models.DO_NOTHING, db_constraint=False
>
> If the related model does not exist in the database (eg the remote object 
> was removed or does not currently exist), attempting to access a 
> relationship on an object will raise a DoesNotExist exception rather than 
> a RelatedObjectDoesNotExist exception which is raised if the local field 
> is empty.An example traceback looks like this (full traceback at the 
> end of this comment 
> ):
>
>   [...]
>   File "django/db/models/fields/related_descriptors.py", line 177, in __get__
> rel_obj = self.get_object(instance)
>   File "django/db/models/fields/related_descriptors.py", line 297, in 
> get_object
> return super().get_object(instance)
>   File "django/db/models/fields/related_descriptors.py", line 144, in 
> get_object
> return qs.get(self.field.get_reverse_related_filter(instance))
>   File "django/db/models/query.py", line 399, in get
> self.model._meta.object_name
> app.models.person.DoesNotExist: Person matching query does not exist.
>
> By comparison, if the local field's value is empty (eg None/NULL, no 
> relationship set), then a  RelatedObjectDoesNotExist exception will be raised
> instead when attempting to access the relationship.  This has the effect of 
> impacting the use of hasattr() if following the one-to-one relationships 
>  example
> for avoiding exception handling.  In this case, DoesNotExist doesn't inherit 
> from AttributeError, so it isn't swallowed with hasattr()
> but RelatedObjectDoesNotExist does so it gets swallowed.
>
> In short, it would be more consistent if accessing a non-existent related 
> object raised RelatedObjectDoesNotExist.  From Simon Charette's comment 
>  on the original 
> issue: 
>
> I'd be in favor of making ForwardManyToOneDescriptor.get_object raise 
>> self.RelatedObjectDoesNotExist as the current code clearly doesn't take 
>> db_constraint=False into account based on ​the heuristic comment there 
>> 
>> .
>>
>
> For context, parts of my database are managed outside of Django and retain 
> records of remote object references as the data may return at some point 
> (eg a limited view of HR database where staff may or may not have a record 
> at a given point in time).  The local side of the relationship continues to 
> have a value in case the remote object reappears (eg staff member is now 
> employed) so in my context, both a value of NULL or a non-existent foreign 
> key are conceptually the same, meaning there's no person object present.
>
> Regards,
> David
>
>
>
>

-- 
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/cdcf9eda-c691-4354-b806-51de36ec6d24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Mariusz Felisiak]

> This would address the problem of some pull requests not being merged
> for a long period, because of minor formatting issues.
>

We don't have such PRs. If PRs have tests, docs (when required) and 
solutions are of good quality we would fix minor formatting issues before 
merge. It never stopped us from merging.

-- 
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/b9fd3273-c062-42cc-aded-2c824ce19e21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Why does ModelForm do validation and not Model

[Will Gordon]

I can't seem to find a good reason for this. And I could foresee this 
preventing potential mistakes. I'm not proposing to actually change the 
implementation, I guess I'm just looking for the reason of it.

-- 
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/97ae2f12-bc27-403d-8b76-f456a63fc0d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

['Ivan Anishchuk' via Django developers (Contributions to Django itself)]

My two cents: black's mostly ok but I'm against any auto-formatting. Code
style is much more than whitespace arrangement, it requires looking,
creative thinking, judging, and sometimes actually compromising rules and
looks for readability while the usual attitude with such tools is "I have
this autoformatter tool so I don't have to think about style anymore, see,
all my whitespace is nice and shining". Using some helpers in your favorite
editor is great but relying on automatics without looking is almost
completely counter-productive.

I find that PR autocommenter is a great way to keep issues detectable by
flake8/pylint to a minimum.

Ivan.

On Sat, Apr 13, 2019 at 6:35 PM 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/CADPNjZ7ZUbZ_Bk77urc0TU7XfspdBiQGCiAUeSc84pTN-%2BcGkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does ModelForm do validation and not Model

[Aymeric Augustin]

Hello Will,

It's mostly for performance reasons, since validation can be expensive. You can 
override save() to call full_clean() in a model if you'd like.

Cheers,

-- 
Aymeric.



> On 16 Apr 2019, at 20:47, Will Gordon  wrote:
> 
> I can't seem to find a good reason for this. And I could foresee this 
> preventing potential mistakes. I'm not proposing to actually change the 
> implementation, I guess I'm just looking for the reason of it.
> 
> -- 
> 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/97ae2f12-bc27-403d-8b76-f456a63fc0d9%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/D7E2A8BE-C236-4000-8E05-A6D756AD4C46%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Josh Smeaton]

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

Not having to think of formatting at all, either as a developer or
reviewer, is a major productivity win. Even if some of the formatting
choices are not agreeable.

On Wed, 17 Apr 2019 at 03:38, 'Ivan Anishchuk' via Django developers
(Contributions to Django itself)  wrote:

> My two cents: black's mostly ok but I'm against any auto-formatting. Code
> style is much more than whitespace arrangement, it requires looking,
> creative thinking, judging, and sometimes actually compromising rules and
> looks for readability while the usual attitude with such tools is "I have
> this autoformatter tool so I don't have to think about style anymore, see,
> all my whitespace is nice and shining". Using some helpers in your favorite
> editor is great but relying on automatics without looking is almost
> completely counter-productive.
>
> I find that PR autocommenter is a great way to keep issues detectable by
> flake8/pylint to a minimum.
>
> Ivan.
>
> On Sat, Apr 13, 2019 at 6:35 PM 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 a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> 

Re: Why does ModelForm do validation and not Model

[Will Gordon]

So the validation is cheaper when performed by ModelForm, as opposed to the 
Model?

-- 
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/8d929b8e-b0e9-4a88-b796-26f00266f729%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why does ModelForm do validation and not Model

[Will Gordon]

Ahh, cool. That makes more sense. I worry that it still leaves open the 
potential of accidentally not validating something. It may make more sense 
to offer instance.save(validate=False) instead of relying on the developer 
to always know whether they can trust the input. But I agree that for 
historical reasons, I'm sure it's much more difficult to implement this now.

-- 
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/cd8ba920-f59d-4afc-afe7-7988fb3348a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

['Ivan Anishchuk' via Django developers (Contributions to Django itself)]

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.

On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton 
wrote:

> Ivan, what you’re talking about is subjective code formatting, and lends
> itself to extreme bikeshedding and little consensus. Django already has a
> formatting standard that mergers try to enforce at review and commit time.
> But it’s time consuming, prone to missing things, and requires lots of back
> and forth.
>
> Not having to think of formatting at all, either as a developer or
> reviewer, is a major productivity win. Even if some of the formatting
> choices are not agreeable.
>
> On Wed, 17 Apr 2019 at 03:38, 'Ivan Anishchuk' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> My two cents: black's mostly ok but I'm against any auto-formatting. Code
>> style is much more than whitespace arrangement, it requires looking,
>> creative thinking, judging, and sometimes actually compromising rules and
>> looks for readability while the usual attitude with such tools is "I have
>> this autoformatter tool so I don't have to think about style anymore, see,
>> all my whitespace is nice and shining". Using some helpers in your favorite
>> editor is great but relying on automatics without looking is almost
>> completely counter-productive.
>>
>> I find that PR autocommenter is a great way to keep issues detectable by
>> flake8/pylint to a minimum.
>>
>> Ivan.
>>
>> On Sat, Apr 13, 2019 at 6:35 PM 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 

Re: Why does ModelForm do validation and not Model

[Tom Forbes]

The idea is that you generally always have to do extensive validation when
accepting user input through a form. These validations could require
additional database queries or other somewhat expensive lookups (especially
with validate unique).

However if you are loading data from a trusted source, e.g:

for row in your_csv_file:
instance = Model(**row)
instance.save()

Then there is no need to call that potentially slow full_clean(). There is
not much value in slowing down all .save()’s needlessly - the developer
should know when it’s appropriate to run validations and can run
full_clean() when needed.




On 16 April 2019 at 21:42:24, Will Gordon (wpg4...@gmail.com) wrote:

So the validation is cheaper when performed by ModelForm, as opposed to the
Model?
--
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/8d929b8e-b0e9-4a88-b796-26f00266f729%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/CAFNZOJMUPSptux9yeSVtcHLi2HR80YfzgXmhMqnWQ_eEMYqqdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Force "required" fields to be included in a ModelForm

[Will Gordon]

Sorry if I wasn't more clear, but using a warning was exactly what I was 
proposing. In the same way that a FieldError is raised when an editable field 
is listed in fields, I was essentially planning on doing the exact same 
check on the blank attribute. I agree that this should be ignorable, and 
I'm not sure that I've settled on a way to do that as of yet.

-- 
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/5e34c24e-513b-42fd-889b-993e2b083a5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Force "required" fields to be included in a ModelForm

[Will Gordon]

Would it be weird to just make it so that the "required" field *must* be 
present in exclude? This way, if you *accidentally* leave off a required 
field, you're quickly notified about itbut if you explicitly mark it as 
something to exclude, it makes it clear to everyone exactly what you're 
trying to do? The whole "explicit is better than implicit" and what not.

-- 
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/c0b7e5d5-f422-42be-ace8-c0201a2f79a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Force "required" fields to be included in a ModelForm

[Will Gordon]

In the same way that editable fields are forced to not be included in a 
ModelForm (
https://github.com/django/django/blob/master/django/forms/models.py#L146), 
I would like to propose that "required" fields (`blank=False`) be forced to 
be included in a ModelForm.

While I understand that a developer can force this inclusion themselves, 
but on a large project, it should not be necessary to always ensure that a 
Model and ModelForm are in sync.

Since this is probably a non-trivial patch (
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#non-trivial-patches)
 
I need to provide evidence that this has been discussed. As such, I'm open 
to any and all opinions!

-- 
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/980d8112-d51c-4e88-a17f-5e9a4a3577d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Dan Davis]

+1 isort
-1 black

I think that codestyle checkers are better, because you teach yourself
proper style for python.

On Tue, Apr 16, 2019 at 8:17 PM Josh Smeaton  wrote:

> We aren't talking about code minifiers though, are we? We're talking about
> a very specific tool with very specific rules. No one will ever agree on
> one specific code style, which is why subjectivity is anti-productive.
> Black chooses a specific set of rules and removes ambiguity. Some choices
> will be agreeable, others will not be. And the ones that are agreeable
> aren't agreeable to every person.
>
> > and code passed through autoformatters (especially if author _didn't
> think_ about style) is harder to understand then written by thinking humans
>
> I find this statement to be mostly incorrect with regard to Black. There
> are edge cases, but they are few.
>
> On Wednesday, 17 April 2019 09:45:11 UTC+10, Ivan Anishchuk wrote:
>>
>> 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.
>>
>> On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton  wrote:
>>
>>> Ivan, what you’re talking about is subjective code formatting, and lends
>>> itself to extreme bikeshedding and little consensus. Django already has a
>>> formatting standard that mergers try to enforce at review and commit time.
>>> But it’s time consuming, prone to missing things, and requires lots of back
>>> and forth.
>>>
>>> Not having to think of formatting at all, either as a developer or
>>> reviewer, is a major productivity win. Even if some of the formatting
>>> choices are not agreeable.
>>>
>>> On Wed, 17 Apr 2019 at 03:38, 'Ivan Anishchuk' via Django developers
>>> (Contributions to Django itself)  wrote:
>>>
 My two cents: black's mostly ok but I'm against any auto-formatting.
 Code style is much more than whitespace arrangement, it requires looking,
 creative thinking, judging, and sometimes actually compromising rules and
 looks for readability while the usual attitude with such tools is "I have
 this autoformatter tool so I don't have to think about style anymore, see,
 all my whitespace is nice and shining". Using some helpers in your favorite
 editor is great but relying on automatics without looking is almost
 completely counter-productive.

 I find that PR autocommenter is a great way to keep issues detectable
 by flake8/pylint to a minimum.

 Ivan.

 On Sat, Apr 13, 2019 at 6:35 PM 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 

Re: Force "required" fields to be included in a ModelForm

[James Bennett]

Python has a warning system, and Django already uses it for things like
deprecation notices.

I don't like error by default as an approach to this, but a warning (which
is easy to ignore -- it doesn't break your code) would be fine.

-- 
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/CAL13Cg9FfQ4Fv3Mjvw-4qaL4d%3Dbgm1y5pWeYRfA%2BUcJqAymLdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Force "required" fields to be included in a ModelForm

[Tobias McNulty]

There are plenty of use cases when this behavior wouldn't be desired, such
as editing the same model object with 2+ different model forms. Such a
pattern might be more common when editing an existing object, but isn't out
of the question for creating new objects, either (think of a multi-step
form wizard).

Cheers,
Tobias

On Tue, Apr 16, 2019, 8:34 PM Will Gordon  wrote:

> In the same way that editable fields are forced to not be included in a
> ModelForm (
> https://github.com/django/django/blob/master/django/forms/models.py#L146),
> I would like to propose that "required" fields (`blank=False`) be forced to
> be included in a ModelForm.
>
> While I understand that a developer can force this inclusion themselves,
> but on a large project, it should not be necessary to always ensure that a
> Model and ModelForm are in sync.
>
> Since this is probably a non-trivial patch (
> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#non-trivial-patches)
> I need to provide evidence that this has been discussed. As such, I'm open
> to any and all opinions!
>
> --
> 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/980d8112-d51c-4e88-a17f-5e9a4a3577d2%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/CAMGFDKQ4Pk172H-Mo38cnYsaY%2BNC255qkLo8Q5ZTMm8bkVeGnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Josh Smeaton]

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

> and code passed through autoformatters (especially if author _didn't 
think_ about style) is harder to understand then written by thinking humans

I find this statement to be mostly incorrect with regard to Black. There 
are edge cases, but they are few.

On Wednesday, 17 April 2019 09:45:11 UTC+10, Ivan Anishchuk wrote:
>
> 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.
>
> On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton  > wrote:
>
>> Ivan, what you’re talking about is subjective code formatting, and lends 
>> itself to extreme bikeshedding and little consensus. Django already has a 
>> formatting standard that mergers try to enforce at review and commit time. 
>> But it’s time consuming, prone to missing things, and requires lots of back 
>> and forth. 
>>
>> Not having to think of formatting at all, either as a developer or 
>> reviewer, is a major productivity win. Even if some of the formatting 
>> choices are not agreeable. 
>>
>> On Wed, 17 Apr 2019 at 03:38, 'Ivan Anishchuk' via Django developers 
>> (Contributions to Django itself) > > wrote:
>>
>>> My two cents: black's mostly ok but I'm against any auto-formatting. 
>>> Code style is much more than whitespace arrangement, it requires looking, 
>>> creative thinking, judging, and sometimes actually compromising rules and 
>>> looks for readability while the usual attitude with such tools is "I have 
>>> this autoformatter tool so I don't have to think about style anymore, see, 
>>> all my whitespace is nice and shining". Using some helpers in your favorite 
>>> editor is great but relying on automatics without looking is almost 
>>> completely counter-productive.
>>>
>>> I find that PR autocommenter is a great way to keep issues detectable by 
>>> flake8/pylint to a minimum.
>>>
>>> Ivan.
>>>
>>> On Sat, Apr 13, 2019 at 6:35 PM 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 
 

Re: Force "required" fields to be included in a ModelForm

[James Bennett]

As the documentation points out, ModelForm avoids implicitly adding fields
to a form when you haven't told it to, and does so for security reasons.
Mass-assignment bugs have caused significant security issues in the past
for other systems which *did* implicitly support/add fields, and I'd like
to keep Django from doing that.

So if the proposal is just that any field with required=True is implicitly
included, I'd be against it. Similarly, I think it would complicate the API
too much to add support for some kind of "__all_required__" special
declaration.

I would suggest there's value in figuring out a way to either have
ModelForm raise some type of ignorable warning, or maybe having the
system-check framework warn you, if you do have a ModelForm that doesn't
include a required field, though.

-- 
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/CAL13Cg-EJYA7NAzPb%2BpQOR_Ywuzo5A_%3DBGJBS5CYd-J0SoKhSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Force "required" fields to be included in a ModelForm

[Will Gordon]

I can certainly agree that there may be some use cases where it should be 
possible to disable this functionality, but I would argue that erroring on 
a missing, required field should be the default, and allow for a way to 
override...as opposed to allowing missing fields and requiring a workaround 
to ensure they're not missing.

-- 
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/7ab66349-f1e2-4f49-9015-e55761fc8682%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Emil Madsen]

Hello,

I'm not sure if it's relevant for the discussion, but black requires python 
3.6.0+.
Several Linux distros does not ship 3.6.0+ yet, including, but not limited 
to:

* Debian Stretch (current LTS)
* FreeBSD 12 (current release)
* Ubuntu 16.04 Xenial (previous LTS)
* Linux Mint 18.1 (previous LTS)
* OpenSuse Leap 42 (previous LTS)
* Slackware 14.1 (previous LTS)
* Fedora 27 (two versions old)

While it is ofcourse possible to install python 3.6.0+ on these systems, it 
requires more effort than a simple package manager install.

-- 
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/fd23a249-7808-4ab4-a994-1e64d1dfa66f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bugfix on #29103 creates different bug

[Claude Paroz]

For the record, the ticket is https://code.djangoproject.com/ticket/30371. 
The discussion continues there.

Claude

Le lundi 15 avril 2019 16:56:46 UTC+2, Melvyn Sopacua | 3YOURMIND a écrit :
>
> Well, the testcase is a bit hard. I can reproduce it by calling 
> `sqlmigrate` on any migration that adds a char or text field with a default 
> value. The migration it self will go through, but sqlmigrate will fail.
>
> I'll look into testcasing that.
>
> On Mon, Apr 15, 2019 at 3:25 PM Claude Paroz  > wrote:
>
>> Please create a new ticket (where you can reference the original one).
>> If you can provide a failing test case, it would be great.
>>
>> Claude
>>
>> Le lundi 15 avril 2019 13:40:53 UTC+2, Melvyn Sopacua | 3YOURMIND a 
>> écrit :
>>
>>> Hi,
>>>
>>> I've added a comment on the commit: 
>>> https://github.com/django/django/commit/3c4ff2176323dd20507e35658599da220fbe1741
>>>
>>> Should I reopen the bug or create a new one? Also it would help to know 
>>> what the return type is supposed to be or what the intention of the code 
>>> is? Should the if clause be `not instance` and should we be decoding or is 
>>> the test correct and should we be encoding?
>>> -- 
>>>
>>> *Backend Developer*
>>>
>>> Mobile: +49 (0)160 179 6874
>>> eMail: m...@3yourmind.com
>>> Web: www.3yourmind.com 
>>> 
>>>
>>>
>>>
>>> P.S. Ready for the #ManufacturingRevolution? Watch our new videos here 
>>> .
>>>
>>>  
>>>
>>> P.P.S. Follow the top industry trends 
>>> 
>>>  
>>> in our newsletter.
>>>
>>>  
>>>
>>> Meet us at:
>>>
>>> Rapid+TCT  | 20 - 23 May  | Detroit, USA| 
>>> Booth 753
>>>
>>> 3D Print Lyon  | 4 - 6 June | 
>>> Lyon, FR
>>>
>>> Rapid.Tech Fabcon 3.D   | 25 - 27 
>>> June | Erfurt, DE | Booth 2-415
>>>
>>>  
>>>
>>> We're hiring self-driven, innovative, AM-focused people here. 
>>> 
>>>
>>>
>>> 3YOURMIND GmbH
>>>
>>> Bismarckstraße 10-12 | 10625 Berlin | Germany
>>>
>>>  
>>>
>>> VAT ID - USt-IdNr. gemäß § 27 a Umsatzsteuergesetz: DE296555110
>>>
>>> Company with its registered seat in - Sitz der Gesellschaft: Berlin
>>>
>>> Register court - Registergericht: Amtsgericht Charlottenburg (Berlin)
>>>
>>> Register number - Registernummer: HRB 160616
>>>
>>> Executive Manager - Geschäftsführer: Aleksander Ciszek & Stephan Kühr
>>>
>> -- 
>> 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/3324c145-6f7b-468f-b98a-df738f33a557%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
>
> *Backend Developer*
>
> Mobile: +49 (0)160 179 6874
> eMail: m...@3yourmind.com 
> Web: www.3yourmind.com 
> 
>
>
>
> P.S. Ready for the #ManufacturingRevolution? Watch our new videos here 
> .
>
>  
>
> P.P.S. Follow the top industry trends 
> 
>  
> in our newsletter.
>
>  
>
> Meet us at:
>
> Rapid+TCT  | 20 - 23 May  | Detroit, USA| 
> Booth 753
>
> 3D Print Lyon  | 4 - 6 June | Lyon, 
> FR
>
> Rapid.Tech Fabcon 3.D   | 25 - 27 June 
> | Erfurt, DE | Booth 2-415
>
>  
>
> We're hiring self-driven, innovative, AM-focused people here. 
> 
>
>
> 3YOURMIND GmbH
>
> Bismarckstraße 10-12 | 10625 Berlin | Germany
>
>  
>
> VAT ID - USt-IdNr. gemäß § 27 a Umsatzsteuergesetz: DE296555110
>
> Company with its registered seat in - Sitz der Gesellschaft: Berlin
>
> Register court - Registergericht: Amtsgericht Charlottenburg (Berlin)
>
> Register number - Registernummer: HRB 160616
>
> Executive Manager - Geschäftsführer: Aleksander Ciszek & Stephan Kühr
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  

Re: GSoC Proposal: Add Cross-DB JSONField, ArrayField, and HStoreField

[Raphael Michel]

Hi Sage, Hi everyone,

I lacked the time to read this mailing list in the past months, and
someone at DjangoCon Europe just pointed me to this thread, so just for
reference, I want to add some prior work that I did to the list:

At DjangoCon US and thereafter, I developed a third-party
implementation that does a little more than the ones that are more
well-known and mentioned in the proposal:

https://github.com/raphaelm/django-jsonfallback

django-jsonfallback supports native JSON fields on PostgreSQL, MariaDB
*and* MySQL (which are quite different in that regard). On all other
databases, it falls back to the behaviour of just storing strings in
text fields. Therefore, it's still different from what is being
proposed here, and also the implementation is quite unclean in the
sense that it needs to check for database backends on the level of
database fields. When implemented in core, this could be done much more
nicely.

Still, it might be an interesting thing to look at when doing this, if
only for the test cases and the weird MySQL/MariaDB things. I'd love to
see this in core and are happy to help wherever I can with my expertise.

Best
Raphael

Am Tue, 2 Apr 2019 04:41:36 -0700 (PDT)
schrieb "Sage M.A." :

> Hello, everyone! My name is Sage. I'm a 19-year-old computer science 
> student from Indonesia. I'm planning to join the Google Summer of
> Code (GSoC) this year, and I want to contribute to Django. I have
> written a draft for my proposal in this gist 
> .
> I have submitted two small patches for Django, and I hope to
> contribute more in the future. Feedbacks are much appreciated, thanks!
> 

-- 
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/20190416114408.35c8afa4%40kvothe.
For more options, visit https://groups.google.com/d/optout.


pgp5YMkBtqawZ.pgp
Description: Digitale Signatur von OpenPGP

Re: Proposal to format Django using black

[Florian Apolloner]

Hi Emil,

this would only affect Django 3.0 which supports only python3.6 -- as such 
you couldn't even run Django on those systems anyways.

Cheers,
Florian

On Tuesday, April 16, 2019 at 10:12:20 AM UTC+2, Emil Madsen wrote:
>
> Hello,
>
> I'm not sure if it's relevant for the discussion, but black requires 
> python 3.6.0+.
> Several Linux distros does not ship 3.6.0+ yet, including, but not limited 
> to:
>
> * Debian Stretch (current LTS)
> * FreeBSD 12 (current release)
> * Ubuntu 16.04 Xenial (previous LTS)
> * Linux Mint 18.1 (previous LTS)
> * OpenSuse Leap 42 (previous LTS)
> * Slackware 14.1 (previous LTS)
> * Fedora 27 (two versions old)
>
> While it is ofcourse possible to install python 3.6.0+ on these systems, 
> it requires more effort than a simple package manager install.
>
>

-- 
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/978cc4b6-ede8-4dde-8591-4e6ad3bfb51b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal to format Django using black

[Christian González]

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

I've filed a feature request for git itself
(https://public-inbox.org/git/5df051ce-007c-cc12-6f02-345b33480...@nerdocs.at/T/),
and it seems that there is a feature within git which is in development
and seems to deal with that blame-before-not-important-commits issues.
Like I said there, it's not perfect IMHO, and would be done easier by
using a config file and individual/project specific commit takeouts for
blaming. That's certainly seen for long-term, but When Django 3.0 will
arrive, hopefully with black 1.x, it's early enough for "git with blake
skip support" too. And, as it's only for development, It would be fully
backwards compatible for git users that don't have support for that
feature - they could always use black/git and skip blame the "old" way.

That said, I hope black will be used in Django.

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/abf83a20-9485-c367-eed1-57e3ad88ef4f%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.


pEpkey.asc
Description: application/pgp-keys