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: Can we move the activity on this list to the Forum now?

messages. Admittedly, I've been most focused on cleaning up the "Using Django" dumping ground. However, if there's any request for me to change my focus for a bit to get the Internals category cleaned up, I'd be more than happy to oblige. Ken Whitesell On 5/4/2023 11:02 AM, Tim Graham

Re: URLField Validation

That limit is a default setting. You're free to change it to whatever value you want in your models. (See the docs for URLField ) On Friday, September 23, 2022 at 3:58:55 PM UTC-4 matthew.pava wrote: > Hello, > > I ran into an

Re: Regarding Django forms

Absolutely. If you're using Django, then *use* Django. Take advantage of all the facilities it provides you. Yes, it's a little more work on your part to convert this to a Form-based template. But what it provides you are all the facilities available within Django forms for data validation

Re: Feature Request: New parameter for render_to_string() to render part of a template using a selector

I'm going to chime in as a -1 here. It does not seem to me that you can guarantee that you have the correct element(s) unless you actually render the complete template. Once you've rendered that template, then you can use tools like BeautifulSoup to extract the elements desired and ignore

Re: Case Sensitive Usernames

Also a strong -1. While it is rare, it is perfectly legitimate to have a mail server treat the name portion of an email address as being case sensitive. Yes, you can find a lot of wrong answers on the internet stating otherwise, but paragraph 2.4 of RFC 5321 clearly states that the

Re: Error in Models Documentation

This is not an error. The identified example does _not_ say that it will "return" those entries. It states it will _exclude_ entries matching either of those two conditions. Likewise, the SQL statement referenced is a negation ("and not") of the condition. This portion of the

Re: Feature Request: Nested Natural Join Query

Yes, such a query can be written, so no change to the ORM is required for this. However, this isn't the right mailing list for providing direct assistance. If you need help constructing such a query, please visit one of the appropriate support venues.

Re: Add feature request for django permissions.

mber of different packages available, such as Django guardian, that can help. However, the details of using such packages doesn't belong in _this_ mailing list. I believe such a discussion would be more appropriate for Django users. Ken Whitesell On 6/12/2021 7:30 AM, wael muhammed wrote: ?Did any

Re: Add image and phone_number fields to Django User auth model

I can see where you might think that, but I actually believe it should go in the other direction - that the User model should be the absolute _minimum_ of an entity. 1. The User model is retrieved with every authenticated request. The more fields in the model, the more data is being handled

Re: Query identity operation

A couple questions came to mind if we're going to document this as "official behavior": 1. This also appears to be true for filter. Would the same clarification be appropriate there? 2. I don't see any tests validating the behavior for either Q or filter, should there be? Ken On

Re: Changing the discovery method for management commands

On 12/18/2020 8:48 PM, Diptesh Choudhuri wrote: As of now, if you need to create a management command, it is necessary to create a file *app_name/management/commands/my_command.py, *and then add *app_name *to *INSTALLED_APPS *in *settings.py. *This prevents non-django packages from defining