Re: Settings: lists or tuples?

On 12/17/2014 11:49 PM, Russell Keith-Magee wrote: > On Thu, Dec 18, 2014 at 7:48 AM, Carl Meyer wrote: >> This is clever, but on second thought I'm trying to figure out in what >> scenario a backwards-compatibility would actually occur here. In the >> context of

Re: Bypassing 1.7+ migrations

On 12/19/2014 11:59 AM, Marcin Nowak wrote: > > > On Friday, December 19, 2014 12:19:11 AM UTC+1, Shai Berger wrote: >> >> >> As far as I understood, Marcin wants to treat *all* models as unmanaged; >> there >> are no managed models to reference the unmanaged ones. >> > > I would like to disa

Re: Bypassing 1.7+ migrations

Hi Marcin, On 12/22/2014 10:28 AM, Marcin Nowak wrote: >> This is not an optional contrib add-on, it's a core part of the ORM. > > There are systems where Django is not a core, but it is used as lightweight > app server. > Database schema migrations are created and executed in the other way..

Re: Delivering PR 3114 - The _meta refactor

Hi Russell, Many thanks to Daniel, and to you, for all the work on this PR! On 12/22/2014 12:39 AM, Russell Keith-Magee wrote: > * get_fields(include_parents=True, include_hidden=False) > > Returns a list of fields associated with a model. > > include_parents controls whether the list of field

Re: Delivering PR 3114 - The _meta refactor

On 12/22/2014 06:04 PM, Russell Keith-Magee wrote: [snipped agreement on many things!] > I'd argue whether a mixin is needed at all. At present, the mixin is only > used on Field, GenericForeignKey and RelatedObject. RelatedObject will > potentially be deleted; that leaves 2 classes. Every field

Re: Optional separation of the concepts of how long server caches content and how long it tells client to cache it

Hi Alejandro and Russell, On 12/28/2014 07:29 PM, Russell Keith-Magee wrote: > On Sun, Dec 28, 2014 at 8:13 PM, Alejandro Dubrovsky > wrote: >> On Sunday, December 28, 2014 7:23:34 PM UTC+11, Alejandro Dubrovsky wrote: >>> On Sunday, December 28, 2014 1:03:26 PM UTC+11, Russell Keith-Magee wrote:

Re: intended security model for templates

Hi Tim, On 12/24/2014 01:35 PM, Tim Graham wrote: > I was hoping to get clarification on what security model we intend to > support for template authors. In ticket #12772 > it's proposed to allow > loading template tags using a dotted Python path. T

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

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': 'django.template.bac

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, p

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 > wit

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! I

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 t

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 I misunderstand what yo

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 (use

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 practic

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 to

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: 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 feeling

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 seve

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 > interfer

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, b

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

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 c

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

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: 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 I

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 officia

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 schema

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, multiple

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 > running Django's own

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 i

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 th

Re: Removing global database converters and adapters for datetimes

On 04/13/2015 12:13 PM, Aymeric Augustin wrote: [snip] > Do you think the backwards-incompatibilities are acceptable? I think so, yes. It really isn't good behavior for Django to be automatically installing such global adapters and converters. Perhaps the release notes documenting this backwards-

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: 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 bef

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: 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: 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, a

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 tha

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 is

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 the

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: 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 provider

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: 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 `authentica

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 a

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 mi

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 wou

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 Django'

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 `use

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 mailto:e...@kth.se>>: [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 the same language

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 >

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 >> >> value="x" >> >> Then

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 o

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: https://github.com/django/deps/blob/master/draft/0003-java

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 di

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

und for the annoying 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: >

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 dea

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 > means w

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 test failures when we c

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: 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 AP

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 deprecated in 1.5, 1.6, 1.7

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 to

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 s

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. > > The l

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 s

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 repre

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 stand

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 > ChoiceFiel

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 Django

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/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 curren

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 >>>> m

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 __slot

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: 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 inter

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 blogs and other simple sites

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: 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, whe

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 SILENCED_SYSTEM_CHECKS

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 (d

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, whic

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

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 >> leave

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 securi

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: [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 d

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: 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 c

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, etc

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 this

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 model,

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: 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 should

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 > requiring

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 somethin

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 o

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 (further)

<    1   2   3   4   5   6   7   8   >