iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 615: consistent terminology (#1586) 

* PEP-615 consistent terminology

It repeatedly refers to a ZoneInfo object as a "file", confusing it with either the file it was constructed from, or the IO object representing the file.

* Further clarification of caching implications
This commit is contained in:
James Howe 2020-09-08 23:44:27 +01:00 committed by GitHub
parent 7cff39a91d
commit b085b2ddfa
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
pep-0615.rst
View File

@ -134,7 +134,7 @@ behavior for end users.
``ZoneInfo`` objects are ejected when no references to them exist (for
example, a cache implemented with a ``weakref.WeakValueDictionary``) — it is
allowed but not required or recommended to implement this with a "strong"
cache, where all ``ZoneInfo`` files are kept alive indefinitely.
cache, where all ``ZoneInfo`` objects are kept alive indefinitely.
.. code-block::
@ -190,11 +190,11 @@ of the interpreter, it must not invalidate any caches or modify any
existing ``ZoneInfo`` objects. Newly constructed ``ZoneInfo`` objects, however,
should come from the updated data source.
This means that the point at which a ``ZoneInfo`` file is updated depends
primarily on the semantics of the caching behavior. The only guaranteed way to
get a ``ZoneInfo`` file from an updated data source is to induce a cache miss,
either by bypassing the cache and using ``ZoneInfo.no_cache`` or by clearing the
cache.
This means that the point at which the data source is updated for new
invocations of the ``ZoneInfo`` constructor depends primarily on the semantics
of the caching behavior. The only guaranteed way to get a ``ZoneInfo`` object
from an updated data source is to induce a cache miss, either by bypassing the
cache and using ``ZoneInfo.no_cache`` or by clearing the cache.
.. note::
@ -274,7 +274,7 @@ An example:
When a ``key`` is not specified, the ``str`` operation should not fail, but
should return the file's ``__repr__``::
should return the objects's ``__repr__``::
>>> zone = ZoneInfo.from_file(f)
>>> str(zone)
@ -299,7 +299,7 @@ Rather than serializing all transition data, ``ZoneInfo`` objects will be
serialized by key, and ``ZoneInfo`` objects constructed from raw files (even
those with a value for ``key`` specified) cannot be pickled.
The behavior of a ``ZoneInfo`` file depends on how it was constructed:
The behavior of a ``ZoneInfo`` object depends on how it was constructed:
1. ``ZoneInfo(key)``: When constructed with the primary constructor, a
``ZoneInfo`` object will be serialized by key, and when deserialized the
@ -701,7 +701,7 @@ implementation in ways that may not be compatible with a non-ICU-based
implementation — particularly around the behavior of the cache.
Since it seems like ICU cannot be used as simply an additional data source for
``ZoneInfo`` files, this PEP considers the ICU support to be out of scope, and
``ZoneInfo`` objects, this PEP considers the ICU support to be out of scope, and
probably better supported by a third-party library.
Alternative environment variable configurations
@ -846,7 +846,7 @@ Footnotes
but user support mostly focuses on these three types.
.. [b]
The statement that identically constructed ``ZoneInfo`` files should be
The statement that identically constructed ``ZoneInfo`` objects should be
identical objects may be violated if the user deliberately clears the time
zone cache.