Re: Fellow Reports -- October 2019
Hi all. Calendar Week 42 -- ending 20 October. Triaged: https://code.djangoproject.com/ticket/30536 -- Allow running custom logic in django.setup(). (wontfix) https://code.djangoproject.com/ticket/28752 -- Prevent django.setup() from running multiple times (wontfix) https://code.djangoproject.com/ticket/30887 -- UnicodeEncodeError problem while saving binary to database (invalid) https://code.djangoproject.com/ticket/30890 -- Support relate spatial lookup on MariaDB 10.1+ (Accepted) https://code.djangoproject.com/ticket/30888 -- Dangerous behavior for queryset combinator (Duplicate of #27995) https://code.djangoproject.com/ticket/26481 -- Add a "strict mode" for defer()/only() to prevent queries on unfetched field access (Duplicate of #22492) Reviewed: https://github.com/django/django/pull/11933 -- Fixed #30890 -- Added MariaDB support for the relate lookup. https://github.com/django/django/pull/11908 -- Fixed #20456 -- Modified View.setup to ease testing # https://github.com/django/django/pull/11408 -- Fixed #29799 -- Allowed registration and unregistration of lookups per field instances. https://github.com/django/django/pull/11435 -- Refs #30536 - Make django.setup() idempotent and tweakable https://github.com/django/django/pull/11440 -- Fixed #28752 -- Made django.setup() idempotent. https://github.com/django/django/pull/11928 -- Fixed #30885 -- Dropped support for MariaDB 10.1. https://github.com/django/django/pull/11927 -- Fixed #30562 -- Doc'd MariaDB support for GIS spatial lookups. https://github.com/django/django/pull/11925 -- Refs #28436 -- Corrected docs regarding MySQL support of distance lookups. https://github.com/django/django/pull/11919 -- Fixed #28699 - Deferred CSRF token rotation on login to middleware process response phase. Authored: https://github.com/django/django/pull/11921 -- Moved "Sign the CLA" to bottom of New Contributor First Steps. https://github.com/django/django/pull/11903 -- Fixed #30872 -- Improved unknown command message when settings are manually configured. Calendar Week 43 -- ending 27 October. Triaged: https://code.djangoproject.com/ticket/30910 -- Add system check warning on duplicate check constraints. (Accepted) https://code.djangoproject.com/ticket/30906 -- Error Outputting CSV code example. Template.render() does not accept Context objects. (Accepted) https://code.djangoproject.com/ticket/30902 -- The value of a TextChoices/IntegerChoices field has a differing type (Accepted) https://code.djangoproject.com/ticket/30894 -- Reverse OneToOneField relation: `prefetch_related` uses `related_name` while `select_related` uses `related_query_name` (wontfix) https://code.djangoproject.com/ticket/30895 -- Multiples trailing slashes appended to URL (Invalid) Reviewed: https://github.com/django/django/pull/11974 -- Refs #30908 -- Fixed the empty value of forms.FilePathField in docs. https://github.com/django/django/pull/11504 -- Fixed #29087 -- Added delete buttons for unsaved admin inlines on validation error. https://github.com/django/django/pull/11955 -- Fixed #30897 -- Improved QuerySet.explain() for newer versions of MariaDB, MySQL and PostgreSQL. https://github.com/django/django/pull/11968 -- Fixed DatabaseFeatures.update_can_self_select on MariaDB 10.3+. https://code.djangoproject.com/ticket/20935 -- ePub documentation not valid https://github.com/django/django/pull/11963 -- Refs #29926 -- Bumped minimum tblib version to 1.5.0 in test requirements. https://github.com/django/django/pull/11962 -- Bumped minimum Pillow version to 6.2.0 in test requirements. https://code.djangoproject.com/ticket/30252 -- ImageField's to_python() stores reference to closed Image object Authored: https://github.com/django/django/pull/11967 -- Fixed #30900 -- Skipped asgi tests for Windows using Python 3.8.0. https://github.com/django/django/pull/11964 -- Fixed #30902 -- Added __str__ for model choice enums. https://bugs.python.org/issue38563 -- Asyncio regression on Windows with Python 3.8 https://github.com/django/asgiref/pull/133 -- Fixed #132 -- Set explicit loop policy for Windows & Python 3.8. Kind Regards, Carlton -- 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/103299aa-4688-4f5a-8fb5-4de71a990f9a%40googlegroups.com.
Re: Removing old branches from the Django Git repository.
OK, just to double-confirm. We will move the `soc` and `attic` branches to tags[*] with the next releases (Nov 4th that will be). [*] Loosely: A branch is just tag that updates right? You can check them out, or create new branches from them just as easily. And these are "branches" that never will be updated[+]. [+] At some future point, I'm might be inclined to do similar to EOL `stable` branches... (Don't shoot me, note "at some future point..." :) Kind Regards, Carlton On Monday, 21 October 2019 20:42:52 UTC+2, Shai Berger wrote: > > +1 for keeping some way to reach these. > > I was going to suggest two steps: Moving the soc*/* branches "under" > attic (that is, renaming them with the attic prefix), and using > something like "zzzattic" for the attic prefix so all attic branches > get pushed to the end of the list and don't get in the way so much. > > But tags sound even better. > > On Fri, 11 Oct 2019 07:01:19 +0200 > Carlton Gibson > wrote: > > > Tom’s Tag idea seems to hit the balance. > > > > I’d like to clean them out. I use git branch all day and they’re just > > noise there. > > > > Tags would keep the references we’d need to check them out, without > > the additional work of creating a separate repo, or learning > > new/arcane git features, which don’t merit the effort on any given > > day. > > > > On Fri, 11 Oct 2019 at 02:28, Tim Graham > wrote: > > > > > Same proposal from 2016: > > > > https://groups.google.com/d/topic/django-developers/sf2adeIAkQA/discussion > > > > > > On Thursday, October 10, 2019 at 4:09:24 PM UTC-4, Tom Forbes > > > wrote: > > >> > > >> I second this, there are a few other branches in that list > > >> (successful or not) that have historic value to Django. Is there a > > >> pressing need to delete them, other than spring cleaning? > > >> > > >> I guess maybe it’s sentimental value, and nobody would ever check > > >> them out, but still... > > >> > > >> Tom > > >> > > >> On 10 Oct 2019, at 20:15, Adam Johnson wrote: > > >> > > >> Can we leave magic-removal as a tag since it’s such a pivotal > > >> point in djangos history? xD > > >> > > >> On Thu, 10 Oct 2019 at 19:09, Mariusz Felisiak > > >> wrote: > > >> > > >> Hi y'all, > > >>> > > >>> We're going to remove some old branches from the Django Git > > >>> repository on 1st November 2019: > > >>> > > >>>- *9* old branches related with Google SOC projects: > > >>>- soc2009/admin-ui > > >>> - soc2009/http-wsgi-improvements > > >>> - soc2009/i18n-improvements > > >>> - soc2009/model-validation > > >>> - soc2009/multidb > > >>> - soc2009/test-improvements > > >>> - soc2010/app-loading > > >>> - soc2010/query-refactor > > >>> - soc2010/test-refactor > > >>>- *17* *attic* branches: > > >>> - attic/boulder-oracle-sprint > > >>> - attic/full-history > > >>> - attic/generic-auth > > >>> - attic/gis > > >>> - attic/i18n > > >>> - attic/magic-removal > > >>> - attic/multi-auth > > >>> - attic/multiple-db-support > > >>> - attic/new-admin > > >>> - attic/newforms-admin > > >>> - attic/per-object-permissions > > >>> - attic/queryset-refactor > > >>> - attic/schema-evolution > > >>> - attic/schema-evolution-ng > > >>> - attic/search-api > > >>> - attic/sqlalchemy > > >>> - attic/unicode > > >>> > > >>> Best, > > >>> Mariusz > > >>> > > >>> -- > > >>> 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 view this discussion on the web visit > > >>> > https://groups.google.com/d/msgid/django-developers/9837cb41-66bc-40f2-8296-75f0ad173ee3%40googlegroups.com > > > >>> < > https://groups.google.com/d/msgid/django-developers/9837cb41-66bc-40f2-8296-75f0ad173ee3%40googlegroups.com?utm_medium=email&utm_source=footer> > > > > >>> . > > >>> > > >> -- > > >> Adam > > >> > > >> -- > > >> 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 view this discussion on the web visit > > >> > https://groups.google.com/d/msgid/django-developers/CAMyDDM2kqTztbjzBg%2BOtTCO1M-5TxpaguH60BNv3m5TUe2T-dw%40mail.gmail.com > > > >> < > https://groups.google.com/d/msgid/django-developers/CAMyDDM2kqTztbjzBg%2BOtTCO1M-5TxpaguH60BNv3m5TUe2T-dw%40mail.gmail.com?utm_medium=email&utm_source=footer> > > > > >> . > > >> > > >> -- > > > You received this message because you are subscribed to the Google > > > Group
Re: Adding Occitan language code 'oc' in LANG_INFO
That looks good to me. To avoid mutating Django's default setting (though
it's unlikely to do any harm), I'd do:
from django.conf import global_settings
LANGUAGES = global_settings.LANGUAGES + [('oc', gettext_lazy('Occitan'))]
Would you like to make a documentation PR to reword it to not just talk
about restricting? There are many more languages in the world than in
Django right now!
On Sun, 27 Oct 2019 at 12:34, Yann Sionneau wrote:
> Hi,
>
> Thanks Adam for your quick answer!
>
> I investigated this a bit more in depth.
>
> It seems that Django cannot use any translation that the visitor would
> want (via cookie or via Accept-Language header) if the language code is not
> in settings.LANGUAGES.
>
> If I read documentation about settings.LANGUAGES :
> https://docs.djangoproject.com/en/2.2/ref/settings/#languages
>
> it says :
>
> "Generally, the default value should suffice. Only set this setting if you
> want to restrict language selection to a subset of the Django-provided
> languages."
>
> So the documentation is talking about *restricting* the list, not
> expanding it.
>
> Anyway, I tried to expand it, it seemed to work.
>
> I did this in my settings file:
>
> LANGUAGES.append(
> ('oc', gettext_lazy('Occitan')),
> )
>
> Would you say that my understanding is correct? Is my solution correct?
> The best one?
>
> Thanks!
>
> Yann
> Le 25/10/2019 à 15:00, Adam Johnson a écrit :
>
> Hi Yann,
>
> I'm no translation expert, but I believe you can add your own language
> codes in your project and translate your project's strings. To be added to
> core django I think we need (at least some) translation coverage. The last
> language added was Armenian, in this PR:
> https://github.com/django/django/pull/10830 . The translations were first
> submitted on Transifex:
> https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations
>
> Thanks,
>
> Adam
>
> On Fri, 25 Oct 2019 at 10:47, Yann Sionneau wrote:
>
>> Hello,
>>
>> Do you think there would be any show stopper preventing from adding
>> Occitan language in
>>
>> django/conf/locale/__init__.py LANG_INFO ?
>>
>> That would (I think) allow Django apps to use 'oc' translations.
>>
>> Cheers,
>>
>> --
>>
>> Yann
>>
>> --
>> 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/aa5f8eb8-4ad3-e52b-16b8-38aa911a7c2e%40sionneau.net
>> .
>>
>
>
> --
> Adam
> --
> 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/CAMyDDM1YDoNw1%3D21E0UpVMyvygAvJJEZrvS1wHemLvEJbf5F4Q%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/e20fa361-9345-fc3f-6844-b0378e81e98d%40sionneau.net
>
> .
>
--
Adam
--
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/CAMyDDM3HwZzHKmTZm%2Bgf3%2BGVjFLOL8TQedg9yk__a0jARj37tA%40mail.gmail.com.
Allowing numbers in the top level domain
https://code.djangoproject.com/ticket/30924#ticket
The current regex in URLValidator does not allow numbers in the top-level
domain
e.g. www.example.org33 raises a ValidationError
Rarely, if ever, do public top-level domains contain a number, however
internal, private networks can certainly be configured with numbers present
in the top-level domain. Thus it is important to handle these URIs without
having to specify custom regex patterns to pass into the URLValidator.
The change can be achieved by replacing the following line in the
URLValidator class:
r'(?:[a-z' + ul + '-]{2,63}'
with
r'(?:[a-z' + ul + r'0-9' + '-]{2,63}'
I think the same rationale for allowing dashes in the top level domain (
https://code.djangoproject.com/ticket/25452#comment:2) can be argued for
this case
To note, the above line change would allow for addresses like
http://1.1.1.1.1
http://123.123.123
to pass, which are currently in invalid_urls.txt
I am hoping this post generates some meaningful discussion around this
proposed design change, 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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/b622e51b-3854-493f-b2f6-cd143157b8c2%40googlegroups.com.
Allowing numbers in top level domain
https://code.djangoproject.com/ticket/30924#ticket
The current regex in URLValidator does not allow numbers in the top-level
domain
e.g. www.example.org33 raises a ValidationError
Rarely, if ever, do public top-level domains contain a number, however
internal, private networks can certainly be configured with numbers present
in the top-level domain. Thus it is important to handle these URLs without
having to specify custom regex patterns to pass into the URLValidator.
The change can be achieved by replacing the following line in the
URLValidator class:
r'(?:[a-z' + ul + '-]{2,63}'
with
r'(?:[a-z' + ul + r'0-9' + '-]{2,63}'
To note, the proposed change above does allow for addresses like
http://1.1.1.1.1
http://123.123.123
which are currently listed under invalid_urls.txt
I think the rationale for allowing dashes in the top level domain (
https://code.djangoproject.com/ticket/25452#comment:2) can be applied to
this case as well.
I am hoping this post can generate some insightful discussion around this
topic. 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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/007a2765-f906-4db9-b77f-ecf9fb8fbb2a%40googlegroups.com.
