[docs] [issue37635] Using constant for whence arg in seek()

Kyle Stanley report at bugs.python.org
Sat Jul 20 17:14:09 EDT 2019

Kyle Stanley <aeros167 at gmail.com> added the comment:

>The named versions are just alternatives available for end-users

While it is true that the usage of 0,1,2 is more commonly used across the repository, the constants are used several times across Lib/_compression.py and Lib/_pyio.py. From my perspective, it looks like the locations which already used the integer values were just not updated rather than it being an intentional design decision.

However, if it is primarily targeted at the end-users, I would still recommend at least updating the tutorial and perhaps other IO documentation to use the constants. To any user unfamiliar with the integers, the constants convey their purpose far more explicitly, and I don't think anyone familiar with the integers would be confused by the constants. 

>The numbered forms also let us avoid a bunch of otherwise unnecessary imports (which affect >start-up time and occasionally create load order bootstrapping issues).

I can definitely understand this argument for anything that doesn't already import IO. It probably wouldn't be worthwhile to increase start times and introduce load order bugs. 

But for anything that already imports IO anyways, this seems like it would only serve to be a readability improvement without causing any change in functionality. This might not make a difference at all to developers who are used to using 0,1,2, but their purpose is not inherently obvious to anyone that isn't. 

This change would be in alignment with "Explicit is better than implicit". The purpose of the integers is defined only by implication based on tradition, whereas the constants explicitly define the purpose of the argument. 

A major advantage of Python over many existing languages is the emphasis on providing maximum readability. Sometimes functionality should be prioritized, such as in places where IO is not already imported. But in cases where there is no functionality cost, readability should be the priority. Even for non-public sections such as the tests, improved readability leads to easier maintenance and incorporation of new Python developers.


Python tracker <report at bugs.python.org>

More information about the docs mailing list