Re: Channels integration plan, first draft

Hi Andrew, On 12/17/2015 04:34 AM, Andrew Godwin wrote: > Hi everyone, > > One of the first steps I want to get done for Channels is get a rough > plan in place for how things are going to work in terms of where code > goes, supported versions, etc. I've written up my thoughts on this into > a

Re: Possible bug transaction rollback or SQLite backend

Hi Jonas, On 12/03/2015 07:02 AM, Jonas H wrote: > Hi there, > > there seems to be something wrong with either the SQLite backend, the > SQLite library itself or Django's transaction handling. Whenever I try > to run the test suite of a specific project of mine >

Re: Case-insensitive email as username

On 11/24/2015 04:33 AM, Aymeric Augustin wrote: > 2015-11-23 23:52 GMT+01:00 Carl Meyer <c...@oddbird.net > <mailto:c...@oddbird.net>>: > > I've implemented the CITEXT-based solution a couple times; I think for a > PostgreSQL-based project it's the preferable o

Re: Case-insensitive email as username

On 11/23/2015 03:52 PM, Carl Meyer wrote: ... > I suppose the best we could do to ease this would be to add a > CreateExtension migration operation in contrib.postgres that, if lacking > super-user permissions, simply errors out and tells you what SQL you > need to run manually as

Re: Case-insensitive email as username

Hi Aymeric, On 11/22/2015 11:56 AM, Aymeric Augustin wrote: > I spent a good part of today implementing what must be the most common > scenario for custom user models: case-insensitive email as username. > (Yes. This horse has been beaten to death. Multiple times.) > > Since it was the first

Re: Odd behavior change in 1.8 with {% if %}, RelatedObjectDoesNotExist, and TEMPLATE_STRING_IF_INVALID

On 11/12/2015 09:22 AM, Tim Graham wrote: > The expected behavior of the {% if %} tag isn't clear to me. How do you > propose to solve the "bug"? As I noted in the ticket: > > We end up checking {% if %} which passes for a > non-empty string_if_invalid. I'm not sure we should add special

Re: Feature proposal: Target API version

Hi Patryk, On 11/12/2015 05:48 AM, Patryk Zawadzki wrote: > I have spent quite a while thinking about this and am still not sure > what the best approach would be or even if there are enough benefits > to justify the change. I think the idea is interesting (and I know it's been at least briefly

Re: Password validation in Django revisited

On 09/07/2015 06:31 PM, Tim Graham wrote: > The extra complexity of varying validation logic based on DEBUG doesn't > seem quite right to me, but I guess I won't oppose it if that's the > consensus. I'm strongly -1 on anything that automatically turns off password validation everywhere based on

Re: Proposal for making Storage API timezone aware

Hi James, This proposal makes good sense to me. I think the problem is worth fixing (I saw this problem on a previous project and never did get to the bottom of what was causing it!), and you've carefully identified a backwards-compatible route to fixing it, where no existing code breaks

Re: Erroneous HTTPS CSRF Referrer Failure

On 08/31/2015 12:09 PM, Joshua Kehn wrote: > On 31 Aug 2015, at 14:02, Tim Graham wrote: > > Is this related or duplicate to > https://code.djangoproject.com/ticket/24496? > That ticket has a patch that got stalled a bit, but might be worth > reviving > first in case this new

Re: Erroneous HTTPS CSRF Referrer Failure

On 08/31/2015 11:37 AM, Joshua Kehn wrote: > 2) If it's set, a match with the Host header (or maybe with any host in > |ALLOWED_HOSTS|) should still be allowed, so you aren't forced to > duplicate |ALLOWED_HOSTS| inside |CSRF_TRUSTED_REFERERS|. > > So the check here would look

Re: Erroneous HTTPS CSRF Referrer Failure

A couple follow-up thoughts: On 08/31/2015 11:22 AM, Joshua Kehn wrote: > On 31 Aug 2015, at 13:21, Carl Meyer wrote: > I think it would make sense to just add a |CSRF_ALLOWED_REFERERS| > setting, defaulting to |None| (which would give the current behavior of > requi

Re: Erroneous HTTPS CSRF Referrer Failure

Hi Josh, I think it would make sense to just add a `CSRF_ALLOWED_REFERERS` setting, defaulting to `None` (which would give the current behavior of requiring a match with the `Host` header). If set, it would be a list of valid referer hosts. Documentation needs to be extremely clear that you

Re: Erroneous HTTPS CSRF Referrer Failure

Hi Josh, On 08/31/2015 09:38 AM, Joshua Kehn wrote: > I understand why the Referrer check for secure requests is in place. > What is currently preventing cross-domain API requests is that the check > is not configurable. I'm talking specifically about requests when > |request.is_secure()| returns

Re: CHECK Constraints and migrations

Hi Gavin, On 08/27/2015 07:27 PM, Gavin Wahl wrote: > I'm interested in writing a third-party app that allows users to > declaratively write check constraints and have them automatically be > added and removed by migrations. I'm envisioning being able to attach a > list of Q objects to your

Re: How to disable system check framework?

On 08/25/2015 09:15 AM, Marcin Nowak wrote: > PS. I would like to avoid any monkey patches, hacks, and just omit > obstacles. :) I agree. In this case, you should use a custom User model instead of monkey-patching User, but you asked us not to discuss that question :-) Carl -- You received

Re: How to disable system check framework?

Hi Ma On 08/25/2015 07:46 AM, Marcin Nowak wrote: > Thanks for replies, Carl, Adam, Shai. > > But I think you're worrying too much for too many things. You're > trying to control everything, trying to replace automated tests with > system check framework, trying to block "invalid" operations,

Re: How to disable system check framework?

On 08/25/2015 08:57 AM, Marcin Nowak wrote: > Well, I'm not sure now, because Tim wrote that it was a design decision > and it is well documented. I still think we should change that design. It is simply wrong to have a setting called `SILENCED_SYSTEM_CHECKS` that fails to actually _silence_ the

Re: Pre-DEP: community support of unmaintained versions of Django

Hi Christian, On 08/24/2015 03:52 PM, Christian Hammond wrote: > pip's removed support for dependency_links, requiring that all package > dependencies be made available on PyPI. This means there's no way we can > host a build of this ourselves, have a project depend on it, and build > the project

Re: Pre-DEP: community support of unmaintained versions of Django

Hi Christian, On 08/18/2015 08:01 PM, Christian Hammond wrote: [snip] > Also as a status update, we've started a fork and applied for the > pre-notification list. I've backported all current security fixes to a > branch, ensured the test suite passes with flying colors, and have added > a README

Re: Pre-DEP: community support of unmaintained versions of Django

On 08/19/2015 09:38 AM, Donald Stufft wrote: > Do we have any evidence that users will notice a fourth digit and > will make the mental association that they are not official releases? > I wouldn’t if I hadn’t read this thread. I mean I don’t actually care > if they use 1.6.11.x or 1.6.12+, I just

Re: Pre-DEP: community support of unmaintained versions of Django

Hi Christian, On 08/18/2015 08:01 PM, Christian Hammond wrote: > I know it's been a while since we discussed this, but today's security > release is the first one that's really affecting our product and we've > finally got things in shape to be able to start distributing unofficial > Django

Re: Pre-DEP: community support of unmaintained versions of Django

On 08/19/2015 09:28 AM, Donald Stufft wrote: > On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote: >> In my ideal world, the version number would help convey unofficial-ness >> a bit more strongly, but after re-reading PEP 440 I don't think it >> leaves us

Re: Enhancement to the call_command function to allow the use of modules as arguments

On 08/18/2015 10:10 AM, Mike Lissner wrote: > On Tuesday, August 18, 2015 at 12:00:30 PM UTC-4, Carl Meyer wrote: > > > (Doc patches to better reflect that principle in the management command > docs are welcome, IMO.) > > Yeah, it's sounding like this is the chan

Re: Enhancement to the call_command function to allow the use of modules as arguments

Hi Marc, Mike, Aymeric, On 08/18/2015 06:52 AM, Marc Tamlyn wrote: > This is a deliberate approach you would use - South used it for years to > customise syncdb. > > call_command is intended as a python API for testing `$ django-admin > foo`. Two of your arguments are based around IDE usage,

Re: removing FlatPage.enable_comments field?

On 08/13/2015 12:39 AM, Loïc Bistuer wrote: > How about we deprecate contrib.flatpages: I'm not sure I agree with this. I think flatpages is actually an example of the kind of thing that belongs in contrib: a simple app to fulfill a simple, frequent need. > - I see people abuse it all the time

Re: How to disable system check framework?

Hi Marcin, On 08/11/2015 10:44 AM, Marcin Nowak wrote: > They aren't really silenced, but skipped. I would like to silence them > for real. They are skipped, but still printed out. I'm not sure what you're referring to here. If you include a system check warning code in the

Re: Future of the development server's auto-reloading

Hi Aymeric, I actually spent the PyCon 2015 sprints working on a generic watcher/reloader for Python servers, built on top of watchdog: https://github.com/carljm/wsgiwatcher It should still be considered alpha/prototype code, but I think the approach is promising. It uses a two-process model,

Re: #25227 Add utility method `get_updated_model()` to `ModelForm`

Hi Tim, On 08/10/2015 11:07 AM, Tim Graham wrote: > Yes, the idea is that ModelForm.save() method could become (after > deprecation finishes): > > def save(self): > """ > Save this form's self.instance object and M2M data. Return the model > instance. > """ > if self.errors:

Re: How to disable system check framework?

> On Aug 4, 2015, at 9:18 AM, Marcin Nowak wrote: > > I need to upgrade project to Django 1.8 but the SystemCheck Framework bothers > me. > It complains about thigs that should work, even if they are a little tricky. > > I need to disable system checks designed for

Re: default values on database level

On 07/28/2015 11:55 PM, Loïc Bistuer wrote: > +1 on db defaults as well, I've actually started experimenting on > this last week. It's a bit tricky because migrations do use db > defaults in some operations (and drop them once they are done) so we > have to ensure that the new feature doesn't

Re: @staff_member_required handling of non-staff users

On 07/28/2015 12:36 PM, Tim Graham wrote: > We received a ticket [1] noting that when a non-staff user tries to > access an admin page, they will be redirected to the admin login page > with no explanation. A pull request [2] proposes to add this message to > login page if a user is authenticated,

Re: Should we use __slots__? (and benchmarking memory usage)

On 07/24/2015 09:11 AM, Tim Graham wrote: > I'm interested in this old ticket about adding __slots__ to some of > Django's classes to reduce memory usage: > https://code.djangoproject.com/ticket/12826 > > I wonder if anyone has some experience with

Re: Why Django is making migrations for external apps?

On 07/20/2015 11:47 AM, Shai Berger wrote: > On Monday 20 July 2015 18:47:07 Carl Meyer wrote: >>> >>>> Personally I don't really see much use case for this feature >>>> except as a workaround for reusable apps that generate spurious new >>>> migrat

Re: Why Django is making migrations for external apps?

On 07/19/2015 06:14 AM, Anssi Kääriäinen wrote: > To me it seems the choice of doing migrations for app/model should be > done by the author of the app. > > How about model/app level setting migrations_mode, where the choices are > auto, manual and never. Auto is the defaul and behaves like

Re: Why Django is making migrations for external apps?

Hi Shai, On 07/19/2015 01:52 AM, Shai Berger wrote: [snip] >> It seems like what Marcin wants is more of a "don't ever create new >> migrations for this app, but go ahead and use its existing ones >> normally" flag (thus something that affects only `makemigrations`, not >> `migrate`). > > That's

Re: Why Django is making migrations for external apps?

On 07/17/2015 10:38 AM, Marcin Nowak wrote: > Sounds enough good. One important thing for me is that I have many of > external apps and few in project managed by me. Reconfiguring most of > apps just to tell Django "leave them alone" sounds like an overhead. > That's why I would like to tell

Re: Why Django is making migrations for external apps?

Hi Andrew and Marcin, On 07/15/2015 05:10 PM, Andrew Godwin wrote: > Django persists every single field attribute change, no matter what it > is - this was a deliberate decision as we didn't want to declare certain > attributes as "not important for schema" (for example, a subclass of >

Re: DEP django model internalization feedback

Hello, On 06/28/2015 08:04 AM, Ashley Camba Garrido wrote: > Damn, forgot the link. > > https://github.com/ashwoods/deps/blob/master/draft/-model-internalization.rst I think the DEP is well-motivated; thanks for picking up this topic. This is a problem that would be useful to have some

Re: 1.9 release planning

I am +1 on the 1.10 - 1.11 - 2.0 plan; I think the discrepancy between 2.x and the future version numbering scheme will in practice be _much_ more confusing (and already has been). I have never found any objection to 1.10-style version numbers convincing. Dotted version numbers are clearly a

Re: Password validation in Django revisited

On 06/21/2015 06:17 PM, Alex Becker wrote: > With the PR merged, password validation applies to the SetPasswordForm > and the password changing forms, but not to the UserCreationForm or to > the creation of superusers. Is there a reason not to apply validation to > these as well? Certainly makes

Re: Proposing DEP 3 (JS tests and linting) for acceptance

On Monday, June 8, 2015 at 2:29:22 PM UTC-6, Carl Meyer wrote: > > After lots of great work by Trey Hunner on the draft implementation (and > review from Tim Graham, Aymeric Augustin, Tomasz Paczkowski, and James > Da Costa), I think DEP 3 is ready for acceptance. > >

Re: how long to support Python 3.3?

On Monday, June 15, 2015 at 7:49:32 AM UTC-6, Tim Graham wrote: > > Here are the cleanups for dropping Python 3.3: > https://github.com/django/django/pull/4861 > > To prevent users from getting stuck on a non-LTS version of Django with an > old version of Python (when they would have had longer

Re: 1.9 release planning

Thanks Loïc, On 06/16/2015 01:15 AM, Loïc Bistuer wrote: > I've attempted to summarize the history of this thread. Note that I > marked as +1 any generally positive feedback towards a given > proposal, please correct if you feel misrepresented. > [snip] > > # Third iteration: > > 5/ Switching

Re: 1.9 release planning

Hi Matt, On 06/11/2015 07:30 PM, Matt Austin wrote: > On 11 June 2015 at 01:37, Collin Anderson wrote: >> >> I'd propose something slightly different, that's very close to our current >> deprecation timeline: >> 1.8 (LTS): No features dropped. >> 1.9: Dropped features

Re: Template-based widget rendering

Hi Preston, On 06/10/2015 11:46 AM, Preston Timmons wrote: > I've been working through solutions for #15667 -- template based widget > rendering. This is a problem that was close to a solution at one time, but > stalled out due to performance concerns and difficulties with defining a > workable

Re: Form assets and static file storage

On 06/10/2015 07:52 AM, Tim Graham wrote: > The problem has come up before: > https://code.djangoproject.com/ticket/18455 > > but there is some question about whether the design of the Media class > is something we should try to continue building on: > https://code.djangoproject.com/ticket/22298

Re: how to deal with inspect.getargspec() deprecation?

On 06/10/2015 01:48 PM, Berker Peksağ wrote: > On Wed, Jun 10, 2015 at 9:49 PM, Tim Graham wrote: >> inspect.getargspec() was deprecated in Python 3.0 and will be removed in 3.6 >> (ETA late 2016). It started throwing a deprecation warning in Python 3.5 >> which causes some

Re: 1.9 release planning

On 06/10/2015 11:54 AM, Collin Anderson wrote: > On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote: > > And there is a significant added maintenance cost to my proposal > compared to yours. Dropping deprecated APIs in the release after an LTS > mean

Re: how to deal with inspect.getargspec() deprecation?

On 06/10/2015 12:49 PM, Tim Graham wrote: > inspect.getargspec() was deprecated in Python 3.0 and will be removed in > 3.6 (ETA late 2016). It started throwing a deprecation warning in Python > 3.5 which causes some test failures when we check the number of > deprecation warnings so I'd like to

Re: Minor Feature Request: Unconfigured Allowed_Hosts Setting Should Raise ImproperlyConfigured Error

case would be simple - just go ahead and configure ALLOWED_HOSTS to something non-empty, even though you technically don't need it. Carl > [1] https://code.djangoproject.com/ticket/19875 > > On Wednesday, June 10, 2015 at 1:40:11 PM UTC-4, Carl Meyer wrote: > > On 06/10/2015 09

Re: Minor Feature Request: Unconfigured Allowed_Hosts Setting Should Raise ImproperlyConfigured Error

On 06/10/2015 09:55 AM, Robert Roskam wrote: > I realize this is a simple thing, but I'm sure this will save some > people time. > > Since Allowed_Hosts is a required setting, when debug mode is off, it > should raise an appropriate ImproperlyConfigured error. > > I'm sure there's some broader

Proposing DEP 3 (JS tests and linting) for acceptance

Hi all, After lots of great work by Trey Hunner on the draft implementation (and review from Tim Graham, Aymeric Augustin, Tomasz Paczkowski, and James Da Costa), I think DEP 3 is ready for acceptance. The latest draft of the DEP is here:

Re: Making management forms for formsets optional

On 06/07/2015 02:18 AM, Shai Berger wrote: > Semi-devil's-advocate suggestion: Replace the management form with a > management field, a hidden field with > > name = "__manage__%s" % (formsetname) > > and > > value="x" > > Then instead of taking the number of forms from a field

Re: Making management forms for formsets optional

On 06/08/2015 04:11 AM, Patryk Zawadzki wrote: > 2015-06-07 10:18 GMT+02:00 Shai Berger : >> Semi-devil's-advocate suggestion: Replace the management form with a >> management field, a hidden field with >> >> name = "__manage__%s" % (formsetname) >> >> and >> >>

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

Hi Emil, On 06/02/2015 11:53 AM, Emil Stenström wrote: > On Tuesday, 2 June 2015 19:06:35 UTC+2, Carl Meyer wrote: > Using Jinja2 on the server and nunjucks on the client with shared > templates works very well, is quite easy, and doesn't require > Node.js on > t

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

On 06/02/2015 05:54 AM, Aymeric Augustin wrote: > 2015-05-30 17:52 GMT+01:00 Emil Stenström >: [snip] > 2. A template language that has a solid javascript implementation. > To be able to render the templates the server side and client side > must use

Re: Proposal: Manually login without authenticate

Hi Unai, On 05/25/2015 10:52 AM, Unai Zalakain wrote: >> We can't default the `backend` argument to anything but a sentinel >> value, because if it's supplied, it should take priority, but if it's >> not supplied we need to maintain backwards compatibility with existing >> behavior, where the

Re: Proposal: Manually login without authenticate

On 05/24/2015 02:17 AM, Unai Zalakain wrote: >> 3) Use the only configured backend, if there is only one. >> 4) Raise ValueError("You have multiple authentication backends >> configured; you must provide the `backend` argument to `login`.") > > What about defaulting the backend argument to

Re: Proposal: Manually login without authenticate

On 05/23/2015 11:37 AM, Marc Tamlyn wrote: > If the backend is inferred by a single value in the settings and not > stored alongside the user ID, what would happen to existing users > who are already logged in when a second backend is added to the > settings and deployed? Django

Re: Proposal: Manually login without authenticate

Hi Paulo, On 05/22/2015 02:42 PM, Paulo Gabriel Poiati wrote: > I completely agree with the API design, it can be improved. What I'm > really trying here is to keep things simple. > > I don't see that importance in keeping the authentication backend > information in the http session (maybe I'm

Re: Proposal: Manually login without authenticate

Hi Paulo, On 05/22/2015 01:49 PM, Paulo Gabriel Poiati wrote: > I understand your points Carl, but I'm more inclined to think about the > average django developer and the new comers. Most people don't know or > don't want to know what an Authentication Backend is, they just want to > write their

Re: Proposal: Manually login without authenticate

On 05/22/2015 09:44 AM, Tim Graham wrote: > Could you elaborate on what use case you are trying to solve? > > On Friday, May 22, 2015 at 11:36:21 AM UTC-4, poiati wrote: > > Hello guys, > > I want to discuss the current login workflow in django. As it is we > need to call

Re: Can Django assume connect privileges to the 'postgres' database?

Hi Claude, On 05/14/2015 12:42 PM, Claude Paroz wrote: > Le jeudi 14 mai 2015 18:22:58 UTC+2, Carl Meyer a écrit : > > (...) > > I think the answer here is appropriate configurability. I see at least > two ways to make that happen: > > 1) add a c

Re: Can Django assume connect privileges to the 'postgres' database?

Hi Tim, On 05/13/2015 09:29 PM, Tim Graham wrote: > Django 1.8 requires a connection to the 'postgres' database in order to > resolve ticket #16969 [1]. We've had several reports of cases where > connecting to the 'postgres' database isn't permitted (e.g. Heroku and > other shared hosting

Re: SSL support for Django-admin runserver‏

Hi Russ, On 05/11/2015 06:05 PM, Russell Keith-Magee wrote: > > I'm completely on-board with the idea of switching to a "real" web > server rather than continuously improving our own. > > However, there might be better options than gunicorn. Graham Dumpleton > has released mod_wsgi-express: >

Re: An easier path to upgrade from one LTS release to another

Hi Tim, On 05/08/2015 08:28 AM, Tim Graham wrote: > Do we need to make it easy to support two LTS releases at once? For > example, at this point in time I expect projects to drop 1.4 support > when adding 1.8 support, not try to support both given that 1.4 will be > EOL in < 6 months. Assuming

Re: An easier path to upgrade from one LTS release to another

Hi Tai, On 05/07/2015 10:20 PM, Tai Lee wrote: > This sounds good. But will it significantly slow down the rollout of new > features into Django that require deprecation? No, because it would only delay the removal of deprecated features, not prevent the initial deprecation. The only cost here

Re: An easier path to upgrade from one LTS release to another

On 05/07/2015 08:53 AM, Tim Graham wrote: > I think there is some merit to reconsidering the deprecation schedule as > Anssi suggests. What I have seen is that most third-party apps didn't > consider dropping support for the previous LTS (1.4) until the next LTS > (1.8) was released. This meant

Re: URL dispatcher API

Hi Marten, On 05/04/2015 01:45 PM, Marten Kenbeek wrote: > I'd like to discuss the API I'm proposing for the new url dispatcher I'm > working on. I'll try to explain the API and some of the rationale behind it. Thanks for seeking comment early, and providing working PoC code, prose description,

Re: Allow deferral of ModelSignal callback invocation until after transaction commit

Hi Andrew, On 04/30/2015 06:13 AM, Andrew Godwin wrote: > I agree that perhaps making it part of signals is not in everyone's > favour (as signals are kind of unloved) but I also like the simplicity > of Christopher's approach - the patch is small and understandable, and > using it is pretty easy

Re: Allow deferral of ModelSignal callback invocation until after transaction commit

Hi, On 04/27/2015 08:17 AM, Christopher Adams wrote: > So wrote an > RFC > > and a > prototype >

Re: Idea/request for help: Django Developers Community Survey

On 04/25/2015 06:29 AM, Tim Graham wrote: > Aymeric and I put together a draft: > > https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform > > All questions are optional so you can just click through it to view the > questions. We'll probably clear any responses

Re: CSRF middleware calculates new tokens that are never used

Hi Jay, On 04/24/2015 12:29 PM, jay...@linear3d.com wrote: > It was requested of me that I post this here to get some more eyes on it: > > Django ticket: https://code.djangoproject.com/ticket/24696 > Pull request: https://github.com/django/django/pull/4550 > > I noticed that the csrf middleware

Re: 1.9 release planning

Hi Tim, On 04/04/2015 06:30 AM, Tim Graham wrote: > Now that Django 1.8 is released, I wanted to bump this thread for > discussion so we can hopefully ratify this schedule or modify it based > on feedback. In particular, I heard a concern that a six month release > schedule may be too often for

Re: Fate of sql* management commands

On 04/03/2015 02:30 PM, Collin Anderson wrote: > And the auto-generated in-memory migrations should work for tests too, > right? Well, that would depend on whether you have anything important in a RunSQL migration, or otherwise in a migration but not reflected in your model files. So, maybe. But

Re: Fate of sql* management commands

On 04/03/2015 03:17 AM, Aymeric Augustin wrote: > 2015-04-02 23:03 GMT+02:00 Marc Tamlyn >: > > As far as I'm aware, we have some code paths which still work in 1.9 > which generate tables directly from the models. We use this when >

Re: Two phase cleaning of models/forms

Hi Preston, On 04/02/2015 10:15 AM, Preston Timmons wrote: > Since I think this can be a useful feature, I'll explain why. > > One use case is for validating address forms. We deal with a lot of > them with varying levels of validation based on country, state, zip > code, etc. Sometimes,

Re: Fate of sql* management commands

Hi Pascal, On 03/30/2015 02:57 PM, Pascal Chambon wrote: > Thanks for your answers, > > l'm confused nonetheless, because their are two notions mixing up, here, > that we should probably separate: > > - the HISTORY of SQL schemas, aka "django/south migrations" > - the CURRENT STATE of SQL

Re: Pre-DEP: community support of unmaintained versions of Django

Hi Christian, On 03/26/2015 05:11 PM, Christian Hammond wrote: > I know you guys are still sorting out how you want to run this, but I > wanted to let you know that, given our current dependence on Python 2.6, > I'm willing to do what's needed to maintain security backports for > either an

Re: Pre-DEP: community support of unmaintained versions of Django

Hi John and Christian, On 03/27/2015 09:46 AM, John Paulett wrote: > James, thanks for putting this together. > > Christian, I am in a similar position, supporting 2.6 for the next 6-12 > months. I had planned to keep a personal fork of Django 1.6, > backporting security patches as needed, but

Re: Two phase cleaning of models/forms

Hi Thomas, On 03/25/2015 03:37 AM, Thomas Güttler wrote: > Up to now the validation/cleaning of a attribute can not access the > value of an other attribute. > > The work around is to override the clean() method of the form/model. > > A team mate and I talked about it, and we asked ourself, if

Re: Request for feedback on GSoC proposal "Test framework cleanup"

Hi Varun, On 03/24/2015 07:18 PM, Varun Sharma wrote: > I've been writing this proposal from past few days. After going through > the pycon talks of Carl Meyer and Julien Phalip on Django's testing > framework and working on the test framework from last 2 months, I have >

Re: improving debug logging in development

I played around with this a bit, and it seems that if you `disable_existing_loggers` but mention a specific pre-existing logger in your new config, that logger (and its children) are not disabled. So in your example here, because you're including the 'django' logger in your new config, it and its

Re: improving debug logging in development

On 03/23/2015 12:18 PM, Carl Meyer wrote: > On 03/23/2015 11:48 AM, Tim Graham wrote: >> The alternative to a new setting would be to revert the "merging" >> behavior of the django.utils.log.DEFAULT_LOGGING and settings.LOGGING >> entirely. This original design was

Re: improving debug logging in development

On 03/23/2015 11:48 AM, Tim Graham wrote: > The alternative to a new setting would be to revert the "merging" > behavior of the django.utils.log.DEFAULT_LOGGING and settings.LOGGING > entirely. This original design was proposed by Claude in > https://code.djangoproject.com/ticket/18993#comment:7,

Re: improving debug logging in development

On 03/22/2015 08:23 PM, Carl Meyer wrote: > The first, more complex and more important question is: how do we fix > Django's logging config process to be less broken, so that the best > advice for getting it to do what you what isn't "disable Django's > interference entirely a

Re: improving debug logging in development

On 03/21/2015 12:56 PM, Aymeric Augustin wrote: > The lack of a fathomable way to get a functional logging config is a > huge pain point :-) > > In this case, I wish we improve Django’s logging tools rather than > document how to bypass them :-/ I agree. The current behavior is pretty bad in

Re: Pre-DEP: community support of unmaintained versions of Django

Hi James, Thanks for taking the time to write this up carefully, research the history, etc. I think some form of extended community-based support could work, but I have some concerns about your specific proposal; mostly, that it places too much of the responsibility with the core team. My

Re: Bitwise operations in QuerySets?

Hi Charlie, On 03/16/2015 02:13 PM, Charlie Hayes wrote: > How do you evaluate if something is common enough to warrant inclusion? Frequency of people asking "how do I do this?" in django-users or IRC, popularity of third-party libraries solving the problem, etc. It's not exactly scientific, but

Re: csrf middleware token from request body

Hi Rafał, On 03/13/2015 12:42 PM, Rafał Pitoń wrote: > On Friday, March 13, 2015 at 4:14:55 PM UTC+1, Florian Apolloner wrote: > > I am pretty sure you can configure angular to send the token in the > header. Either way, we are not going to try and load json, just we > can't find a

Re: Abstract models and the app registry

On 02/11/2015 08:17 PM, Alex Hill wrote: > I'm still curious as to why abstracts aren't registered – is that a > requirement of some feature of the app registry design, or is it just > that way because? I think it's just a natural consequence of not considering them to be real models. One

Re: Abstract models and the app registry

Hi Alex, On 02/11/2015 11:39 AM, Alexander Hill wrote: > I'm looking for some background about abstract models, specifically why > they aren't registered with the app registry as normal models are. > > For some context, I'm working on a ticket [0] to refactor Django's lazy > model operations

Re: discontinue shipping tests with contrib apps?

On 02/10/2015 12:08 AM, Jannis Leidel wrote: >> On 10 Feb 2015, at 00:12, Tim Graham wrote: >> >> Is it a best practice? In my unscientific sampling, none of the >> following ship tests inside the application directory, but rather >> in a separate "tests" directory. Or did

Re: resurrecting an old friend, whitespace in forms, #6362

On 02/04/2015 02:00 AM, Tom Christie wrote: >> it will be backwards incompatible for every Django installation out > there, but also because throwing away data that the user actually > entered should be an opt-in, not opt-out behavior. > > If adequately called out I think there'd be a valid case

Re: Use sub-query in ORM when distinct and order_by columns do not match

Hi Miroslav, On 01/24/2015 08:20 PM, Miroslav Shubernetskiy wrote: > Hi everyone, > > Just created my first django new feature ticket and wanted to get some > community opinion on the topic > - https://code.djangoproject.com/ticket/24218#ticket. Welcome, and thanks for the suggestion + patch!

Re: Settings: lists or tuples?

On 01/19/2015 01:13 PM, Andreas Kahnert wrote: > I advertise that strongly against lists, because we actually had that > kind of issue in our company. > One colleague created a list with phrases for some verbose logging in > the settings.py. In the view function he promoted this list together >

Re: Fellow Report - January 16, 2015

On 01/19/2015 10:21 AM, Tim Graham wrote: > Thanks, Anssi. By the way, we are compiling testimonials to help in the > fundraising efforts. Do you mind if we include those two sentences from > you? (feel free to add a couple more sentences if you like). If anyone else > would like to share one,

Re: simplifying the default template context_processors

Hi Russ, On 01/11/2015 05:20 PM, Russell Keith-Magee wrote: >> Without having spent much time to research the consequences — it's on my >> TODO list but Collin brought it up before I investigated — my straw man >> proposal is: >> >> TEMPLATES = [ >> { >> 'BACKEND':

Re: Last call: Meta API (GSoC 2014/PR 3114) is ready for commit

Congratulations, Daniel! Thanks for sticking around long past the end of the GSoC to make this change happen. Carl On 01/07/2015 06:14 PM, Daniel Pyrathon wrote: > Hi all, > > My project has just landed in master, since last night (EU time). > > I just wanted to say THANK YOU for everyone that

<    1   2   3   4   5   6   7   >