Re: Ticket #34646 Ordering a Django admin column based on multiple model fields

26, 2024 at 7:10:36 PM UTC+2 Mubarak Alrashidi wrote: Could you re-consider it please? it is really important, and we need it. I have started another project where I need to create a computed column (used_invitations / max_invitations) Best regards On Friday, June 23, 2023 at 10:39:51 AM UTC

Re: Ticket #34646 Ordering a Django admin column based on multiple model fields

Could you re-consider it please? it is really important, and we need it. I have started another project where I need to create a computed column (used_invitations / max_invitations) Best regards On Friday, June 23, 2023 at 10:39:51 AM UTC+3 Mubarak Alrashidi wrote: > I really h

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

Hi! I would be happy to make a contribution if a decision can be reached. I'm in favor of making the Group model swappable with the AUTH_GROUP_MODEL setting, similar to the User model. The ticket was marked as Someday/Maybe, I'm not sure why. The customization of the Group model is necessary

Re: Should Django use Ada?

Thanks for the replies everybody. A few thoughts >From Adrián: > You should probably be addressing urllib devs with this inquiry (e.g. such vuln is then probably in many other web frameworks) I did that in 2021 when I found the issue with newlines in URLs. Python devs had the resources to

Re: Should Django use Ada?

I agree with Jörg. We need evidence of problems before we decide to act, and that those problems aren’t being addressed in Python. Forcing a new dependency on all users is not something we’d do lightly. On the contradictory standards, see the cURL maintainer’s post:

Re: Should Django use Ada?

You should probably be addressing urllib devs with this inquiry (e.g. such vuln is then probably in many other web frameworks). Anyhow, just out of curiosity, wouldn't it be possible to use functools.partial function to replace urllib.parse.urlparse with ada-python in settings.py? Or make some

Re: Should Django use Ada?

You write: "It could still be a vulnerability ... / It could fail to parse ... / could decide it's invalid - This is all pretty bad..." I agree - this indeed would be really bad, if it can be used in malicious ways. But note that the fact that django or an upstream lib decided to slightly

Re: Should Django use Ada?

I always wonder why people feel the need to belittle others' work with statements like " But Python, being maintained mostly by volunteers, did the minimum needed work to fix the vulnerability without really fixing the urlparse library properly." But then add something about their time being too

Re: Fellow Reports - March 2024

March 25-26 *Triaged:* https://code.djangoproject.com/ticket/35330 - The update of related objects fails in the admin when the related model is camel case. (accepted) https://code.djangoproject.com/ticket/35331 - Adding a new related entry using the "+" sign from M2M field doesn't

Re: Intermittent IntegrityError on Model Save with auto_now and auto_now_add Fields

Looks like this issue isn't affecting lots of folks, since nobody is piping up, so I'll just add that if anybody arrives here in the future, we'll be tracking this in a public issue here: https://github.com/freelawproject/courtlistener/issues/3359 My theory is it has something to do with race

Re: Fellow Reports - March 2024

Week ending March 24 *Triaged:* https://code.djangoproject.com/ticket/35312 - FileNotFoundError escapes from run_formatters() (invalid) https://code.djangoproject.com/ticket/34059 - Validation of check constraints on JSONField key transforms with None produces invalid SQL on

Re: Fellow Reports - March 2024

Week ending March 17 *Triaged:* https://code.djangoproject.com/ticket/35287 - manage createsuperuser too restrictive (duplicate) https://code.djangoproject.com/ticket/35291 - Whitenoise Not Working when DEBUG = FALSE - Django - Hosting Static Files (duplicate)

RE: Intermittent IntegrityError on Model Save with auto_now and auto_now_add Fields

Hi Bill, We ended up using a package called Django-audit-log: https://pypi.org/project/django-audit-log/. It’s outdated now, but we used the source code for their CreatingUserField, LastUserField, CreationDateTimeField, and ModificationDateTimeField. More modern packages may have enhanced

Re: Use of TIME_INPUT_FORMATS in TimeField

USE_I18N does not disable localization, but internationalization. USE_L10N was the setting to enable/disable localization, but it was deprecated in Django 4.0: https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was removed completely in Django 5.0, in this commit:

Re: Use of TIME_INPUT_FORMATS in TimeField

Thanks, I'll look into that. But does that mean that settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic flows that lead to it being used. On Tue, Mar 5, 2024 at 3:00 AM David Sanders wrote: > Define TIME_INPUT_FORMATS in your local formats.py setup as per: >

Re: Use of TIME_INPUT_FORMATS in TimeField

Define TIME_INPUT_FORMATS in your local formats.py setup as per: https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton wrote: > The documentation ( >

Re: Fellow Reports - February 2024

Week ending March 3 *Triaged:* https://code.djangoproject.com/ticket/35245 - Django freezes on DRF's APIView. (invalid) https://code.djangoproject.com/ticket/35253 - Pagination for StackedInline and TabularInline (duplicate) https://code.djangoproject.com/ticket/35251 - dumpdata

Re: Fellow Reports - February 2024

Week ending February 25 *Triaged:* https://code.djangoproject.com/ticket/35232 - Cache Options.verbose_name_raw (accepted) https://code.djangoproject.com/ticket/35234 - ExclusionConstraint.expressions should be checked for foreign relationship references (accepted)

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

I've found the reason why I've been thinking this wrong way. `getattr(self.get_queryset(), name)` is getting a bound method from Manager.get_queryset() which is a QuerySet class instance, while method is getting function from _queryset_class. The difference is one of them is bound method,

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

Thanks for your answer. I will continue to investigate based on your suggestions and if I find the answer I will respond again. 在2024年2月28日星期三 UTC+8 10:13:09 写道： > Hi Ryoma, a good way to investigate this would be to make the change and > see if anything breaks. > > If I understand correctly,

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

Hi Ryoma, a good way to investigate this would be to make the change and see if anything breaks. If I understand correctly, your suggest is: -return getattr(self.get_queryset(), name)(*args, **kwargs) +return method(*args, **kwargs) In that case, running the

Re: Deprecate CICharField, CIEmailField, CITextField

True, not the end of the world. Just ... another dependency. The NPM world has traumatized me. Many thanks for creating that. If there's nothing that can be done, it's time to move on. But worth asking. (Interestingly, even with the deprecation, historical migration fields still need to be

Re: Deprecate CICharField, CIEmailField, CITextField

I just say it: The decision certainly had good intentions, but maybe wasn't fully informed. It happens. But since we don't really have a processed to revert a deprecation, I would recommend using the django-citext package. It's a drop-in replacement with the same license as Django and a corporate

Re: Deprecate CICharField, CIEmailField, CITextField

Coming in again now that I've looked at upgrading. @Adam: your post was useful. But can you actually say you prefer the new approach? But I'm going to be honest, this is a lot of hoops and gotchas. What did we actually gain by deprecating this? I'm seeing maybe 15-20 lines of code that will

Re: Fellow Reports - February 2024

Week ending February 18 *Triaged:* https://code.djangoproject.com/ticket/35181 - behaviour of makemessage dont follow documentation (needsinfo) https://code.djangoproject.com/ticket/35185 - Daphne: websocket works locally with ws protocol, but it connects and quickly disconnects in

Re: Proposal for SyncChatRoom Integration in Django

That sounds great, I will keep you updated for any technologies to use or have you have any technical issues also keep me updated On Sun, Feb 18, 2024, 03:08 David Ansa wrote: > Hi Fawemimo Owolabi, > > Thank you for your support and feedback! I appreciate your suggestion to > use SyncChatRoom

Re: Proposal for SyncChatRoom Integration in Django

Hi Fawemimo Owolabi, Thank you for your support and feedback! I appreciate your suggestion to use SyncChatRoom as a third-party package, and I'm considering extending it to integrate with Django REST Framework as well. I'll keep the community updated on the progress, and feel free to share any

Re: New feature request - Run only a random subset of tests.

agreed about this is a unittest/pytest specific focus, not django. This is pretty straightforward to do with pytest, can have a custom flag and then randomize the test collection. With unittest, not sure. On Monday, February 12, 2024 at 11:36:57 AM UTC-5 Jörg Breitbart wrote: > I also think

Re: Proposal for SyncChatRoom Integration in Django

I really support these motions, it really sound great but it will be best to used as a third-party package, also for drf as well On Tuesday, February 13, 2024 at 11:21:02 PM UTC+1 Adam Johnson wrote: > Hi David > > SyncChatRoom sounds more like something that Django would help users > build,

Re: Proposal for SyncChatRoom Integration in Django

Hi David SyncChatRoom sounds more like something that Django would help users build, rather than include in the framework. If it’s somewhat reusable between projects, it would be best be published as a third-party package. Thanks, Adam On Tue, Feb 13, 2024, at 8:57 PM, David Ansa wrote: > Hi

Re: Testing Unmanaged Models - Using the SchemaEditor to create db tables

Hi Adam, Thanks for your response! I understand your point about unmanaged models being a niche use case of Django. I've decided to proceed with creating a package and see how it goes. The new enterContext() and other methods in unittest seem interesting. I'll definitely be using them more

Re: New feature request - Run only a random subset of tests.

I also think that your requirements are too specific to be added to django. You are prolly better suited by creating your own test picking abstraction for this, e.g. by writing custom test suite aggregates or using unittest.TestLoader.discover and going into tests of interest by your own logic

Re: New feature request - Run only a random subset of tests.

I’d be against this. I think this approach would be counterproductive in most cases due to the high probability of a false positive. Including it as a core feature is not necessary when it can be added through a third party package. On Mon, Feb 12, 2024, at 2:22 PM, אורי wrote: > Hi, > > Also,

Re: New feature request - Run only a random subset of tests.

Hi, Also, sometimes I just want to see how many tests are in a specific module, without running them. So I can just run `./tests_manage_all_sites_with_all_warnings.sh test speedy.net --test-only 0 --test-all-languages` which gives me the number of tests in speedy.net, or any module I need. There

Re: New feature request - Run only a random subset of tests.

Hi Jörg, All our tests are tested anyway with GitHub Actions. The idea is to run a subset of tests locally to catch 90% of the problems before I commit and wait 40 minutes for all the tests to run. It works most of the time. Of course the whole tests should be run before deploying to production,

Re: New feature request - Run only a random subset of tests.

Adding to my last comment: If you are looking for a more tailored unit testing with low test pressure and still high reliability - maybe coverage.py can give you enough code insights to build a tailored test index db to only run affected tests from current code changes. I am not aware of test

Re: New feature request - Run only a random subset of tests.

@Uri May I ask, whats the idea behind running a random subset of tests only? Wouldn't a Monte Carlo approach be highly unreliable, e.g. lure ppl into thinking everything is ok, but in reality the random test selection did not catch affected code paths? I mean for tests - its all about

Re: Testing Unmanaged Models - Using the SchemaEditor to create db tables

Hi Emmanuel Most activity from this mailing list has moved to Django Internals category on the forum: https://forum.djangoproject.com/c/internals/5 . Better to post there in future, or you could even duplicate this post. I think your approach is worth sharing in a blog post, or even a package,

Re: Fellow Reports - January 2024

Week ending February 4 *Triaged:* https://code.djangoproject.com/ticket/35153 - FORMAT_MODULE_PATH not acting as I expected. (accepted) https://code.djangoproject.com/ticket/35154 - QuerySet implements `contains` but not `__contains__` (wontfix)

Re: Fellow Reports - January 2024

Week ending January 28 *Triaged:* https://code.djangoproject.com/ticket/35132 - Django admin dark mode leaves the main container light. (worksforme) https://code.djangoproject.com/ticket/35134 - "Select all" checkbox in admin model view doesn't work in Django 5.0.1 (worksforme)

Re: Possible async view regression in django 5.0?

Hello Hugo, thanks for this email. Just for completeness sake and for future readers, I'm leaving a note here that a ticket was created for this issue ( https://code.djangoproject.com/ticket/35148) which was closed as a duplicate of https://code.djangoproject.com/ticket/35059. On Sun, Jan 28,

Re: Fellow Reports - January 2024

Week ending January 21 *Triaged:* https://code.djangoproject.com/ticket/35113 - Adding urls.py file while creating new app using startapp command (duplicate) https://code.djangoproject.com/ticket/35114 - Create a tests directory instead of tests.py when a new app is created (wontfix)

Re: Transition Docs to Inline

Hi Moshe, Just so you know there are a lot more discussions about Django these days on the Django Forum than this mailing list. There are also no such things as Django lords or a governing board :) The project is consensus-driven, so doesn’t require any

Re: Transition Docs to Inline

I agree that the official Python docs are well maintained and achieve a tough goal - the right balance of just replaying basic interface facts on one side, or being overly prosaic on the other side. Nope, they are well balanced giving enough of both extremes to get you going, place repo code

Re: Transition Docs to Inline

On 1/11/2024 12:01 AM, Moshe Dicker wrote: I should not that I'm only being critical to improve. The docs are well written, it's just disorganized. Something I've learned over the past 47 years of reading computer documentation is that _no_ documentation is "perfect" - especially not for

Re: Transition Docs to Inline

I should not that I'm only being critical to improve. The docs are well written, it's just disorganized. I mean no disrespect, we stand on the shoulders of giant, but that doesn't mean we should stop trying to improve. On Wednesday, January 10, 2024 at 11:57:40 PM UTC-5 Mariusz Felisiak wrote:

Re: Transition Docs to Inline

Agreed with Tim. > *I'll argue that right now we don't have documentation. We just have a mix of docs and reference, resulting in a convoluted manual that doesn't fit either need.* This is a really unfair opinion (not the only one in your comment). Hundreds of folks have put a lot of effort

Re: Transition Docs to Inline

I'll argue that right now we don't have documentation. We just have a mix of docs and reference, resulting in a convoluted manual that doesn't fit either need. Django isn't some fly-by-night framework whose documentation will devolve if we move the technical reference and documentation into

Re: Transition Docs to Inline

I don't think moving docs inline is a good idea. Quoting Aymeric from 2013 regarding django.contrib.admindocs [1] summarizes my feelings: """ 1) It's called the "documentation generator", but it only operates on docstrings. This promotes the idea that docstrings are appropriate documentation,

Re: Transition Docs to Inline

Ah interesting that you mentioned django-stubs. I had good to mediocre success applying it to my own django apps. It gets the job mostly done for high level interfaces, but shows rough stub edges as soon as you have to touch lower interfaces (can only speak for the ORM section in this regard,

Re: Transition Docs to Inline

Django uses a lot of bootstrap/runtime patching under the hood, from custom metaclasses, explicit injection pattern up to proxies at various ends. I understand this is true on low level APIs and on classes we implement ourselves (Like passing the correct arguments when creating a django

Re: Transition Docs to Inline

+1 on the idea for better inline docs, would be some relief for IDEs figuring out a proper interface story boosting dev speed for rarely used aspects, where currently one would have to search through the prosaic online docs or end up browsing the django source. On the other hand I am not

Re: Transition Docs to Inline

Django’s API Reference is more like a guide than an actual Reference at this point. I’m proposing as follows: 1. We take any part of the reference that is short and to the point and put it in a docstring. I think going the FastAPI route on this would be best, A guide and a

Re: Transition Docs to Inline

I will address each part of your questions. Why is consulting the online documentation insufficient? I think most developers build Django projects while referencing the online documentation rather than while reading Django’s source code. Having documentation available within the IDE really

Re: Transition Docs to Inline

Hi Moshe, Why is consulting the online documentation insufficient? I think most developers build Django projects while referencing the online documentation rather than while reading Django's source code. What sort of documentation would be inlined? Would this require a large amount of

Re: Fellow Reports - December 2023

Week ending December 31 *Triaged:*https://code.djangoproject.com/ticket/35062 - Update csrf.py to check request.POST if request.method is not GET (invalid) https://code.djangoproject.com/ticket/35059 - ASGI server leaves stale DB connections (needsinfo)

Re: Fellow Reports - December 2023

Week ending December 24 *Triaged:* https://code.djangoproject.com/ticket/35046 - BlankChoiceIterator causes AttributeError for some existing packages and projects (invalid) https://code.djangoproject.com/ticket/35050 - Issue filtering on FilteredRelation with F object (accepted)

Re: Deprecate CICharField, CIEmailField, CITextField

I only started trying to move to collations instead of citext recently, and it broke the regex validation as as non deterministic collation can't support regex validator, like what, why are we replacing something with an alternative that actually cant do the job as a replacement On Thu, 21 Dec

Re: Deprecate CICharField, CIEmailField, CITextField

This breaks search_fields. I can annotate a deterministic collation for simple fields. I don't understand why I have to do workarounds to get builtin stuff to work. There's no workaround I can figure out across joins though. I have `search_fields = ['owners__email']`. Using an annotated field

Re: Add a PersistedTemporaryFileUploadHandler for file upload

My first reflex to this is -1 for a simple reason: the persistence layer in django is meant to be db-driven. The upload logic is transient for that reason, and nothing stops you from creating a better controlled file upload handling with a model holding those files before entering your real

Re: Fellow Reports - November 2023

Week ending November 26 *Triaged:* https://code.djangoproject.com/ticket/34977 - Turn link to change password form in admin user change form into a button (accepted) https://code.djangoproject.com/ticket/34978 - Annotating through an aggregate with RawSQL() raises 1056 "Can't group on"

Re: Looking for a code that separates fields while applying migrations

On 28 Nov 2023, at 13:00, Remy Lukoo Hangi wrote: > > Fais-moi le setup.exe de python django suis débutant > Hi Remy, You found the developers email list for Django. Actually the email lists are not really used anymore, and you should use the ‘forums’ instead —>

Re: Looking for a code that separates fields while applying migrations

Fais-moi le setup.exe de python django suis débutant Le mardi 3 octobre 2023 à 06:41:12 UTC+2, Akash Sen a écrit : > This one worked : SQL: > https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/models/fields/__init__.py#L142 > . > Thank you Adam. > > On

Re: Fellow Reports - October 2023

Week ending November 3 Released Django 4.2.7, 4.1.13, and 3.2.23. *Triaged:* https://code.djangoproject.com/ticket/34941 - db_default with decimal.Decimal() doesn't return Decimal instances on Oracle. (created) https://code.djangoproject.com/ticket/34943 - Support passing database

Re: Fellow Reports - October 2023

Week ending October 29 *Triaged:* https://code.djangoproject.com/ticket/34923 - MESSAGE_TAGS ignored in 5.0a1 (accepted) https://code.djangoproject.com/ticket/34924 - Example for squashmigration not working properly (duplicate) https://code.djangoproject.com/ticket/34919 - Missing

Re: How do you set the python path for django-admin?

Hi tobias. The django-admin command has a `--pythonpath` option for this (docs ). So, for example in a 3rd party package using the src layout (example ) where the module

Re: Wrong ordering of many-to-many fields with explicit intermediary model in Django admin

Hi Alan, This is a known issue, you can find a discussion in https://code.djangoproject.com/ticket/12203. It's an accepted ticket so feel-free to work on it. Best, Mariusz -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to

Re: Potential bug with how Value works with Django ORM queries

Hi David, Thanks for response. I understand it now. I was assuming that Value auto typecasts to the field that we are querying. This makes sense. Thank you for taking time to respond. Cheers Nitin On Thursday, October 26, 2023 at 3:52:17 AM UTC-4 David Sanders wrote: > Hi Nitin, > > Not sure

Re: Potential bug with how Value works with Django ORM queries

Hi Nitin, Not sure what db you're using but will explain assuming PG. In this particular example, Django uses the `->` operator which requires that we compare jsonb types. The `__in=("Program1", "Program2")` is converted to jsonb via `DatabaseOperations.adapt_json_value()` where as `Value()`

Re: Question about support dates

As the maintainer of several Django-related packages and a contributor to many more, I see the policy as fair. Most maintainers have little capacity, and anything to reduce that burden is welcome. Third-party packages typically test with a matrix of Python versions against Django versions.

Re: Fellow Reports - October 2023

Week ending October 22 *Triaged:* https://code.djangoproject.com/ticket/34901 - Add async interface to contrib.sessions (accepted) https://code.djangoproject.com/ticket/34902 - django.test.client.Client.head request fails on AttributeError as_sync is missing (worksforme)

Re: Fellow Reports - October 2023

Week ending October 15 *Triaged:* https://code.djangoproject.com/ticket/34894 - Query.change_aliases() has several significant bugs (needsinfo) https://code.djangoproject.com/ticket/34895 - Reverse migrations fail with mysql / mariadb with sql_safe_updates set to 1 (duplicate)

Re: Admin login view does not respect REDIRECT_LOGIN_URL

Hello, Please double check the setting name, it should be LOGIN_REDIRECT_URL https://docs.djangoproject.com/en/4.2/ref/settings/#login-redirect-url. Regards, Maciej wt., 17 paź 2023 o 05:35 Gagan Deep napisał(a): > Hello everyone, > > While working on my project, I found that the admin login

Re: Needed feedback on the approach to solve bulk_update silently truncating values for size limited fields

Got it. Thank you for the response Mariusz and Simon. On Tuesday, October 17, 2023 at 11:43:00 AM UTC+5:30 Mariusz Felisiak wrote: > I wanted to propose these solution as a hotfix unless we get #31202 > or #29771 >

Re: Needed feedback on the approach to solve bulk_update silently truncating values for size limited fields

I wanted to propose these solution as a hotfix unless we get #31202 or #29771 done. As we are going to upgrade the bulk_update in near future, resolving the bug for now seems reasonable to me.

Re: Needed feedback on the approach to solve bulk_update silently truncating values for size limited fields

The argument of having new specialized bulk_update_cast method is more logical than the earlier two approaches. But the best approach should be drop using Case / When which will eventually come with #31202 or #29771

Re: Needed feedback on the approach to solve bulk_update silently truncating values for size limited fields

Hello Akash, Another approach that isn't mentioned here but alluded to in the ticket is to actually move bulk_update away from using Case / When which is the root of the issue here. We know that using Case / When is slow

Re: HELP needed in a Reactjs Django project

I have done like this where there is input in front end and data is passed to django admin panel you have to make first crossorigin in django and then make api structure in django and then pass it in reactjs call api from axios I have code of it I will send you after some time understand it simple

Re: HELP needed in a Reactjs Django project

Hi! 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: HELP needed in a Reactjs Django project

Bien Le ven. 13 oct. 2023 à 14:14, Tejas Vaij a écrit : > I am trying to upload a blob from a service-worker in react-js to a django > server but for some reason it is not getting uploaded. I have tried a lot > of things but nothing seems to be working. Can anyone please help me know > what is

Re: Pertaining the 4.2.6 release's "recreate indexes" footnote

I’ve created a PR with a suggested improvement: https://github.com/django/django/pull/17359 . On Thu, Oct 12, 2023, at 5:09 AM, Mariusz Felisiak wrote: > > Thoughts on this? > > Documentation improvements are always welcome, you can send your proposition > via GitHub PR. > > Best, > Mariusz >

Re: Pertaining the 4.2.6 release's "recreate indexes" footnote

> Thoughts on this? Documentation improvements are always welcome, you can send your proposition via GitHub PR. 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

Re: Pertaining the 4.2.6 release's "recreate indexes" footnote

Pardon, @Mariusz, I didn't mean to specify "non-text fields" - I had re-worded that sentence before posting. On Wednesday, October 11, 2023 at 2:29:58 AM UTC-4 Mariusz Felisiak wrote: > My immediate thought is that any indexes on non-text fields, created with > these versions,

Re: Pertaining the 4.2.6 release's "recreate indexes" footnote

My immediate thought is that any indexes on non-text fields, created with these versions, will be useless in ORM-based queries. If that's the case, this seems like a much bigger deal than the footnote would imply. I'm puzzled. Why you assumed that all non-string based fields are affected?

Re: Pertaining the 4.2.6 release's "recreate indexes" footnote

Hi, I also think a more specific documentation as to how to fix this issue is required. I usually upgrade Django about 6 months after the initial major release, which is this month. But because of this issue I decided to wait 2 more months. Thanks, Uri. אורי u...@speedy.net On Wed, Oct 11,

Re: Link to alternative Python resource

It seems plausible to me. I'll try to look into other places where it has been repeated and try to make a PR. On Monday, 9 October 2023 at 20:58:15 UTC+5:30 Adam Johnson wrote: > I think it would be better to remove the link from the contribution guide, > since it’s quite advanced. The

Re: Link to alternative Python resource

I think it would be better to remove the link from the contribution guide, since it’s quite advanced. The recommendation for the tutorial and “you should have a good understanding of Python itself” seem sufficient to me. I noticed we have other “Dive Into Python” links throughout the docs.

Re: Update returning

I think it's okay to return something else based on a parameter. This is already done for e.g. values_list(flat=True) and values_list(named=True). While the bool addresses the obvious footgun I think it also loses a lot of flexibility. If you have a field modified by a pre-update trigger or a

Re: Update returning

Hi! I considered making `returning: bool` a flag that we are returning data. That would make it `Foo.objects.update(x=1, y=2, returning=True)` and avoid some footguns. Or even a new function (`update_returning`?) because I have mixed feelings about different return types based on parameters.

Re: Update returning

Hi Aivars, Since we spoke yesterday I've been thinking about this... I don't really see the value in returning a QuerySet. There are only a limited number of options that make sense at this point, and even those are tough to justify. Like what would happen if you do `Foo.objects.update(x=1,

Re: Fellow Reports - September 2023

Week ending October 1, 2023 *Triaged:* https://code.djangoproject.com/ticket/34866 - Cannot inspect migrations that replace squashed migrations with sqlmigrate (needsinfo) https://code.djangoproject.com/ticket/34871 - Validation of UniqueConstraint with Case() crashes. (accepted)

Re: Update returning

Bien Le lun. 25 sept. 2023 à 17:44, Aivars Kalvāns a écrit : > Hi! > > I want to implement these changes and I have a PR in the ticket > https://code.djangoproject.com/ticket/32406 > At the moment I have a new `update_returning` method but I can easily > replace it with ` (updates=None, *,

Re: Looking for a code that separates fields while applying migrations

This one worked : SQL: https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/models/fields/__init__.py#L142 . Thank you Adam. On Monday, October 2, 2023 at 3:44:34 PM UTC+5:30 Adam Johnson wrote: > See alte_field in the schema editor: >

Re: Looking for a code that separates fields while applying migrations

See alte_field in the schema editor: https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/backends/base/schema.py#L811 It steps through what has changed in the field and generates SQL for the database relevant changes, queueing up statements with

Re: (Circa end of 2021) Localization issues with input type=date?

On Thursday, November 10, 2022 at 5:40:45 AM UTC-3 Jacob Rief wrote: How about ditching the JS based datepicker altogether and replace it against the built-in datepicker offered by modern browsers? This would also help users of mobile devices because they already have good internal

Re: Update returning

Hi! I want to implement these changes and I have a PR in the ticket https://code.djangoproject.com/ticket/32406 At the moment I have a new `update_returning` method but I can easily replace it with ` (updates=None, *, returning:bool=None, **kwargs)` if you decide to add functionality to the

Re: Django in Portuguese

Hi, I created the following issue: https://code.djangoproject.com/ticket/34854 Thanks, Uri. אורי u...@speedy.net ‪On Tue, Sep 19, 2023 at 9:57 PM ‫אורי‬‎ wrote:‬ > Django Developers, > > I need to translate my website (Django) to Portuguese (Europe/Portugal > version). I translated the site

Re: Proposal: Clarify individual members page

Small typo in my previous post. Clearly I meant I'll open the PR next year... Better late than never, here is the PR with changes from my previous draft based on everyone's input: https://github.com/django/djangoproject.com/pull/1406 Thanks again for all the feedback. On Friday, November

RE: Allow applications to register links in the admin interface

(Contributions to Django itself) Subject: Re: Allow applications to register links in the admin interface You have some great points that I definitely overlooked in the initial implementation. I don't think that overloading the template is a great solution since there are still some features

Re: Allow applications to register links in the admin interface

I'm also -1. Django Admin is not a universal tool for building an app and adding a new option is always controversial (we already have many of them). There is a way to achieve the same by providing

  1   2   3   4   5   6   7   8   9   10   >