+1 from me - I was thinking of this the other day.
On Sun, 22 Mar 2020 at 22:38, charettes wrote:
> For anyone interested I finally submitted a ticket[0] to add this feature
> to core since the third-party app[1]
> was proven to be quite functional in all the projects I've used it so far
> and n
For anyone interested I finally submitted a ticket[0] to add this feature
to core since the third-party app[1]
was proven to be quite functional in all the projects I've used it so far
and no issues were opened
against the package in the two years it has been around.
Looking forwards to see this
Hey Tobias, thanks for chiming in.
The main motivation behind this package and this core inclusion proposal is
that I've come across a non-negligible number users that were surprised to
find out this was not working automatically and others that completely
stopped using setUpTestData because of
On Fri, Nov 30, 2018, 1:03 PM Adam Johnson Tobias - using database updates isn't always viable. Also the system under
> test might need to take in the model instance, mutate it and execute its
> own save(), and then there's no way of rolling that back if the object
> wasn't deepcopy'd
>
Fair enou
Hunar - it's best to start a separate thread for different topics, and even
better to check a support channel first, like the IRC channels. I think you
might be looking for how to contribute translations - start here:
https://docs.djangoproject.com/en/dev/internals/contributing/ . Or if you
just ne
hi there , im from kurdistan and my mother language is kurdish but
unfortunately django doesnt support kurdish language , sometimes i need to
add multi language to my projects , how can i add multi language?
thanks for advice
On Fri, Nov 30, 2018 at 7:15 PM Tobias McNulty
wrote:
> Hi Simon,
>
>
Hi Simon,
Intriguing proposal! Thanks for bringing it up. This is certainly something
I've struggled with on older projects we've continued to maintain.
My first impression (and it may be only that) is that this seems a big
magical and potentially confusing, especially in the event the copy
opera
Hey Josh, glad the package can help in the mean time!
> Is there anyway to determine the pickle-ability of something without just
trying to pickle it? I wouldn't be keen on that overhead.
Not that I'm aware off but unfortunately. There really shouldn't be much
overhead though because the deepco
Our project also suffers extensively with mutating objects assigned from
setUp, preventing us from moving most of our tests to setUpTestData. I'll
likely begin using your pypi package right away, thanks Simon!
Backward compat issues are probably likely - but they'd be in test cases
exclusively,
>
> Are these the kind of objects you assign during setUpTestData though?
>
They're not the kind of things *I* assign but I bet somewhere out there,
some project does extensively :)
What about going through a deprecation period where non-picklable
> assignment during setUpTestData raises a deprec
Thanks for chiming in Adam.
I think this is too much of an ask for backwards compatibility. Lots of
> things aren't deepcopy-able, as per its docs:
>
Right. Are these the kind of objects you assign during setUpTestData
though? They could be easily moved to setUpTestCase for example.
How about
I have run into this problem myself in the past. On a previous project we
added a helper function to make deepcopy's of named attributes during
setUp().
>From a check against a few projects and Django's test suite[2] I have only
> identified a single issue which is that attributes assigned during
Dear developers,
Django 1.8 introduced the `TestCase.setUpTestData()` class method as a mean
to
speed up test fixtures initialization as compared to using `setUp()`[0].
As I've come to use this feature and review changes from peers using it in
different projects the fact that test data assigned
13 matches
Mail list logo
