-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
Doc: Update references and examples of old, unsupported OSes and uarches #92791
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
6032ecb
534de62
2a67a2a
7fc91e7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -252,20 +252,23 @@ Binary Data | |
----------- | ||
|
||
It is perfectly possible to send binary data over a socket. The major problem is | ||
that not all machines use the same formats for binary data. For example, a | ||
Motorola chip will represent a 16 bit integer with the value 1 as the two hex | ||
bytes 00 01. Intel and DEC, however, are byte-reversed - that same 1 is 01 00. | ||
that not all machines use the same formats for binary data. For example, | ||
network byte order is big-endian, with the most significant byte first, | ||
serhiy-storchaka marked this conversation as resolved.
Show resolved
Hide resolved
|
||
so a 16 bit integer with the value ``1`` would be the two hex bytes ``00 01``. | ||
However, most common processors (x86/AMD64, ARM, RISC-V), are little-endian, | ||
with the least significant byte first - that same ``1`` would be ``01 00``. | ||
Socket libraries have calls for converting 16 and 32 bit integers - ``ntohl, | ||
htonl, ntohs, htons`` where "n" means *network* and "h" means *host*, "s" means | ||
*short* and "l" means *long*. Where network order is host order, these do | ||
nothing, but where the machine is byte-reversed, these swap the bytes around | ||
appropriately. | ||
|
||
In these days of 32 bit machines, the ascii representation of binary data is | ||
In these days of 64-bit machines, the ASCII representation of binary data is | ||
frequently smaller than the binary representation. That's because a surprising | ||
amount of the time, all those longs have the value 0, or maybe 1. The string "0" | ||
would be two bytes, while binary is four. Of course, this doesn't fit well with | ||
fixed-length messages. Decisions, decisions. | ||
amount of the time, all those integers have the value 0, or maybe 1. | ||
The string ``"0"`` would be two bytes, while a full 64-bit word would be 8. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It does not fit with functions ntohl, htonl, ntohs, htons, described in previous paragraph, which only work with 16 and 32 bit integers. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, but I'm not sure it has to, since those two paragraphs are describing separate topics, and the respective integer widths are each appropriate to the point being made—the standard library functions are nominally for smaller 16 and 32-bit integers, while modern machines and Python's own native integer type are 64-bit, where encoding small integers as ASCII/UTF-8 has the greatest potential size advantage over binary, while also avoiding the need to potentially convert endianness, particularly so when the aforementioned functions are not available for 64-bit ints (though perhaps one could be added). Is there something specific you'd like me to add/clarify here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is obvious to me that this paragraph refers to the previous one. It's mention of "all those longs" is a reference to "long" in Also, on most modern 64-bit platforms the standard integer type There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Okay, thanks for providing something specific. I replaced that wording with "most integers", as well as clarified the terminology in the following sentence as well. If there's something else specific you would like me to change, let me know.
Yes, if by "standard" you mean the C type that has the name There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Python 3 does not have a native fixed-width integer type. There was one in Python 2, but it was 32-bit on Windows. Well, I think it is not important. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Sorry, I should have used clearer terminology—what I meant to imply was "native" to the language vs. third party (e.g. Numpy dtypes), but in this context "native" more conventionally means platform-native, as you say above. I also somewhat inaccurately simplified Python's |
||
Of course, this doesn't fit well with fixed-length messages. | ||
Decisions, decisions. | ||
|
||
|
||
Disconnecting | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -53,7 +53,7 @@ Cross Platform | |
|
||
.. function:: machine() | ||
|
||
Returns the machine type, e.g. ``'i386'``. An empty string is returned if the | ||
Returns the machine type, e.g. ``'AMD64'``. An empty string is returned if the | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it what returned on the AMD processors? On my computer it is 'x86_64'. Update also the docstring of platform.machine(). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The original 'proper' name of what is also called the "x86-64" architecture is AMD64, as it was created by AMD and later adopted by Intel when Intel's IA-64 (Itanium) architecture failed in the market. What is returned depends (AFAIK) on the OS, not the CPU; Windows and many (most?) Linux distros call it
I can, but as this PR currently only modifies the docs, I'd rather do that separately; there are other places in the codebase that should be updated too, for consistency. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Docstrings are a part of the docs. If we do not update them together with the rst files, they are left desynchronized. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This only affects the choice of one specific example, both of which are equally accurate and valid, and which will be synchronized if and when I do a similar pass through the codebase itself. Several of the other Given the change was minor and not strictly required in the first place, and I almost didn't make it, if this is going to be a big issue I'll just drop this change instead, since its not at all worth the cost. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Either way the docstrings and the documentation should be consistent. |
||
value cannot be determined. | ||
|
||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -37,7 +37,7 @@ Large File Support | |
|
||
.. sectionauthor:: Steve Clift <[email protected]> | ||
|
||
Several operating systems (including AIX, HP-UX and Solaris) provide | ||
Several operating systems (including AIX and Solaris) provide | ||
support for files that are larger than 2 GiB from a C programming model where | ||
:c:type:`int` and :c:type:`long` are 32-bit values. This is typically accomplished | ||
by defining the relevant size and offset types as 64-bit values. Such files are | ||
|
Uh oh!
There was an error while loading. Please reload this page.