Hi,
On Thu, Nov 10, 2022 at 9:40 AM 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
> implementations to s
On Tue, Nov 1, 2022 at 10:34 AM Florian Apolloner
wrote:
> Right, that would work. I am wondering though if we want to go all in on a
> typed config object like that or in a first step only have a simple API
> like `config.get('DEBUG', cast=bool)`.
>
>
I found a neat trick in a 12factor library s
Hi
I believe the main objection is against adding additional API to querysets.
get_object_or_404 only converts DoesNotExist into a 404 exception and
doesn't handle MultipleObjectsReturned.
I'm not the first to suggest adding an additional shortcut, e.g.
django.shortcuts.get_object_or_none which w
Maybe we're doing something stupid or there's a misunderstanding but we had
a recent use case for this: The same website runs on several domains, one
domain per language and each domain has its own email address. We were
using an email relay (Mailgun in this case but the same will probably be
true
Yes, please.
As a third party app developer I'll have to update a few GitHub
workflows and tox configurations (since I'm running testsuites against
the main branch too). It may be useful to announce this change on as
many channels as possible (mailing lists, the forum, as a news entry on
the
on the web visit
> https://groups.google.com/d/msgid/django-developers/f96a4b22-3ce3-4031-a97a-d3b406d788ccn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/f96a4b22-3ce3-4031-a97a-d3b406d788ccn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
&
Hi
I have survived a few changes in Django over the last >10 years, and this
change is absolutely not comparable to any of the problematic ones.
For example, the get_query_set -> get_queryset rename was hard because it
was unclear how to properly support subclassing querysets.
The on_delete addi
ibutions 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/DCC0D41F-A34F-
Hi,
You could make the generic-list.html template extend a configurable base
template, e.g. "{% extends base_template|default:'base.html' %}", and add
context["base_template"] = "orders/base.html" in views belonging to the
orders app, and "products/base.html" in the products app.
I often use this
On Wed, Apr 24, 2019 at 9:06 AM Carlton Gibson
wrote:
> On Wednesday, 24 April 2019 08:58:57 UTC+2, Josh Smeaton wrote:
>>
>> lots of bikeshedding
>>
>
> Yeah. 🙂
>
> But we've already got a style guide, so **IF** we can get a YAPF config to
> work to that then hopefully the arguments against usin
After dozens of mails it's clear that this is certainly a controversial
topic -- especially, as always, string quoting.
I think there is an overwhelming benefit in adopting black and not
deviating from the defaults even if the only benefit of this is just never
having to discuss these choices agai
Please don't do this.
There are very good reasons for NOT including blank=False fields by default
such as batch-editing some field with a formset or inlineformset or just
offering different forms to users with different access levels (as Tobias
wrote).
Django started recommending using `fields`
t;>> user and resolved the same way, either by setting LANGUAGES_BIDI or adding
>>> it to SILENCED_SYSTEM_CHECKS.
>>>
>>> I think I'm against removing the check, but pro anything that can make
>>> it easier for users such as yourself - perhaps somethin
something as simple as a
> suggestion in the error message to set LANGUAGES_BIDI = [] if you're not
> using RTL languages?
>
> Thanks,
>
> Adam
>
> On Tue, 9 Apr 2019 at 11:22, Matthias Kestenholz wrote:
>
>> Hello everyone,
>>
>> The resolution of
Hello everyone,
The resolution of https://code.djangoproject.com/ticket/30241 in
https://github.com/django/django/commit/4400d8296d268f5a8523cd02ddc33b12219b2535
introduced a new and in my opinion backwards incompatible requirement
through the system checks framework.
Previously*, overriding LANG
On Wed, Apr 3, 2019 at 11:39 AM James Bennett wrote:
> On Wed, Apr 3, 2019 at 2:34 AM Carlton Gibson
> wrote:
>
>> Yes, super thanks. Breaking login in development would qualify as a good
>> *Why* yes. 🙂
>>
>> I'll assume we're NOT going to do this, but anyone with input, please do
>> comment.
>
On Wed, Apr 3, 2019 at 10:02 AM Carlton Gibson
wrote:
> Hi all.
>
> https://code.djangoproject.com/ticket/30314
>
> > Per the documentation, "Leaving this setting off isn’t a good idea
> because an attacker could capture an unencrypted session cookie with a
> packet sniffer and use the cookie to
Hi,
On Sat, Mar 18, 2017 at 12:49 AM, Tim Graham wrote:
> Hi, I don't know anything about CTE, but did you see this third-party
> package? https://github.com/petrounias/django-cte-trees -- It seems to be
> PostgreSQL only.
Just chiming in to point out a maintained and up-to-date friendly fork
of
On Thursday, September 29, 2016 at 4:11:04 PM UTC+2, is_null wrote:
>
> Thanks for the heads up, a similar ticket has been closed as wontfix,
> because it isn't compatible with CSP:
> https://code.djangoproject.com/ticket/13978
>
> While I'm all against inline scripts, I have a use case which s
On Mon, Jul 12, 2010 at 2:13 PM, Roald wrote:
> Hi all,
>
>
> There is a discussion 'Class based generic views in 1.3?' in this
> list. I would like to suggest an alternative: ModelViews. There
> normally are multiple standard views associated with one model, and
> such a class can take advantage
On Thu, Sep 11, 2008 at 10:40 AM, Matthias Kestenholz <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 11, 2008 at 10:17 AM, Michael Radziej <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> On Wed, Sep 10, Malcolm Tredinnick wrote:
>>> Commit ids are stable in,
On Thu, Sep 11, 2008 at 10:17 AM, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> On Wed, Sep 10, Malcolm Tredinnick wrote:
>> Commit ids are stable in, for example, git-svn,
>> so merges will be the same for everybody who merges from a
>> subversion-tracking branch to their development bra
On Mon, Sep 8, 2008 at 6:55 PM, Ben Firshman <[EMAIL PROTECTED]> wrote:
>
>
> On 8 Sep 2008, at 13:36, Erik Allik wrote:
>
>>
>> I'm glad this came up, because I would also like to recommend
>> considering an admin interface for models that use django-mptt. I know
>> django-mptt is an external pro
On Mon, 2008-06-09 at 21:16 -0400, Karen Tracey wrote:
> On Sat, Jun 7, 2008 at 3:06 PM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
> * Start a "train release" schedule: schedule a couple of 1.0
> betas, a
> rc or two, and then a final release. Features that are done by
Hi.
this is very exciting! I've one suggestion/question though.
On Tue, 2008-04-22 at 13:24 -0700, Nicolas E. Lara G. wrote:
> with the possibility of using non-keyword arguments for un-aliased
> aggregation, in which case the 'alias' would be automatically created
> from the query made:
> >>>
25 matches
Mail list logo
