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

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

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

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

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

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 <c...@oddbird.net> wrote: >> We already provide the on_delete=DO_NOTHING option for people who >> want to push cascade handling to the database. > > It's better

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

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

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

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

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 > > wrote: > > I've seen enough people in #django suffering because they need a > FKey on a table they simply can't

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

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

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

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,

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

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

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

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:

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

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 >

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

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 >

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 branc

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 <ca...@oddbird.net > > wrote: > >> Hi Russ, >> >> On 05/09/2013 04:51 AM, Russell Keith-Magee wrote: >> > Great work Carl and

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

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

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

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

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

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 sp

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 conten

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

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

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

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

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

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

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

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 <ian.g.ke...@gmail.com> wrote: > On Feb 20, 2013 4:41 PM, "Carl Meyer" <c...@oddbird.net> wrote: > > On 02/20/2013 04:25 PM, Nick Phillips wrote: > > >> There was extensive back-and-forth discussion of

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: GitHub migration done!

On 05/01/2012 12:45 AM, Vinay Sajip wrote: On May 1, 2:19 am, Carl Meyer<c...@oddbird.net> 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 ma

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

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

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

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

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

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

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

Re: extra files in startproject

On 04/12/2012 03:16 PM, Aymeric Augustin wrote: > This problem occurs at least when you run "setup.py install" before > and after the commit that introduced the new project layout. > > Some people who had the habit of running "setup.py install" from a > git clone to keep up-to-date with the

Re: extra files in startproject

Hi Alex, On 04/12/2012 01:07 PM, Alex Ogier wrote: > Maybe it would be worth experimenting with various combinations of > django 1.x django-admin.py executables with django 1.4 libraries? Maybe > if django-admin.py is a symlink into a 1.3 tree but django 1.4 is on the > search path this stuff

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 12:43 PM, Anssi Kääriäinen wrote: > It is important that pre/post init signals will not get more expensive > than they currently are. Even now they can give around 100% overhead > to model.__init__(). And this is in a case where the currently > initialized model has no signals

Re: extra files in startproject (was: Django is not a serious framework, really)

Hi Jason, On 04/11/2012 06:10 AM, Jason Ma wrote: > Hi, > I download and tried to use the Django 1.4 yesterday. I am a dummy > and I just follow the official document, but When I just start a > project. > I found that it is what I see from my computer: > > jason@jason-pc:~/workspace/hunqing$

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 11:02 AM, Javier Guerra Giraldez wrote: > IOW, i think the existing signals are database-related and should be > fired only for the concrete part(s). if the abstract part wants to, > it can send custom signals. Also, it isn't really true that the model signals are strictly tied to

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 10:52 AM, Jeremy Dunck wrote: > On Thu, Apr 12, 2012 at 9:31 AM, Carl Meyer <c...@oddbird.net> wrote: >> There's a discussion ongoing on ticket #18094 >> (https://code.djangoproject.com/ticket/18094) that has enough potential >> back-compat implications

#18094: signals, model inheritance, and proxy models

Hi all, There's a discussion ongoing on ticket #18094 (https://code.djangoproject.com/ticket/18094) that has enough potential back-compat implications that it seems worth getting feedback here. Currently, when you delete a concrete-inheritance child model instance, pre_delete and post_delete

Re: auth.user refactor: the profile aproach

On 04/03/2012 02:34 PM, Daniel Sokolowski wrote: > Correct me if I’m wrong but both LFK or a swappable user model approach > like your fail to address issue of extensibility. If today my project is > authorizing with username and password and tomorrow I wish to add > OpenAuth then my User model is

<    1   2   3   4   5   6   7   >