On Fri, Oct 11, 2019 at 9:29 PM Matt wrote:
> I think it should just show instead of .
>
I agree, I think this makes the most sense.
I think it can be argued that QuerySet should be consistent with [RawQuerySet,
> which just uses a string of the query in the repr]
>
I can see the argument I s
I reviewed the patch that was originally created for this:
https://github.com/django/django/pull/1055/commits/7d53d428c0323a7eca93b7b56968a895b031e2ae
Essentially, it only includes the results of the queryset in the repr *if*
the QuerySet._result_cache has been populated. There is one m
A better link for the CSS class issue is this one
https://docs.djangoproject.com/en/2.2/ref/forms/widgets/
On Fri, 11 Oct 2019 at 20:54, Carlton Gibson
wrote:
> HI Alex,
>
> For label_suffix, I'd say a base form class for your project is exactly
> the way to go.
> You can set CSS classes at th
HI Alex,
For label_suffix, I'd say a base form class for your project is exactly the
way to go.
You can set CSS classes at the field level[0]
... — I suspect the API is there, but maybe reviewing the guide[1] for
where it's lacking might be good.
There are also third-party options, such as C
It's just scope:
* Not clear we need to _replace_ the space for books, and blog posts,
and so on, in the main docs.
and bandwidth:
* These things are difficult to get right, and it needs someone to do
them. (PRs always warmly received!)
On balance, I have to say, I think the default pr
Exactly, I believe a best practices section should be added to the already
robust Django documentation. Something akin to the Two Scoops of Django
book. That would be better than focusing a pattern on everyone.
On Fri, 11 Oct 2019, 13:21 Carlton Gibson, wrote:
> I can see a How-To explaining dif
I can see a How-To explaining different patterns here being a valid addition to
the docs.
FWIW, there’s a PR to ease/enable SECRET_KEY rotation. It might mitigate some
of the issues with first committing sensitive values to git when it lands.
https://code.djangoproject.com/ticket/30360
--
Yo
This feature should be filled under a "nice to have" and not a "must have".
On Fri, 11 Oct 2019, 12:45 Mariusz Felisiak,
wrote:
> Hi,
>
> I don't agree that Django should force pattern with multiple settings
> files (*base, development, staging, and production*) there is many ways
> to keep
Hi,
I don't agree that Django should force pattern with multiple settings
files (*base, development, staging, and production*) there is many ways to
keep secrets and probably a *production.py* settings file is not the best
one (IMO). Everything depends on a project (not all of them have suc
On Thursday, October 10, 2019 at 9:41:53 PM UTC+2, Bobby Mozumder wrote:
>
> Additionally, startproject should add a .gitignore in the root directory
> to not include development/staging/production settings files.
>
I am very much against creating a .gitignore as part of startproject. Also
I
I strongly disagree with this.
I've not seen a common standard between companies when it comes to settings
in Django and for good reason. Different companies employ different
standards and practices when it comes to configuration and security.
Enforcing an arbitrary standard - such as a settings f
Hi, may I disagree - I set up projects very often (for testing a
package), and I always feel a bit awkward because of that monolithic
settings.py file.
I can really support Bobby's idea, even if
development/staging/production may be a bit overkill. Having a practical
standard which ensures good pr
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for 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 unlikely to answer yo
13 matches
Mail list logo
