Re: Built-in router link generator in Django

2016-10-03 Thread Marc Tamlyn
This doesn't seem like something which is the responsibility of core django to me. There are dozens of different ways to build your menus, I don't see anything about that package which makes it the best way of doing it. On 3 October 2016 at 03:24, Val Neekman wrote: > Folks, > > I am wondering i

Re: New deferred loading implementation (Was: [Review Request] Added support for database delegated fields (like AutoField))

2016-11-08 Thread Marc Tamlyn
I have fed a lot into this discussion in person and on Slack. I don't understand all the ins and outs completely, but I feel that the situation is sufficiently complex enough that we need to consider it all together. The code was certainly very challenging when I tried to make a UUID field use a DB

Re: Getting full URL using django.urls.base.reverse - PR

2016-11-11 Thread Marc Tamlyn
Given we already have `request.build_absolute_uri(path)`, I'm not 100% sure what extra this gives us. It's a bit of syntactic sugar for sure, but it solves a pretty narrow use case. The only times I've actually needed this has been when sending emails and I'm using a `Site` object instead of reques

Re: drop compatibility with Python < 2.7.8?

2016-11-15 Thread Marc Tamlyn
I'd be inclined to agree with Claude. On 15 November 2016 at 07:20, Claude Paroz wrote: > I wouldn't spend too much energy about Python 2.7 stuff. Let the > workarounds in place, and just wait for Python 2 to die. I don't see the > point in forcing people of stable Debian-based distributions to

Re: automating Django releases

2016-11-26 Thread Marc Tamlyn
I'm pretty confident we can just automate the process you currently do. On 26 November 2016 at 05:40, Josh Smeaton wrote: > I think automating as much of the release process is a fantastic idea. > Regarding bumping the release numbers, have you seen the bumpversion > project https://pypi.python.

Re: Guidelines to name python modules of Django applications?

2016-12-07 Thread Marc Tamlyn
What Aymeric and Florian sayid. On 7 December 2016 at 15:58, Florian Apolloner wrote: > On Wednesday, December 7, 2016 at 1:10:48 PM UTC+1, Aymeric Augustin wrote: >> >> I still think I wouldn't use a django_ prefix when I create new apps >> because >> it adds a small but pervasive overhead to p

Re: Responsive admin

2017-01-09 Thread Marc Tamlyn
I'd suggest including this with a mechanism (on the admin site?) to disable it for a while if that causes problems for existing custom setups? Marc On 9 January 2017 at 11:59, Adam Johnson wrote: > - perhaps supplying an empty CSS file with the same name overrides the >> file provided by the ad

Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

2017-01-12 Thread Marc Tamlyn
DEFAULT_CONTENT_TYPE does sound like a setting which shouldn't exist. On 12 January 2017 at 10:53, Adam Johnson wrote: > Having reviewed the ticket a bit and thought about it, I've had two > thoughts: > >1. The current patch doesn't fix existing custom views > >

Re: SubQuery without using RawSQL

2017-01-12 Thread Marc Tamlyn
Subquery is one word so the lowercase Q would be correct yes. I'm skewed from using SubQuery in my code for the last few months, so that looks fine to me, but let's not get into another query_set problem On 12 January 2017 at 13:11, Adam Johnson wrote: > I vote for Subquery - I wouldn't make a c

Re: Should Model.save() fix incorrect types that happen to save correctly?

2017-02-14 Thread Marc Tamlyn
Agreed - ensuring that this works in the general case is not reliable. On 13 February 2017 at 15:51, Adam Johnson wrote: > What do you think? Absent a better suggestion, we could document this >> pitfall so that there's something to point to when related tickets come in. > > > +1, as Aymeric poi

Re: Template handling of undefined variables

2017-02-20 Thread Marc Tamlyn
+1 to not having to add (and then remove later) a {% load %} tag to every template - that was seriously dull with the URL change. Marc On 20 February 2017 at 11:42, Luke Plant wrote: > On 19/02/17 12:55, Adam Johnson wrote: > > +1 for more obvious errors, silently changing the behaviour could i

Re: Permission classes for Class Based Views

2017-03-16 Thread Marc Tamlyn
I don't feel there is any need for this feature in Django. As you mention in the ticket, there are ways of approaching it used in DRF, there are other ways in django-braces[0], I personally have my own taste in how to handle it. The details will depend on the logic necessary - sometimes you need to

Re: Provide 'V' as alias for 'Value'?

2017-04-05 Thread Marc Tamlyn
Given that you can always do import Value as V, I'm not sure providing an alias is necessary. On 3 April 2017 at 12:15, Josh Smeaton wrote: > I think I proposed V as an alias back when I was writing the patch, but > the rough consensus at the time was that one letter class names are a bit > of a

Re: Vietnamese Django full text search in postgres.

2017-04-05 Thread Marc Tamlyn
Hi Cử Nhữ Văn, This mailing list is for development of Django itself, rather than support queries. You may get a better answer on the main mailing list or on #django on IRC. You may also find some help about different languages in the docs: https://docs.djangoproject.com/en/1.10/ref/contrib/postg

Re: Adding generated common table expressions

2017-04-06 Thread Marc Tamlyn
Hi! This looks generally very good, and I'm quite excited about it. In terms of taking it forwards, I think a DEP is a very good idea, and there are at least 3 core devs who are keen to see a solution. Whether you have the right solution yet I'm not so sure, but it sounds like you're not either.

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

2017-04-07 Thread Marc Tamlyn
I would be happy to revisit that decision which was made 9 years ago. APIs returning unusual status codes such as 204 are much more common now than they were then. I can't think of a good reason not to add ~10-15 2-line classes. Marc On 7 April 2017 at 09:37, Brice PARENT wrote: > > Le 07/04/17

Re: Proposal: provide postgresql powered full-text search in djangoproject.com

2017-05-08 Thread Marc Tamlyn
I'm not sure I see the benefit here. The strength and purpose of postgres FTS is that you can combine some FTS behaviour with some relational queries easily at the same time. I'm pretty sure our search requirements on dp.com need that, so using a dedicated search provider is a better option. On 7

Re: Proposal: provide postgresql powered full-text search in djangoproject.com

2017-05-08 Thread Marc Tamlyn
Yes, don't need that sorry. On 8 May 2017 at 14:40, Adam Johnson wrote: > I'm pretty sure our search requirements on dp.com need that, > > > s/need/don't need/ ? 😉 > > On 8 May 2017 at 13:59, Marc Tamlyn wrote: > >> I'm not sure I see the ben

<    1   2   3   4