from:"Ken Whitesell"

Re: Transition Docs to Inline

2024-01-11 Thread Ken Whitesell

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 everyone.

All documentation is a compromise.

Different people have different ways of reading and understanding
written material. There is no "one right way" to write or organize a set
of manuals. The best you can hope for is to create docs that are
complete, materially correct, and internally consistent.

I have also learned through the years that it's _me_ that needs to adapt
myself to the different styles of documentation available. Yes, I have
preferences for certain styles. But, I also recognize that not everyone
reads and processes information the same way I do. I have no doubt that
_you_ would find it an improvement to change the docs as you describe.
However, I would suggest that you not try to sell the idea as being
objectively true for everyone and that it's "obviously better".

Me? Personally, I have an extreme dislike of docs embedded in code. When
I want to read the code, I want to see the code - not a full set of
reference information that I have to wade through - and ignore - while
I'm trying to find the information I want to see.

I want the code to be free of any clutter that can be better stored
elsewhere.

Likewise, I greatly prefer docs that go well beyond just being an "API
reference". I find sites for libraries showing nothing more than
Javadoc-style pages to be virtually useless to me when I'm first getting
started.

I have long maintained that I am more than twice as productive using
Python than I am in any other language - and part of that is the quality
of the Python docs. I always seem to be able to easily find what I'm
looking for.

In my opinion, the Django docs are close - but not quite as good - as
the Python docs. There are a couple of specific topics where I do find
myself thinking "Where is that documented?" and have to search for it.
It's not that I think they're in the "wrong" place, but it's probably
not where _I_ would have put that information. But that's ok, I probably
should just bookmark those pages...

So no, I'd be a strong -1 to any recommendation suggesting that
docstrings be used to clutter up the code.

Re: Can we move the activity on this list to the Forum now?

2023-05-04 Thread Ken Whitesell

Hi Tim,

I'm one of the Moderators of the forum, and yes, I am actively working
on cleaning up the categorization of the messages. (It's a slow grind,
but I'm making gradual-but-reasonably-steady progress.) I do try to stay
on top of new messages - but I'm also going back through existing 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 wrote:

I agree with Carsten. I find the groups.google.com web interface much
easier to follow and to quickly scan and see which threads I've read
and which have new activity. I follow this mailing list more closely
than the forum and prefer writing to it.

Incidentally, when I look at the "Django Internals" category of the
forum, I see a lot of inappropriate usage questions that get answered
there rather than pointed to the correct category. Is there a way to
recategorize those posts?

On Thursday, May 4, 2023 at 2:09:35 AM UTC-4 Carsten Fuchs wrote:

Hello,

unfortunately, the subject lines of the emails sent by the forum
have the forum category prepended. These prefixes are long and
make it difficult to parse a large number of emails quickly, which
significantly reduces one of the main strengths of mail(ing-list)s.

To be honest, I'm surprised that not more mailing list members
argue in favor of the mailing list.

The mailing list makes it easy to read or at least glance at every
single message, if desired, while enabling readers to skip
uninteresting threads quickly. This is a lot more difficult on the
forum, especially with the user interface as implemented by
Discourse, which wastes a lot of white space (lines with much
vertical spacing, as with the topic lines on the Latest page, are
difficult to parse quickly) und whose „last visit“ line is
unreliable, especially if you read the forum on multiple devices
(home, office, mobile, …) with possibly several tabs open at the
same time.

I'm aware that I'm in a minority and that there is no way to
convince the relevant people to keep the mailing-lists, but in my
opinion the switch the forum is a step backwards in accessibility,
usability and easy of use.

Best regards,
Carsten

Am 04.05.23 um 07:49 schrieb Jure Erznožnik:

This has been answered affirmatively in this very thread before.

The forum even has a "Mailing list mode" in addition to several
other mailing options (including a nifty "activity summary").

LP,
Jure

On 4. 05. 23 07:28, Curtis Maloney wrote:

Does the Forum allow me to get email notifications / summaries?

If not, it will mean I disconnect with that part of the community.

--
Curtis

On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:

Yes please!

On May 3, 2023 at 11:19:12 PM, jure.er...@gmail.com
(jure.er...@gmail.com) wrote:

*From:*django-d...@googlegroups.com
*On Behalf Of *natali...@gmail.com
*Sent:* sreda, 03. maj 2023 20:10
*To:* Django developers (Contributions to Django itself)

*Subject:* Re: Can we move the activity on this list to the
Forum now?

Hello everyone!

I was wondering if we could make a decision about this topic.
On the one hand, and as far as I understand, the forum is the
preferred channel of communication. On the other hand, having
multiple channels of communication can spread important
discussions too thin, making it difficult to have productive
conversations in one place.

As a newcomer to the contributing community, I can attest that
the current situation causes some confusion. IMHO, the same
applies to the chat options: there is IRC and the Discord
server (though perhaps I should start a new forum topic about
that in order to keep decisions separated).

In summary, I'm +1 to "move on-mass (all few of us :) over there"!

Thank you!

Natalia.

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/2c6cf8cc-91f5-48d9-a3a9-337fff1f3439n%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/2c6cf8cc-91f5-48d9-a3a9-337fff1f3439n%40googlegroups.com?utm_medium=email_source=footer>.

--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emai

Re: URLField Validation

2022-09-23 Thread Ken Whitesell

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 issue with a models.URLField because it limits the size of 
> the field to 200 characters. I find this too short to my use case. I have a 
> valid URL to an external website (in academia), and it won’t fit in the 
> Django URLField.
>
>  
>
> This took me down a rabbit hole and this very good answer on Stack 
> Overflow:
>
> https://stackoverflow.com/a/417184/603819
>
>  
>
> Summary:
>
>1. The HTTP protocol doesn’t place a limit on the number of characters.
>2. Modern browsers suggest not exceeding 2,000 characters.
>
>  
>
> There are other details, such as the domain name not exceeding 255 
> characters, but that is a different issue.
>
>  
>
> Why does Django impose such a limit on URLField? Could we increase it to, 
> say, 2000 characters? Or even just remove the limitation on it?
>
> Thanks,
>
> Matthew
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a42f7ebc-d6c3-4e57-8b23-03dad0e5f391n%40googlegroups.com.

Re: Regarding Django forms

2022-09-23 Thread Ken Whitesell

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 and conversions.

On 9/23/2022 10:06 AM, Nishant Sagar wrote:
That's the whole point. I've attached my form.html file, do you think
it's a generous idea to design the whole form page using widgets if I
already have the form template ready?

id="register-form">

{% csrf_token %}
Registration form

Name of Homeowner :

Roof Age :
required />

Email ID :
required />

Phone :
required />

Full Home Address :
required />

Average Monthly Electric Bill Costs :
required />

Do you have HOA?

Yes

Would you also need a
battery?

Yes

Is your home on concrete
foundation?

Yes

Roof Type :

Select here
Comp Shingle
Concrete
Metal
Spanish
Clay

Your Availability :
placeholder="Select Time"

required />

Upload your bill :

id="reset" />
id="submit" />

On Fri, Sep 23, 2022 at 7:20 PM siyamak abasnezhad
wrote:

You can use widget Tweeks or crispy

On Fri, Sep 23, 2022, 09:26 Nishant Sagar
wrote:

Hey forks,

I’m in little dilemma regarding Django forms. I'm working on a
project as a backend guy who doesn't know much about CSS and
JavaScript so a frontend guy delivered me a form template
designed using CSS, however, Django documentation suggests
that it's good practice to use Django forms.

So how feasible do you think it is for a frontend guy to learn
Django widgets from scratch to implement the same thing he can
easily do from CSS and JS. As a newbie backend guy, it's not
easy for me either to learn frontend tech to implement the
same thing in so little time.

So I tried implementing the form without using Django forms
but I find it hard to deal with files as there is no
documentation I can look up to.

So can we add these to the documentation or it is still
advisable to use Django forms?

Thanks and regards,
Nishant
--
You received this message because you are subscribed to the

Google Groups "Django developers (Contributions to Django
itself)" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to
django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/CANNtL-Kqud7V6sk_%3DYnagzATw8eJjO9pCeDx9Za80XywXBi2tQ%40mail.gmail.com

--
You received this message because you are subscribed to the Google

Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/CAOGgH_-umvzoQ2cDkQFbTMU%3D6cvsxNV%2B2MNCwvr46kPCOCJ-Gw%40mail.gmail.com

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CANNtL-KYchoxjB9GoQsBhHQb%2BEdhtO9FdC9D%2B%2BTmipg96JskKw%40mail.gmail.com
.

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

2022-07-16 Thread Ken Whitesell

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 the rest.

I don't see value in trying to replicate what BeautifulSoup provides
within Django.

Ken

On 7/15/2022 8:21 PM, Dan Swain wrote:

With the growing uptake of technologies like HTMX, I would like to see
an additional parameter added to render_to_string(). In my rewritten
definition of render_to_string() below (taken from the docs), I have
named the parameter “part”. In rendering portions of a template for
responses to ajax calls, these template portions end up being stored
in separate template snippet files and then {% include(d) %} in the
main template. I think that keeping everything related to a view in a
single template file is much more desirable. Therefore, just include
*/part=selector/* in order to pull out the part of the template that
is needed for rendering. The file structure for managing templates
would become much simpler with this approach.

*render_to_string**(**/template_name/**, /part=None,/
**/context=None/**, **/request=None/**, **/using=None/**)¶
*

*render_to_string()* loads a template like *get_template()*
and
calls its *render()* method immediately. It takes the following arguments.

*template_name***

The name of the template to load and render. If it’s a list of
template names, Django uses *select_template()*
instead
of *get_template()*
to
find the template.

*part***

An optional CSS selector that will be used to cause only the portion
of the template that matches the selector to be rendered.

*context***

A *dict* to be
used as the template’s context for rendering.

*request***

An optional *HttpRequest*
that
will be available during the template’s rendering process.

*using***

An optional template engine *NAME*
.
The search for the template will be restricted to that engine.

Re: Case Sensitive Usernames

2021-12-12 Thread Ken Whitesell

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
local-part of an address is case-sensitive.

(Note: I operate a case-sensitive email server, just as a demonstration
of that standard.)

On 12/12/2021 10:32 PM, Arthur Pemberton wrote:
A setting to convert all usernames to lowercase would be good too --
that's my preference overall in general. However I haven't yet seen
how best that could/would be accomplished.

For simpler uses case where I'm just sub-classing AbstractUser and not
customizing the auth backend, I've taken to
overriding UserManager.get_by_natural_key to allow for
case-insensitive logins. Though really, I probably should add a signal
handler to force username to lowercase.

Arthur

On Sunday, December 12, 2021 at 11:21:32 AM UTC-5 Uri wrote:

Hi Arthur,

I would recommend users of Django to use only lowercase usernames.
And if they insist that the username is an email address, also
convert it to lowercase. Otherwise you can have 3 separate users
uri, Uri, and uRI, or 3 separate users with email addresses
u...@example.com, u...@example.com, and u...@example.com (or even
u...@example.com). Maybe it's better to add an optional setting to
enforce usernames to be lowercase. And by the way also
alphanumeric. You don't want "!@#" to be a username on your system
(or the user's name in Chinese or Hebrew).

It's interesting that this ticket is 15 years old and still not
completely resolved.

By the way, when people type their email address, some programs
(including browsers) convert the first letter to uppercase, and I
have received email addresses from people with the first letter in
uppercase, although their true address is lowercase. I don't think
you want this uppercase letter to appear on your database in the
email field.

אורי
(Uri)

u...@speedy.net

On Sun, Dec 12, 2021 at 6:02 PM Arthur Pemberton
wrote:

Especially with the ability to set USERNAME_FIELD to "email",
it would be really useful to at least have a well documented
warning that usernames are case-sensitive in Django.

I've been using Django for years, and even I forget that fact
some times. Until I start Googling and come across [1].

Ideally, it would be great to have a setting (or model field)
that would allow easy switching to case insensitive usernames.

Arthur Pemberton

[1] https://code.djangoproject.com/ticket/2273

--
You received this message because you are subscribed to the

Google Groups "Django developers (Contributions to Django
itself)" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/9a5e1df3-778d-4993-8c32-57870fafd8f9n%40googlegroups.com

Re: Error in Models Documentation

2021-10-10 Thread Ken Whitesell

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 documentation is accurate and correct with what it's
saying.

Ken

On 10/10/2021 8:15 AM, Pranav Mittal wrote:

Hello everyone.

https://docs.djangoproject.com/en/3.2/ref/models/querysets/#django.db.models.query.QuerySet.exclude

The second example mentions that the query will return entries /whose
/pub_date/ is later than 2005-1-3 /*_O_**_R _*/whose headline is “Hello”./

/
/
/But the equivalent SQL statement mentions /_AND_.

Untitled.png
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/9028b784-9bd8-4207-91e0-d46e9907fb44n%40googlegroups.com
.

Re: Feature Request: Nested Natural Join Query

2021-09-10 Thread Ken Whitesell

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.
https://docs.djangoproject.com/en/3.1/faq/help/

On 9/10/2021 3:08 PM, Mani Mozaffar wrote:

Hello,

Imagine this case:
Model A
——> Model B(many to many to A)
-> Model C (many to many to B)
-——->Model D (many to many to C)

To get a query set of objects D which are connected to an object like
A.id=1 , we can do a query like this:

Select * from A natural join B natural join C natural join D

Such a query does not exist as long as I have researched, so I think
Django ORM should be modified.

Re: Add feature request for django permissions.

2021-06-12 Thread Ken Whitesell

Yes, I understand you.

Please keep in mind that depending on time zone and day-of-week, not
everyone is up early on a Saturday morning to reply to the mailing list.
A proper response may take a while as people read & understand what you
wrote.

While I'm not a Django developer (in the context of this mailing list),
I'll offer an opinion here that I don't think what you're looking for is
worth adding into Django core.

Handling row-level security is very much a per-project issue - I don't
think I've ever worked on two systems having the same requirements.

There are a number 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 one understands me

في السبت، 12 يونيو 2021 في تمام الساعة 11:27:39 ص UTC+3، كتب ‪wael
muhammed‬‏ رسالة نصها:

? What is yours opinion could I make a pull request

في السبت، 12 يونيو 2021 في تمام الساعة 9:40:48 ص UTC+3، كتب ‪wael
muhammed‬‏ رسالة نصها:

could this

<https://stackoverflow.com/questions/67946118/django-permissions-according-to-branch-id>
want feature request.

--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/34e5b0d5-c4aa-4f77-ba94-d96a35fe992en%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/34e5b0d5-c4aa-4f77-ba94-d96a35fe992en%40googlegroups.com?utm_medium=email_source=footer>.

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

2021-01-28 Thread Ken Whitesell

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 unnecessarily.
(Do you really need the User phone number with every request?)

2. If you go in that direction, there's no way you're going to reach a
consensus as to what fields should be included, or to make a valid
argument against field "X" once field "Y" has been added - ending up
with an extremely over-bloated object.

3. It's too easy to extend or replace the user model. The process is
well-documented. Saying "some developers don't want to" do something
doesn't constitute a reason.

(I'm an extremist in the other direction. I believe that the User model
should only consist of the PK, and an "active" flag. All other
information can be stored in ancillary tables - but I acknowledge that
that's very much a minority position as well.)

On 1/28/2021 8:25 AM, Muhammad Shehzad wrote:
Hey Developers! Some fields should be inside models.User e.g. image,
phone_number. Some developers don't want to extend the auth model. Yes
i know there are some ways to extends the auth model. But i think
these fields should come with models.User

Re: Query identity operation

2020-12-21 Thread Ken Whitesell

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 12/21/2020 9:45 AM, Adam Johnson wrote:
I saw that Q() with no arguments is not documented, so I've made a PR
to add a sentence covering it:
https://github.com/django/django/pull/13798
.

On Mon, 21 Dec 2020 at 05:21, Mariusz Felisiak
mailto:felisiak.mari...@gmail.com>> wrote:

complete_query = ~Q(pk__in=[]) # this should be something like
Q.ident()

You can use `complete_query = Q()`. Also, this mailing list is for
discussing the development of Django itself, not for support using
Django.
Best,
Mariusz
--
You received this message because you are subscribed to the Google

https://groups.google.com/d/msgid/django-developers/676b8f7e-073d-4b69-9b70-b7824c31d3f3n%40googlegroups.com

--
Adam
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM2b6-sxMdCMkncivfHEi%3DUPX4ZDXsKSvHSB5q88GiQOsQ%40mail.gmail.com
.

Re: Changing the discovery method for management commands

2020-12-20 Thread Ken Whitesell

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 their own management
commands, because it explicitly requires them to create a django app
which just adds a bunch of unnecessary files to their source code.

I propose we overhaul the existing management command discovery system
so that it is easier to write management commands. Also I suggest we
keep the default discoverer in place so as to maintain backwards
compatibility.

All of this will require documentation and I am ready to make a PR for
that too. Please tell me if the idea is feasible, and I will get to
work on it ASAP.

Best
Diptesh Choudhuri

What extra files do you think are necessary? I just created a project
consisting of the management/commands directory and a command file. I
then installed the package in a venv, imported the module in my
settings.py file and added it to INSTALLED_APPS. Works fine. No other
files or directories were needed. (Python 3.8, Django 3.1)