PEP 615: consistent terminology (#1586)

OrangeDog · web-flow · commit b085b2ddfa41 · 2020-09-08T18:44:27.000-04:00
* 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
diff --git a/pep-0615.rst b/pep-0615.rst
@@ -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.
 
