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:
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:
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
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,
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,
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.
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
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
>
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.
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
I think some duplication will always be required, unfortunately. Bridging
the two paradigms is necessarily costly as it involve communicating between
threads. IMO duplication is worth it to avoid performance regressions for
sync code, and to make async code worth using.
I am doubtful there is a
Welcome!
There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/
If you’re looking to work
9 August 2023, Niccolò Mineo wrote:
>>
>>> Yes, not pretty, though, right?
>>>
>>> Il giorno martedì 8 agosto 2023 alle 07:33:12 UTC+2 Adam Johnson ha
>>> scritto:
>>>
>>>> You should be able to disable the button by creating an empty
>&
You should be able to disable the button by creating an empty
admin/color_theme_toggle.html template in your project.
On Mon, Aug 7, 2023 at 10:28 PM Niccolò Mineo
wrote:
> * I haven't found a convenient way, that is.
>
> Il giorno lunedì 7 agosto 2023 alle 23:26:11 UTC+2 Niccolò Mineo ha
>
This sounds reasonable, but unfortunately, it's backwards incompatible and
so we cannot make the change. Any URL with a “reason” URL parameter would
no longer be resolvable.
You can make a project-specific shortcut function that allows providing the
reason parameter. Since it’s two lines long,
cs/ref/models/class.txt
> - https://github.com/django/django/blob/main/docs/topics/db/models.txt -
> perhaps within a new subheading in the Model inheritance section?
>
> Once confirmed I'll amend the PR
>
> Thanks
>
>
> On Wed, 28 Jun 2023 at 10:28, 'Adam Johnson' via Dj
Hi!
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 unlikely to
ectations could be done by moving most of the
>> ModelBase.__new__ logic to Model.__init_subclass__ but this would require a
>> massive re-enginering of meta programming logic that is remain unchanged
>> for years.
>>
>> Le vendredi 12 mai 2023 à 09:38:04 UTC-4,
Hi Arthur,
You've found the wrong mailing list for this thread. This mailing list is
for discussing the development of Django itself, not for support using
Django. I guess that's why no one replied.
If you would like to suggest a documentation change please do open a PR
with reference to the
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 unlikely
I have replied on the ticket with an example using arbitrary HTML as
required.
On Wed, May 10, 2023 at 10:30 AM Carsten Fuchs
wrote:
> Hello,
>
> ticket #26761 was closed as wontfix, however I don't understand the reason.
> https://code.djangoproject.com/ticket/26761#comment:19
>
> The ticket's
+1 from me. As Simon covered on the ticket, the change is small. Making
Django classes support __init_subclass__ might unlock some nice dynamic
field patterns.
On Thu, May 11, 2023 at 12:47 PM hottwaj
wrote:
> Hi there, I opened the above ticket and submitted a PR with fix and test
> added. I
diving into this
>>> topic, thanks for sharing.
>>>
>>> However, I don't agree about the index. The best solution is using the
>>> CITEXT db type, which is very much alive.
>>> Should Django to deprecate support for the db type, a 3rd party package
u wish to ignore etc. They also
>> have a handy notice/disclaimer
>> <https://github.com/un33k/django-ipware/blob/master/README.md#Notice> on
>> the subject.
>>
>> IMO Django core should leave this 3rd party packages and individual
>> deployment
A setting isn't so mad. Many Django projects I've seen use a similar custom
setting for constructing URLs outside of requests.
One question though, how will we support projects that are served at
multiple domains? Would Django only support the "main" site through
BASE_URL and require you to
Just to note, for anyone that finds it useful, that I wrote a blog post on
migrating to collations:
https://adamj.eu/tech/2023/02/23/migrate-django-postgresql-ci-fields-case-insensitive-collation/
But yes, I have also been thinking like Tom that indexing UPPER("email")
seems to be the path of
It's surprisingly complex to interpret x-forwarded-for:
https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ . We
will never be able to safely add automated handling.
I *guess* we could add a note to the deployment guide like "check your
HTTP_X_FORWARDED_FOR setting". I'm
Indeed, David is right. The --update flag is intended for developing a
feature branch and adding extra changes to a work-in-progress migration.
This is why it requires the migration to not be applied.
On Sun, Apr 9, 2023 at 9:20 PM David Wobrock
wrote:
> Hi,
>
> As you can see, the error
Welcome Natalia
On Tue, Apr 11, 2023 at 2:52 PM Natalia Bidart
wrote:
> Week ending April 9, 2023
>
> Hello! I'm Natalia (AKA nessita), the new Django Fellow. I officially
> started on April 1st (really :-)) though I had a slow start since I had a
> long-time planned vacation.
>
> So far I
I don't think we should adopt Ruff. It's a new, somewhat experimental
project. It wouldn't provide any gains except speed, but that is not really
a concern since it still takes a handful of seconds to lint Django with
Flake8 and co.
On Mon, Apr 3, 2023 at 1:59 PM Jerome Obi wrote:
> Hi !
> I
I agree that we should remove Stalebot. Closing old issues doesn't fix them
or provide a reason why they aren’t going to be worked on.
On Thu, Apr 6, 2023 at 8:02 AM Sarah Boyce wrote:
> From what it sounds, I guess the main value was prompting a one time
> spring clean. As there are not that
Mariusz, I agree with the burden, but it should be noted that SQL has both
CHECK on the field and table level, and CheckConstraint only defines
table-level constraints. This is not true for unique constraints or indices.
Also, what do you think of a way for custom field classes to add
I agree this feature would be useful, at least to allow bundling check
constraints with custom field classes. As you point out the
PositiveIntegerField classes do this within Django, and doubtless many
custom fields have used the db_check() method.
The only thing I'm not a fan of in your proposal
I agree with Mariusz. Encouraging alternative import paths for standard
library functions can only lead to confusing code.
On Mon, Mar 20, 2023 at 11:47 AM Mariusz Felisiak <
felisiak.mari...@gmail.com> wrote:
>
> I find it confusing that we have to import now from django.utils.timezone,
> but
I'm also against the idea, unless done in a very minimal fashion.
Many tools in the ecosystem put "ignore everything here" .gitignore files
into their not-normally-committed directories: at least Coverage.py, Mypy,
pytest, and virtualenv. So the trend is that less and less .gitignore
patterns are
The Django project has a .gitignore file:
https://github.com/django/django/blob/main/.gitignore
On Thu, Mar 9, 2023 at 3:46 PM Daniel Azubuine
wrote:
> I think it will be a little bit helpful to add a very minimal .gitignore
> file to the django project.
> Maybe one that just ignores the
Welcome!
There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/
If you’re looking to work
Hi Matteo,
I agree with Mariusz on the ticket - this is a step beyond what Django
should support. You've shown in your proposal that such a function takes 3
lines of code for PostgreSQL. I don't think this is a burden on developers
to implement when needed.
Also, the TruncDate(Now()) pattern is
Putting HTML for the admin in model definitions is a bit too coupled.
I think you may be able to add icons already by overriding the admin
template - can you try playing around with that?
On Mon, Feb 6, 2023 at 12:07 AM Yeonggwang Yang
wrote:
> that sounds good with me
>
> 2023년 2월 5일 일요일 오전
Welcome Mohammed!
There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/
If you’re looking
Please don’t email random code snippets to this list.
On Mon, Feb 13, 2023 at 3:29 PM Thomas Ménès
wrote:
> def extra_permissions(permission_classes):
> """Decorate a CBV method to add specific permissions on the instance."""
> def decorator(func):
> def decorated_func(self, *args, **kwargs):
>
Hi Jansen,
I would like to see a more concrete and thought-out proposal, with the
motivation. For many problems you might encounter with the auth module,
there is a way to customize it. Beyond a certain point though, “reimplement
it yourself” is a reasonable solution. For example, if you need a
I'm also skeptical we need to support this use case. Certainly some users
prefer *shared* log messages, so all actions are shown regardless of which
interface was used.
Just to comment on the DB side: storing the same few names over and over in
such a column would be a waste of disk space. It
In a brief search, I could not find any docs for X-Forwarded-Prefix.
MDN documents X-Forwarded-For and others:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For
To customize those functions, you could use a middleware to modify requests
to wrap them:
class
+1 to what Carlton said. You can make this function in your project like so:
class Age(Func):
function = "AGE"
A Django wrapper would actually be more complicated. You’d need to
understand both the PostgreSQL and Django function docs, and you might not
be sure Django does anything special
Welcome!
There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/
If you’re looking to work
Hi Mark
I agree that subparsers should use the same error formatting.
After looking at the problem a bit more, I found a solution to pass
called_from_command_line through to subparsers by changing CommandParser. I
filed a ticket and a PR: https://code.djangoproject.com/ticket/34259#ticket
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 unlikely
There is a Django Threadless store where you can buy T-Shirts and other
merchandise, which all supports the DSF: https://django.threadless.com/
It’s linked from the fundraising page:
https://www.djangoproject.com/fundraising/
I have a Django phone case from there!
On Fri, Jan 13, 2023 at 11:44
Your proposal is quite niche: it only shortens the creation of a Manager
class when you need to add a single filter() call. The function seems like
it might be a useful helper within a project, if you use many such
managers. But custom managers might use any queryset methods, or other
logic. I've
This thread got too long too fast: it's a hell of a lot to catch up on. In
the future, please can we all let things sit for a bit so other voices can
chime in, especially when the issue has concretely affected very few users.
In the past I have also been frustrated at particular bug fixes not
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 unlikely
Yes, a single line message warning that the migration needs some edits
would be nice.
On Fri, Dec 23, 2022 at 11:18 AM Christian González <
christian.gonza...@nerdocs.at> wrote:
> HM wouldn't it be better to add a stdout message after completing the
> squash? Because if the cmd doesn't say
On the ticket associated with that PR (
https://code.djangoproject.com/ticket/33212 ), there was a lot of
discussion, ending with Mariusz saying:
As far as I'm aware both propositions (PR15015 and PR15019) are backward
> incompatible, so they are against out stability policy, unless it's not a
>
Federico - I think we’d like to see a few more “pro”s in the thread.
Personally, I am pro adding a default timeout. The lack of a default
timeout in *requests* is a constant source of outages, which lead me to
write this hack
Big +1 from me, I love the forum. It’s a lot more discoverable and powerful.
On Mon, 28 Nov 2022 at 15:22, 'Tobias McNulty' via Django developers
(Contributions to Django itself) wrote:
> As someone who only just joined the forum -- I'm +1:
>
>- The forum has seen great adoption from what I
I don’t think it’s worth adding support for “instance”. The name “instance”
is used in generic mode view classes because they work with any kind of
object. Since the password change view knows it has a user, it can use the
more specific variable name.
You can add an “instance” property in your
I’m happy with this approach, it’s a little step forwards towards
maintainable settings files.
On Sun, 27 Nov 2022 at 20:37, 'Tobias McNulty' via Django developers
(Contributions to Django itself) wrote:
> Hi Raphael,
>
> Thanks for taking this on.
>
> Starting with a limited scope seems like a
I am not sure the db level defaults PR is suitable for a GSoC project at
this point - it’s pretty well developed. I think it could do with some
review and testing form those who are interested.
On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django
developers (Contributions to Django
+1 from me
And +1 to using the forum in future
On Tue, 29 Nov 2022 at 00:23, charettes wrote:
> +1 from me as well.
>
> Le lundi 28 novembre 2022 à 08:32:01 UTC-5, carlton...@gmail.com a écrit :
>
>> Hi All.
>>
>> Tom Forbes is currently unable to post to the Google Group here, due to
>>
Your proposal seems reasonable - if actually saving, we should save the m2m
fields too.
I think the best next step would be to file a ticket and work on a PR. The
first step would be to add a test case reproducing the issue.
On Wed, Nov 23, 2022 at 4:59 PM Mark Gensler wrote:
> Hello all!
>
>
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 unlikely
Four ideas from myself:
1. CORS in core
django-cors-headers’ implementation is a bit janky, for example it uses a
regex to filter paths. It also lacks the key ability to set up different
CORS policies per path. Both of these could be done with a decorator.
I’d like to see a form of CORS support
Christian - did you end up making a docs PR here?
I’m afraid I don’t really know why fields aren’t localized by default. If
you have a proposal to change this in a backwards-compatible, low
disruption way, that could be easier to discuss.
On Mon, Sep 5, 2022 at 9:23 PM Christian González <
I do like this suggestion. I also find the current behaviour surprising.
Do you have a plan for implementation? I guess this would have to go
through the regular deprecation pathway?
On Tue, Oct 4, 2022 at 4:32 PM אורי wrote:
> Hi Shai,
>
> Actually, I think this issue is very similar to
ld have a slight preference for raising an
> UnsupportedMediaType as well and letting that percolate to a 415 as it
> seems more correct from a content negotiation perspective.
>
> Le vendredi 11 novembre 2022 à 11:22:44 UTC-5, Adam Johnson a écrit :
>
>> This first-step solution is good with
ould be a review of serialization
>> and forms, in light of developments such as Pydantic, attrs/cattrs, and
>> django-readers, but that is **not** on topic here.) This was first
>> suggested in 2011, but has made little progress in that time. [0][1]
>>
>> [0
django-developers is not a support channel. Email support requests to
*only* django-users.
On Sat, Nov 5, 2022 at 7:34 AM Nishant Sagar wrote:
> Hi all,
>
> I deployed the django project to AWS ec2 instance using nginx and gunicorn
> but the static file is not loading at all.
>
> Can someone
>
> But it is not possible unless we directly override the
> password_validation classes and this is an extra and dirty work.
I don't think this work is dirty!
We generally prefer to avoid extra settings (and sub-settings) where
possible. The settings file should be clear, and not do what code
This can currently be achieved with:
qs.annotate(lowername=Lower("name")).filter(lowername__in=['text'])
You’re free to add “iin” to your projects, but I'm not sure it's valuable
enough to add to Django.
Some years ago, there was an idea to allow python expressions to generate
ORM filters, that
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 unlikely
I'm inclined to agree with David here. This is a “understanding Python”
thing. We can’t feasibly add documentation warnings everywhere such a
mistake could be made.
On Sat, Oct 29, 2022 at 8:00 PM David Sanders
wrote:
> Hi Daniel,
>
> I don't think a warning is necessary here as it's fairly
. This
is because the database libraries Django supports don't have async
interfaces.
On Fri, Oct 21, 2022 at 4:49 PM Adam Johnson wrote:
> If you have a suggestion, sure. But from my perspective the docs are
> clear. There's an adelete() method doc'd for QuerySet, and not for Model,
> and the rel
erface...”.
On Fri, Oct 21, 2022 at 3:51 PM Jason Johns wrote:
> gotcha, then perhaps a documentation tweak would be in order, on both
> queryset and model pages? because as is, its unclear this is expected.
>
> On Friday, October 21, 2022 at 9:57:33 AM UTC-4
This is intentional, as it stands. Django 4.1 only added async QuerySet
methods, not async Model methods. Async model methods like adelete(), and
perhaps asave(), would be the next logical step.
On Fri, Oct 21, 2022 at 1:47 PM Jason Johns wrote:
> I came across a reddit post yesterday
>
+1 from me. Using in-memory storage is great for tests.
On Thu, Oct 20, 2022 at 6:30 PM Paolo Melchiorre (paulox) <
pa...@melchiorre.org> wrote:
> Hi all,
>
> there is a package that provide in-memory data storage backend, but it's
> now abandoned.
>
> Having support for in-memory data storage
Steffan
Your question suffers from the ”X/Y problem”. You’re asking whether to
change Django to make Y easy, without explaining the X you’re trying to
achieve. *Why* do you want to know if you're in the runserver main process?
Also, it may work to check the running command from sys.argv (
ion of the session value is the encoded value, base64
> encoded, and potentially compressed.
> The second section is the encoded timestamp, used to determine if it was
> created too long ago on decode
> The third section is the HMAC signature, base64 enc
(https://github.com/pricemoov/django/pull/2/files)
> Would you like me to open a PR in Django or should I wait for the fix of
> the test being developed first?
>
>
> Le lun. 10 oct. 2022 à 09:39, 'Adam Johnson' via Django developers
> (Contributions to Django itself) a
> écr
Yes please create a ticket. If you’re feeling brave, try to adapt your test
into Django’s test suite (here:
https://github.com/django/django/blob/84206607d6bfd61e7f7a88b51163ffd4153e3b5a/tests/postgres_tests/test_array.py#L212
)!
On Sun, Oct 9, 2022 at 11:49 AM Ion Alberdi
wrote:
> Hello to
Looking through blame, it looks like this hardcoded salt was added in 2010:
https://github.com/django/django/commit/45c7f427ce830dd1b2f636fb9c244fda9201cadb#diff-3a6c11bbe36a0e6927f71ad8d669f0021897ba73768ee41073a318a12e11c3d1L85-L90
This actually changed from using the secret key as the salt, to
I'd also be -1. There are two good alternatives already, which are both
more flexible. No need to add a third way.
On Sun, Oct 2, 2022 at 8:35 AM Carlton Gibson
wrote:
> Hi.
>
> Re-reading again, I'm still not sure (personally) of the need/motivation
> given either of the "use two entries" or
Big +1. IMO tags should work like HTML tags, which can be spread across
multiple lines, as often done with multiple attributes. Also, Jinja does it.
If you're going to write a DEP, I'd say don't make it too long. The feature
is clear enough.
The old PR
Hi!
I think you've found the wrong mailing list for this post
(django-developers). 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
To have extra properties, we'd need to add extra database fields. It would
be somewhat wasteful to add them to all ImageFields when few users will
care about the difference.
On Mon, Sep 26, 2022 at 10:28 AM David Sanders
wrote:
> Actually might as well throw out one idea, feel free to discard:
I’m +1 to making this change. Incorrect orientation is frustrating and this
is why browsers changed to always consider it (by default).
You're right that the web default is to consider EXIF orientation data,
controllable with the image-orientation CSS property:
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 unlikely
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 unlikely
Some data...
The idna package has ~9M downloads a day (
https://pypistats.org/packages/idna ) compared with Django's ~350k (
https://pypistats.org/packages/django ).
However it has 191 GitHub stars ( https://github.com/kjd/idna ) compared to
Django's 66k ( https://github.com/django/django ).
I
I'm not sure I quite understand your proposal. Are you suggesting a
decorator that caches the results of every queryset that is resolved within
the decorated function?
If so, I'm not sure how useful it would be. First, if a single query is
problematic, there’s normally a way to optimize it within
I can see the appeal of allowing you to have fewer classes, but I don't
think that's a good thing in itself. Keeping responsibilities separate
("convert slugs to/from URL's" versus "be a slug") is a generally desirable
property.
This change would also complicate the URL parsing process: it would
Hi Steven
I agree that grouped choices would be nice to support in the enum types.
Thank you for taking a look at this.
I'm not sure about either of your proposed syntaxes. They both seem error
prone and unclear to me. I propose instead using a separate grouping
attribute:
class
Improving the docs sounds good.
I think it would also be worth renaming engines to backends, and
EngineHandler to BackendHandler, or similar. Yes it would require a
deprecation cycle, but I also imagine 99% of projects would be unaffected.
On Tue, Aug 23, 2022 at 8:39 PM Peter Thomassen wrote:
g 2022 at 14:11, 'Adam Johnson' via Django developers
> (Contributions to Django itself)
> wrote:
>
>> Hi
>>
>> I just wrote a blog post on a late-binding bug that can occur with using
>> transaction.on_commit() with a function or lambda within a loop. THe post
Hi
I just wrote a blog post on a late-binding bug that can occur with using
transaction.on_commit() with a function or lambda within a loop. THe post
shows how using functools.partial() solves this. See the post here:
Django logs warnings for missing variables. I believe this logging was
added since that ticket was closed.
I recently wrote a blog post with some techniques you can use to hook into
this logging and turn those errors into exceptions:
topics/http/sessions/#using-database-backed-sessions>
> sessions) (4mlo) or Django admin logs (66mlo).
>
>
>
>
>
> Mit freundlichen Grüßen,
>
> DI Mag. Maxim Danilov
>
>
>
> +43(681)207 447 76
>
> ma...@wpsoft.at
>
>
>
> *From:* '
>
> If the object to be deleted contains many relations, the user
> is overwhelmed with a list of other objects to be deleted together with the
> current object. Often those objects are just internal relations the user
> never heard of, and this may be unsettling.
>
I would argue that if the list
Hi Kazooie
LiveServerTestCase is a bit more lightweight than tools for using specific
drivers. It doesn't tie into Selenium, or Playwright, or any other
particular web browser library. Therefore I don't think there's going to be
any way for LiveServerTestCase to know what the current page is, in
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 unlikely
1 - 100 of 1085 matches
Mail list logo
