This documentation change includes the following:

* content/best-practices/dos-donts.md: Adds a note to clarify that "Common Types" (such as Date and Money) are not included with the standard compiler and require a dependency on the GoogleAPIs repository.
* content/editions/features.md: Significantly expands the documentation for Protobuf editions features.
* content/programming-guides/proto3.md: Adds content to the Proto3 programming guide about specifying paths for import files
* content/reference/python/python-comparison.md: Adds a new documentation page that compares different Python implementations for Protocol Buffers.
* content/programming-guides/proto-limits.md: Minor content updates.
* content/includes/version-tables.css: Minor style adjustments.

PiperOrigin-RevId: 799563507
Change-Id: I0624d9dc24207f1366e91b5b82b162da141bf52b

Author: Protocol Buffer Team

content/best-practices/dos-donts.md

@@ -168,6 +168,11 @@ when a perfectly suitable common type already exists!
 *   [`color`](https://github.com/googleapis/googleapis/blob/master/google/type/color.proto)
     is a color in the RGBA color space.
 
+**Note:** While the "Well-Known Types" (such as `Duration` and `Timestamp`) are
+included with the Protocol Buffers compiler, the "Common Types" (such as `Date`
+and `Money`) are not. To use the Common Types, you may need to add a dependency
+on the [googleapis repository](https://github.com/googleapis/googleapis).
+
 <a id="do-define-widely-used-message-types-in-separate-files"></a>
 
 ## **Do** Define Message Types in Separate Files {#separate-files}

content/programming-guides/proto-limits.md

@@ -15,6 +15,8 @@ others.
 
 ## Number of Fields {#fields}
 
+All messages are limited to 65,535 fields.
+
 Message with only singular proto fields (such as Boolean):
 
 *   ~2100 fields (proto2)

content/programming-guides/proto3.md

@@ -879,6 +879,34 @@ file:
 import "myproject/other_protos.proto";
 ```
 
+The protobuf compiler searches for imported files in a set of directories
+specified using the `-I`/`--proto_path` flag. The path given in an `import`
+statement is resolved relative to these directories. For more information on
+using the compiler, see [Generating Your Classes](#generating).
+
+For example, consider the following directory structure:
+
+```
+my_project/
+├── protos/
+│   ├── main.proto
+│   └── common/
+│       └── timestamp.proto
+```
+
+To use definitions from `timestamp.proto` within `main.proto`, you would run the
+compiler from the `my_project` directory and set `--proto_path=protos`. The
+`import` statement in `main.proto` would then be:
+
+```proto
+// Located in my_project/protos/main.proto
+import "common/timestamp.proto";
+```
+
+In general you should set the `--proto_path` flag to the highest-level directory
+that contains protos. This is often the root of the project, but in this example
+it's in a separate `/protos` directory.
+
 By default, you can use definitions only from directly imported `.proto` files.
 However, sometimes you may need to move a `.proto` file to a new location.
 Instead of moving the `.proto` file directly and updating all the call sites in
@@ -915,12 +943,6 @@ import "old.proto";
 // You use definitions from old.proto and new.proto, but not other.proto
 ```
 
-The protocol compiler searches for imported files in a set of directories
-specified on the protocol compiler command line using the `-I`/`--proto_path`
-flag. If no flag was given, it looks in the directory in which the compiler was
-invoked. In general you should set the `--proto_path` flag to the root of your
-project and use fully qualified names for all imports.
-
 ### Using proto2 Message Types {#proto2}
 
 It's possible to import
@@ -1739,7 +1761,7 @@ generator plugin for the compiler; you can find this and installation
 instructions in the [golang/protobuf](https://github.com/golang/protobuf/)
 repository on GitHub.
 
-The Protocol Compiler is invoked as follows:
+The protobuf compiler is invoked as follows:
 
 ```sh
 protoc --proto_path=IMPORT_PATH --cpp_out=DST_DIR --java_out=DST_DIR --python_out=DST_DIR --go_out=DST_DIR --ruby_out=DST_DIR --objc_out=DST_DIR --csharp_out=DST_DIR path/to/file.proto

content/reference/python/python-comparison.md

@@ -0,0 +1,89 @@
++++
+title = "Python Comparison"
+weight = 751
+linkTitle = "Python Comparison"
+description = "Describes how Python compares objects."
+type = "docs"
++++
+
+Because of how proto data is serialized, you cannot rely on the wire
+representation of a proto message instance to determine if its content is the
+same as another instance. A subset of the ways that a wire-format proto message
+instance can vary include the following:
+
+*   The protobuf schema changes in certain ways.
+*   A map field stores its values in a different order.
+*   The binary is built with different flags (such as opt vs. debug).
+*   The protobuf library is updated.
+
+Because of these ways that serialized data can vary, determining equality
+involves other methods.
+
+## Comparison Methods {#methods}
+
+You can compare protocol buffer messages for equality using the standard Python
+`==` operator. Comparing two objects using the `==` operator compares with
+`message.ListFields()`. When testing, you can use `self.assertEqual(msg1,
+msg2)`.
+
+Two messages are considered equal if they have the same type and all of their
+corresponding fields are equal. The inequality operator `!=` is the exact
+inverse of `==`.
+
+Message equality is recursive: for two messages to be equal, any nested messages
+must also be equal.
+
+## Field Equality and Presence
+
+The equality check for fields is value-based. For fields with
+[explicit presence](#singular-explicit), the presence of a field is also taken
+into account.
+
+A field that is explicitly set to its default value is **not** considered equal
+to a field that is unset.
+
+For example, consider the following message which has an explicit presence
+field:
+
+```proto
+edition = "2023";
+message MyMessage {
+  int32 value = 1; // 'explicit' presence by default in Editions
+}
+```
+
+If you create two instances, one where `value` is unset and one where `value` is
+explicitly set to `0`, they will not be equal:
+
+```python
+msg1 = MyMessage()
+msg2 = MyMessage()
+msg2.value = 0
+
+assert not msg1.HasField("value")
+assert msg2.HasField("value")
+assert msg1 != msg2
+```
+
+This same principle applies to sub-message fields: an unset sub-message is not
+equal to a sub-message that is present but empty (a default instance of the
+sub-message class).
+
+For fields with [implicit presence](#singular-implicit), since presence cannot
+be tracked, the field is always compared by its value against the corresponding
+field in the other message.
+
+This behavior, where presence is part of the equality check, is different from
+how some other languages or protobuf libraries might handle equality, where
+unset fields and fields set to their default value are sometimes treated as
+equivalent (often for wire-format compatibility). In Python, `==` performs a
+stricter check.
+
+## Other Field Types {#other-types}
+
+*   **Repeated fields** are equal if they have the same number of elements and
+    each corresponding element is equal. The order of elements matters.
+*   **Map fields** are equal if they have the same set of key-value pairs. The
+    order of pairs does not matter.
+*   **Floating-point fields** (`float` and `double`) are compared by value. Be
+    aware of the usual caveats with floating-point comparisons.