Re: Experience with black formatting in django

2022-05-18 Thread 'Adam Johnson' via Django developers (Contributions to Django itself) 
Hi!

Although the DEP for Black was written several years ago, we only actually
adopted it in the code base in February this year. The DEP determined to
use Black when it was no longer beta, and that took a while :)

I think the reformatting was fairly popular, many people have given
positive reactions on the PR: https://github.com/django/django/pull/15387 .
My impression is there's only a minority who dislike Black, and often only
one thing like the choice of double quotes.

The fellows (Carlton and Mariusz) do most of the day-to-day work, and they
would have a better view on whether there has been any friction with new or
returning contributors. I know that rebasing the existing branches was a
bit of work, but one off.

Personally I adopted Black across the open source projects I maintain years
ago, and haven't had any problems. I use pre-commit and pre-commit.ci to
run Black and automatically reformat PR's. This means even contributors
don't need to run it locally.

My advice would be to adopt :)

All the best,

Adam

On Tue, May 17, 2022 at 3:04 PM Tom Aldcroft  wrote:

> The astropy project is currently considering implementing code formatting
> with black, much as Django did in 2019. I was happy to see the case for
> transitioning to black formatting in Django DEP-0008 (
> https://github.com/django/deps/blob/main/final/0008-black.rst). I think
> it captures the key points both pro and con, along with the inevitable lack
> of complete consensus in a large project.
>
> My goal in writing is to request feedback from Django developers about how
> this transition has impacted django development and community engagement in
> the three years since the transition.
>
> Has there been specific feedback from contributors (both experienced and
> new) related to black autoformatting?
>
>- Ease of actually running black and meeting the black-format standard
>for PRs. Have there been technical problems that required assistance?
>- Style considerations?
>
> Have most core developers accepted or embraced the black style at this
> point? The DEP included some testimonials to that effect, but some of us
> wondered if those represented a fair sampling of the community.
>
> Are there any regrets or things you would change?
>
> Do you have any advice for the astropy project?
>
> Any feedback from your experience would be most appreciated.
>
> Regards,
> Tom (@taldcroft on GitHub)
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/33b9a27e-2a0c-4e7c-ba2b-c5072a87073an%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1j0pa%3D5iQeFL%2BZr4QOb2-kjYtj%2BRG%3DPNsxsEv0RqDTRg%40mail.gmail.com.

Re: Django 4.1 alpha 1 released

2022-05-18 Thread אורי 
Hi,

Django 4.0 had this code:

errors = {}
if exclude is None:
exclude = []
else:
exclude = list(exclude)

try:
self.clean_fields(exclude=exclude)
except ValidationError as e:
errors = e.update_error_dict(errors)

In Django 4.1 alpha it looks like this:

errors = {}
if exclude is None:
exclude = set()
else:
exclude = set(exclude)

try:
self.clean_fields(exclude=exclude)
except ValidationError as e:
errors = e.update_error_dict(errors)

My model tests fail:
==
ERROR: test_username_too_long_exception_4
(speedy.core.accounts.tests.test_models.ReservedUsernameHebrewTestCase)
--
Traceback (most recent call last):
  File
"D:\Uri\Speedy_Net\Git\speedy-net-public\speedy\core\accounts\tests\test_models.py",
line 395, in test_username_too_long_exception_4
reserved_username.save()
  File
"D:\Uri\Speedy_Net\Git\speedy-net-public\speedy\core\base\models.py", line
21, in save
return super().save(*args, **kwargs)
  File
"D:\Uri\Speedy_Net\Git\speedy-net-public\speedy\core\base\models.py", line
12, in save
self.full_clean()
  File
"D:\Uri\Speedy_Net\Git\speedy-net-public\.venv_3.9\lib\site-packages\django\db\models\base.py",
line 1464, in full_clean
self.clean_fields(exclude=exclude)
  File
"D:\Uri\Speedy_Net\Git\speedy-net-public\speedy\core\accounts\models.py",
line 182, in clean_fields
exclude += ['username', 'slug']
TypeError: unsupported operand type(s) for +=: 'set' and 'list'

--

Is `exclude` a set now (instead of a list) and where is it documented? If
it's not documented, please document it. I didn't find it documented on
https://docs.djangoproject.com/en/dev/releases/4.1/.

What is the best written code to change the line `exclude += ['username',
'slug']` in my code? Is it `exclude |= set(['username', 'slug'])` or
`exclude |= {'username', 'slug'}`? Or should I convert to list and then
back to set?

What is the reason `exclude` was changed to a set?

Thanks,
Uri.

אורי
u...@speedy.net


On Wed, May 18, 2022 at 9:09 AM Carlton Gibson 
wrote:

> Details are available on the Django project weblog:
>
>
> https://www.djangoproject.com/weblog/2022/may/18/django-41-alpha-1-released/
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJwKpyQmCB6q__p167GcmaH8dBT%3D-jSbtr2LLb_E63E9QRQUXQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeFuepUy_Mr6fqvPU6GX-0su-8SXpW8W2P4%3DjfWbxwTgPQ%40mail.gmail.com.

Re: Django 4.1 alpha 1 released

2022-05-18 Thread אורי 
Hi,

In my code there is clean_fields with exclude as an optional argument:

def clean_fields(self, exclude=None):
"""
Allows to have different slug and username validators for Entity
and User.
"""
if (exclude is None):
exclude = []

Is it still optional and should I define it as a set if it's None? Or is it
not optional any more?

I see in Django 4.1 alpha this is the code now:
def clean_fields(self, exclude=None):
"""
Clean all fields and raise a ValidationError containing a dict
of all validation errors if any occur.
"""
if exclude is None:
exclude = set()



אורי
u...@speedy.net


On Wed, May 18, 2022 at 9:09 AM Carlton Gibson 
wrote:

> Details are available on the Django project weblog:
>
>
> https://www.djangoproject.com/weblog/2022/may/18/django-41-alpha-1-released/
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJwKpyQmCB6q__p167GcmaH8dBT%3D-jSbtr2LLb_E63E9QRQUXQ%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeG9RYV2%2BqKN1_XT%2Bn0%3DJ6W2G0t-OWFBB-pLWQQFvEVJDQ%40mail.gmail.com.