Re: extra files in startproject

On 04/12/2012 03:27 PM, Alex Ogier wrote: > That seems like too much to ask. "setup.py install" should Just > Work(tm), and if django requires that a certain directory be clean of > any .py files in order to function properly then "setup.py install" > should make that happen. The note might still b

Re: extra files in startproject

Hi Alex, On 04/12/2012 04:23 PM, Alex Ogier wrote: > On Apr 12, 2012 6:16 PM, "Carl Meyer" <mailto:c...@oddbird.net>> wrote: >> The correct solution is to warn people away from using installation >> techniques in ways they were not intended to be used, and that

Re: extra files in startproject

Hi Alex, On 04/12/2012 10:49 PM, Alex Ogier wrote: > The problem is that not everyone uses package managers. A reasonable > way to track django trunk for example is to periodically pull and run > "setup.py install" which is in most cases approximately idempotent. I > have seen setup.py's that use

Re: extra files in startproject

On 04/13/2012 08:30 AM, Daniel Sokolowski wrote: > People won’t always read all the docs – it’s a fact – so sooner or later > some other new comer will experience this issue complain, gave up and > worse even blog his/hers negative experience. We do want the newbie > experience to be as painless as

Re: extra files in startproject

On 04/13/2012 08:33 AM, Carl Meyer wrote: > Thanks Daniel. I'm experimenting right now with a patch to setup.py that > would print a loud warning to console if it detects an existing django/ > directory in the target site-packages. I've filed a pull request (https://github.com

Re: Revised revised form rendering

Hi Mikhail, On 03/29/2012 01:31 PM, Mikhail Korobov wrote: > GSoC'11 Gregor Müllegger's and Carl Meyer's project (Revised form > rendering) seems to get stuck because of performance issues. > > Question 1. Am I understand this correctly and the limiting factor is > the template rendering speed?

Re: Migrating to 1.4

Since it seems that the additional test-suite runtime from the new default password hasher is enough to be a blocker for migrations to 1.4 in some cases, I've opened a ticket for documenting this workaround: https://code.djangoproject.com/ticket/18157 Carl signature.asc Description: OpenPGP dig

Re: Django use of stdlib HTMLParser "internals"

Hi Vinay and Aymeric, On 04/28/2012 12:50 AM, Aymeric Augustin wrote: On 28 avr. 2012, at 00:49, Vinay Sajip wrote: From the discussion on python-dev, it seems possible that an optimal fix might require changes both in Python and in Django. Before creating a ticket about this for Django, I wou

Re: GitHub migration done!

Hi Vinay, On 04/30/2012 07:11 PM, Vinay Sajip wrote: On Apr 28, 4:08 am, Adrian Holovaty wrote: * We're going to keep the Subversion repository around indefinitely, but it'll no longer be updated. That means that any mirrors using that repository as a source are also not worth using any mor

Re: GitHub migration done!

On 05/01/2012 12:45 AM, Vinay Sajip wrote: On May 1, 2:19 am, Carl Meyer wrote: Good point. I think which of those happens now depends on whether a motivated someone steps up to figure out how to convert the mirror to use hg-git and source from Git, and then maintain it as needed. I originally

Re: Model forms error messages

Hi Karol, On 05/02/2012 08:13 AM, Karol Sikora wrote: According to my ticket: https://code.djangoproject.com/ticket/18237 and previous one eg.: https://code.djangoproject.com/ticket/13693 I would to discuss wider this case. IMHO redefining field in model form subclass to set custom error message

Re: GitHub migration done!

On 05/02/2012 10:09 AM, Cal Leeming [Simplicity Media Ltd] wrote: Apologies if this question has already been answered or seems silly but - is there a reason Mercurial is needed?? Can contributors not just switch to using git? i.e. if we have deprecated SVN, then why isn't Mercurial also being d

Re: Django git guidelines

Hi Anssi, Thanks for working on git usage guidelines! I very much agree that a pull request should only be created when the contributor considers the branch finished and ready for review and merge (for instance, there should never be a pull request created without the necessary docs and tests). Ha

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

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

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

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

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

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

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

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

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

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

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

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

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 any

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

On 11/04/2014 03:27 PM, Aymeric Augustin wrote: > > 2014-11-03 19:47 GMT+01:00 Carl Meyer <mailto:c...@oddbird.net>>: > > * The description for option 4 implies that ordering of template engines > is only useful if their directories overlap. This is not the

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 dictio

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 wrote: >> >> Seeing the `OrderedDict` syntax in the example in the latest PEP update >> made me sad. > > I’m convinced. > > I had an interesting idea for NAME. It c

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

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

On 11/17/2014 09:48 AM, Tim Graham wrote: > The reasoning for why it wasn't documented is provided here: > https://github.com/django/django/pull/1443#issuecomment-28045150 That comment is actually in favor of documenting it for Model.clean(), just suggested it be done in a separate PR. (Personall

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 upd

Re: Configurable safety options for high performance Django systems

Hi Rick, On 11/18/2014 11:59 AM, Rick van Hattem wrote: [snip] > In all but the most basic Django projects I've seen problems like these. > Sane defaults won't hurt anyone and solves issues for people with larger > systems. And running forks of Django seems counter productive as well. As a side n

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

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 eas

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 upda

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 rea

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 th

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

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

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

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

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

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

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

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 wheth

Re: Proposal: Prevent data loss in the admin

On 12/09/2014 02:16 PM, Rune Kaagaard wrote: > >> >> A whole other issue is how to handle the deletion of already deleted >> objects. >> > I misspoke here. I meant how to handle the deletion of an object with an > outdated version number. Should it raise the same exception? Yes, I think that d

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 s

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 wrote: >> >>> So I think there is a backwards-compatibility issue

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 wrote: >> >> On 12/17/2014 04:39 PM, Russell Keith-Magee wrote: >>> >>> I agree that lists are preferable to tuples. >>> >>> One option for handling

<    1   2   3   4   5   6   7   8   >