Re: select_for_update and transactions (bad dev UX in a feature)

Hello, > On 18 Nov 2021, at 11:11, Florian Apolloner wrote: > > FWIWI I always recommend disabling ATOMIC_REQUESTS and using transactions as > needed :) Investing engineers' time into evaluating the exact transactional integrity requirements of every view may be appropriate in some

Re: Proposed change in ORM model save logic

Hello, > On 15 Oct 2021, at 08:49, Barry Johnson wrote: > > Instead of resolving this difference in keys by executing: > setattr(self, field.attname, obj.pk) > We believe it should instead: > setattr(self, field.name, obj) For anyone reading this, this code is

Re: Proposal for a transaction.on_before_commit

Hello Raphael, Oh - a use case for django-transaction-signals ;-) I'm bringing up this elaborate joke because you're essentially asking for a "pre-commit" signal here and the README contains a good list of things that can go wrong with

Re: Custom Groups model and interoperability

Hello, The semi-official position is "create a separate model with a FK to the auth.Group". I know that's less than helpful. At least you know that there's nothing better built-in. -- Aymeric. PS: `{% block content %}` doesn't provide a meaningful level of interoperability. The

Re: Feature request : Load signals automatically

Hello, I'd like to to chime in quickly as I'm responsible for this boilerplate (see this talk , slide 33). This is really a question of convention vs. configuration. Django tends to prefer configuration over convention, because there's

Re: Django models `EmailField` default is empty string - Not `None` (or Null) . Why ?

Hello, https://docs.djangoproject.com/en/3.2/ref/models/fields/#django.db.models.Field.null should clarify the situation. -- Aymeric. > On 13 Jun 2021, at 13:17, Carlos Leite wrote: > > > Yesterday I

Re: Transaction APIs do not consult the DB router to choose DB connection

> On 3 Jun 2021, at 12:03, N Aditya wrote: > > 1. If atomic(using=...) is the way to go and the same has been implemented > for ORM queries as well, why introduce something like the routers framework > in the first place ? You can meaningfully route individual ORM queries based on the model

Re: Transaction APIs do not consult the DB router to choose DB connection

> On 2 Jun 2021, at 07:49, N Aditya wrote: > > Below are a few things I'd like to clarify: > Are you referring to thread-locals as `global state/variables` in your > previous message ? Yes. > If so, why suggest something which you consider bad practise ? You rejected the good practice before —

Re: Transaction APIs do not consult the DB router to choose DB connection

Hello, > On 1 Jun 2021, at 14:35, N Aditya wrote: > > All I'm looking for is a hook that the transaction APIs can call before > deciding on which database to use. I don't see any reason for why providing a > hook seems so difficult. Just because something is easy to implement doesn't mean

Re: Transaction APIs do not consult the DB router to choose DB connection

Hello, The first item in Django's design philosophies is Loose coupling . Per this principle, the database layer shouldn't know about the HTTP layer. This is a strong reason for keeping the HTTP request object

Re: Let's simplify coding with html

Hello, There are several projects providing alternate syntax for generating HTML, along the lines of your suggestion, and other projects for integrating these with Django. Here's one such project: https://github.com/nyaruka/django-hamlpy . I believe

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

time to make progress here but, what did you think > about allowing an early opt-in for Django v3.2? (I’m not sure we have > capacity to get the in in-time now anyway, so it may be moot.) > > Kind regards, > Carlton. > > > > On Sat, 2 Jan 2021 at 10:29, Aymeric August

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

Hello, As the original author of support for timezone aware datetimes in Django, I've been meaning to review this... for six months... Better late than never I guess? In this discussion, we're assuming settings.USE_TZ = True. The original design

Re: Ticket #21289 - Login rate limiting

Hello, Having some basic throttling built-in would be an improvement for the vast majority of websites. Also it would plug one of the big holes in django.contrib.auth (another big one being 2FA). Some DoS concerns were expressed on the pull request. I believe the options are: 1. use a global

Re: Should the docs suggest namespace packages?

on that consensus, my inclination wouldn't be to try to make > Django work with as few __init__.py files as possible. What do you think? > > > On Thursday, May 21, 2020 at 7:52:49 AM UTC-4 Adam Johnson wrote: > +1 for reverting ccc25bf . > > On Wed, 20 May 2020 at 19:54, Ayme

Re: Custom collation support

Hello Tom, Just wanted to give you some encouragement here, as you've been monologuing for two months ;-) The PR looks promising! Regarding migrations, I'm not seeing how the collation for a column will be set or unset in the database if you change it in the code e.g.: MySQL : ALTER TABLE ...

Re: Django Query optimizing performance (HUGE DATA)

Hello, I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are

Re: The blacklist / master issue

Hello, In the context of access control, blacklist / whitelist makes sense only if the reader has a preconceived assumption that black = bad, illegal, forbidden / white = good, legal, authorized. You can probably see where I'm going. Sure, blacklist / whitelist has nothing to do with race to

Re: ./manage.py settings

Django already attempt to mask security-sensitive settings in the debug page. It would make sense to do the same by default for the output of diffsetting: obfuscate secrets. A --include-secrets flag (on any other name) would show the secrets. -- Aymeric. > On 12 Jun 2020, at 13:59, Jure

Re: Implement QuerySet.__contains__?

> If people agree QuerySet.contains() should be added, how do we move forward? Yes, if there's no major new argument in a couple days, we can assume consensus on adding .contains(). * Create a ticket in Trac. Point to this discussion and to the previous ticket where .contains() was suggested.

Re: What happens if a Fellow has a holiday?

Hello, It would be best if fellows took 5 weeks off per year — or whatever is common in their country. Our usual strategy for tackling fragile processes is to see what breaks then figure out a solution. Enjoy your holidays. We'll learn how much we depend on you :-) -- Aymeric. > On 4

Re: Implement QuerySet.__contains__?

> On 2 Jun 2020, at 19:42, Tim Graham wrote: > > And here's some past discussion: > https://code.djangoproject.com/ticket/24141 - contains() method for QuerySets > (closed as needsinfo due to no mailing list discussion to find a consensus) > https://github.com/django/django/pull/3906 -

Re: Implement QuerySet.__contains__?

> On 2 Jun 2020, at 13:30, Florian Apolloner wrote: > > On Tuesday, June 2, 2020 at 11:28:34 AM UTC+2, Adam Johnson wrote: > If you already fetched the queryset, `if obj in queryset` will make a new > database query > > I don't see why we couldn't implement __contains__ to do a walk through >

Re: Implement QuerySet.__contains__?

Hello Johan, You explained the upside. There's one downside to be aware of. If you already fetched the queryset, `if obj in queryset` will make a new database query, which will be slower than walking through the already fetched data (unless the queryset is really large and the database really

Re: Should the docs suggest namespace packages?

Hello, Commit ccc25bf refers to ticket #23919 in the commit message. In that ticket, I argued that the __init__.py files should be kept: https://code.djangoproject.com/ticket/23919#comment:102 . No one brought a counter argument. It's

Re: Clear all filters

On 18 May 2020, at 11:10, Mariusz Felisiak wrote: > Link to the right of the search box ("X total") already removes the entire > query string, so ... Ah, this is a bug I'm hitting! I have a small personal app where I classify data. Some classification is automated with regexes. New data

Re: Management of static assets

Thanks David for investigating the topic thoroughly! I wasn't expecting all that when I filed a one-line ticket six years ago :-) So, here's a bunch of opinions. Before I start, I'd like to quote the intro to the Media class : >

Re: Technical Board statement on type hints for Django

Sorry for the late answer, I didn't have time to read this mailing list for the last month :-( Here's my position on the matter. Adding type annotations only makes sense if a type checker checks them. Otherwise, they're unlikely to be correct and usable, so it would be counterproductive to add

Re: Removing url() ?

Hello, When proposing deprecations that require numerous but simple code changes, providing an automated upgrade path could reduce frustrations about "useless churn". Unfortunately, I don't know a great way to do that on Python code. Here are the options I'm aware of: - Writing 2to3 fixers

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

Hello, This is quite disruptive — says the guy who suggested to remove request.REQUEST a few years back — but I think we could go ahead and do it. The names proposed by Adam are good. I read the concerns about (e.g. for search forms) where form data ends up in query_params and not form_data.

Re: New Merger nomination.

Hello, I trust Claude to act as a Merger as described in DEP 10. I vote in favor. With apologies for the late answer! -- Aymeric. > On 21 Apr 2020, at 20:11, Andrew Godwin wrote: > > I also vote in favour of Claude becoming a Merger! > > Andrew > > On Tuesday, April 21, 2020 at 4:28:41

Re: GSoC Proposal to extend the parallel test runner to Windows and macOS and to support Oracle parallel test running

test runner originally even > on Linux and I propose to extend support to Oracle as well in my proposal. I > want to confirm if there is significant support behind this as a feature or > not before I commit to writing a specification, but as a summary it is > definitely possible

Re: Support for MongoDB

Hello Sanskar, You can find discussions about this issue in archives of this mailing list. I don't think it came up recently; you'll have to go a few years back. Support for MongoDB would mean support in the ORM. The R in ORM stands for Relational. MongoDB isn't a relational database.

Re: Proposal to deprecate NullBooleanField (and remove in Django 4.0)

Hello, I'm inclined to Accept as well. -- Aymeric. > On 17 Mar 2020, at 08:49, Carlton Gibson wrote: > > Hi all. > > > https://code.djangoproject.com/ticket/31369 > Proposes to deprecate NullBooleanField. > > > https://code.djangoproject.com/ticket/29227 > Allowed BooleanField to be

Re: Deprecating logout via GET

Hello, Le dim. 1 mars 2020 à 11:04, Adam Johnson a écrit : > Yes, but then hovering on the link doesn't show the logout URL at the >> bottom of the screen. > > > I don't think this is a concern. > If it's just the link preview, yes, I think we can make the trade off. The more general concern

Re: Proposal: Multiple-Inheritance in Templates

This suggestion is better than mine for the use case discussed here :-) -- Aymeric. > On 18 Feb 2020, at 21:57, Matthias Kestenholz wrote: > > Hi, > > You could make the generic-list.html template extend a configurable base > template, e.g. "{% extends base_template|default:'base.html'

Re: Proposal: Multiple-Inheritance in Templates

Hello Yo-Yo Ma, Please assume good faith. You've been around for 11 years, so you know the way you address Matthew isn't how we behave on this mailing-list. I believe that the most common way to achieve what you want is to include the "generic list" HTML with the {% include %} tag. This allows

Re: Use "raise from" where appropriate, all over the codebase

Hello Ram, > On 6 Feb 2020, at 19:08, Ram Rachum wrote: > > In other words, "raise from" is the inevitable future, it's just that we're > not in a rush to get there. I'm not sure how you came to this conclusion; I'm not seeing this in Carlton's and Mariusz' answers. Carlton only said that

Re: Admin: Making raw_id fields navigable for readonly users

Hello Julien, This would be a nice UX improvement. The link should only be rendered if the user has permission to view the target model. Perhaps a stupid question, but — wouldn't this apply to non-raw_id, readonly foreign keys as well? I don't think they're rendered as links, are they? Best

Automatically discovering AppConfig subclasses

Hello, Since the app-loading refactor in Django 1.7, we recommend referencing AppConfig classes in INSTALLED_APPS e.g. "django.contrib.admin.apps.AdminConfig". I don't think this style gained a lot of traction compared to the legacy, shorter style e.g. "django.contrib.admin". As a

Re: GDAPS

>> Maybe an error message would be better. default=true should only be valid >> once! >> >> Best regards, >> >> Christian >> >> >> Am 12.01.20 um 21:42 schrieb Aymeric Augustin: >>> Hello, >>> >>> I created a PR

Re: GDAPS

Hello, I created a PR for this: https://github.com/django/django/pull/12310 I'd love to get some feedback on the design before I polish the patch. Best regards, -- Aymeric. > On 10 Jan 2020, at 14:18, Christian González > wrote: > > > > Am 08.01.20 um 22:39 schrie

Re: GDAPS

Hello Christian, > On 5 Jan 2020, at 14:30, Christian González > wrote: > > And to be honest - does this really make sense to urge people - writing more > code to satisfy the framework? > What I mean is: Why don't you drop that recommendation - when noone is using > it - more than one

Re: app_get_config(app_label).path as only way to get an app's path

Hello Christian, > if there are more than one packages with the same label? Two apps cannot have the same label. One of them must be relabeled as described in https://docs.djangoproject.com/en/2.2/ref/applications/#django.apps.AppConfig.label

Re: Allowing numbers in the top level domain

Hello, Also, as far as I know, the URLValidator is intended to catch common mistakes of people typing URLs in text fields rather than to enforce strictly a standard. Best regards, -- Aymeric. Le mer. 30 oct. 2019 à 08:40, Claude Paroz a écrit : > Hi, > > Could you please tell us a bit more

Re: docs request: signals documentation warning

Hello, Yes, I think the docs should be a better job at preventing people from getting signal-happy without grasping all the consequences. I've faced that issue in a big (> 1 million LoC) project as well. Without getting too emotional, I think the docs could say that: 1. Signals are for

Re: Redis cache support in core

Hello, This is an interesting point — and one we tend to forget too often. The documentation for memcached says that it doesn't support Windows: https://github.com/memcached/memcached/wiki/Install#installation The documentation for redis says that it supports Windows, with some limitations, and

Re: Creating a new "Triage & Review Team"

Yes, I'm in favor of trying this. -- Aymeric. Le mer. 14 août 2019 à 15:06, Josh Smeaton a écrit : > I think that's sensible, including making the team public. > > > This struck me as a little absurd: if we weren't going to dissolve it, > Nick should definitely be part of the old "Django

Re: Ideas for a new DEP on long-term Django API compatibility

Hello Pascal, As we're getting to the end of useful arguments here, I'd like to ask you to step back for a minute and take a calm look at what you're writing. Imagine you were receiving such messages rather than sending them. Would you want to spend more time collaborating with the person

Re: Django LTS support time

Hello, Actually an individual attempted this for Django two years ago: https://web.archive.org/web/20170710090735/https://djangolts.com/ The website disappeared after a year. I don't know what happened. The quick death

Re: Proposing development discussion forums

Hello, I'm in favor of trying Discourse. -- Aymeric. > On 10 Aug 2019, at 05:03, Andrew Godwin wrote: > > Hi everyone, > > This might be slightly controversial, but I would like to propose that we > have a forum for discussing Django development (and potentially user > support),

Re: Make Development More Accessible

Hello John, This was discussed before, when we moved from self-hosted svn to GitHub-hosted git, but I'm not sure there are public archives of all discussions. As far as I remember, the main points to tackle are: 1. Does GitHub allow "anonymous triage" i.e. labelling, closing, and reopening

Re: Ignoring accept_language in localization middleware based on prefixed URL patterns

Hello, Yes, I think this change makes sense, assuming no unexpected difficulties arise in the implementation. Best regards, -- Aymeric. > On 6 Aug 2019, at 10:58, Janez Kranjc wrote: > > Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since 1.3 > and I’ve recently come

Re: Translation templatetag aliases

Hello, I'm in favor of adding support for {% translate %} and {% blocktranslate %} and switching the Django documentation to use these for two reasons: - As stated by Mike, the mental associations that "block trans" creates for those who identify as trans are just bad — I can't believe it took

Re: #30646 - close_if_unusable_or_obsolete fails to close unusable connections

Hello Daniel, In the PR you propose to ping all database connections at the beginning and at the end of every HTTP request. I'm positive that this will have a significant performance impact. It's quite common to have secondary database connections that are rarely used, not scaled to be pinged

Re: Pre-proposal: adopt dj-database-url as a DEP 7 official project

Hello, In the short term, I'm in favor of moving dj-database-url to the Django organization. I have only one concern. dj-database-url supports a few third-party database backends:

Re: Application specific middleware support

ably make use of routing information except in > process_view, because if another middleware changes request.urlconf, it will > be "re-routed". > > On Sun, 7 Jul 2019 at 19:51, Aymeric Augustin > <mailto:aymeric.augus...@polytechnique.org>> wrote: > Hello Kapil, &

Re: Application specific middleware support

Hello Kapil, When you talk of a "URL served by an app", I suppose you're referring to URL namespaces, which provide a request.currrent_app attribute associating an HTTP request to an app. As far as I know, this is the only association of a request and an app that Django defines. Django's

Re: Discussing improvements of django.setup()

Hello Pakal, Making django.setup() idempotent In https://code.djangoproject.com/ticket/28752 , you say: > I've been bitten numerous times by the impredictable behaviour of django when > django.setup() was called numerous times. > In the old days I

Re: Ideas for a new DEP on long-term Django API compatibility

Hello Pakal, If I understand correctly, you're proposing that: 1. The Django project should maintain a higher level of backwards compatibility. 2. This would be easier to achieve outside the main codebase, in a submodule or in a separate repository. 3. This would reduce the amount of work

Re: j'ai une erreur de la fonction def __str__(self):

Bonjour Randa, Ce n'est pas la bonne liste de diffusion pour ce type de question. django-developers traite du développement de Django lui-même, pas de l'utilisation de Django. Je vous encourage à écrire a django-users ou à passer par un site tel que Stack Overflow. Par ailleurs, si vous

Re: Redis cache support in core

Hello, Until now, this feature request was always declined. As a consequence, every user who wants Redis has to choose between django-redis and django-redis-cache. Considering that Redis must be the most popular cache backend these days, I'm in favor of providing an off-the-shelf solution in

Re: Django ORM Internals

Hello, I would suggest https://www.youtube.com/watch?v=bgV39DlmZ2U if you'd like to understand how the ORM is structured in layers. -- Aymeric. Le lun. 13 mai 2019 à 12:16, Adam Johnson a écrit : > Yes there isn't much documented on the ORM internals, but there are other > resources. The

Re: Django Async DEP

> On 9 May 2019, at 22:06, Andrew Godwin wrote: > > Jannis suggested what I think might be a nicer approach on Twitter, which is > to add an async "proxy object" to access methods with, e.g.: > > cache.get("foo") > cache.async.get("foo") > > This is still explicit but looks less ugly, and

Re: Django Async DEP

Hello Andrew, Thanks for your work putting together this plan. Within our constraints, it's a good plan. Regarding templating, I would say it isn't a priority because a developer who knows how to parallelize I/O bound operations will prefer (or at least accept) to perform these operations in

Re: injecting settings

> On 8 May 2019, at 11:38, Michal Petrucha wrote: > > On Tue, May 07, 2019 at 10:53:37PM +0200, Aymeric Augustin wrote: >> If we're only talking about providing default values for settings, currently >> there are two straightforward solutions: >> >> 1. Like Ada

Re: injecting settings

> On 7 May 2019, at 17:49, Christian González > wrote: > Apps should have the possibility to add DEFAULT settings to the Django global > settings. As already mentioned in my plugin system question, I don't see a > problem with app/settings loading order. The loading order is done in >

Re: injecting settings

Hello Christian, I'm not aware of any plans in this area. When you say this is not possible, I assume you are referring to my work on app-loading in Django 1.7. Here's what comes to mind. There's a chicken'n'egg problems if an app modifies INSTALLED_APPS during app loading. This is a common

Re: Proposal to format Django using black

So this thread just passed the 100 message mark... I wish we could redirect some of that energy to things that actually matter to end users... Anyway, I updated DEP 8 to account for all comments made so far. Thanks everyone who provided feedback! -- Aymeric. -- You received this message

Re: Proposal to format Django using black

done > without breaking blame. > > Alex > > [0] https://prettier.io/docs/en/options.html#range > <https://prettier.io/docs/en/options.html#range> > [1] https://github.com/nrwl/precise-commits > <https://github.com/nrwl/precise-commits>

Re: Proposal to format Django using black

Hello, Here's my attempt at summarizing the conversation in a DEP: https://github.com/django/deps/pull/55 . It's easier to read as a rich diff: https://github.com/django/deps/pull/55/files?short_path=95a1a7b#diff-95a1a7b430e2608b84f5c834fd6c258c

Re: Proposal to format Django using black

> On 14 Apr 2019, at 15:10, Josh Smeaton wrote: > > Finally, there are some tricks you pick up if black fights you on some > decisions. To use Berkers example: > > TIME_INPUT_FORMATS = [ > '%H:%M:%S', # '14:30:59' > '%H:%M:%S.%f', # '14:30:59.000200' > '%H:%M', # '14:30' > ] >

Re: Proposal to format Django using black

I'm writing a DEP. -- Aymeric. > On 25 Apr 2019, at 13:30, Josh Smeaton wrote: > > To answer the question about decision making... > > Usually a decision is made if there’s reasonable consensus in the discussion > or after a vote. If no clear consensus can be reached with the core team,

Re: Proposal: Allow ManyToMany using a intermediary table to be defined as symmetrical

Hello Nadège, While I'm not an expert of this area, your proposal makes sense to me. It looks like a reasonable extension of previous work. You can go ahead with a ticket and a pull request. Best regards, -- Aymeric. > On 23 Apr 2019, at 12:09, Nadège Michel wrote: > > Hello, > > We

Re: django_chatterbot

Hello, This mailing list is for the development of Django itself, not for support using Django or third-party apps. Please use the support channels for the django-chatterbot project or a site like Stack Overflow. -- Aymeric. > On 18 Apr 2019, at 10:39, Meow wrote: > > Hi, Abhineet,

Re: Why does ModelForm do validation and not Model

Hi Curtis, Le mer. 17 avr. 2019 à 22:32, Curtis Maloney a écrit : > It's mostly for performance reasons, since validation can be expensive. > > Really? My memory was that it was (a) backward compatibility [model > validation was added later], and (b) practicality [try catching > everywhere in

Re: Why does ModelForm do validation and not Model

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

Re: Proposal to format Django using black

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.

Re: Newcomer's questions

Hello Alexey, Thanks for contributing! 1. You should make a PR against master and, if you're fixing a Trac ticket, start the commit message with "Fixed #x -- bla bla bla". Version indicators such as [2.0.x] are added when patches are backported to stable branches. You don't need to care

Re: BitBounce Spam Replies From the Mailing List

:35, Aymeric Augustin > a écrit : > > Since Twitter is the only place where BitBounce responded, I tried again: > https://twitter.com/aymericaugustin/status/1097231848973967362 > > I'm skeptical about their willingness to fight spam: they're using it as > their primary mar

Re: BitBounce Spam Replies From the Mailing List

Since Twitter is the only place where BitBounce responded, I tried again: https://twitter.com/aymericaugustin/status/1097231848973967362 I'm skeptical about their willingness to fight spam: they're using it as their primary marketing channel. The more we're talking about them, the happier they

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

Hello, I wrote a three-part essay on this question last year: 1. https://fractalideas.com/blog/making-react-and-django-play-well-together/ 2. https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/ 3.

Re: django.utils.dateparse

Hello Guiseppe, At this point I think we can agree on why we disagree :-) First, I believe that the function responsible for converting datetimes stored in ISO 8601 format in SQLite databases should parse ISO 8601 and not do anything else. I'm -1 on changing it to accept localized datetimes. (A

Re: django.utils.dateparse

1 loops, best of 3: 32.7 usec per loop > > python -m timeit -s "import datetime" > "datetime.datetime.strptime('2019-02-03T17:27:58.645194', > '%Y-%m-%dT%H:%M:%S.%f')" > 1 loops, best of 3: 53.5 usec per loop > > python -m timeit -s "from date

Re: Show applied datetime in showmigrations

Hello, This sounds interesting. You should think a bit about backwards compatibility because there's a good chance that some users are calling django-admin showmigrations in scripts or tools. I don't think this is a blocker for changing the output format. However you should plan to minimize

Re: django.utils.dateparse

Hello Guiseppe, django.utils.dateparse provides helpers needed by Django to implement datetime, date and time fields on SQLite. (SQLite doesn't have a native date time type.) Their job is to parse ISO 8601 fast. That's it. A utility module should do exactly what Django needs and nothing more.

Re: Breaking change vs deprecation on Sitemaps `ping_google` command

Ditto. I'd rather have a small, documented backwards incompatibility (and that's unlikely to cause significant problems) that another setting. Cheers, -- Aymeric. > On 9 Jan 2019, at 16:09, charettes wrote: > > I agree with Tim, this is a minor change in a contrib app. > > I don't think

Re: Migration strategy for proxy model permissions to use their own content type

Hello Arthur, I agree that option 1 is the way to go. It would be nice to make the migration reversible. If someone upgrades to Django 2.2.x, migrates the database, and later discovers a blocking issue, they should have the option to migrate backwards and downgrade to 2.1.y. Best regards, --

Re: Simplify authentication backend interface

Hello Tobias, And sorry for the late answer! Yes, this is a good idea. https://docs.djangoproject.com/en/2.1/topics/auth/customizing/#handling-authorization-in-custom-backends reads

Re: BitBounce Spam Replies From the Mailing List

compensation for unsolicited email after all :-) and you sent quite a lot to us :-( Looking forwards to a prompt resolution, -- Aymeric. > Le 6 janv. 2019 à 10:35, Aymeric Augustin > a écrit : > > [[ I'm adding BitBounce support to this discussion, even though I expect I'll > ju

Re: BitBounce Spam Replies From the Mailing List

[[ I'm adding BitBounce support to this discussion, even though I expect I'll just get one more of their spam — "we'll ignore the spam problem we cause to you until you pay money to us". ]] > On 2 Jan 2019, at 01:39, Daniele Procida wrote: > > On Wed, Jan 2, 2019, Daniele Procida wrote: >

Re: New optional settings - disable bulk_create in all managers and call self.full_clean() before saving the models

Hello, Your ValidateModelMixin and ManagerMixin look perfectly reasonable. You wanted to customize two aspects of Django's behavior. You managed to do so in four lines and three lines respectively. (I'm leaving out `id_generator` which is another concern.) Preventing database writes without

Re: Consensus about visual diagrams in the docs.

Hello, A few years ago, I redid most illustrations and included them in the docs as SVG files. The primary driver was switching from PNG to SVG to better accommodate hi-dpi displays. I also committed the source files. Unfortunately, they're in a proprietary format and cannot be reused without

Re: Extending django.contrib.auth.models Group name to be 191 character max_length

That seems all right to me. -- Aymeric. > On 13 Nov 2018, at 16:56, joh...@alumni.upenn.edu wrote: > > If the other fields are also 191, i see no reason not to make the change. It > should be a non-breaking change. And Yes i am that colleague... > > On Tuesday, November 13, 2018 at

Re: Pluggable secret key backend

break and continue to work as > expected. > > Tom > > > > > > On 11 November 2018 at 07:38:15, Aymeric Augustin > (aymeric.augus...@polytechnique.org) wrote: > >> Hello, >> >> I think this is a great idea. >> >> As suggested

Re: Pluggable secret key backend

Hello, I think this is a great idea. As suggested by others, an even better default implementation would be: class SecretKeysBackend: def get_signing_key(self): if isinstance(settings.SECRET_KEY, (list, tuple)): return settings.SECRET_KEY[0] else:

Re: Make `raw_id_fields` the default functionality in the admin

On 6 Nov 2018, at 02:47, 'Ivan Anishchuk' via Django developers (Contributions to Django itself) wrote: > How about some field that intelligently guesses the table size and looks > either like default select or like raw id field depending on that? Yes, that would be interesting. I

Re: django.utils.timezone.make_aware confusion

Hello Dan, If that assertion fails, I assume the default time zone (the TIME_ZONE setting) isn't Europe/Berlin. See https://docs.djangoproject.com/en/2.1/ref/utils/#django.utils.timezone.make_aware If you

Re: django migrations on live database for large tables for postgresql

t zero downtime migrations support > with detailed proposition of improvements and backward compatibility support? > > Regards, Paveł > > On Sunday, 7 October 2018 10:31:27 UTC+3, Aymeric Augustin wrote: > Hello Pavel, > > There's an accepted ticket about CREATE I

Re: python-memcached seems to be unmaintained

Hello Adrian, I think that's a good plan. If there's opposition to deprecating the python-memcached backend now, it would still be possible to introduce and recommend the pymemcache backend. Best regards, -- Aymeric. > On 29 Oct 2018, at 01:42, Adrian Turjak wrote: > > Through some of

  1   2   3   4   5   6   7   8   9   10   >