The Python comparison protocol requires that if an object doesn't know how to
compare itself to an object of a different type, it returns NotImplemented
rather than False. The interpreter will then try performing the comparison using
the other operand. This translates, for protos, to:
If a proto message doesn't know how to compare itself to an object of
non-message type, it returns NotImplemented. This way, the interpreter will then
try performing the comparison using the comparison methods of the other object,
which may know how to compare itself to a message. If not, then Python will
return the combined result (e.g., if both objects don't know how to perform
__eq__, then the equality operator `==` return false).
This change allows one to compare a proto with custom matchers such as mock.ANY
that the message doesn't know how to compare to, regardless of whether
mock.ANY is on the right-hand side or left-hand side of the equality (prior to
this change, it only worked with mock.ANY on the left-hand side).
Fixes https://github.com/protocolbuffers/protobuf/issues/9173
PiperOrigin-RevId: 561728156
GetOptions on fields (which parse the _serialized_options) will be called for the first time of parse or serialize instead of Build time.
Note: GetOptions on messages are still called in Build time because of message_set_wire_format. If message options are needed in descriptor.proto, a parse error will be raised in GetOptions(). We can check the file to not invoke GetOptions() for descriptor.proto as long as message_set_wire_format not needed in descriptor.proto.
Other options except message options do not invoke GetOptions() in Build time
PiperOrigin-RevId: 560741182
This fixes Python/C++ and upb, and pushes the buggy behavior to pure python. There, it's very difficult to handle options on the bootstrapped proto with the current architecture. Future changes will attempt to address this more isolated issue.
PiperOrigin-RevId: 559450900
The Python comparison protocol requires that if an object doesn't know how to
compare itself to an object of a different type, it returns NotImplemented
rather than False. The interpreter will then try performing the comparison using
the other operand. This translates, for protos, to:
If a proto message doesn't know how to compare itself to an object of
non-message type, it returns NotImplemented. This way, the interpreter will then
try performing the comparison using the comparison methods of the other object,
which may know how to compare itself to a message. If not, then Python will
return the combined result (e.g., if both objects don't know how to perform
__eq__, then the equality operator `==` return false).
This change allows one to compare a proto with custom matchers such as mock.ANY
that the message doesn't know how to compare to, regardless of whether
mock.ANY is on the right-hand side or left-hand side of the equality (prior to
this change, it only worked with mock.ANY on the left-hand side).
See https://github.com/protocolbuffers/protobuf/issues/9173
PiperOrigin-RevId: 559056804
Remove array.h and map.h as hdrs from :collections_internal
Remove alloc.h and arena.h as hdrs from :mem_internal (and add them to :mem)
Remove common.h and decode.h and encode.h as hdrs from :wire_internal
Lock down the visibility of :wire_internal to upb-only
Merge :mini_descriptor_encode_internal into :mini_descriptor_internal
PiperOrigin-RevId: 558235138
This proto is only used in C++ tests, and doesn't need to be built in python. Python doesn't support editions yet, so we should just remove it for now. This also fixes some other issues with setup.py where tests fail.
Closes#13501
PiperOrigin-RevId: 555681295
When build a FileDescriptorProto into pool, FieldDescriptorProto.type may not set if type_name is set. This only add tests. UPB python Fix has been submit in other change
PiperOrigin-RevId: 554516745
The file structure was broken only when invoking from protobuf repo (`bazel build @upb//python/dist:source_tarball`) since filegroup files have a path like `protobuf/external/upb/python/dist/setup.py` rather than `protobuf/setup.py`
This was broken by 79af13abde
PiperOrigin-RevId: 553821217
This flag was added to Protobuf and submitted separately due to version skew between repos.
This attempts to fix the following error from local and release settings both matching.
```
ERROR: /workspace/_build/out/external/upb/python/dist/BUILD.bazel:251:9: Illegal ambiguous match on configurable attribute "platform" in @upb//python/dist:binary_wheel:
@upb//python/dist:linux_x86_64_local
@upb//python/dist:windows_x86_64
Multiple matches are not allowed unless one is unambiguously more specialized or they resolve to the same value. See https://bazel.build/reference/be/functions#select.
```
PiperOrigin-RevId: 553226261
The next in a series of CLs to split upb/BUILD into subdirs.
Create mem/internal/
Delete the deprecated upb/arena.h and upb/alloc.h stub headers
PiperOrigin-RevId: 552864952
pkg_files() has some odd quirks, like breaking if a filename exists in multiple directories. filegroup() does everything we need, without these quirks.
PiperOrigin-RevId: 547523447
Use the default generated pool for some message factory tests. Use a new descriptor
pool each time may turns out flake refleck test -- garbage collectors aren't
very predictable.
For blaze test third_party/py/google/protobuf/internal:message_factory_test_python_protos --runs_per_test_detects_flakes --runs_per_test=1000 --copt=-DPy_DEBUG
There were 30-50 failures before the change. Now tests are passing
PiperOrigin-RevId: 546091823
After this change, `mini_table` only has MiniTable definitions themselves. Everything having to do with the MiniDescriptor wire format is in `mini_descriptor`.
Also rearranged some of the files in mini_table to have better structure for `internal/`.
This CL contains no functional change.
PiperOrigin-RevId: 543529112