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.

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,

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

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

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 <c...@oddbird.net> 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 &

Re: Settings: lists or tuples?

On 12/17/2014 04:57 PM, Ryan Hiebert wrote: > >> On Dec 17, 2014, at 5:48 PM, Carl Meyer <c...@oddbird.net> wrote: >> >> On 12/17/2014 04:39 PM, Russell Keith-Magee wrote: >>> >>> I agree that lists are preferable to tuples. >>> >>> O

Re: Settings: lists or tuples?

On 12/17/2014 04:39 PM, Russell Keith-Magee wrote: > On Thu, Dec 18, 2014 at 5:03 AM, Aymeric Augustin < > aymeric.augus...@polytechnique.org> wrote: > >> On 17 déc. 2014, at 21:54, Carl Meyer <c...@oddbird.net> wrote: >> >>> So I think there is a b

Re: Settings: lists or tuples?

On 12/17/2014 01:48 PM, Aymeric Augustin wrote: > I’m about to introduce a new setting that is a sequence of things, TEMPLATES, > and I have to decide whether it will be a tuple of a list. > > Unfortunately Django is very inconsistent in the type of settings. In > global_settings.py: > > - 22

Re: Experimental APIs DEP

On 12/07/2014 04:37 PM, Russell Keith-Magee wrote: > For my money, the role of this policy change isn't to introduce > instability into Django's process. The role is to give us permission to > introduce features which we might not otherwise land (or might delay in > landing) due to fears over

Re: Experimental APIs DEP

On 12/07/2014 04:37 PM, Russell Keith-Magee wrote: > To my mind, the role of this new status is closer to "provisional", > rather than "experimental". It's a recognition of the fact that no > matter how many times we ask for pre-release testing, the first *real* > test of any API is when it sees

Re: Experimental APIs DEP

On 12/06/2014 07:24 PM, Andrew Godwin wrote: > My notes from the meeting say "experimental API language", so I may have > taken an adjective too literally when I made this. > > Nevertheless, the key thing _I_ want to see is for us to commit to > putting release notes out for some of Django's APIs

Re: Experimental APIs DEP

Hi Andrew, Thanks for putting together this proposal. On 12/05/2014 09:32 PM, Andrew Godwin wrote: > One of the results of discussions at Django Under The Hood was support > for the idea of marking APIs "experimental" - that is, document them and > include them in mainline Django releases, but

Re: delegating our static file serving

On 12/04/2014 10:33 PM, Collin Anderson wrote: > Hi All, > > I'm pretty interested in getting secure and _somewhat_ efficient static > file serving in Django. > > Quick history: > 2005 - Jacob commits #428: a "static pages" view. Note that this view > should only be used for testing!" > 2010

Re: Should annotations allow model field constraints?

On 12/04/2014 11:15 PM, Anssi Kääriäinen wrote: > On Thu, 2014-12-04 at 18:04 -0800, Josh Smeaton wrote: > >> >> I've implemented https://github.com/django/django/pull/3655/ which >> effectively ignores the max_digits and decimal_places arguments in the >> base expression class. Subclasses are

Re: Adding model managers to migrations

Hi Markus, On 12/05/2014 11:22 AM, Markus Holtermann wrote: > Ticket: https://code.djangoproject.com/ticket/23822 > Pull Request: https://github.com/django/django/pull/3687 > > Hey folks, > > As of now migrations don't expose the model managers to models. Thus it is > "impossible" to use e.g.

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

On 11/30/2014 05:54 AM, tomv wrote: > It's important to note that right now, index names are not re-creatable in > retrospect. They rely on the names of models and fields, that are free to > be renamed. So a complete rethink will be needed if introspection can no > longer be used for

Re: Adding hard dependencies to Django's test suite

On 11/27/2014 06:42 PM, Tim Graham wrote: > There have been some proposals to add new dependencies in Django's test > suite: > > 1. #23289 - unittest.mock > (included in Python 3.3+; a backport version would need be installed > when testing on Python

Re: delegating our static file serving

On 11/28/2014 07:15 AM, Tim Graham wrote: > Berker has worked on integrating gunicorn with runserver > so that we might be able to > deprecate our own homegrown webserver. Windows support for gunicorn is > supposedly coming soon >

Re: Make deconstructible classes forwards compatible

Hi Markus, On 11/21/2014 05:35 AM, Markus Holtermann wrote: > As of now (Django 1.7.x and master) the migration writer serializes > classes like the CreateModel operation with kwargs and not args. > Which is the right way to do. However, as soon as Django changes some > of these operations'

Re: DB Migrations: Proposed fix for "Index name collisions after objects are renamed then re-created"

On 11/20/2014 11:07 AM, Andrew Godwin wrote: > (also, I had an idea on the way back that perhaps we could derive the > random element from the migration name, making it different across > different migrations so they don't clash but still the same across runs, > but I'm not sure how you'd access

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

I don't think that spreading add_error to more places really helps with the "more than one way to do it" issue - raising ValidationError isn't going anywhere as documented public API. It's still the simplest thing to do from a clean_field method, or if you want the error in non_field_errors. I

Re: Handling "Save with update_fields did not affect any rows"

Hi Jeroen, On 11/20/2014 02:43 AM, Jeroen Pulles wrote: > I'm still wondering what's best for save_table to do. Pre-1.6 Django > code would end up with a new object in my situation, and no complaints. > Apparently, that worked, for me. I'm inclined to think that is still > what I want for the

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

On 11/18/2014 12:34 PM, Alasdair Nicol wrote: > On 17/11/14 16:53, Carl Meyer wrote: >> (Personally I think it would be better to document the same technique >> for both Model.clean() and Form.clean(), because I don't think >> Form.add_error() is significantly easier,

Re: Handling "Save with update_fields did not affect any rows"

Hi Jeroen, On 11/18/2014 10:12 AM, Jeroen Pulles wrote: > On Tuesday, November 18, 2014 5:00:06 PM UTC+1, Carl Meyer wrote: > > Hi Jeroen, > > On 11/18/2014 08:44 AM, Jeroen Pulles wrote: > > the model.save() arguments `force_update` and `updat

Re: Handling "Save with update_fields did not affect any rows"

Hi Jeroen, On 11/18/2014 08:44 AM, Jeroen Pulles wrote: > the model.save() arguments `force_update` and `update_fields` cause an > explicit check if the update statement matched any rows. > > Every once in a while one of my applications runs into a "race > condition" where one process does an

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

Hi Alasdair, On 11/17/2014 09:05 AM, Alasdair Nicol wrote: > Ticket #16986 (Model.clean cannot report errors on individual fields) > was fixed in Django 1.7, but the new feature is not documented. The > Model.clean() docs still state: > >> Any ValidationError exceptions raised by Model.clean()

Re: Multiple template engines for Django - week 4 - DEP ready for review!

On 11/06/2014 01:14 PM, Aymeric Augustin wrote: >> On 6 nov. 2014, at 01:31, Carl Meyer <c...@oddbird.net> wrote: >> >> Seeing the `OrderedDict` syntax in the example in the latest PEP update >> made me sad. > > I’m convinced. > > I had an interesting

Re: Multiple template engines for Django - week 4 - DEP ready for review!

On 11/05/2014 05:16 PM, Tim Graham wrote: > Nice work on the DEP. I tend to agree with Carl that I like a 'NAME' key > in TEMPLATES rather than requiring the use of OrderedDict, but I can > also see why you don't. I think it might simply the implementation if > TEMPLATES was always a list of

Re: Multiple template engines for Django - week 4 - DEP ready for review!

Hi Collin and Aymeric, On 11/03/2014 03:26 PM, Aymeric Augustin wrote: > Hi Collin, > > It’s exactly the right time to discuss APIs :-) > > After pondering your proposal, I'm still +0 on consistency with > DATABASES and CACHES, but I'll make that change if other people agree > with you. Does

Re: Multiple template engines for Django - week 4 - DEP ready for review!

Hi Aymeric, Great work! I'm afraid that my review comments are lengthy. Feel free to suggest that I provide them in some other format (issues and/or PRs on https://github.com/aaugustin/mtefd ?) if that would be more useful. * In the rationale section, it may be worth mentioning the specific

Re: cursor.callproc()

> On Oct 22, 2014, at 5:56 PM, Shai Berger <s...@platonix.com> wrote: >> On Wednesday 22 October 2014 19:35:49 Carl Meyer wrote: >>> On 10/21/2014 04:04 PM, Shai Berger wrote: >>> I'd argue that in the common case, the user shouldn't care if the >>>

Re: cursor.callproc()

Hi Shai, On 10/21/2014 04:04 PM, Shai Berger wrote: > On Monday 20 October 2014 21:26:50 Carl Meyer wrote: >> Hi Marc, >> >> On 10/19/2014 12:54 AM, Marc Tamlyn wrote: >>> I guess now with migrations we have a nice way of running the SQL >>> against the d

Re: cursor.callproc()

Hi Chris, On 10/22/2014 09:05 AM, Chris Foresman wrote: > Good points. I went looking for `callproc()` documentation and couldn't > find anything useful, which if I understand correctly is part of the > reason this thread started. So +1 on documenting it! > > The most complicated part of dealing

Re: cursor.callproc()

On 10/20/2014 12:26 PM, Carl Meyer wrote: > On 10/19/2014 12:54 AM, Marc Tamlyn wrote: >> I guess now with migrations we have a nice way of running the SQL >> against the database to create the stored procedures. >> >> However if we plan to make this a public A

Re: cursor.callproc()

Hi Marc, On 10/19/2014 12:54 AM, Marc Tamlyn wrote: > I guess now with migrations we have a nice way of running the SQL > against the database to create the stored procedures. > > However if we plan to make this a public API, it should be a nice one. > Something along the lines of

Re: Django detects HTTP Accept-Language header in case-sensitive manner

Hi Wayne, On 10/20/2014 04:59 AM, Wayne Ye wrote: > Hi Carl, > Thanks for the encouragement! > I've created a new ticket in > Trac: https://code.djangoproject.com/ticket/23689#ticket, could you > please kindly take a look, feel free to revise it if I missed anything, > and change the triage

Re: Django detects HTTP Accept-Language header in case-sensitive manner

On 10/16/2014 09:41 PM, Wayne Ye wrote: > HI Carl and Ramiro, > Thank you both very much for tracking this issue! > > Actually I am a junior Django developer (but has nearly 10 years exp on > ASP.NET and RoR), I am eager to contribute to the Django project! If > this issue has not yet been

Re: permissions and groups data migration

On 10/15/2014 06:52 AM, Michael wrote: > Also, ContentType.objects.get_for_model does not work ('Manager' object > has no attribute 'get_for_model'). Not sure, but it might work to instead call `django.contrib.auth.management.create_permissions(...)` in the migration? You'll need to get hold of

Re: Django detects HTTP Accept-Language header in case-sensitive manner

Hi Ramiro, On 09/27/2014 06:13 AM, Ramiro Morales wrote: > The names of directories with translations on disk are actually GNU > gettext locale names[1] as opposed to language names[1] (the ones in > the Accept-Language HTTP header and discussed above.) > > It does specify that the part after

Re: RFC: "UPSERT" in PostgreSQL

On 09/29/2014 01:56 AM, Anssi Kääriäinen wrote: > I think we could use UPSERT for our .save() logic. Django's save() > method is defined as: > - Insert a row in to the database if there isn't already a matching > row for the saved model's primary key > - Otherwise update the row > > This is

Re: Django detects HTTP Accept-Language header in case-sensitive manner

Hello Wayne, On 09/26/2014 01:58 AM, Wayne Ye wrote: > I noticed on small defect here while I was testing my django website's > I18N/L10n, basically below are example Accept-Language headers sent by > Chrome and Firefox (all latest version): > > Chrome: Accept-Language:

Re: mod_security SQL injection rules and Django cookies

Hi Nikolai, On 09/19/2014 05:50 AM, Nikolai Prokoschenko wrote: > the people responsible for the Apache part of our Django application > have recently introduced a policy for mandatory use of mod_security with > OWASP ruleset. The SQL injection rule [1], has raised their attention, > because it

Re: Should reverse() return a Unicode string?

Hi Jon, On 09/18/2014 02:01 PM, Jon Dufresne wrote: > In my Django application, I'm making a strong attempt to always deal > with Unicode strings at the application layer. Byte strings are only > handled at the protocol layer -- sending data out on the "wire". If my > application tests if an

Re: Fwd: Django 1.7 polymorphism error

Hi Thiago, On 09/18/2014 08:51 AM, Thiago Avelino wrote: > I think I found a error polymorphism in django 1.7, field slug exist in > _meta.fields and run filter return error "FieldError: Cannot resolve > keyword 'slug' into field. Choices". > > Example:

Re: Django 1.7 migrations and third-party imports

Hi Greg, On 09/09/2014 03:00 PM, Greg Brown wrote: > Moving over to the new migrations, I noticed that whenever I > create a migration involving a custom model field, it imports that field > at the top of the migration. The South docs were always quite firm about > not doing this sort of thing,

Re: The greatest proposal yet: rename this damn group

On 09/08/2014 08:56 AM, Aymeric Augustin wrote: > 2014-09-08 16:21 GMT+02:00 Thomas Leo >: > > +1 for django-contributors > > > That would be "Django Contributors" since we're talking about changing > the display name of the group, not its email

Re: Setting dictionaries (was Re: integrating django-secure)

On 09/05/2014 03:11 PM, Marc Tamlyn wrote: > Yup, that works. The issue is that most users never explicitly call > django.setup(), so they need to know how to modify manage.py and wsgi.py > to do > > conf = MyProjectConfig() > django.setup(conf) > > > In the case of wsgi.py this isn't too

Re: Setting dictionaries (was Re: integrating django-secure)

On 09/05/2014 02:54 PM, Marc Tamlyn wrote: > I like the idea Russ - from a brief peruse of the code base it's > apparently to me how disparate the handling of various "setup" settings > is throughout the codebase. For example: > > INSTALLED_APPS is handled by django.setup() and Apps.populate()

Re: Setting dictionaries (was Re: integrating django-secure)

Hi Ryan, On 09/05/2014 12:02 PM, Ryan Hiebert wrote: > ​I'd like to see the email settings get moved into a dictionary so that > I can use a single environment variable to configure it very easily, ala > dj-database-url. There's dj-email-url right now, but it requires 7 lines > to configure

Re: Setting dictionaries (was Re: integrating django-secure)

Hi Russ, On 09/05/2014 10:38 AM, Russell Keith-Magee wrote: > The other way to resolve this would be to rethink the way Django starts up. > > Settings like MIDDLEWARE_CLASSES have always struck me as being a little > odd - they're not really settings, they're a way to configure the way > code

Re: Models inside test folder - Django 1.7 problem

On 09/04/2014 08:53 AM, galozek wrote: > I'm trying to port my project to Django 1.7. Every goes fine except 1 > problem with an abstract model testing. > Django 1.7 runs migrate command while testing. That means models not > included in migrations are omitted. That's the issue I've got. > > What

Re: proposing max line length of 119 + enforcing it with flake8

On 09/03/2014 01:47 PM, Tim Graham wrote: > Ticket #23395 raised the > issue that our contributing guidelines is not exactly clear regarding > long lines. Currently it says, > > "One big exception to PEP 8 is our preference of longer line lengths. >

Re: integrating django-secure

On 09/01/2014 02:34 PM, Michael Manfre wrote: > On Mon, Sep 1, 2014 at 2:12 PM, Aymeric Augustin > > wrote: > > If we recommend HSTS, we need visible warnings and a small duration > in examples, for people

Re: integrating django-secure

On 09/01/2014 11:31 AM, Erik Romijn wrote: [snip] > So, although I encourage anyone to enable HSTS, we should not recommend > people to just "switch it on". They should be well aware of the > consequences as it can affect an unknown set of users beyond their > Django site, long after the change

Re: integrating django-secure

Hi Claude, On 08/31/2014 12:08 PM, Claude Paroz wrote: > The situation about multiple user settings file is absolutely not > changed by that patch. If you import from a parent settings file, it's > still your choice to either overwrite the dictionary or update it, no > magics happen at all at

Re: integrating django-secure

On 08/30/2014 07:28 PM, Tim Graham wrote: > If we drop magical merging of dictionary settings (which seems like it > will cause more confusion), a user's options for customizing a single > key in settings are: > 1. Redefine the entire dictionary in a project's settings > 2. Use the following

Re: integrating django-secure

I was initially indifferent about putting the django-secure settings in a dictionary, but the more I've thought about the more I feel Collin is correct; there is no real benefit (just an arguable sense of "tidiness") and there are several negatives (more verbosity in documentation, check warnings,

Re: integrating django-secure

On 08/28/2014 06:44 AM, Tim Graham wrote: > I've implemented the ability to register "deployment checks" by adding > deploy=True to register: @register("tag_name", deploy=True). These > checks are only run if you pass the --deploy flag to check. So in > development you can run `manage.py check

Re: Requiring GitHub login for actions on Trac

+1 from me. I don't see a problem with supporting only GitHub OAuth in this case. Django is hosted on GitHub, and any code contribution (which is ultimately what Trac is all about) will happen via GitHub, so it seems quite natural to me to support GitHub OAuth rather than any other arbitrary

Re: Proposal: Use timestamp or hash to determine name when uploading duplicate filenames

On 08/05/2014 03:42 AM, Areski Belaid wrote: > I also agree with you that custom storage will be more elegant solution. > > On the other hand it seems to me that reusing the same file on upload > will not allow a clean management of user's resources, for instance if a > user decide to delete a

Re: Updating the organization of the Django Project

Hi Christian, On 08/01/2014 01:37 PM, Schmitt, Christian wrote: [snip] > i mean maybe we should really look at a review tool and maybe say if two > people of the community reviewed it gets pipelined to the "core" which > can do a final review. so it would be more community oriented and fewer >

Re: 1.7 release status (RC2 coming soon)

On 07/25/2014 09:17 AM, Ryan Hiebert wrote: > On a somewhat-related tangent, I seem to recall there being a good > reason for not releasing pre-release versions on PyPI, but I’m having > trouble finding the discussions that document that reason. Anybody > care to enlighten me, or give me a link?

Re: Updating the organization of the Django Project

+1 Carl On 07/23/2014 07:29 AM, Aymeric Augustin wrote: > Hello, > > I've been working on updating our organization: > https://github.com/django/django/pull/2947 > > This proposal attempts to address several issues with our current > organization. There's no short version and any simplistic >

Re: modelformset_factory and unique_together don't always validate unique fields

Hi Jon, On 07/02/2014 09:06 PM, Jon Dufresne wrote: > I'm reporting this to the developers list as I feel this shows a > shortfall in (to me) expected behavior. I'm not sure this is exactly a > bug or simply a use case the unique validation wasn't designed for. > > Basically, sometimes I want to

Re: Regression in ValidationError in 1.7

On 06/27/2014 06:41 AM, Russell Keith-Magee wrote: > > On Fri, Jun 27, 2014 at 7:35 PM, Curtis Maloney > > wrote: > > Am I reading this right as "people used to commonly solve this > problem by using an internal API, but now

Re: Building a library of SQL functions into Django

On 06/18/2014 04:41 PM, Chris Wilson wrote: I think database backends should have a hook to override the SQL implementation of any given Function. I don't think this needs to imply pushing the default implementation of all Functions down into the database backend (that just

Re: Building a library of SQL functions into Django

Hi Chris, On 06/18/2014 03:55 PM, Chris Wilson wrote: > Hi Carl, > > On Wed, 18 Jun 2014, Carl Meyer wrote: >> On 06/18/2014 02:59 PM, Aymeric Augustin wrote: >>> 2014-06-18 19:18 GMT+02:00 Carl Meyer <c...@oddbird.net >>> <mailto:c...@oddbird.net>

Re: Building a library of SQL functions into Django

On 06/18/2014 02:59 PM, Aymeric Augustin wrote: > 2014-06-18 19:18 GMT+02:00 Carl Meyer <c...@oddbird.net > <mailto:c...@oddbird.net>>: > > If you need a Function in your > project (whether provided by Django or by a third-party library), and > the Fun

Re: Building a library of SQL functions into Django

he other available options. Carl > Personally, I happy with the current API design now we have AppConfigs > as a way for third party backends to officially monkeypatch Django - > though I can see the arguments that this in itself seems like poor API > design. > > Marc >

Re: Building a library of SQL functions into Django

On 06/18/2014 08:08 AM, Marc Tamlyn wrote: > Worth noting that Lookups now have exactly the same as_vendor API. The > registration API simply allows you to overload the lookup table with a > subclass rather than just monkeypatching. > > This is harder here are the classes are used directly. We

Re: Why not Single Table Inheritance?

On 05/16/2014 04:46 AM, Shai Berger wrote: > On Monday 12 May 2014 12:27:01 Thomas Güttler wrote: >> Single Table Inheritance is used by ruby-on-rails and SQLAlchemy. >> >> Are there reasons why it is used in django? >> > > Essentially, STI is a form of database denormalization. I think Django

Re: Proposal: Write unit tests for JavaScript

On 04/16/2014 07:20 PM, Russell Keith-Magee wrote: > On Thu, Apr 17, 2014 at 5:57 AM, Trey Hunner > wrote: > > I saw a previous discussion about JavaScript testing in Django but > it looks like there hasn't been any progress in a few

Re: Proposal: document and enforce style of all files (including JS, CSS, HTML)

On 04/16/2014 07:08 PM, Russell Keith-Magee wrote: > Sounds like a reasonable proposal to me. Our JavaScript code has… > evolved, shall we say… over the years. We've recently started enforcing > Flake8 compliance on our Python codebase; adopting similar rigour for > our JavaScript code would seem

Re: [GSOC] Shifting to Py.Test and Improving the Test Suite

Hi Chris, Just a couple notes to set the record straight: On Sunday, April 6, 2014 1:02:18 PM UTC-4, Chris Wilson wrote: > > Hi Andrew, > > I'm not a Django core contributor but just a user and occasional patcher. > I submit some comments on this proposal in the hope that they will be >

Re: LiveServerTestCase vs StaticLiveServerCase

On 03/30/2014 06:02 AM, Harry Percival wrote: > In that case, maybe the question is: which should be the default? > > Given that, as you say, most people use staticfiles, it feels to me like > the test case in which static files "just work", without having to > remember to run `collectstatic`

Re: LiveServerTestCase vs StaticLiveServerCase

On 03/29/2014 02:36 PM, Shai Berger wrote: > On Saturday 29 March 2014 19:11:17 Harry Percival wrote: >> >> What I *am* saying is that, in my opinion, there's not much point in >> LiveServerTestCase if it doesn't do static files. So, to keep things >> simple, it would be simpler to remove it, and

Re: Saving forms without validation, and formsets

On 03/19/2014 06:58 AM, Chris Wilson wrote: >> This requires overrides of a few methods on the parent form: __init__() >> to create the formsets, is_valid() to ensure the formsets are valid too, >> has_changed() to see if formsets have changed, and save() to save >> formsets too. > > There's a

Re: Saving forms without validation, and formsets

Hi Chris, I've definitely faced similar issues. A few scattered thoughts below: On 03/18/2014 02:54 PM, Chris Wilson wrote: [snip] > 1. GCBV and Vanilla Views do a great job for simple forms, but they > leave out embedded formsets entirely. (For example our large form has > repeating sections

Re: Add support for get_or_none?

On 03/14/2014 09:50 AM, Michael Manfre wrote: > On Fri, Mar 14, 2014 at 11:15 AM, Cal Leeming [Simplicity Media Ltd] > > wrote: > > > .get(or=None) (of some description) would be my preference, but >

Re: An improved settings.py configuration (revisited)

Hi Vernon, On 03/07/2014 07:44 PM, VernonCole wrote: > Several months ago, I floated an idea on this forum for re-structuring > the settings.py environment. > > It generated a fair amount of discussion. The consensus was that > something really ought to be done, but no one was sure just what.

Re: [GSoC] Switching to Jinja2 proposal

Hi Christopher, On 02/15/2014 09:43 AM, Christopher Medrela wrote: > What I'm proposing now is more conservative proposal. Firstly, Django will > support Jinja2 out-of-the-box, but DTL will remain the "blessed" option. > Secondly, Django will allow to mix DTL and Jinja2 templates (so you can >

Re: [GSoC] Switching to Jinja2 proposal

Hi Russ, On 02/15/2014 05:16 PM, Russell Keith-Magee wrote: > a) Some of us prefer DTL to Jinja2 :-) Just as a point of clarification: have you used Jinja2 for a non-trivial project, and are there specific areas where you, personally, for your own use, prefer how you do something in DTL vs how

Re: [GSoC] Switching to Jinja2 proposal

On 02/12/2014 02:25 PM, Curtis Maloney wrote: > On 12 February 2014 21:29, Gwildor Sok One downside I can think of is that Jinja does not escape variables > by default, which might become a XSS security issue. > > That's quite a large downside! Jinja2 supports

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

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 > > wrote: > > Why not switching to Jinja2? I thought that somebody else proposed > this idea > but

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

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

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,

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.

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

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

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" flag,

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 <c...@oddbird.net> wrote: > >> I very much hope >> that moving the admin autodiscovery to the admin AppConfig still allows >> some reasonable path to opt-out of autodis

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

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 <ca...@oddbird.net > > wrote: > > > Those interested in this feature may find django-transac

<    1   2   3   4   5   6   7   >