Re: Moving to ... Github vs Bitbucket

On 16 February 2012 15:42, Łukasz Rekucki wrote: > 1) I can't argue about popularity, because I have no data, but most > Django applications I use come from github, so it's also quite > popular. > > 2) I don't think Django should care if the collaboration tool runs >

Re: FormMixin success_url should accept callable

to delay the evaluation until after the urlconf has been initialised. I don't think there's a real benefit to having a third approach. Regards, Andrew Ingram On 8 Apr 2012, at 22:12, Martin Tiršel wrote: > Hello, > > I just started to use class based views and I came to the C

Re: Allowing formsets to contribute kwargs to forms they create

this facility to BaseFormSet, I think the formset factories will need to hook into it as well. Regards, Andrew Ingram On 24 April 2012 14:55, Tom Evans <tevans...@googlemail.com> wrote: > Hi all > > I raised a ticket about this new feature, with patch: > > https://code.djangoproject.com

Re: Suggestion: make auth login view more dynamic

It seems to me there'd be more mileage in making new class-based versions of the auth views. - Andy On 24 May 2012 13:51, Florian Apolloner wrote: > Hi, > > -1 from me here. > > A) why don't you have site_name_name etc (those are still fixed). > B) templates need to be

Re: RFC: More class based views, take two

Hi Iván, I'd temporarily given up on getting extra_views into Django because of a blocking issue with pagination and formsets. Assuming a goal is to be able to build a new admin using class-based views, there is a prerequisite of being able to paginate, sort and filter on the querysets used for

Re: Draft branch: Swappable User models in contrib.auth

risk, of course, is that it means any third-party app could override any other model without you necessarily being aware of it, not sure how this would be mitigated. If I've not made much sense let me know, I've always found it hard to articulate on this particular topic. Regards, Andrew Ingr

Re: Proposed Field API additions

On 7 June 2012 18:17, Andrew Godwin wrote: > This means either having to register custom fields (like admin classes, > for example), or requiring fields to live in a fields.py or fields > package (like models and models.py). This is to provide for a > less-fragile way of

Re: Proposal: Signal connection via "my_app.MyModel"

I can see a use case for this, but would this not work? from django.db.models import get_model post_save.connect( my_signal_handler, sender=get_model('my_app', 'MyModel'), ) As long as the app cache has been initialised before you call get_model, this should work fine. - Andy On 22

Re: Model inheritance extended.

On 25 September 2012 17:45, Alex Ogier wrote: > There's a big thing you cannot do without grouping models: you can't have > an abstract base class relate to another abstract base class. Django's > foreign key mechanism doesn't know how to relate to a to-be-instantiated >

Add a "split" field to a model causes problems

s such a problem so it might be a one-off. Regards, Andrew Ingram -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/0A23Ye0xgcQJ. To p

Re: URL dispatcher fallthrough?

The approach we take at work is to have a view that wraps around the product, category and occasion views and takes care of the fallthrough logic. I'm not a fan of this approach, because it means that you can't just look at the urlconf and see which pattern maps to which view function. On the

Re: javascript view for named urls

On 29 Mar 2013, at 17:22, Bernhard Ja wrote: > Hello together, > this is my first post to the Django developers list. Please let me know if > this topic is better placed on Django users :-) > > For i18n there is a javascript_catalog view we can use to access translations >

Re: Enhance class Storage with additional methods

On 10 April 2013 14:56, Javier Guerra Giraldez wrote: > check django-storages > http://django-storages.readthedocs.org/en/latest/ it includes several > storage backends, S3 among them. > > -- > Javier I think he was asking whether the storage API should be extended to

Re: Proposal: Redefine specific {% block %} in an intermediate template

I've been wanting this exact feature for years. I've always struggled to explain the problem, but I've had numerous cases where this would have made for a vastly simpler template structure. Big +1 from me. On 17 April 2013 16:50, Emil Stenström wrote: > Hi, > > Proposal: > Make

Re: Proposal for simplifying part of the GCBV API slightly.

The original use case for pk_url_kwarg and slug_url_kwargs was something like this: /(?P[\w-]*)/ - DetailView /(?P[\w-]*)/another-resource/ - Scoped ListView /(?P[\w-]*)/another-resource/(?P[\w-]*) - Scoped DetailView In this case, the Scoped ListView and Scoped DetailView would both inherit a

Re: Django 1.6 release timeline

On 30 Apr 2013, at 23:38, Shai Berger wrote: > I see one issue with this: According to current procedures, if this timeline > is followed, support for 1.4 will be dropped less than 6 months after the > release of 1.5. At least for some of us (which, as I mentioned earlier on

Re: Django 1.6 release timeline

On 1 May 2013, at 00:13, Donald Stufft <don...@stufft.io> wrote: > > On Apr 30, 2013, at 7:10 PM, Andrew Ingram <a...@andrewingram.net> wrote: > >> On 30 Apr 2013, at 23:38, Shai Berger <s...@platonix.com> wrote: >>> I see one issue

Re: Django 1.6 release timeline

On 1 May 2013, at 00:35, Carl Meyer <c...@oddbird.net> wrote: > On 04/30/2013 05:27 PM, Andrew Ingram wrote: >> Absolutely, there's no requirement to migrate, but it does have the >> feel of an weird kind of deprecation. Obviously there are >> workarounds, like you

Re: reconsider re-opening ticket 901

On 12 May 2013, at 00:55, Russell Keith-Magee wrote: > I'm sure I understand this argument. Python objects are passed around by > reference, not by value, so if you've passed in a Django object deep into > another library, that library will be pointing at the same

Re: Custom prefetches (#17001)

I'd love to see this solved. I'm not sold on the API, but then again I've yet to see a single suggested API for this problem that I actually like. I showed you this a little while ago, you had some reservations with my idea, but I figured I might as well add it to the conversation anyway:

Re: Custom prefetches (#17001)

wrote: > On Friday, August 23, 2013 6:25:42 PM UTC+3, Andrew Ingram wrote: >> >> I'd love to see this solved. I'm not sold on the API, but then again I've >> yet to see a single suggested API for this problem that I actually like. >> >> I showed you this a little while

Re: FormSetView and ModelFormSetView

Having basically built all of the views in question, I agree with Russell. By having multiple form classes in a view itself, you're essentially pulling validation logic out of the form and into the view where it doesn't belong. A view shouldn't be concerned with the specifics of validation, it

Re: Django support added to BuiltWith!

move towards best practices it'll become increasingly difficult to tell them apart. This is definitely a good thing, I am generally rather pleased if I can deploy something without someone knowing what server side tools are in use. - Andrew Ingram -- You received this message because you are sub

Re: MultipleObjectMixin and Pagination

Hi Julien, I'm already involved on that ticket, the pagination issue is part of what's holding me back from contributing a patch. So I was looking to get some discussion about whether it's something that needs to be solved in core. In light of what you've said, I'm trying to think of a more

Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

On 9 Jul 2011, at 10:44, Sam Lai wrote: > I concur. The consensus seems to be shifting towards a 'strip' flag > though (defaulting to false), and I'm +1 on that. That would make it > explicit, minimise repetitive boilerplate code and also make it less > likely to accidentally forget to strip a

Re: Splitting out admin functionality

On 10 October 2011 13:13, Russell Keith-Magee wrote: > > The approach taken by django-messages should be the model here. When a > new messages framework was proposed for Django in 1.2, an effort was > made to find out all the features that were desirable, and then pull >

Re: Proposal: Add a "lookup" attribute to SelectObjectMixin

SingleObjectMixin is designed to only ever give you one object back (though I'm surprised it doesn't handle the MultipleObjectsReturned exception), so out of all the lookup choices we have, only an exact match on a unique field makes sense. Am I missing something here? Regards, Andrew Ingr

Re: Delivering PR 3114 - The _meta refactor

as far as the model is concerned, but isn't one in reality. Regards, Andrew Ingram On 22 December 2014 at 14:50, Collin Anderson <cmawebs...@gmail.com> wrote: > Ditto. I'm ok with a tiny shim for GFK, and we should get the API right > for RelatedObject going forward, (as long as i

Re: automated import sorting and better pull request checks

For what it's worth, I prefer one import per line, if only because it makes diffs that involve changes to imports a lot easier to digest, and usually smaller. ie, something like this: https://gist.github.com/AndrewIngram/16da35699bd495f79adb Andy On 30 January 2015 at 09:36, aRkadeFR

Re: Feature: Support a javascript template language on the server

Based on my own experiences building isomorphic JavaScript apps with Django, I haven't had any issues where I felt Django was getting in my way. I've tackled the problem in two different ways, both of which worked without any great difficulty: 1. The primary web-app is actually a node process.

Re: Feature: Support a javascript template language on the server

dev for the last 10 years. But Django has an excellent data layer, and I want to keep using it if I can. Andy On 2 June 2015 at 18:17, Emil Stenström <e...@kth.se> wrote: > On Tuesday, 2 June 2015 12:58:22 UTC+2, Andrew Ingram wrote: >> >> Based on my own experience

Re: Vendoring Select2

In previous projects (before moving to rolling my own UI components), I ended up favouring Selectize (http://selectize.github.io/selectize.js/) after getting fed up with Chosen and Select2 - but this was a few years ago and I can't remember my reasons. But if it hasn't been considered, it might be

Re: Deprecate is_superuser, is_staff and is_active

I've always felt that `is_staff` should be changed to a permission such as `can_access_admin` provided by the Admin app itself. However, `is_superuser` is slightly different, in that it's not a permission, but rather a flag that says "this user has EVERY permission". It's also potentially