Re: Schema Alteration update

[Andrew Godwin]

I certainly don't want to tread on anyone's toes - the idea will be that,
like in South currently, migrations will be enabled/disabled on a per-app
basis, so if you don't want them they won't muck stuff up. Alternatively,
we could let the other apps override syncdb.

I'm hoping, in fact, that adding the database backends into core will make
anyone else who is doing custom migration stuff's lives easier - especially
if it's something highly custom internal to a company where you don't have
the time or team to do that stuff properly.

Andrew

On Thu, Oct 11, 2012 at 11:21 AM, Luke Plant  wrote:

> On 28/09/12 08:41, Andrew Godwin wrote:
> > Yeah, I think I mentioned it a couple of times at DjangoCon but perhaps
> > not loudly enough - Jacob and I had a talk at DjangoCon EU where he said
> > he wanted it all in core, and I tend to agree.
> >
> > Preston has had a look at what I'm doing/planning with AppCache and
> > apparently it'll be compatable with what's in app-loading with a little
> > work, which is reassuring.
> >
> > Only remaining question is whether migration-runner (the smarts) should
> > be in contrib or core. I know Alex believes core; I'm split, seeing as
> > some people will want to turn it off (so contrib), but it overrides core
> > commands like syncdb (so core would be cleaner).
>
> I'm very happy with South being in core/contrib, but I am aware of other
> people who use different solutions. It would be nice if we didn't make
> life hard for them. I don't know what that means in practice, but if we
> got feedback from the developers of those other solutions it would be
> good. We might need something like a 'syncdb --ignore-migrations' option.
>
> Luke
>
>
> --
> "Because Your lovingkindness is better than life,
>  My lips shall praise You."  (Ps 63:3)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Tom Evans]

On Thu, Oct 11, 2012 at 2:53 PM, Tom Evans  wrote:
> On Wed, Oct 10, 2012 at 7:52 AM, Moonlight  wrote:
>> Here is an article comparing various URL dispatchers:
>>
>> http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
>>
>> What cause django URL dispatcher that much... slow?
>>
>
> Now that I've looked in detail at the test, it is because the test is
> nonsensical. Each time it tests the URLs, it constructs a fresh WSGI
> application. Each fresh application has to compile each URL in the
> urlconf before using it. It then destroys the application, and starts
> another one up.
>
> In a normal django application, you do not start from fresh on each
> request. This explains why the performance degradation from
> "static[0]" to "static[-1] " - which is the difference between testing
> the first url in the urlconf and the last url in the urlconf - is so
> pathological, each time it is run Django is recompiling each and every
> URL regexp in the urlconf (as well as _all_ other work django does at
> server start).
>
> This is testing something, but it is not testing django as a web
> application, or as Django is intended to be run.
>
> Cheers
>
> Tom

I was wrong, the WSGI app is initialized correctly just once.
Something pathological is happening with this test case, the
performance of the resolver looks decidedly dicey as number of
patterns grows.

Something for the weekend…

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Moonlight]

> FWIW, here's a link to a cProfile result for the mentioned 
> benchmark[1] on Django 1.4.1 and CPython 2.7.3. A quick look shows 
> that we're calling get_language() 1.5mln times (read: for every 
> pattern), so that's definitely going to slow down things. 
>

Happy to see we moved it a bit forward! Well done!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ZnKPiKqj-tgJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: URL dispatcher slow?

[Tom Evans]

On Thu, Oct 11, 2012 at 10:58 PM, Łukasz Rekucki  wrote:
> On 11 October 2012 10:20, Russell Keith-Magee  wrote:
>>
>> And don't just say "Why are Django's URL resolvers slow?". Do some
>> profiling, and come back with an analysis of where the time is being
>> spent and/or wasted.
>
> FWIW, here's a link to a cProfile result for the mentioned
> benchmark[1] on Django 1.4.1 and CPython 2.7.3. A quick look shows
> that we're calling get_language() 1.5mln times (read: for every
> pattern), so that's definitely going to slow down things.
>
> I'll try running the same with 1.3 and maybe 1.4 without the locale
> mixin and post if I find anything interesting.
>
> [1]: https://gist.github.com/3875701
>
>

It definitely doesn't help; ideally language code should be calculated
once per call to resolve, and the same value used throughout.
Hard-coding a value of 'en' for language code in
LocaleRegexProvider.regex gives an idea of what gains would be:

Stock django:

static[0] msecrps  tcalls  funcs
django1583   6318 143 69

static[-1]msecrps  tcalls  funcs
django   208794791934 70


Hard coded 'en' in LocaleRegexProvider.regex:

static[0] msecrps  tcalls  funcs
django1424   7023 133 67

static[-1]msecrps  tcalls  funcs
django4972   2011 929 68

static[0] represents tests matching the first URL in the urlconf,
static[-1] represents tests matching the approximately 100th URL in
the urlconf.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

save() method could return the object

[Chris Wilson]

Hi all,

If the save() method returned the object itself, then we could chain it 
like this:


old_status = Status(last_contact=None).save()

Instead of having to do this:

old_status = Status(last_contact=None)
old_status.save()

It's a trivial one-line change to the Model class and I don't think it 
would break backwards compatibility, as I doubt that anyone is relying on 
the save() method returning None. Should I submit a patch?


Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: save() method could return the object

[David Winterbottom]

While such a change is initially appealing, it violates the command-query
separation principle in that a 'command' method such as 'save' should not
return anything.
http://en.wikipedia.org/wiki/Command-query_separation

Hence, it's not a good idea to make this change.  It's more important to
have clearly purposed methods than saving a line of code.

David


On 12 October 2012 14:25, Chris Wilson  wrote:

> Hi all,
>
> If the save() method returned the object itself, then we could chain it
> like this:
>
> old_status = Status(last_contact=None).**save()
>
> Instead of having to do this:
>
> old_status = Status(last_contact=None)
> old_status.save()
>
> It's a trivial one-line change to the Model class and I don't think it
> would break backwards compatibility, as I doubt that anyone is relying on
> the save() method returning None. Should I submit a patch?
>
> Cheers, Chris.
> --
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
>
> Aptivate is a not-for-profit company registered in England and Wales
> with company number 04980791.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to 
> django-developers@**googlegroups.com
> .
> To unsubscribe from this group, send email to
> django-developers+unsubscribe@**googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/**
> group/django-developers?hl=en
> .
>
>
>


-- 
*David Winterbottom*
Head of Programming

Tangent Labs
84-86 Great Portland Street
London W1W 7NR
England, UK

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: save() method could return the object

[Marijonas Petrauskas]

There already exists create method that does exactly what you need:
obj = SomeModel.objects.create(name='foo', age=42)

On Fri, Oct 12, 2012 at 2:33 PM, David Winterbottom <
david.winterbot...@tangentlabs.co.uk> wrote:

> While such a change is initially appealing, it violates the command-query
> separation principle in that a 'command' method such as 'save' should not
> return anything.
> http://en.wikipedia.org/wiki/Command-query_separation
>
>  Hence, it's not a good idea to make this change.  It's more important to
> have clearly purposed methods than saving a line of code.
>
> David
>
>
> On 12 October 2012 14:25, Chris Wilson  wrote:
>
>> Hi all,
>>
>> If the save() method returned the object itself, then we could chain it
>> like this:
>>
>> old_status = Status(last_contact=None).**save()
>>
>> Instead of having to do this:
>>
>> old_status = Status(last_contact=None)
>> old_status.save()
>>
>> It's a trivial one-line change to the Model class and I don't think it
>> would break backwards compatibility, as I doubt that anyone is relying on
>> the save() method returning None. Should I submit a patch?
>>
>> Cheers, Chris.
>> --
>> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
>> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
>>
>> Aptivate is a not-for-profit company registered in England and Wales
>> with company number 04980791.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to 
>> django-developers@**googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> django-developers+unsubscribe@**googlegroups.com
>> .
>> For more options, visit this group at http://groups.google.com/**
>> group/django-developers?hl=en
>> .
>>
>>
>>
>
>
> --
> *David Winterbottom*
> Head of Programming
>
> Tangent Labs
> 84-86 Great Portland Street
> London W1W 7NR
> England, UK
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[Chris Wilson]

Hi all,

On Thu, 11 Oct 2012, Daniel Moisset wrote:


obj, = SomeModel.objects.filter(foo='bar') or [None]


Daniel's solution is elegant, but far from clear or clean.

I'm strongly in favour of a simple, obvious way to do the common thing, 
which is to return None if the object doesn't exist, instead of throwing 
an exception. My preferred method names would be .nget(), .get_or_none() 
or .first().


May I invoke the Zen of Python to add more than +1 to votes for this 
change? (not that my vote counts anyway, of course :)


+1  Beautiful is better than ugly.
+1  Explicit is better than implicit.
+1  Simple is better than complex.
+1  Flat is better than nested.
+1  Readability counts.
-1  Special cases aren't special enough to break the rules.
+1  Although practicality beats purity.
+1  There should be one-- and preferably only one --obvious way to do
it.
+1  Now is better than never. :)
+1  If the implementation is hard to explain, it's a bad idea. (the
alternative one-liner proposed by Daniel is hard to explain)
+1  If the implementation is easy to explain, it may be a good idea.

+9  Total

Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: save() method could return the object

[Yo-Yo Ma]

+1

A lot of people are overriding ``save`` and not returning anything, but 
this isn't going to hurt them (ideally, they should already be returning 
the result of ``super(``, but nobody does).

On Friday, October 12, 2012 9:25:46 AM UTC-4, Chris Wilson wrote:
>
> Hi all, 
>
> If the save() method returned the object itself, then we could chain it 
> like this: 
>
>  old_status = Status(last_contact=None).save() 
>
> Instead of having to do this: 
>
>  old_status = Status(last_contact=None) 
>  old_status.save() 
>
> It's a trivial one-line change to the Model class and I don't think it 
> would break backwards compatibility, as I doubt that anyone is relying on 
> the save() method returning None. Should I submit a patch? 
>
> Cheers, Chris. 
> -- 
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838 
> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK 
>
> Aptivate is a not-for-profit company registered in England and Wales 
> with company number 04980791. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WkAiV5BsEiEJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: save() method could return the object

[Alex Gaynor]

On Fri, Oct 12, 2012 at 6:36 AM, Yo-Yo Ma  wrote:

> +1
>
> A lot of people are overriding ``save`` and not returning anything, but
> this isn't going to hurt them (ideally, they should already be returning
> the result of ``super(``, but nobody does).
>
>
> On Friday, October 12, 2012 9:25:46 AM UTC-4, Chris Wilson wrote:
>>
>> Hi all,
>>
>> If the save() method returned the object itself, then we could chain it
>> like this:
>>
>>  old_status = Status(last_contact=None).**save()
>>
>> Instead of having to do this:
>>
>>  old_status = Status(last_contact=None)
>>  old_status.save()
>>
>> It's a trivial one-line change to the Model class and I don't think it
>> would break backwards compatibility, as I doubt that anyone is relying on
>> the save() method returning None. Should I submit a patch?
>>
>> Cheers, Chris.
>> --
>> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
>> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
>>
>> Aptivate is a not-for-profit company registered in England and Wales
>> with company number 04980791.
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/WkAiV5BsEiEJ.
>
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

This isn't going to happen. It violates a fundamental API design in Python:
methods which mutate/have side effects return none, methods which return a
new object... return a new object. This has a side effect, and doesn't
construct a new object, ergo, it returns None.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: save() method could return the object

[Chris Wilson]

On Fri, 12 Oct 2012, Marijonas Petrauskas wrote:


There already exists create method that does exactly what you need:obj = 
SomeModel.objects.create(name='foo', age=42)


OK, thanks, that appears to be completely undocumented.

Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: save() method could return the object

[Alex Gaynor]

On Fri, Oct 12, 2012 at 6:40 AM, Chris Wilson  wrote:

> On Fri, 12 Oct 2012, Marijonas Petrauskas wrote:
>
>  There already exists create method that does exactly what you need:obj =
>> SomeModel.objects.create(name=**'foo', age=42)
>>
>
> OK, thanks, that appears to be completely undocumented.
>
>
> Cheers, Chris.
> --
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
>
> Aptivate is a not-for-profit company registered in England and Wales
> with company number 04980791.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to 
> django-developers@**googlegroups.com
> .
> To unsubscribe from this group, send email to
> django-developers+unsubscribe@**googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/**
> group/django-developers?hl=en
> .
>
>
https://docs.djangoproject.com/en/1.4/ref/models/querysets/#create

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Schema Alteration update

[Andre Terra]

On Fri, Oct 12, 2012 at 4:00 AM, Andrew Godwin  wrote:

> especially if it's something highly custom internal to a company where you
> don't have the time or team to do that stuff properly.
>

Thank you for highlighting this scenario. Unfortunately, this is usually
the case with my one-man projects, and I feel Django needs to take these
use cases into consideration more often.


Cheers,
AT

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

SQLCompiler.as_sql with_col_aliases

[Michael Manfre]

Is it safe to assume that the with_col_aliases argument of 
SQLCompiler.as_sql is intended to only be True when the query is a 
subquery? Those are the only usages I've found in the code.

MSSQL only supports ordering subqueries under a limited number of 
circumstances. To fix the SQL in django-mssql's compiler, I need a clear 
way of identifying when the query is a sub-query. If this is not a safe way 
of using with_col_aliases, is there another?

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/56Tv7DEP3EkJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Update on localflavor move

[Adrian Holovaty]

Hi all,

We've been talking about moving django.contrib.localflavor into
separate packages, outside of Django proper
(https://groups.google.com/d/topic/django-developers/OiyEGmXTifs/discussion).
Today I did the work of creating the django-localflavor-* packages and
copying code/tests/docs to them.

Now we have 44 django-localflavor-* projects on our Django GitHub
account, and you can see them here:

https://github.com/django

>From now on, please consider django.contrib.localflavor to be READ-ONLY:

* If you have any existing pull requests for localflavor, please close
them and open them again on the appropriate django-localflavor-*
project.

* If you have any existing Trac tickets for localflavor, please close
them and open a pull request on the appropriate django-localflavor-*
project.

* If you're a committer, please don't make changes to
django.contrib.localflavor. You have commit rights on all
django-localflavor-* projects, so commit changes there.

Eventually we'll be removing django.contrib.localflavor, in favor of
these outside packages. I've updated the localflavor docs to note the
new code location and tips on migration:

https://docs.djangoproject.com/en/dev/ref/contrib/localflavor/

Here are the outstanding to-dos with this effort:

* Move/copy translations into the django-localflavor-* packages. This
is outside of my expertise, so does anybody want to take the lead on
this?

* Document a clear way to run the tests for a given
django-localflavor-* package. I moved the tests into the separate
packages, but there's no clear way to run them. Any suggestions?

* Add DeprecationWarning to django.contrib.localflavor in trunk,
before Django 1.5. I will take care of this.

* I'll write up a more formal message for django-users and the
djangoproject.com blog.

Adrian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Update on localflavor move

[Russell Keith-Magee]

On Sat, Oct 13, 2012 at 6:21 AM, Adrian Holovaty  wrote:
> Hi all,
>
> We've been talking about moving django.contrib.localflavor into
> separate packages, outside of Django proper
> (https://groups.google.com/d/topic/django-developers/OiyEGmXTifs/discussion).
> Today I did the work of creating the django-localflavor-* packages and
> copying code/tests/docs to them.
>
> Now we have 44 django-localflavor-* projects on our Django GitHub
> account, and you can see them here:
>
> https://github.com/django

w00t! Nice work, Adrian!

> Here are the outstanding to-dos with this effort:
>
> * Document a clear way to run the tests for a given
> django-localflavor-* package. I moved the tests into the separate
> packages, but there's no clear way to run them. Any suggestions?

The best option I've see for this sort of thing is tox:

http://tox.testrun.org/

This allows you to specify the PyPI packages (and versions) that need
to be installed in order to run the test suite, and automates the
process of setting up the test environment (using virtualenv). If code
needs to run as part of a larger project, tox can coordinate running
the tests in that project. It also integrates nicely with CI servers,
and it allows for easy testing across Python and Django versions.

To pick an example at random: here's the tox.ini file for
Easy-thumbnails, which tests Py2.5-Py2.7, Django 1.2-1.4, as well as
the documentation build.

https://github.com/SmileyChris/easy-thumbnails/blob/master/tox.ini

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.