Re: Development GUI

2012-09-06 Thread Alec Taylor
Hi Timothy, Not sure where you're going with this… but sounds interesting. [watching] -> looking forward to some sample code + whatever in the Readme :) On Fri, Sep 7, 2012 at 11:38 AM, Timothy Clemans wrote: > Hi, > > I'm developing a web-based development GUI for

Re: Improve Django markdown rendering.

2012-09-06 Thread ptone
On Thursday, September 6, 2012 10:48:30 PM UTC-4, waylan wrote: > > If instead, improvements are only going to be made to the markdown > filter, then I would suggest a complete overhaul allowing access to > all of markdown's features [2]. > In fact the plan is to deprecate the markup contrib

Re: Improve Django markdown rendering.

2012-09-06 Thread Donald Stufft
https://bitbucket.org/ionata/django-bleach On Thursday, September 6, 2012 at 10:48 PM, Waylan Limberg wrote: > On Thu, Sep 6, 2012 at 8:22 PM, Thomas Purchas (mailto:tpurc...@gmail.com)> wrote: > > I have submitted a path to improve the way Django handles html in

Re: Development GUI

2012-09-06 Thread ptone
This falls pretty squarely in the category of 3rd party project in the Django ecosphere. While it is a tool oriented for Django, it would not be part of what Django itself does as a web framework. -Preston On Thursday, September 6, 2012 9:38:24 PM UTC-4, Timothy Clemans wrote: > > Hi, > >

Improve Django markdown rendering.

2012-09-06 Thread Thomas Purchas
I have submitted a path to improve the way Django handles html in markdown. Specifically how it escapes it. Ticket 6526 has all of the detail, could someone please review my patch. Thanks in advance. -- You received this message because you are

Re: Backporting some Python 3 support features to 1.4.x?

2012-09-06 Thread Luke Plant
On 06/09/12 19:09, Aymeric Augustin wrote: > Now we have two alternatives: > 1) tell them to roll their own compat or wait until they can target 1.5 > + 1.6 — quite a downer, > 2) add some forwards compatibility tools to 1.4. > > We generally don't add features to minor releases, but there's a >

Re: Testing multidb with TEST_MIRROR

2012-09-06 Thread Anssi Kääriäinen
On 7 syys, 01:10, Jeremy Dunck wrote: > Well that is pretty damn awesome.  It also doesn't fix my problem. > Let's ignore my problem for now, though.  I'd like to look at the > diffs.  I doubt this is the real >

Re: Testing multidb with TEST_MIRROR

2012-09-06 Thread Anssi Kääriäinen
On 7 syys, 00:35, Andrew Godwin wrote: > That's an incredible speedup - I've had a quick look over the patch, and it > looks to be doing all the right things, so I'd definitely be behind merging > this in. Have you tried running the test runner over some third-party apps' >

Re: Testing multidb with TEST_MIRROR

2012-09-06 Thread Donald Stufft
On Thursday, September 6, 2012 at 6:10 PM, Jeremy Dunck wrote: > What's the base branch for the fast_tests_merged comparison? https://github.com/akaariai/django/compare/django:master...fast_tests_merged -- You received this message because you are subscribed to the Google Groups "Django

Re: Testing multidb with TEST_MIRROR

2012-09-06 Thread Jeremy Dunck
On Thu, Sep 6, 2012 at 12:16 PM, Anssi Kääriäinen wrote: > On 3 syys, 07:40, Anssi Kääriäinen wrote: >> I would like to make the TransactionTestCase faster. Currently when >> running Django's test suite, for every test ran you will truncate >>

Re: Testing multidb with TEST_MIRROR

2012-09-06 Thread Andrew Godwin
That's an incredible speedup - I've had a quick look over the patch, and it looks to be doing all the right things, so I'd definitely be behind merging this in. Have you tried running the test runner over some third-party apps' tests to make sure it works? I suspect South's/migrations' might get

Re: Backporting some Python 3 support features to 1.4.x?

2012-09-06 Thread Andrew Godwin
I'm definitely +1 on this - I have a few codebases I want to start converting but also want to keep running on 1.4, and the patch looks sensible to me. There is precedent for this, and even if there wasn't, this is a nice way to get the migration cycle started. Andrew On Thu, Sep 6, 2012 at 3:05

Re: Testing multidb with TEST_MIRROR

2012-09-06 Thread Anssi Kääriäinen
On 6 syys, 19:17, Anssi Kääriäinen wrote: > I now have a pretty good WIP approach of tracking changes in testing. > The changes can be found from here: [https://github.com/akaariai/ > django/tree/fast_tests_merged]. The approach relies on existing > signals + a new

Re: Backporting some Python 3 support features to 1.4.x?

2012-09-06 Thread Donald Stufft
Just as an additional aside, the apps can also depend on the actual six library itself instead of Django's embedded version (It could be an optional dependency on Django < 1.5). The major things I think would be anything Django specific that don't come from six. On Thursday, September 6, 2012

Re: Backporting some Python 3 support features to 1.4.x?

2012-09-06 Thread Mark Lavin
Hi, I am one such author and I wanted to share my experience. I have ported my code and test suites for 3 applications to run on Django 1.3-1.5dev and Python 2.6, 2.7 and 3.2 (1.5dev only). Those are https://github.com/mlavin/django-responsive, https://github.com/mlavin/django-ad-code and

Backporting some Python 3 support features to 1.4.x?

2012-09-06 Thread Aymeric Augustin
Hello, Several people have started porting their apps for Python 3, but they're running into trouble when they try to support both Django 1.4 and master. They end up with regrettable patterns such as: try: from django.utils.six import PY3 except ImportError: PY3 = False Authors of

Re: Testing multidb with TEST_MIRROR

2012-09-06 Thread Anssi Kääriäinen
On 3 syys, 07:40, Anssi Kääriäinen wrote: > I would like to make the TransactionTestCase faster. Currently when > running Django's test suite, for every test ran you will truncate > around 1000 tables, then create around 4000 objects (permissions + > content types).

Re: Moving forward with Serialization.

2012-09-06 Thread Tom Christie
Thanks Piotr, > But when serializing also Field is saved with data so it's not so clean. I'm not sure whether it's an issue or not. As with Django's form fields, the fields are copied off of base_fields, so saving state isn't necessarily a problem. I'd agree that it's possibly not the

Re: RawQuerySet as subquery when used with an __in filter

2012-09-06 Thread Alex Hill
Hi Anssi, Thanks for your feedback! Responses inline. 1. It should not be assumed that the primary key is the field needed > in the inner query. We do have foreign keys to other fields, and one > can use this approach without foreign keys at all. Hmm, yes. Thinking about it, this seems