> On 10 Feb 2015, at 00:12, Tim Graham wrote:
>
> Is it a best practice? In my unscientific sampling, none of the following
> ship tests inside the application directory, but rather in a separate "tests"
> directory. Or did I misunderstand what you meant?
>
> - Django REST framework
> - djang
That'll teach me to respond to email before coffee :)
--
C
On 10 February 2015 at 10:12, Tim Graham wrote:
> Is it a best practice? In my unscientific sampling, none of the following
> ship tests inside the application directory, but rather in a separate
> "tests" directory. Or did I misunders
Why should this be treated differently than the general behavior when
realted_names clash when you have more than one foreign key to the same
model? So as one would normally do
set the related_name explicitly to some other value.
setting the field to None is just the way of removing a field and h
Is it a best practice? In my unscientific sampling, none of the following
ship tests inside the application directory, but rather in a separate
"tests" directory. Or did I misunderstand what you meant?
- Django REST framework
- django-nap
- the apps that split out from contrib (formtools, commen
Just to shine a light on another perspective- I frequently tell people to
look at contrib for "best practices", and including tests within a 3rd
party app would fall under that.
--
Curtis
On 10 Feb 2015 03:34, "Marc Tamlyn" wrote:
> +1 to removing tests from contrib itself, so long as they remai
I'd like some additional opinions on the following:
Say you have the following classes:
class Parent(models.Model):
cousin_set = models.CharField(max_length=100)
class Meta:
abstract = True
class Child(Parent):
pass
class Cousin(models.Model):
child = models.ForeignKey(
Hi Andriy,
The direction looks OK to me, but it'll be a lot easier to review properly
once you've opened a pull request.
I'm not sure that you need to separate out "general" and "statistics" into
different modules, but that's something we can discuss on the PR.
Nice work :)
Josh
On Tuesday,
+1 to removing tests from contrib itself, so long as they remain obviously
separated in the test section in case of future removals from core.
On 9 February 2015 at 15:44, Preston Timmons
wrote:
> I think the "need" is mainly conceptual--whether tests are more
> appropriately grouped with their
I think the "need" is mainly conceptual--whether tests are more
appropriately grouped with their app or with the other tests. With the
discover runner it's uncommon that contrib tests are included in any local
test runs.
I do prefer moving all tests into the tests directory. The logic to get
t
I'm +1 on moving the contrib tests to tests/_tests/ .
The respective ticket on Trac is https://code.djangoproject.com/ticket/24293
/Markus
On Monday, February 9, 2015 at 4:09:47 PM UTC+1, Tim Graham wrote:
>
> I wonder if there is any need to continue to ship tests as part of contrib
> apps? Cu
I wonder if there is any need to continue to ship tests as part of contrib
apps? Currently the contributing docs say, "Tests for contrib apps go in
their respective directories under django/contrib, in a tests.py file. You
can split the tests over multiple modules by using a tests directory in t
I implemented some of functions:
https://github.com/coldmind/django/compare/postresql_aggregate_functions
Implementation of general-purpose functions is trivial; statistic-purpose
functions are somewhat different.
I want include to the first pull request general-purpose and
statistic-purpose fu
Hi Collin,
I would like that, good idea!
Wim
On Saturday, 7 February 2015 02:10:02 UTC+1, Collin Anderson wrote:
>
> Hi All,
>
> I was reminded by:
> Allow shadowing of abstract fields
> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
> and https://code.djangoproject
13 matches
Mail list logo
