Re: [GSoC] Switching to Jinja2 proposal

On 02/12/2014 02:25 PM, Curtis Maloney wrote: > At this point someone should start asking for real-world examples with > measurements. > > I'm personally of the "let's see if we can improve DTL first, then > revisit the question" stance. > > But in order to show any improvements, we must have tim

Re: Testing 1.7a2 -- pre_migrate and post_migrate (py2.7)

On 02/11/2014 12:17 PM, Carl Meyer wrote: > On 02/11/2014 12:11 PM, Val Neekman wrote: >> Is the following statement still valid? >> >> "Any handlers that listen to this signal need to be *written* in a >> particular place: a management module in one

Re: Testing 1.7a2 -- pre_migrate and post_migrate (py2.7)

On 02/11/2014 12:11 PM, Val Neekman wrote: > Is the following statement still valid? > > "Any handlers that listen to this signal need to be *written* in a > particular place: a management module in one of your INSTALLED_APPS >

Re: [GSoC] Switching to Jinja2 proposal

Hi Chris and Russ, On 02/08/2014 05:11 PM, Russell Keith-Magee wrote: > > On Sun, Feb 9, 2014 at 6:16 AM, Christopher Medrela > mailto:chris.medr...@gmail.com>> wrote: > > Why not switching to Jinja2? I thought that somebody else proposed > this idea > but I couldn't find any discuss

Re: Why SlugField overrides get_internal_type()?

Hi Val, On 02/07/2014 04:07 PM, Val Neekman wrote: > None of the other subclasses of CharField override get_internal_type() > but the SlugField and I am wondering why? > > Class SlugField(CharField): > > def get_internal_type(self): > return "SlugField" "Internal type" abstracts a f

Re: Check Framework Feedback

On 02/05/2014 04:14 PM, Russell Keith-Magee wrote: > On Wed, Feb 5, 2014 at 10:13 PM, Thomas Güttler > wrote: > > Hi, > > here is some feedback to the check framework, documented at: > > https://docs.djangoproject.__com/en/dev/ref/checks/ >

Re: freenode under DDOS attack -- IRC works on webchat

On 02/03/2014 01:55 AM, Shai Berger wrote: > If you're experiencing difficulties connecting to IRC, it's not your fault; > the > #freenode channel's subject is currently: > > """ > We're currently experiencing what appears to be a DOS attack against our > servers. Some servers are offline, and

Re: 1.7 Schema migrations and AUTH_PROFILE_MODULE / get_profile() deprecation

Hi Ryan, On 01/23/2014 09:50 PM, Ryan Hiebert wrote: > Assuming that the changes from the deprecation policy are in trunk now > that the alpha has landed, any use of the AUTH_PROFILE_MODULE must be > eliminated _before_ moving to 1.7, since they are not just deprecated, > but _removed_ in 1.7. Mig

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 01/21/2014 06:48 AM, Russell Keith-Magee wrote: > As Marc indicated in his post, I don't think we should be treating this > as a permanent feature of the API, but as but as a migration aid. Yes, > default_app_config will exist as a bad smell for 2 releases, but come > Django 1.9, we can remove i

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

Hi Marc, On 01/20/2014 01:23 PM, Marc Tamlyn wrote: > Now I have a moment to mention this, there is a very important issue I > currently don't see a way around, contrib highlights it well but in > reality it's more a third party app issue. > > Suppose my third part app has a (normal) Django two-r

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 01/20/2014 01:01 PM, Carl Meyer wrote: >>> 3a) As for 3, but use a flag on the AppConfig subclass that marks >>> it as "use me as the default". If there are more than one AppConfig >>> objects in an apps module that has the 'use as default" f

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

Hi all, I just filed #21831, which is a release-blocking regression directly related to this. My opinion is that doing check-registration as an import side-effect in `__init__.py` is not viable, as it means that every single check needs to be coded defensively against the possibility that the app

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 01/20/2014 12:22 PM, Aymeric Augustin wrote: > On 20 janv. 2014, at 18:36, Carl Meyer wrote: > >> I very much hope >> that moving the admin autodiscovery to the admin AppConfig still allows >> some reasonable path to opt-out of autodiscover - perhaps by subclassin

Re: App-loading: Pragmatic concerns about default AppConfig objects and ready() implementations

On 01/19/2014 07:08 AM, Aymeric Augustin wrote: > On 19 janv. 2014, at 13:46, Russell Keith-Magee > wrote: > >> On Sun, Jan 19, 2014 at 5:48 PM, Aymeric Augustin >> > > wrote: >> >> Also there might be good reasons for

Re: Feature request: post/pre commit/rollback signals

On 01/18/2014 01:19 PM, Anssi Kääriäinen wrote: > On Saturday, January 18, 2014 9:02:41 PM UTC+2, Aymeric Augustin wrote: > > On 18 janv. 2014, at 19:50, Carl Meyer > wrote: > > > Those interested in this feature may find django-transaction-hooks > [1]

Re: Feature request: post/pre commit/rollback signals

Hi, Those interested in this feature may find django-transaction-hooks [1] useful. It is my attempt to implement the commonly-useful case (run some code after the current transaction successfully commits, providing the code wasn't registered during a savepoint which was later rolled back.) I th

Re: Trac and getting started contributing (was: 1.7 Release Schedule)

Hi Christian, On 12/09/2013 03:28 PM, Schmitt, Christian wrote: > Also just a question.. I currently looking forward to maybe contribute > something back to django. Great! > But I always struggle with trac it looks so extremly messy. Yeah, it takes some getting used to. If you'd like help with

Re: Proposal to end the war with flake8 warnings

On 10/09/2013 12:38 PM, Tim Graham wrote: > I'd like to propose cleaning up Django's codebase so that we can run > flake8 (with some rules ignored) as a presubmit check (for example, > hooked into pull request submissions). > > Our docs currently state: "Note, however, that patches which only remo

Re: Django 1.6 and migrating to the new test runner: note on user experience

On 10/01/2013 06:36 AM, Ivan Kharlamov wrote: > On 09/27/2013 09:01 PM, Carl Meyer wrote: >> On 09/27/2013 03:07 AM, Ivan Kharlamov wrote: > Thank you for considering a fix! > > Personally, I'd prefer a solution proposed by Shai, which is (5). I commented in my reply to Sh

Re: Django 1.6 and migrating to the new test runner: note on user experience

Hi Shai, On 09/27/2013 05:42 PM, Shai Berger wrote: > On Friday 27 September 2013 20:01:00 Carl Meyer wrote: >> 3) A first-run warning that can be turned off (and presumably would be >> off by default in new projects). The obvious mechanism for turning it >> off would be

Re: Add strutctured settings module to django 1.7?

On 09/27/2013 10:52 AM, andres.osin...@gmail.com wrote: > What is the difference between privately tracking a shell file and a Python > config file? Not a lot of difference, but the env vars give you more flexibility. In a single settings file using env vars, I can easily have things like a "mode

Re: Django 1.6 and migrating to the new test runner: note on user experience

Hi Ivan, On 09/27/2013 03:07 AM, Ivan Kharlamov wrote: > Maybe I'm a careless kind of guy, but when I test out new versions of > Django, reading all of the release notes is rarely the first thing that > I do... my bad. :) My first action is usually firing up the test suites > and looking at the nu

Re: Add strutctured settings module to django 1.7?

Hi Tom, On 09/27/2013 09:51 AM, Tom Evans wrote: > On Thu, Sep 26, 2013 at 2:21 PM, Andres Osinski > wrote: >> Honestly, I find the idea of *not* using a settings file to be inconvenient, >> and the notion of using environment variables for doing anything aside from >> pointing to a settings file

Re: changing the on_delete=CASCADE default

Hi Christophe, On 09/26/2013 04:28 PM, Christophe Pettus wrote: > On Sep 26, 2013, at 2:32 PM, Carl Meyer wrote: >> We already provide the on_delete=DO_NOTHING option for people who >> want to push cascade handling to the database. > > It's better than the previou

Re: changing the on_delete=CASCADE default

On 09/26/2013 03:17 PM, Christophe Pettus wrote: > It's a breaking change, so that's going to be a significant amount of > upgrade work for existing applications. Yes, it would certainly require a deprecation path, so people would have the course of several Django versions to update their code. >

changing the on_delete=CASCADE default

Hi all, I filed a ticket last week suggesting that we change the default from on_delete=CASCADE to on_delete=SET_NULL for nullable ForeignKeys.[1] There's been some lively discussion on the ticket, and Michael Manfre has suggested that we should instead transition to making on_delete a required a

Re: Add strutctured settings module to django 1.7?

On 09/26/2013 09:02 AM, Michael Manfre wrote: > I don't think there will ever be a true consensus. I predict that the > option that would leave the least number of people unhappy is a settings > API that allows for 3rd party settings backends. Having settings in the > environment is ideal for deplo

Re: System check framework

Hi Christopher, On 09/20/2013 02:07 PM, Christopher Medrela wrote: > This summer I'm a student of Google Summer of Code. I was working at > introducing a new system check framework (merging django-secure was a > part of > my proposal, but I didn't manage to do it due to my time > overestimation).

Re: Missing timezone support in built-in time template filter

Hi Warren, On 08/26/2013 03:32 PM, Warren Smith wrote: > Any chance that https://code.djangoproject.com/ticket/20693 can make it > into 1.6? Thanks for your work on the patch! Since it's a new feature, it's a couple months late for 1.6; it would have needed to go in before the first 1.6 beta was

Re: #20739 - Making LiveServerTestCase not depend on staticfiles?

Hi Jannis and Ramiro, On 07/14/2013 07:16 AM, Jannis Leidel wrote: > Yeah, I can relate to that, it does to me, too. I think decoupling > the file serving slightly from how the files got to the place they > are served from, is a good first step. The common denominator between > the core ability to

Re: Confusion around generic views queryset cloning.

Hi Tom, (You said in a follow-up this was intended for django-users, but personally I think it's on-topic for -developers, so I'm replying here.) On 07/11/2013 02:54 PM, Tom Christie wrote: > I've noted that the generic view implementations use the private > `_clone` method when returning the que

Re: Adding a OneToMany Relationship to Django

On 07/10/2013 05:40 PM, Carl Meyer wrote: >> I'm not sure I completely agree with Carl that is breaks correspondence >> -- after all, m2m fields don't correlate to a field, either. However, in >> the absence of a built-in migrations framework, I suspect a O2M field &g

Re: Adding a OneToMany Relationship to Django

Hi Russ, On 07/10/2013 05:33 PM, Russell Keith-Magee wrote: > On Wed, Jul 10, 2013 at 4:20 PM, Curtis Maloney > mailto:cur...@acommoncreative.com>> wrote: > > I've seen enough people in #django suffering because they need a > FKey on a table they simply can't alter -- be it because it's i

Re: Tests -- Errors vs. Failures

Hi Shai, On 07/08/2013 02:55 PM, Shai Berger wrote: > I just pushed a fix to a test failure on Oracle -- the last-executed-query > test. However, I want to ask about the preferred style in writing the test > itself. The test, as it is written now, is: > > def test_last_executed_query(self):

Re: MAC adddres field

Hi Patryk, On 06/26/2013 09:13 AM, Patryk Ściborek wrote: > I would like to ask you to reconsider addition of field representing MAC > address. There was similar ticket created 7 years ago: > https://code.djangoproject.com/ticket/2239 and it was closed with wontfix. > > I use Django in many proje

Re: Adding a OneToMany Relationship to Django

Hi Amir, On Jun 15, 2013, at 9:11 AM, Amir Rachum wrote: > I'm not sure if this feature was discussed before (I've seen some mentions of > it when searching this group, but nothing definitive). > I have written a blog post regarding the reasons (and the suggested syntax) > to use this relations

Re: [GSoC] Revamping validation framework and merging django-secure once again

Hi Christopher, Overall, this looks like a great project and I look forward to the more flexible validation hooks. As the author of django-secure, I do have one concern with the implementation plan: Django's existing validation checks are intended to be run in development, as a debugging aid, but

Re: Migrations, commands and syncdb

On 05/30/2013 12:03 PM, Andrew Godwin wrote: > The proposals are: > > 1. Change syncdb so that it both does the old behaviour (adds models > for unmigrated apps), and additionally runs any outstanding migrations. > There would be a separate "migrate" command for more complex operations, > such as

Re: Testing generated SQL under different backends

Hi Shai, On 05/27/2013 09:26 AM, Shai Berger wrote: > I'm working on fixing some failing tests under Oracle, and I ran into > > commands_sql.tests.SQLCommandsTestCase.test_sql_all() > > which collects the sql_all command's output, and verifies it is as expected. > It includes, among other

Re: Proposal: OpenLayers.js and shipping it in django.contrib.gis statics

Hi Kamil, On 05/26/2013 05:39 PM, Kamil Gałuszka wrote: > Hi Django developers! > > This is my first time here posting, so if I'm wrong please forgive me :) > I wanna learn as much as possible about django development process from > you guys! > Thank you all for inspiring time on DjangoCon.eu sp

Re: test discovery

Hi Chris, On May 18, 2013, at 8:34 AM, Chris Wilson wrote: > On Sat, 18 May 2013, Chris Wilson wrote: > >> I think Travis is unhappy about something in this commit. Any ideas? >> >> == >> ERROR: test_file_path (test_runner.tes

Re: test discovery

Hi Chris, On May 18, 2013, at 9:42 AM, Chris Wilson wrote: > Another odd behaviour of the new test runner. This runs the tests, but fails > to add the test app to INSTALLED_APPS, so they all fail because their tables > are not created: > >PYTHONPATH=.. python -Wall runtests.py --selenium -

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

Hi Emil, On May 16, 2013, at 5:21 PM, Emil Stenström wrote: > Any feedback on how I was thinking? Does it make sense? > > Based on the feedback so far I gather that changing the block tag is a bad > idea. I'd love to continue working on this, because I've felt this need in > lots of different

Re: Triaging: Close as needsinfo

On 05/11/2013 06:01 PM, Shai Berger wrote: > On Sunday 12 May 2013, Łukasz Rekucki wrote: >> Hi, >> >> On 11 May 2013 22:58, Shai Berger wrote: >>> In >>> other communities, I have usually seen "needsinfo" as a ticket state, >>> rather >>> than a reason for closing; such tickets are then closed la

Re: test discovery

Hi Florian, On May 11, 2013, at 7:51 AM, Florian Apolloner wrote: > Hi Carl, > > before I read all the tickets etc; why does runtests.py not use the > TEST_RUNNER from settings.py (see > https://github.com/django/django/commit/9012833af857e081b515ce760685b157638efcef#L60L149)? > We'd need th

Re: test discovery

I merged this patch tonight. Thanks to everyone who contributed! Now let's see how the CI servers feel about it... Carl On Wednesday, May 8, 2013 5:00:56 PM UTC-4, Carl Meyer wrote: > > Preston Timmons and I have been working the last several weeks to get > the test discovery

Re: test discovery

On Thursday, May 9, 2013 8:15:02 PM UTC-4, Russell Keith-Magee wrote: > On Thu, May 9, 2013 at 11:30 PM, Carl Meyer > > wrote: > >> Hi Russ, >> >> On 05/09/2013 04:51 AM, Russell Keith-Magee wrote: >> > Great work Carl and Preston! (And everyone else wh

Re: test discovery

On 05/09/2013 07:50 AM, Andrew Godwin wrote: > Just want to say that I'm happy with a "fast transition". > > Is there a possibility we can detect the case where the tests might be > broken (how might they be?) and print a helpful error message? Two kinds of potential breakage: - The most common

Re: test discovery

Hi Russ, On 05/09/2013 04:51 AM, Russell Keith-Magee wrote: > Great work Carl and Preston! (And everyone else who had a hand in the > patch - I know this has been kicking around for a while now) Thanks for the reminder; I should have mentioned that Mahdi Yusuf did the initial draft patch, based o

Re: test discovery

Hi Tom, On 05/09/2013 03:27 AM, Tom Christie wrote: > * Will it be possible to globally configure the default file/path pattern? > Jannis's django-discover-runner includes support for a > `TEST_DISCOVER_PATTERN` - is there anything similar, or just the command > line `--patterns` option? The us

Re: test discovery

Hi Anssi, On 05/08/2013 03:31 PM, Anssi Kääriäinen wrote: > It would be really nice to be able to use same syntax for running a > single Django's testcase at least for a while. I expect that there > will be problems if inspecting how a given test case behaves in older > versions compared to HEAD.

test discovery

Hi all, Preston Timmons and I have been working the last several weeks to get the test discovery branch (#17365) ready for merge, and I think we now have a pull request ready for consideration: https://github.com/django/django/pull/1050 Brief summary of the features, changes, and open questions:

Re: Ticket 19445

Hi Luke, On 05/01/2013 04:31 PM, Luke Plant wrote: > Can I get some feedback on what to do about ticket 19445? > > https://code.djangoproject.com/ticket/19445 > > I have re-opened this ticket because I don't think it was addressed > satisfactorily. I apologise in advance that this is a bit invol

Re: GSOC: Deadline soon!

On 05/01/2013 01:38 PM, Nicolas Bouliane wrote: > It seems that I have underestimated the barrier of entry to the Google > Summer of Code. With so many hoops to jump through and very little time > left, I will not play against the odds. I understand; it is late in the process to be starting on a p

Re: GSOC: Deadline soon!

On 05/01/2013 11:18 AM, Nicolas Bouliane wrote: > Reading the description of django-floppyforms, I realize most of these > features are overlapping with those in my proposal. > > What do you think would be advisable from that point? In general, I think your proposal would benefit from additional

Re: GSOC: Deadline soon!

On 05/01/2013 11:04 AM, Carl Meyer wrote: > I was the mentor for that GSoC project, and the reason for its failure > is that the Django template language proved too slow for the > template-based system we proposed for rendering form widgets and form > layouts; form-rendering speed su

Re: GSOC: Deadline soon!

Hi Nicolas, On 05/01/2013 10:52 AM, Nicolas Bouliane wrote: > I have done as suggested and submitted my proposal in the mailing list. > I heard about the Google Summer of Code /very/ recently, but hopefully > I'll be able to submit an accurate and sensible proposal on time! > > Coincidentally, I

Re: Django 1.6 release timeline

Hi Shai, On 04/30/2013 04:38 PM, Shai Berger wrote: > On Tuesday 30 April 2013, Jacob Kaplan-Moss wrote: >> Hi folks - >> >> Unless there are strong objections, here's what I'm thinking for the >> Django 1.6 release timeline: >> >> Alpha: May 16 >> Beta: June 20 >> RC: Aug 1 >> Final: as early as

Re: Django 1.6 release timeline

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 said, I can upgrade to 1.5 without changing > user models (though that does involve incurring a bit

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

Hi Emil, On 04/17/2013 04:00 PM, Emil Stenström wrote: > Carl Meyer skrev 2013-04-17 18:37: >> Why not instead add a new block to base.html? So you'd change base.html >> to have: >> >> {% block outer-content %} >> {% block content %}{% endblock content %} >

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

Hi Emil, On 04/17/2013 09:50 AM, Emil Stenström wrote: > Proposal: > Make it possible to use the same template block name twice, if the > second one is nested within the first one. Inheriting from the template > fills in the innermost block. This is an interesting proposal, but I am concerned tha

Re: Support for WSGI applications within Django (Ticket #12091)

Hello Gustavo, On 04/11/2013 08:31 AM, Gustavo Narea wrote: > In the interest of finding a resolution to Ticket #12091 > , a 3-year-old ticket, I > wanted to bring this issue to your attention. > > I think that Django should have built-in support for r

Re: Help on ticket no 4136

Hello Ankit, On 04/10/2013 12:19 PM, ANKIT BAGARIA wrote: > I want to work on ticket no 4136 but am not able to start... Can someone > please help me with this as to where do I get started from. > Link to ticket: https://code.djangoproject.com/ticket/4136 I added a comment to that ticket with

Re: Ticket 20147 - deprecate and replace request.META

Hi Luke, On 04/08/2013 02:02 PM, Luke Plant wrote: > This is already the subject of a ticket, but I didn't get a response > yet. Basically, the idea is replace things like: > > request.META['HTTP_ACCEPT'] > > with > > request.HEADERS['Accept'] > > request.META should be deprecated and repl

Re: Testing project code that resides outside of installed apps

Hi, On 03/30/2013 10:32 AM, Yo-Yo Ma wrote: > A common pattern for larger applications is to maintain bits of reusable > code outside of applications, but still inside of a project (e.g., > myproject/lib), due to synchronous development and modification of > application and library code. They're p

Re: Proposal for allowing dynamic site based on domain name WITHOUT changing settings.SITE_ID.

On 03/25/2013 09:25 PM, meric wrote: > Previous discussion: > https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/dynamic$20sites/django-developers/QSXLGSxy7Vk/TxgiJzz5nd8J > https://code.djangoproject.com/ticket/16983 > https://code.djangoproject.com/ticket/4438 If you're in

Re: An idea for the URL dispatcher

Hi Daniele, On 03/21/2013 02:07 AM, Daniele Procida wrote: > I think it would at minimum require hooks so that the URL dispatcher > could call other functions, not just views. > > So: > > * the URL dispatcher could be invoked with a special argument when > you want it not to call views but perfo

Re: An idea for the URL dispatcher

Hi Daniele, On 03/20/2013 05:46 AM, Daniele Procida wrote: > I have an idea for the URL dispatcher, and I'd like to know what your > thoughts are. > > Often - not always but often - a Django URL will map to a model > instance via a URLconf and a view. > > I can think of a few uses for a feature

Re: Proposal: move non-db tests out of TransactionTestCase

On 03/07/2013 01:32 PM, zalew wrote: > I'm currently working on a project where I don't use db.* and I met a > problem during testing. As django.test.testcases.TestCase [1] inherits > from TransactionTestCase, it complains about "ImproperlyConfigured: > settings.DATABASES". A solution is to fall ba

Re: Proposal: ModelForm API improvements

Hi Bruno, On 03/07/2013 12:42 PM, Bruno Renié wrote: > * Move formfield_for_* to ModelForm and document them as public APIs > * Deprecate `formfield_callback` > * Write an AdminModelForm class that implements all the admin form > fields and widgets customization > * Modify ModelAdmin to make use o

Re: Proposal: deprecate and remove django.contrib.comments

On 03/07/2013 09:48 AM, Jacob Kaplan-Moss wrote: > This one's simple: I'd like to deprecate `django.contrib.comments`, > scheduling it to be removed in a couple of releases. > > My rationale is this: if you don't really care much about how comments > work but just want something easy, then Disqus

Re: Switch to database-level autocommit

On 03/01/2013 05:48 AM, Aymeric Augustin wrote: > Basically, Django intends to provide autocommit by default. Rather than > fight the database adapter that itselfs fights the database, I propose > to simply turn autocommit on, and stop implicitly starting and > committing transactions. Explicit is

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

On Feb 20, 2013, at 6:25 PM, Ian Kelly wrote: > On Feb 20, 2013 4:41 PM, "Carl Meyer" wrote: > > On 02/20/2013 04:25 PM, Nick Phillips wrote: > > >> There was extensive back-and-forth discussion of this in writing the > > >> patch. The issue is that i

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

On 02/20/2013 04:25 PM, Nick Phillips wrote: >> There was extensive back-and-forth discussion of this in writing the >> patch. The issue is that in almost all cases the correct value of the >> setting in local development and under test are different from the >> correct value in production. So how

Re: Django 1.4.4 and contrib/sessions/management/__init__.pyc

We've just released 1.3.7 and 1.4.5 to correct this packaging problem: https://www.djangoproject.com/weblog/2013/feb/20/updated-releases-issued/ Thanks for reporting it! Carl On 02/19/2013 08:12 PM, Nick Popoff wrote: > I downloaded Django 1.4.4 this evening and after switching to it started >

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

On 02/20/2013 01:58 AM, Reinout van Rees wrote: > On 19-02-13 23:32, Nick Phillips wrote: >> I don't recall looking at the ALLOWED_HOSTS setting before. > > Should there be a note in the 1.4 docs that the default ['*'] value is a > temporary default value? That from 1.5 onwards it will be an emp

Re: ANNOUNCE: Django 1.5 release candidate 2, Django 1.4.4, Django 1.3.6 (security releases)

Hi Nick, On 02/19/2013 03:32 PM, Nick Phillips wrote: > I don't recall looking at the ALLOWED_HOSTS setting before. Now that I > do, it seems rather problematic. In particular, that host verification > is apparently turned off while DEBUG is True or while testing. > > Surely this makes it impossi

clarification of API backwards-compatibility policy

Hi, I was just about to tell someone on IRC that Django's backwards-compatibility policy only applies to documented methods and attributes (which is how I'd always understood it), but when I actually went to look at the documented policy it isn't as clear as I'd hoped :/ https://docs.djangoprojec

Re: Database pooling vs. persistent connections

On 02/19/2013 03:04 AM, Anssi Kääriäinen wrote: > I hope this discussion is about what to do at request finish/start > time. > > I am very strongly opposed to anything where Django suddenly changes > connections underneath you. At request finish/start this is OK (you > should expect new connection

Re: Database pooling vs. persistent connections

On 02/18/2013 02:27 PM, Aymeric Augustin wrote: > Problem #1: Is it worth re-executing the connection setup at the beginning of > every request? > > The connection setup varies widely between backends: > - SQLite: none > - PostgreSQL: > https://github.com/django/django/blob/master/django/db/backe

Re: Database pooling vs. persistent connections

On 02/18/2013 12:17 PM, Michael wrote: > On Mon, Feb 18, 2013 at 2:03 PM, Jacob Kaplan-Moss > wrote: > > On Mon, Feb 18, 2013 at 1:51 PM, Michael > wrote: > > I will argue, however, that the AWS use case is a reason we need >

Re: Database pooling vs. persistent connections

On 02/18/2013 06:47 AM, Jacob Kaplan-Moss wrote: > On Mon, Feb 18, 2013 at 7:41 AM, Aymeric Augustin > wrote: >> The goal of my proposal is to save the cost (in response time) of >> establishing >> the database connection, in vanilla Django, without compromising reliability. >> I'm trying to help

Re: Database pooling vs. persistent connections

On 02/17/2013 11:31 AM, Anssi Kääriäinen wrote: > It seems SQLAlchemy has a mature pooling implementation. So, yet > another approach is to see if SQLAlchemy's pooling implementation > could be reused. (Maybe in conjunction with the above 'POOLER' idea). There is in fact an implementation of reusi

Re: Ticket #17093 -- quarantine global state in django.template

Hello Christopher, On 02/08/2013 09:59 AM, Christopher Medrela wrote: > I don't want to discourage you from working on the project if you find > > it interesting and informative, and it may well be that the results are > > worth the effort and end up being merged into Django; but it

Re: Ticket #17093 -- quarantine global state in django.template

Hello Christopher, Since I opened that ticket and sent you down this rabbit-hole, I can at least offer some thoughts :-) In full disclosure, I should also say that since opening the ticket I've had doubts about whether this change (although clearly an improvement in the abstract) is worth the effo

Re: Can you confirm Stack Overflow answer about `.exists()`?

Hi Ram, On 01/18/2013 06:25 AM, Ram Rachum wrote: > Can someone who's familiar with Django internals please confirm or deny > the following answer to my question? > > http://stackoverflow.com/a/14369747/76701 That answer is correct. A common situation for evaluating a queryset in a boolean conte

Re: ImageField's “Currently” and “Clear” Sometimes Doesn't Appear

Hi Nick, On 10/30/2012 08:21 AM, Nick wrote: > I posted this question to Stack Overflow a couple weeks ago (link > ) > but have had no responses. I'm guessing it's geared more towards the > Django

Re: Update on localflavor move

On 10/16/2012 04:00 AM, Łukasz Rekucki wrote: > If we include some form of a test runner in every localflvour, I > suspect they will get out of sync quite quickly. Also, I don't think > there is a good reason for duplicating code. David's pull request seems pretty minimal to me - just a three-line

Re: Feature request: collectstatic shouldn't recopy files that already exist in destination

Hi Dan, On 09/27/2012 04:47 PM, Dan Loewenherz wrote: > Just updated the ticket. > > As I commented, the heuristic for checking if a file has been modified > lies in line 282 of collectstatic.py: > > *if not prefixed_path in self.copied_files:* > * > return self.log("Skipping '%s' (already copie

Re: Logging Out with POST by Default?

On 09/20/2012 11:52 AM, Adam Taylor wrote: > I recently read the Coding Horror article Cross-Site Request Forgeries > and You > , > which suggests requiring an HTTP POST form submission for logging out. > This same

Re: Auto-import support for models and other objects in shell

Hi Phill, On 08/28/2012 03:51 PM, Phill Tornroth wrote: > 2. Are you also -1 on making it easier for projects like shell_plus to > add locals to the shell? What's happening right now is pretty > unfortunate. I can only see upside in an adjustment to the internal API > that doesn't make this kind o

Re: Python 3 str.format()

Hi Daniel, On 08/24/2012 09:56 AM, Daniel Swarbrick wrote: > Since Django 1.5 has set the minimum version of Python at 2.6, and in > conjunction with the push to make Django more Python 3 compatible, > should we slowly start migrating to the new format string [1] syntax? > The Python docs state th

Re: Test runner with search

On 06/14/2012 07:25 AM, Jannis Leidel wrote: > On 14.06.2012, at 12:35, Chris Wilson wrote: >> Hi all, >> >> I've made some improvements (in my view) to the >> DjangoTestSuiteRunner. I got tired of having to remember my test >> class names and of typing so much: >> >> ./manage.py test binder.Bi

Re: ModelForms and the Rails input handling vulnerability

On 06/13/2012 06:12 PM, Doug Blank wrote: > On Wed, Jun 13, 2012 at 5:05 PM, Carl Meyer wrote: >> On 06/13/2012 02:55 PM, Peter wrote: >>> Can I throw in option 5: >>> >>> We leave ModelForms as they are, but emit a warning if you only >>> partia

Re: ModelForms and the Rails input handling vulnerability

Hi Peter, On 06/13/2012 02:55 PM, Peter wrote: > Can I throw in option 5: > > We leave ModelForms as they are, but emit a warning if you only > partially render the form? > > I'm not sure how feasible this is, but presumably we could keep track of > which fields have been rendered for a given fo

Re: ModelForms and the Rails input handling vulnerability

On 06/13/2012 12:57 PM, Anssi Kääriäinen wrote: > The point is the same form with the same fields can be used in > multiple places. There is no need for dynamic addition and removal of > fields in Python code. The dynamism is in which fields to display - > not which fields the form contains. You re

Re: ModelForms and the Rails input handling vulnerability

Hi Luke, Thanks for identifying this issue and continuing to push for a resolution. On 06/12/2012 05:16 PM, Luke Plant wrote: > == Option 1: This is the least secure, but most convenient - you have > several ways to specify which fields should be editable, you can use > whichever you like. "We're

Re: ModelForms and the Rails input handling vulnerability

Hi Anssi, On 06/13/2012 12:08 AM, Anssi Kääriäinen wrote: > On 13 kesä, 02:16, Luke Plant wrote: >> For the record, I brought up the issue initially, and favour the most >> secure of the options outlined below, but I'll try to summarise with as >> little bias as I can! > >> = Option 1: Leave thi

Re: Proposed Field API additions

Hi Andrew, On Thursday, June 7, 2012 11:17:51 AM UTC-6, Andrew Godwin wrote: > > - Requiring that all fields expose a method which says how to > reconstruct them. > > Essentially, it returns the positional and keyword arguments you would > have to pass into the constructor to make the field ag

Re: Django's CVB - Roadmap?

On 06/05/2012 08:12 AM, Donald Stufft wrote: > In order to do this with FBV's i'd either need to modify the existing > FBV to accept > a parameter that says if it should filter by logged in user or not or > copy/paste > the code into a new FBV. Not true, you can also have a function view that r

<    1   2   3   4   5   6   7   8   >