Re: response_change method has too much dublications

Thanks for the suggestion, Jelena. I'd be happy to look at a patch, although my initial instinct is that while there is some duplication, adding a method might actually created unneeded complexity and make things somewhat less readable. Feel free to send a pull request if you take a stab at it

Re: Django Admin - Front-End Improvements

Hi Alex, I believe most of these changes would be welcome, and I'd be happy to review your work in this area. There has already been at least a start on using some CSS3 elements: * Rounded corners: https://github.com/django/django/commit/fb052b528ad5f0a92f7420ab8ade16462b6435fd There is alread

1.8 release planning

I'd like to kickoff the discussion on the timetable and process for the 1.8 release. I am also volunteering to be the release manager. First, a retrospective on the 1.7 release with planned release dates and (actual): Jan. 20: alpha (Jan. 22) March 6: beta (March 20) May 1: RC (June 26) May 15:

Re: 1.8 release planning

If you are upgrading from 1.4, I would recommend going step by step through each intermediate Django version. I don't believe trying to upgrade straight away to 1.8 would be easier. I'd encourage anyone on 1.4 to start doing intermediate upgrades soon, so if there are still undetected regressio

Re: django.db.models.field.subclassing issue

SubfieldBase is deprecated in Django 1.8, so I don't think there will be interest in fixing any issues with it. On Wednesday, October 22, 2014 7:11:05 AM UTC-4, Bobby Mozumder wrote: > > In the file subclassing.py, should the following: > > > def make_contrib(superclass, func=None): > """ >

Re: 1.8 release planning

is > less conservative than "never use it in production", more people might join > in on testing and reporting bugs before an RC. > > On Friday, 17 October 2014 22:48:18 UTC+3, Tim Graham wrote: >> >> I'd like to kickoff the discussion on the timetable an

Re: Removing Unique Together Field (X-Post django-core-mentorship)

Hi Bill, Yes, I believe this is a valid issue. I think it was reported in https://code.djangoproject.com/ticket/23614 Tim On Monday, October 27, 2014 12:32:10 PM UTC-4, Bill Prin wrote: > > Hi all, > > I wasn't sure which mailing list to put this on, so I cross-posted it with > django-core-men

Re: Overwrite mode in collectstatic

For other readers, my analysis of the issue and why I don't think it's appropriate can be found on the ticket where the idea was first raised: https://code.djangoproject.com/ticket/23724 On Wednesday, October 29, 2014 11:34:02 AM UTC-4, Prathik Rajendran M wrote: > > Hi all, > > This is to initi

Re: Overwrite mode in collectstatic

TATIC_ROOT, manually delete the files that > need to be replaced and run collectstatic. > > On Wednesday, October 29, 2014 9:58:51 PM UTC+5:30, Marc Tamlyn wrote: >> >> I'd be inclined to agree with Tim, this seems to simply be a less useful >> version of --cle

Re: Overwrite mode in collectstatic

unning with it. We > should minimize the requirement that people learn certain laws before using > Django because it is possible that they don't and ideally we should have > mechanisms to figure out that they are not and then alert them, I am not > sure if these alerts are the

Fellow Report - October 31, 2014

Hello, If you've read the djangoproject.com blog, you know that Berker Peksag and I have been appointed as "Django Fellows" during the three month pilot program. Part of those duties (which started this week) is to provide a weekly summary of our activities to this mailing list. That report fol

Re: Allow overriding smtplib local_hostname

Hi, there's already a ticket: https://code.djangoproject.com/ticket/6989 On Friday, December 20, 2019 at 7:33:35 AM UTC-5, David Nolan wrote: > > Hey all. > > In cloud environments, when using > django.core.mail.backends.smtp.EmailBackend, socket.getfqdn() is called > to resolve the 'reported ho

Re: Best Profanity filters for using in Python Django project

Hi, I see you also posted to django-users. Please don't cross post to django-developers as this mailing list is about developing Django, not discussing usage questions. On Thursday, December 26, 2019 at 12:47:54 PM UTC-5, Unprofessional coder wrote: > > I have a requirement where I need to use

Re: Worth raising a warning when `order_by('?')` is used with specific backends?

I think issuing a warning would be rude to developers who want to use that feature and are aware of the limitation... they would have to do extra work to silence the warning. On Friday, January 10, 2020 at 10:14:23 AM UTC-5, Santiago Basulto wrote: > > Sadly I have to admit that I'm not involved

Re: [Feature Request] Allow a Field/DeferredAttribute object everywhere a field name as a string is currently expected

If I understand correctly, currently this works: Question.objects.order_by(Question.pub_date.field_name) but your proposal is to avoid the need for ".field_name". I don't think I'd use that syntax as its more verbose and less readable (to me, anyway). Having more than one way to write things (s

Re: Getting error while running tests for postgis

Actually, this is somewhat on topic as it involves running the Django test suite. To solve the failure, add this to your test settings: PASSWORD_HASHERS = [ 'django.contrib.auth.hashers.MD5PasswordHasher', ] It seems like a bug that that test assumes MD5PasswordHasher. As for the skipped t

Re: Announcing CockroachDB support for Django ORM

This is the mailing list for the development of Django itself. Please use django-users for messages like this. On Monday, January 27, 2020 at 4:27:01 PM UTC-5, Charlotte Dillon wrote: > > https://pypi.org/project/django-cockroachdb/ > -- You received this message because you are subscribed to t

Re: Relax system check on fields intermediary tables for db_table collision when database routers are installed

The change for that ticket is already released. Please open a new ticket. On Thursday, February 13, 2020 at 9:00:35 AM UTC-5, Anonymous Rabbit wrote: > > Before I move forward I just to want clarify, my changes are for the same > check specified in ticket #29092. Should I still open a new ticket

Re: Improve migration conflict detection

Have you considered what would happen if a migration has a RunPython or RunSQL? They may require a certain model state. On Tuesday, February 18, 2020 at 12:08:03 PM UTC-5, caio wrote: > > I’m working on this as a standalone PoC app for now, I may be able to > share a repository with the code soo

Re: verbose_name used inconsistently in contrib.admin

Hi, This behavior looks correct. Field names are used when displaying a model's fields, so a model's verbose_name doesn't have any effect there. Consider a model that has a two foreign keys to the same model. Displaying the model name in that case wouldn't allow distinguishing between the field

Re: Does "Someday/Maybe" triage stage imply a low change of pull request getting merged?

Generally "Someday/Maybe" tickets aren't ready for coding. Something else needs to happen first, perhaps a discussion on this mailing list to come to a consensus on how to proceed, or in the cast of that ticket (perhaps), the spec to be approved. On Wednesday, April 8, 2020 at 2:56:44 PM UTC-4,

Re: Adding ability to choose AutoField type (signed vs unsigned)

How would the strategy of having a setting generate new migrations work with third-party apps? Generally migrations can't easily be added to them by user projects and if more migrations are added to the third party app in a later version, there will be an inconsistent history. On Thursday, Apri

Re: handle_uncaught_exception error logging

The relevant commit might be https://github.com/django/django/commit/10b44e45256ddda4258ae032b8d4725a3e3284e6. That change was made in Django 2.1. You didn't say what version of Django you're using. You'll have to give more details about your case and what's behaving differently. On Sunday,

Re: Proposal to not implicitly create varchar/text-pattern opclass indexes on PostgreSQL

I have some sympathy for this issue as I'm trying to make the createcachetable management command use SchemaEditor rather than some custom SQL construction logic*. The related problem I ran into is that the primary key column (a CharField) uses unique=True which means those undesired opclasses

Re: Swappable sessions

Can't you copy whatever data you want from the request into the session data (request.session. = request.) in a view, middleware, or wherever? That seems like the proper separation of concerns. On Wednesday, April 15, 2020 at 11:50:13 AM UTC-4, Lorenzo Peña wrote: > > Now, in order to follow the

Re: Swappable sessions

uestion is: would it be okay to formally ask that the request object, > which is already available there, be passed to that method when called, > like " create_model_instance(self, data, request=None)"? > > El miércoles, 15 de abril de 2020, 17:01:30 (UTC-4), Tim Graham escrib

Re: Loading lzma compressed fixtures

Hi Paolo, Please don't ask for code reviews on this mailing list. It just adds noise. Patches are reviewed from "Patches needing review" at https://dashboard.djangoproject.com/. At this time there are ~30 patches in the queue. Requesting your feature to be moved to the front of the review queue

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

I'm in favor of the change. It seems to me that most slugs I see these days have stop words in them and they read better because of that. I don't think JavaScript warnings would be helpful. A release note is sufficient. Admin users still get a preview of the slug and can edit it if needed. On F

Re: Disabling .delete() in querysets in Django

Hi Uri, I think you've mostly come across documented behaviors rather than "problems". You haven't provided enough details in the bug report to say for sure on that issue. I don't think the things you've implemented are generally applicable to many Django projects such that they warrant the ad

Re: Adding json lines (jsonl) serializer to django

Hi Ali, as I noted on the PR, the ticket isn't in the review queue because "needs tests" is checked. On Thursday, May 21, 2020 at 9:47:53 AM UTC-4, Ali Vakilzade wrote: > > Hi! > > A while back I opened a pull request on this topic and there is no updates > on the my request for a while. I know

Re: Implement QuerySet.__contains__?

It may help to know that QuerySet.__contains__() was implemented until Django 1.6 when chunked reads were removed from QuerySet iteration: https://github.com/django/django/commit/70679243d1786e03557c28929f9762a119e3ac14 On Tuesday, June 2, 2020 at 7:43:25 AM UTC-4, Aymeric Augustin wrote: > > O

Re: Implement QuerySet.__contains__?

o the behavior change) On Tuesday, June 2, 2020 at 8:53:07 AM UTC-4, Tim Graham wrote: > > It may help to know that QuerySet.__contains__() was implemented until > Django 1.6 when chunked reads were removed from QuerySet iteration: > > > https://github.c

Re: Implement QuerySet.__contains__?

(You can reopen https://code.djangoproject.com/ticket/24141 rather than creating a new ticket.) On Friday, June 5, 2020 at 9:06:48 AM UTC-4, Aymeric Augustin wrote: > > If people agree QuerySet.contains() should be added, how do we move > forward? > > > Yes, if there's no major new argument in a

Re: Making startproject's settings more 12-factor-y

Have you read past discussions on the mailing list? For example: Making Django more PaaS-friendly https://groups.google.com/d/topic/django-developers/BAGhOKXGj4I/discussion Searching the archives for "12-factor" yields some other results. That may help you to craft your proposal. On Friday, Ju

Re: Making startproject's settings more 12-factor-y

Here's an unsuccessful attempt to defer the SECRET_KEY check: https://code.djangoproject.com/ticket/29324 It seems like it could be insecure to move that to a system check as "For performance reasons, checks are not run as part of the WSGI stack that is used in deployment." (Also, it seems impo

Re: Should the docs suggest namespace packages?

On the topic of namespace packages, I noticed this line in the 3.1 release notes: "Migrations are now loaded also from directories without __init__.py files." https://code.djangoproject.com/ticket/30300 The ticket's rationale seems to be "We've just finished migrating our codebase to all-pytho

Re: Should the docs suggest namespace packages?

ing time. > > -- > Aymeric. > > > On 19 Jul 2020, at 22:25, Tim Graham wrote: > > On the topic of namespace packages, I noticed this line in the 3.1 release > notes: "Migrations are now loaded also from directories > without __init__.py files." https://code.djangopro

Re: Make tag name a variable in form templates

For me, a custom widget (that could use its own template) looks cleaner. Something like birth_date=DatePicker() seems more readable and doesn't require repeating "tag='duet-date-picker'"" each time. If you prefer your one-line version, you could override the input.html template and make the tag

Re: Make tag name a variable in form templates

A datepicker is rather different from a plain TextInput widget so I think it's good design to use a separate widget. If Django provided datepicker functionality, I'm fairly sure it would be provided as a separate widget rather than instructing users to use something like forms.TextInput(tag='du

Re: Make tag name a variable in form templates

My point is that if Django used variables for tag names in its widget templates, it would suggest developers write code that's inconsistent with Django's design philosophy. As was pointed out with things like the 'type' attribute, these templates aren't meant to be generic templates for web com

Re: Updates to PR are not reflected in Jenkins, checks failing

Hi, I'd try rebasing your branch against master to eliminate the merge conflict. On Monday, August 31, 2020 at 4:37:15 PM UTC-4 ba...@google.com wrote: > Hi All! > > I have an open PR and am > having difficulty getting the Jenkins checks to pass. I

Re: Proposal: Make the domain part of the Email Message-ID configurable

Hi, I think https://code.djangoproject.com/ticket/6989 has some discussion related to this. On Sunday, September 6, 2020 at 7:30:15 AM UTC-4 jacob...@gmail.com wrote: > When Django's mail subsystem generates an email, it creates a unique > Message-ID. This is a requirement specified in RFC2822.

Re: Advancing with the Triage & Review Team idea.

t;> review from me. This has been very helpful, and quite smooth. (It’s in a >> similar vein to marking tickets on Trac Ready for Commit, which also helps >> them to show about the mass.) >> >> Ultimately I think a Triage & Review Team is an opportunity to widen the

Re: Primary Key AutoField -> UUID Field

Hi Brian, There are existing threads about that (try searching the archives for 'default pk' to find some of them). Here's a PR that adds the setting you described: https://github.com/django/django/pull/13179. Perhaps you would like to try it out and see if it meets your needs. On Saturday, Nov

Re: Adding a security concerned feature

I'm not convinced that a system check promoting security by obscurity adds much value. The original poster wrote "sometimes it can be a security concern." Maybe that's the case (how so?) but for most sites I would say it's not. On Wednesday, November 18, 2020 at 7:33:47 AM UTC-5 Carles Pina Esta

Re: Revisiting Python support for after Django 3.2 LTS

Part of the rationale for dropping Python versions after an LTS is was to avoid getting "stranded" on a non-LTS version of Django. For example, if we keep Python 3.7 support in Django until Python 3.7 is end of life in June 2023, that would probably make Django 4.1 the latest version to support

Re: Hello Everyone

Hi Vineet, this is an extremely common question on this mailing list. Please search the archives for something like "contribute to django" and you'll see many answers. Have fun! On Monday, November 23, 2020 at 8:40:47 AM UTC-5 vinee...@gmail.com wrote: > I am Vineet Sharma, pursing computer sci

Re: Revisiting Python support for after Django 3.2 LTS

Dropping support for Python versions as they go EOL in existing Django releases would be disruptive. Distros "support" Python versions longer than the PSF does. If a Django version inadvertently breaks compatibility with an old version of Python because we stop testing with it, we'll get bug re

Re: Feedback on PR "Add warning when inspectdb find multi-columns primary keys"

Please try to make it easy to understand the issue without looking at tickets and pull requests. Even after I did that, I couldn't find why you believe it should be a warning and not a comment. Why is this situation different from all the other places Django uses comments to indicate where intr

Re: Feedback on PR "Add warning when inspectdb find multi-columns primary keys"

implement the PR with a comment instead of a warning. > > Le mar. 1 déc. 2020 à 16:18, Tim Graham a écrit : > >> Please try to make it easy to understand the issue without looking at >> tickets and pull requests. Even after I did that, I couldn't find why you >> be

Re: Proposal: Make the domain part of the Email Message-ID configurable

You don't need to announce a patch on the mailing list. Instead check "According to the ticket's flags , the next step(s) to move this issue forward are" on the ticket and update it accordingly. Tha

Re: App label with dot

app_label "should be a valid Python identifier." Dots aren't allowed. https://docs.djangoproject.com/en/stable/ref/applications/#django.apps.AppConfig.label On Friday, December 18, 2020 at 10:47:45 AM UTC-5 Federico Capoano wrote: > Defining the app_label of an AppConfig with a dot, like "myproj

Re: SynchronousOnlyOperation: bug or misconfiguration?

Hi, this mailing list isn't appropriate for "is it a bug?" questions. Please use django-users instead. On Friday, December 18, 2020 at 11:00:30 AM UTC-5 Federico Capoano wrote: > I have a celery task which performs queries and network operations. > > When deployed with celery with gevent concurr

Re: Technical Board Decision Needed: Admin append_slash behaviour.

As a non-technical board member, I'd prefer option 1. I also think that for most use cases, staff users are at least somewhat trusted and even if they are not, model enumeration isn't likely to be a security problem. On Wednesday, January 6, 2021 at 5:07:44 AM UTC-5 carlton...@gmail.com wrote:

Re: Technical Board Decision Needed: Admin append_slash behaviour.

I wouldn't object to a wontfix. It seems like we've already spent a lot of effort here for little benefit, if any. On Thursday, January 7, 2021 at 8:16:57 AM UTC-5 carlton...@gmail.com wrote: > OK, thanks all. So... > > Two new options then: > > 1. Add the catch-all view to admin to stop the un

Adding Origin header checking to CSRF middleware (#16010)

Hello, I've updated this 10 year old patch but some more changes are needed. I'll target it for Django 4.0. https://code.djangoproject.com/ticket/16010 https://github.com/django/django/pull/13829 Here are a few design decisions and questions that have come up: 1. It seems the main reason this w

Re: Adding Origin header checking to CSRF middleware (#16010)

OWASP Cheat Sheet says, "It is important to note that [the SameSite Cookie] attribute should be implemented as an additional layer *defense in depth* concept. This attribute protects the user through the browsers supporting it, and it contains as well 2 ways to bypass it as mentioned in the fol

Re: Rethink (?) how we handle security headers.

The proposal seems to be a setting of the form: SECURITY_HEADERS = { 'Strict-Transport-Security': 'max-age=60; includeSubDomains; preload', ... } Currently we have system checks to suggest setting SECURE_HSTS_SECONDS, SECURE_HSTS_PRELOAD, etc. Do you envision trying to keep these checks

Re: Rethink (?) how we handle security headers.

> "PRELOAD": True, > "SECONDS": 1_000_000, > }, > } > > > On Tue, 19 Jan 2021 at 01:30, Tim Graham wrote: > >> The proposal seems to be a setting of the form: >> >> SECURITY_HEADERS = { >> 'Strict-Transpor

Re: Permission to discuss

django-users is suitable for that. This mailing list is limited to discussion of the development of Django itself. On Tuesday, January 19, 2021 at 4:56:47 PM UTC-5 Benny wrote: > Hi developers, > > I have an idea for a Django related project and I’d like to get input from > users and developers

Re: Revisiting Python support for after Django 3.2 LTS

Hi Carlton, This chart doesn't look quite right for the policy you wrote. For example, I wouldn't expect Django 4.2 LTS (supported until April 2026) to support Python 3.8 (only supported until October 2024). It seems like this policy makes it more likely that the last Django version to support a

Re: Polymorphics relationship

Search the archives of this mailing list for "polymorphic" to see past discussions. There hasn't been consensus that it needs to be in Django itself. There's already https://django-polymorphic.readthedocs.io/en/stable/. On Thursday, January 21, 2021 at 3:41:13 PM UTC-5 jonnath...@gmail.com wrot

Re: Snowflake db backend

Hi Scott, Recently I've written backends for CockroachDB and Cloud Spanner. Perhaps those databases aren't as different as Snowflake, but I didn't have any major obstacles. I've had good success at contributing database backend API changes to Django to make future maintenance of those backends

Re: Rethink (?) how we handle security headers.

quest): > response = self.get_response(request) > response["Cross-Origin-Embedder-Policy"] = "require-corp" > return response > > Also there are many non-security related headers one might want to add, so > having the ability to add t

Re: PR review request

Hi William, 3.2 alpha marked the feature freeze. Only non-release blocking bug fixes may be backported at this point (from https://code.djangoproject.com/wiki/Version3.2Roadmap#schedule). There are 28 other patches in the review queue, many of which have been there longer than your tickets, so

Re: Revisiting Python support for after Django 3.2 LTS

Looking at this again, I'm not sure it would be six versions. Carlton's suggested policy has the effect of dropping a lot of Python versions right before the LTS since it's supported for 3 years. For example, in Django 5.2 LTS, I think it's incorrect that Python 3.10 and 3.11 would be supported

Re: Docs improvement? - MEDIA_URL in templates

Hi Mike, I think you want to use {{ user.avatar.url }}. https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.fields.files.FieldFile.url For future reference, since this is more of a usage question, it would be better to post to django-users. If you want to suggest a documen

Re: Docs improvement? - MEDIA_URL in templates

't tied to a File field (eg. Resized versions). So > the question remains: are the docs clear enough to explain how to do this? > > On Sat, 30 Jan 2021, 17:16 Tim Graham, wrote: > >> Hi Mike, >> >> I think you want to use {{ user.avatar.url }}. &g

Re: Deprecating django.utils.functional.cached_property() ?

There's a ticket about it: https://code.djangoproject.com/ticket/30949 On Thursday, February 4, 2021 at 5:57:15 AM UTC-5 carlton...@gmail.com wrote: > functools.cached_property is available from Python 3.8. > > https://docs.python.org/3.9/library/functools.html#functools.cached_property > > Is

Re: Easy Pickings

Hi David, I agree with your definition of easy as "ideal first issue" but I don't think aiming for a certain number of easy tickets makes sense. If those issues are quickly solved, then what happens... mark the next 20-30 easiest tickets? I'd say feel free to mark any tickets as "easy pickings"

Re: Feature request: wigets attribute for ModelFormMixin class

This has been proposed before (closed as wontfix): https://code.djangoproject.com/ticket/24589 https://groups.google.com/g/django-developers/c/34HJqx48h6Y/m/Nm3UMTK4BgAJ On Wednesday, February 17, 2021 at 9:53:07 AM UTC-5 jonask...@gmail.com wrote: > > # Feature request: wigets attribute for Mod

Re: New to the Community

It's expected. Some tests are only applicable to certain databases. Search for all mentions of "skip" at https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/. You can run the tests with "-v 2" to see the reason why a test was skipped. On Thursday, February 25,

Re: Help with ticket #28426

I'd like to see what your code looks like so far. Personally, this is sounding a lot more complicated than I imagined when I accepted the ticket. I doubt this is a highly requested feature that couldn't be solved another way (e.g. downloading the template file without Django), and It's not clear

Re: Django 3.2rc1: models.W042 is raised on inherited manually specified primary key.

Hi, It would be helpful to link to the ticket and/or explain the issue in more detail. On Thursday, March 25, 2021 at 9:28:09 AM UTC-4 Caram wrote: > > This issue was raised in alpha1, but I still had the issue in beta1 and > now also in rc1. > > As a result, I have to manually edit the migrati

Re: Request for Comment: settings growth configuring Email Backend.

I don't think settings create any harm. They seem cleaner than suggesting subclassing the backend. If I'm understanding correctly, that would force everyone to write something like: class MySMTPBackend(smtp.EmailBackend) def __init__(self, *args, **kwargs): super().__init__(*args, ke

Re: Request for Comment: settings growth configuring Email Backend.

I don't think there's a big cost to additional entries in docs/ref/setttings.txt. I think it's far more common to browse that document for needed functionality rather than to read the entire thing. There are 23 DATABASES 'TEST' settings that probably aren't used very frequently, yet I don't thi

Re: Test fails silently when using --tag

This was fixed a week ago (will be in Django 4.0). https://code.djangoproject.com/ticket/29127 On Monday, April 5, 2021 at 5:18:45 AM UTC-4 Adam Johnson wrote: > Please don't report bugs here but to the ticket tracker. If you're not > sure there's a bug, django-users, the forum, or IRC are the

remove SECURE_BROWSER_XSS_FILTER setting?

Hi, I think this setting and its functionality could be removed without a deprecation. Django's docs says, "Modern browsers don’t honor X-XSS-Protection HTTP header anymore. Although the setting offers little practical benefit, you may still want to set the header if you support older browsers.

Re: Paid Contributions for specific feature in Django

Hi Taylor, As Adam said, it would be nice not to duplicate work that Disney's already done, but if I can help, I'm open to consulting and have written backends for CockroachDB (https://github.com/cockroachdb/django-cockroachdb) and Google Cloud Spanner (https://github.com/googleapis/python-spa

Re: datetime_safe deprecation

Hi, did you consult the ticket? https://code.djangoproject.com/ticket/32738 On Sunday, August 1, 2021 at 1:09:04 PM UTC-4 mrhe...@gmail.com wrote: > I note that datetime_safe is to be removed in Django 5.0 >

Re: Recognising Contributions

I started including ticket numbers in patch releases because there aren't too many changes there and every change has a release note. I think the ticket numbers are useful to quickly identify the cause of some change or regression in a patch release where upgrades should generally be safer and

Re: deconstruct returns 3-tuple?

That documentation is for serializing classes. There's a note box that says, "This return value is different from the deconstruct() method for custom fields which returns a tuple of four items."

Re: Violating unique constraint in the admin

Hi, there have been some past discussions, e.g. https://groups.google.com/g/django-developers/c/Dju2vvbzECI/m/vYDnYekgBQAJ On Friday, October 8, 2021 at 6:34:02 AM UTC-4 Fab wrote: > Hi, > > When I violate a unique constraint in the admin I get an error page. > > I know I can check this myself a

Re: Snowflake db backend

Cedar Cares, Inc. funded me to write a Snowflake backend. The first alpha for Django 3.2 was released this week. Testers and feedback are welcome! https://github.com/cedar-team/django-snowflake https://pypi.org/project/django-snowflake/ I didn't find the implementation particularly onerous, but pe

Re: Roadmap and communication of features planned for releases

Hi Jason, I'm not aware of any formally planned features. (If there were any, I'd expect they'd be discussed on this mailing list.) The next release will include whatever features the community contributes by the feature freeze deadline. See https://code.djangoproject.com/wiki/Version4.1Roadma

Re: Proposal on how add configuration options to Email Backends

The idea was pursued in https://code.djangoproject.com/ticket/22734 but ultimately abandoned. On Saturday, January 29, 2022 at 6:01:30 PM UTC-5 jacob...@gmail.com wrote: > This proposal attempts to address the following issues: > https://code.djangoproject.com/ticket/6989 (14 years old) > https:

Re: Why I'm not able to see any organization?

I see it now... https://summerofcode.withgoogle.com/programs/2022/organizations/django-software-foundation-8o On Tuesday, March 8, 2022 at 8:23:22 AM UTC-5 sarthak...@gmail.com wrote: > Trying this from last night , is this with me or everyone is facing this > problem ? -- You received this m

Re: Proposals of GSOC.

A proposal that was accepted last year is linked from https://code.djangoproject.com/wiki/SummerOfCode2022. On Wednesday, March 9, 2022 at 10:34:59 PM UTC-5 sarthak...@gmail.com wrote: > Can anyone share me old proposals of GSOC for django software application. > -- You received this message

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

I think I prefer documenting Berker's suggestion rather than adding more classes to Django, unless perhaps, they add some additional functionality as HttpResponseNoContent does. Did you intend to have response subclasses for all 57 values of http.HTTPStatus? On Sunday, August 6, 2017 at 4:17:2

Re: Django 2.0 Python version support (Python 3.6+ only?)

t for Django 2.0 and drop it for 2.1. On Friday, February 17, 2017 at 9:32:20 PM UTC-5, Tim Graham wrote: > > Ok, I created a ticket to track cleanups and new Python features we can > use when Python 3.4 support is removed: > https://code.djangoproject.com/ticket/27857 > > We can

Re: Django 2.0 Python version support (Python 3.6+ only?)

t;> >> I took a look at this thread again and I still reach the same conclusion >> as Claude. >> >> Best regards, >> >> -- >> Aymeric. >> >> >> >> On 9 Aug 2017, at 09:02, Claude Paroz > >> wrote: >> >> Le mar

Fellow Report - August 12, 2017

Triaged --- https://code.djangoproject.com/ticket/28469 - Add additional response type subclasses (accepted) https://code.djangoproject.com/ticket/28481 - migrate --fake produces stale content type warning when CreateModel exists in non-initial migration (fixed) https://code.djangoproj

Fellow Report - August 19, 2017

I was mostly on vacation this week. Triaged --- https://code.djangoproject.com/ticket/28491 - "TypeError: context must be a dict rather than Context" when using loader.select_template() with Context (invalid) Reviewed/committed -- https://github.com/django/django/pull

Re: To keep or not to keep: logging of undefined template variables

silence them. Which can already by >> accomplished by LOGGING, can't it? >> >> Vlastik >> >> Dne neděle 26. března 2017 11:14:23 UTC+2 Melvyn Sopacua napsal(a): >>> >>> On Thursday 16 March 2017 12:03:07 Tim Graham wrote: >>> >>>

drop support for MySQL 5.5 in Django 2.0?

MySQL 5.5 is end-of-life in December 2018. Usually we drop support for a particular database version in the Django release prior to the end-of-life date [0], so that would mean dropping support in Django 2.1 (released August 2018). We don't have MySQL 5.5 testing in our continuous integration s

Fellow Report - August 26, 2017

Triaged --- https://code.djangoproject.com/ticket/28513 - LogoutView doesn't support POST, unlike the function-based logout() view (accepted) https://code.djangoproject.com/ticket/28514 - Clarify docs regarding idempotence of RelatedManager.add() (accepted) https://code.djangoproject.co

Re: Align Django admin checkboxes

This was originally raised in https://code.djangoproject.com/ticket/28521. I wrote: I checked as far back as Django 1.4 and this positioning hasn't changed. I'm not convinced the change would be more disruptive (for example, to third-party admin customizations) than it's worth. The original des

Re: drop support for MySQL 5.5 in Django 2.0?

ngo-pyodbc-azure* is very well maintained > and supports both SQL Server and Azure. > > On Saturday, August 26, 2017 at 11:09:42 AM UTC-4, Tim Graham wrote: >> >> MySQL 5.5 is end-of-life in December 2018. Usually we drop support for a >> particular database version in the Dj

Re: DEP pre-proposal for a simpler URLs syntax.

Is there any more documentation than https://github.com/django/django/pull/7542? It doesn't look very complete: * Release note are missing. * Documentation for url() shouldn't be removed -- as far as I know, there's no plan to deprecate it. It should be as valid alternative (i.e. error messages

Re: Default to BigAutoField

Glancing at the PR, one thing I'm not sure about is renaming AutoField to SmallAutoField. I think that's going to cause needless additional complexity and confusion among people who've worked with Django a long time. For example, you might think that "Small" there has a similar meaning as Small

<    3   4   5   6   7   8   9   10   11   12   >