2015-07-03 17:10 GMT+02:00 Berker Peksağ :
> I agree with you on the StringIO and BytesIO cases, but I agree with
> Andriy on the other usages (e.g. ZipFile, GzipFile). Many contributors
> follow the existing practices to write new tests, so it would be nice
> to use best practices if they don't p
Hello,
On 06/28/2015 08:04 AM, Ashley Camba Garrido wrote:
> Damn, forgot the link.
>
> https://github.com/ashwoods/deps/blob/master/draft/-model-internalization.rst
I think the DEP is well-motivated; thanks for picking up this topic.
This is a problem that would be useful to have some stand
On Fri, Jul 3, 2015 at 4:59 PM, Tim Graham wrote:
> Andriy proposed a patch to close objects like StringIO and BytesIO in our
> test suite [1]. I am not sure how much benefit this gives (frees "a few
> bytes of RAM" according to [2]) and it seems to add a lot of verbosity.
> Looking at Python's ow
Hello ,
If you do mean CPython test suite then it's probably not the best
place to look at because the reference counting *is there* and those
object will be closed at the end of test method. Django doesn't have
this comfort when run with PyPy.
That said, I wouldn't recommend using contextlib.clo
My vision of that was to have clean code (even if these are few bytes).
Python allows to have memory leaks like this, without throwing warnings,
but if we know that we can close it, I think we should do that.
We're usually writing new tests by copying logic from sibling test (if
new test need to d
Andriy proposed a patch to close objects like StringIO and BytesIO in our
test suite [1]. I am not sure how much benefit this gives (frees "a few
bytes of RAM" according to [2]) and it seems to add a lot of verbosity.
Looking at Python's own test suite, it doesn't appear these objects are
close
