Tim Peters wrote:
> `zip` then creates `n` 2-tuple objects, each of which lives only long enough
> to be unpacked into `x` and `y`... With "immediate" reclamation of garbage
> via refcounting, memory use is trival regardless of how large `n` is, as
> CPython reuses the same heap space over &
I'm surprised nobody has mentioned this: there are no "unboxed" types
in CPython - in effect, every object user code creates is allocated
from the heap. Even, e.g., integers and floats. So even non-contrived
code can create garbage at a ferocious rate. For example, think about
this simple
Hi,
tl; dr Buildbots were unstable for 3 weeks but the issue is mostly resolved.
Since last January, the disk of the buildbot server was full every 2
weeks and The Night’s Watch had to fix it in the darkness for you
(usually, remove JUnit files and restart the server). The old machine
only has
Dear list,
log records in the Python logging library always use timestamps provided
by `time.time()`, i.e. the usual system clock (UTC, CLOCK_REALTIME).
This time is used as absolute timestamp in log records and for
timestamps relative to the load of the library (Lib/logging/__init__.py:
Hi,
tl; dr Travis CI issues are now resolved thanks to Ernest!
During the last 3 months, the Travis CI job failed randomly to report
the build status to GitHub pull requests:
https://github.com/python/core-workflow/issues/371
I discovered that travis-ci.org uses the legacy GitHub API, whereas
On 9/2/20 8:50 PM, Jim J. Jewett wrote:
I suspect that splitting the reference count away from the object itself could
also be profitable, as it means the cache won't have to be dirtied (and
flushed) on read access, and can keep Copy-On-Write from duplicating pages.
I had a patch from
