Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

I still don't understand the problem this is solving; is typing "pk=" (or "id=") that much of a burden? Or that frequently left out by accident? As it stands, I agree with Adam that this adds implementation complexity (including potential future implementation complexity, as Ivan noted) and prolif

Re: Make `raw_id_fields` the default functionality in the admin

On 6 Nov 2018, at 02:47, 'Ivan Anishchuk' via Django developers (Contributions to Django itself) wrote: > How about some field that intelligently guesses the table size and looks > either like default select or like raw id field depending on that? Yes, that would be interesting. I implemente

Re: django.utils.timezone.make_aware confusion

Hello Dan, If that assertion fails, I assume the default time zone (the TIME_ZONE setting) isn't Europe/Berlin. See https://docs.djangoproject.com/en/2.1/ref/utils/#django.utils.timezone.make_aware If you cha

django.utils.timezone.make_aware confusion

Working on ticket #29984, I noticed that the following raises: from datetime import datetime import pytz from django.utils.timezone import make_aware euberlin = pytz.timezone('Europe/Berlin')s a dt1 = datetime(2018, 10, 24, tzinfo=euberlin) dt2 = make_aware(datetime(2018, 10, 24)) assert dt1 == d

Re: Make `raw_id_fields` the default functionality in the admin

Well, I did personally encounter this issue more than a couple times on several projects. In most cases simply switching to raw id or read only where required works fine however it does add additional maintenance overhead for projects that started small and at some point database grows and some adm

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

I feel this would be a good addition to just .get(), I’ve wanted this while working with the shell. Model.objects.get(pk) feels very natural to me, and the common Model.objects.get(pk=pk) always felt overly verbose. On 5 November 2018 at 22:37:52, Josh Smeaton (josh.smea...@gmail.com) wrote: I

Re: Standalone is_safe_url() function

Yeah, it can be pretty useful at times, for example, in api clients. I used it quite a few times and had no idea it's not a part of the public api. Ivan. On Sun, Oct 28, 2018 at 12:29 PM Adam Johnson wrote: > I needed that functionality on another project that doesn't use Django at >> all. >> >

Re: Remove pyinotify autoreloader support

I ran a slightly modified version of your test code since we have many modules at "top level". "k3" is one of the top level modules that houses a bunch of apps. In total there are about 1340 python files (including recently squashed migrations and tests). Here's the results: Project: 1575 Total

Re: Explore integrating django-docker-box in some way?

I'm sorry I haven't had the time to review or contribute yet, but I think it'll be a very useful project - especially for new contributors that might have a little docker experience. The current vagrant solution is heavy, does not work properly on windows and some linuxes, and isn't that easy to

Re: backend specific tests

I don't think there's a full list of extensions the test suite uses, but https://docs.djangoproject.com/en/2.1/ref/contrib/postgres/operations/ would be close to a full set I'd imagine. On Sunday, 4 November 2018 14:43:23 UTC+11, Dan Davis wrote: > > So, the contributor guidelines page about uni

Re: Idea: Allow queryset.get() and queryset.filter() to accept a positional argument for implicit primary key filtering

I'm in the same boat as Simon - I've wanted this many times in the last few months, but only when working at the shell. I'd be +1 for get and -1 for filter also. On Thursday, 1 November 2018 05:12:53 UTC+11, charettes wrote: > > As I've mentioned on the ticket I've been wishing get(pk) could tra

Re: Proposal: relationships based on arbitrary predicates

Hello Alex, While investigating an issue with reverse known related objects assignment[0] I stumbled upon a little something that might interest you. It looks like there's currently some tested cases of abusing the ForeignObject interface to achieve something similar to what you are suggesting

Re: Proposal to remove ModelAdmin's collection of actions from superclasses

I agree with you Tim. +1 from me. Le lundi 5 novembre 2018 12:03:55 UTC-5, Tim Graham a écrit : > > Hi, > > A recent bug report [1] brought up the fact that ModelAdmin collects > actions from superclasses. For example: > > class BaseAdmin: > actions = ['a'] > > class SubAdmin(BaseAdmin): >

Re: Proposal to remove ModelAdmin's collection of actions from superclasses

The idea was that you could define a base admin and have the actions appear without having to redeclare them. The only question is are people actually using that? (I can't think of a third-party app that provides an admin with actions that you're meant to subclass for instance — anyone?) If

Re: Proposal to remove ModelAdmin's collection of actions from superclasses

I agree, it shouldn’t be doing something so surprising and undocumented. On Mon, 5 Nov 2018 at 17:03, Tim Graham wrote: > Hi, > > A recent bug report [1] brought up the fact that ModelAdmin collects > actions from superclasses. For example: > > class BaseAdmin: > actions = ['a'] > > class Su

Proposal to remove ModelAdmin's collection of actions from superclasses

Hi, A recent bug report [1] brought up the fact that ModelAdmin collects actions from superclasses. For example: class BaseAdmin: actions = ['a'] class SubAdmin(BaseAdmin): actions = ['b'] SubAdmin will have action 'a' and 'b'. The behavior isn't tested and only mentioned in passing i

Fellow Reports -- November 2018

Hi all, Calendar Week 44 -- ending 04 November. Released: Django v2.1.3 Triaged: https://code.djangoproject.com/ticket/29917 -- admin.E130 (__name__ uniqueness) regression (needsinfo) https://code.djangoproject.com/ticket/29905 -- Can you fix ticket 26171 in 1.8.x (wontfix) Re