flatbuffers/tests/MyGame/MonsterExtra.py

335 lines
11 KiB
Python
Raw Normal View History

# automatically generated by the FlatBuffers compiler, do not modify
# namespace: MyGame
import flatbuffers
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
from flatbuffers.compat import import_numpy
np = import_numpy()
class MonsterExtra(object):
__slots__ = ['_tab']
@classmethod
def GetRootAs(cls, buf, offset=0):
n = flatbuffers.encode.Get(flatbuffers.packer.uoffset, buf, offset)
x = MonsterExtra()
x.Init(buf, n + offset)
return x
Python: Added support for file_identifiers (#5123) * Python: Added support for file_identifiers * Added tests. Fixed file_identifier code. * Python: Fixed excessive padding of file_identifier. Repaired tests. * Python: Made code compatible with python2.7 * Python: Typo fix in @endcond * whitespace normaalization * Stylistic change from if(not X is None) to if(X is not None). Added comment to type string. * Python: Added support for automatic code generation of file_identifiers. Added tests for said code generation. * converted sprintf to snprintf * Bugfix, added snprint deffinition for MSVC * changed snprint deffinition for MSVC to sprint_s * changed scanf to IntToStringHex. Renamed HasFileIdentifier to GenHasFileIdentifier. * Added updated genereated code to commit * Python bugix: flatc no longer produces HasFileIdentfier for shcemas with no file identifier * Added tests to verify `MonsterBufferHasIdentifier` returns false on no Identifier * Python: added tests for GetBufferIdentifier and BufferHasIdentifier Python: removed unessasary parenethesis in if statements Minor format changes. * Python : correceted instances of keyword arguments being called as positional arguments * fixed typos and grammer in comments * Minor style fixes * Indentation fix * Equals style changes * Python: Fixed Alignment Issues. Changed test code to test against atual output * Ran make(forgot to run make last commit) * Python: Style changes * Style changes * indentation and style * readded CONTRIBUTING.md * Formatting tweak Mostly to make CI run again * More formatting fixes * More formatting fixes * More formatting fixes * More formatting fixes * Formatting fix * More formatting fixes * Formatting * ran generate_code.sh
2019-07-26 18:06:25 +00:00
@classmethod
def GetRootAsMonsterExtra(cls, buf, offset=0):
"""This method is deprecated. Please switch to GetRootAs."""
return cls.GetRootAs(buf, offset)
@classmethod
Python: Added support for file_identifiers (#5123) * Python: Added support for file_identifiers * Added tests. Fixed file_identifier code. * Python: Fixed excessive padding of file_identifier. Repaired tests. * Python: Made code compatible with python2.7 * Python: Typo fix in @endcond * whitespace normaalization * Stylistic change from if(not X is None) to if(X is not None). Added comment to type string. * Python: Added support for automatic code generation of file_identifiers. Added tests for said code generation. * converted sprintf to snprintf * Bugfix, added snprint deffinition for MSVC * changed snprint deffinition for MSVC to sprint_s * changed scanf to IntToStringHex. Renamed HasFileIdentifier to GenHasFileIdentifier. * Added updated genereated code to commit * Python bugix: flatc no longer produces HasFileIdentfier for shcemas with no file identifier * Added tests to verify `MonsterBufferHasIdentifier` returns false on no Identifier * Python: added tests for GetBufferIdentifier and BufferHasIdentifier Python: removed unessasary parenethesis in if statements Minor format changes. * Python : correceted instances of keyword arguments being called as positional arguments * fixed typos and grammer in comments * Minor style fixes * Indentation fix * Equals style changes * Python: Fixed Alignment Issues. Changed test code to test against atual output * Ran make(forgot to run make last commit) * Python: Style changes * Style changes * indentation and style * readded CONTRIBUTING.md * Formatting tweak Mostly to make CI run again * More formatting fixes * More formatting fixes * More formatting fixes * More formatting fixes * Formatting fix * More formatting fixes * Formatting * ran generate_code.sh
2019-07-26 18:06:25 +00:00
def MonsterExtraBufferHasIdentifier(cls, buf, offset, size_prefixed=False):
return flatbuffers.util.BufferHasIdentifier(buf, offset, b"\x4D\x4F\x4E\x45", size_prefixed=size_prefixed)
# MonsterExtra
def Init(self, buf, pos):
self._tab = flatbuffers.table.Table(buf, pos)
# MonsterExtra
def D0(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(4))
if o != 0:
return self._tab.Get(flatbuffers.number_types.Float64Flags, o + self._tab.Pos)
return float('nan')
# MonsterExtra
def D1(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(6))
if o != 0:
return self._tab.Get(flatbuffers.number_types.Float64Flags, o + self._tab.Pos)
return float('nan')
# MonsterExtra
def D2(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(8))
if o != 0:
return self._tab.Get(flatbuffers.number_types.Float64Flags, o + self._tab.Pos)
return float('inf')
# MonsterExtra
def D3(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(10))
if o != 0:
return self._tab.Get(flatbuffers.number_types.Float64Flags, o + self._tab.Pos)
return float('-inf')
# MonsterExtra
def F0(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(12))
if o != 0:
return self._tab.Get(flatbuffers.number_types.Float32Flags, o + self._tab.Pos)
return float('nan')
# MonsterExtra
def F1(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(14))
if o != 0:
return self._tab.Get(flatbuffers.number_types.Float32Flags, o + self._tab.Pos)
return float('nan')
# MonsterExtra
def F2(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(16))
if o != 0:
return self._tab.Get(flatbuffers.number_types.Float32Flags, o + self._tab.Pos)
return float('inf')
# MonsterExtra
def F3(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(18))
if o != 0:
return self._tab.Get(flatbuffers.number_types.Float32Flags, o + self._tab.Pos)
return float('-inf')
# MonsterExtra
def Dvec(self, j):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(20))
if o != 0:
a = self._tab.Vector(o)
return self._tab.Get(flatbuffers.number_types.Float64Flags, a + flatbuffers.number_types.UOffsetTFlags.py_type(j * 8))
return 0
# MonsterExtra
def DvecAsNumpy(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(20))
if o != 0:
return self._tab.GetVectorAsNumpy(flatbuffers.number_types.Float64Flags, o)
return 0
# MonsterExtra
def DvecLength(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(20))
if o != 0:
return self._tab.VectorLen(o)
return 0
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
# MonsterExtra
def DvecIsNone(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(20))
return o == 0
# MonsterExtra
def Fvec(self, j):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(22))
if o != 0:
a = self._tab.Vector(o)
return self._tab.Get(flatbuffers.number_types.Float32Flags, a + flatbuffers.number_types.UOffsetTFlags.py_type(j * 4))
return 0
# MonsterExtra
def FvecAsNumpy(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(22))
if o != 0:
return self._tab.GetVectorAsNumpy(flatbuffers.number_types.Float32Flags, o)
return 0
# MonsterExtra
def FvecLength(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(22))
if o != 0:
return self._tab.VectorLen(o)
return 0
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
# MonsterExtra
def FvecIsNone(self):
o = flatbuffers.number_types.UOffsetTFlags.py_type(self._tab.Offset(22))
return o == 0
def MonsterExtraStart(builder):
return builder.StartObject(11)
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def Start(builder):
return MonsterExtraStart(builder)
def MonsterExtraAddD0(builder, d0):
return builder.PrependFloat64Slot(0, d0, float('nan'))
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def AddD0(builder, d0):
return MonsterExtraAddD0(builder, d0)
def MonsterExtraAddD1(builder, d1):
return builder.PrependFloat64Slot(1, d1, float('nan'))
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def AddD1(builder, d1):
return MonsterExtraAddD1(builder, d1)
def MonsterExtraAddD2(builder, d2):
return builder.PrependFloat64Slot(2, d2, float('inf'))
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def AddD2(builder, d2):
return MonsterExtraAddD2(builder, d2)
def MonsterExtraAddD3(builder, d3):
return builder.PrependFloat64Slot(3, d3, float('-inf'))
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def AddD3(builder, d3):
return MonsterExtraAddD3(builder, d3)
def MonsterExtraAddF0(builder, f0):
return builder.PrependFloat32Slot(4, f0, float('nan'))
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def AddF0(builder, f0):
return MonsterExtraAddF0(builder, f0)
def MonsterExtraAddF1(builder, f1):
return builder.PrependFloat32Slot(5, f1, float('nan'))
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def AddF1(builder, f1):
return MonsterExtraAddF1(builder, f1)
def MonsterExtraAddF2(builder, f2):
return builder.PrependFloat32Slot(6, f2, float('inf'))
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def AddF2(builder, f2):
return MonsterExtraAddF2(builder, f2)
def MonsterExtraAddF3(builder, f3):
return builder.PrependFloat32Slot(7, f3, float('-inf'))
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def AddF3(builder, f3):
return MonsterExtraAddF3(builder, f3)
def MonsterExtraAddDvec(builder, dvec):
return builder.PrependUOffsetTRelativeSlot(8, flatbuffers.number_types.UOffsetTFlags.py_type(dvec), 0)
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def AddDvec(builder, dvec):
return MonsterExtraAddDvec(builder, dvec)
def MonsterExtraStartDvecVector(builder, numElems):
return builder.StartVector(8, numElems, 8)
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def StartDvecVector(builder, numElems):
return MonsterExtraStartDvecVector(builder, numElems)
def MonsterExtraAddFvec(builder, fvec):
return builder.PrependUOffsetTRelativeSlot(9, flatbuffers.number_types.UOffsetTFlags.py_type(fvec), 0)
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def AddFvec(builder, fvec):
return MonsterExtraAddFvec(builder, fvec)
def MonsterExtraStartFvecVector(builder, numElems):
return builder.StartVector(4, numElems, 4)
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def StartFvecVector(builder, numElems):
return MonsterExtraStartFvecVector(builder, numElems)
def MonsterExtraEnd(builder):
return builder.EndObject()
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
def End(builder):
return MonsterExtraEnd(builder)
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
try:
from typing import List
except:
pass
class MonsterExtraT(object):
# MonsterExtraT
def __init__(self):
self.d0 = float('nan') # type: float
self.d1 = float('nan') # type: float
self.d2 = float('inf') # type: float
self.d3 = float('-inf') # type: float
self.f0 = float('nan') # type: float
self.f1 = float('nan') # type: float
self.f2 = float('inf') # type: float
self.f3 = float('-inf') # type: float
self.dvec = None # type: List[float]
self.fvec = None # type: List[float]
@classmethod
def InitFromBuf(cls, buf, pos):
monsterExtra = MonsterExtra()
monsterExtra.Init(buf, pos)
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
return cls.InitFromObj(monsterExtra)
@classmethod
def InitFromPackedBuf(cls, buf, pos=0):
n = flatbuffers.encode.Get(flatbuffers.packer.uoffset, buf, pos)
return cls.InitFromBuf(buf, pos+n)
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
@classmethod
def InitFromObj(cls, monsterExtra):
x = MonsterExtraT()
x._UnPack(monsterExtra)
return x
def __eq__(self, other):
return type(self) == type(other) and \
self.d0 == other.d0 and \
self.d1 == other.d1 and \
self.d2 == other.d2 and \
self.d3 == other.d3 and \
self.f0 == other.f0 and \
self.f1 == other.f1 and \
self.f2 == other.f2 and \
self.f3 == other.f3 and \
self.dvec == other.dvec and \
self.fvec == other.fvec
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
# MonsterExtraT
def _UnPack(self, monsterExtra):
if monsterExtra is None:
return
self.d0 = monsterExtra.D0()
self.d1 = monsterExtra.D1()
self.d2 = monsterExtra.D2()
self.d3 = monsterExtra.D3()
self.f0 = monsterExtra.F0()
self.f1 = monsterExtra.F1()
self.f2 = monsterExtra.F2()
self.f3 = monsterExtra.F3()
if not monsterExtra.DvecIsNone():
if np is None:
self.dvec = []
for i in range(monsterExtra.DvecLength()):
self.dvec.append(monsterExtra.Dvec(i))
else:
self.dvec = monsterExtra.DvecAsNumpy()
if not monsterExtra.FvecIsNone():
if np is None:
self.fvec = []
for i in range(monsterExtra.FvecLength()):
self.fvec.append(monsterExtra.Fvec(i))
else:
self.fvec = monsterExtra.FvecAsNumpy()
# MonsterExtraT
def Pack(self, builder):
if self.dvec is not None:
if np is not None and type(self.dvec) is np.ndarray:
dvec = builder.CreateNumpyVector(self.dvec)
else:
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
MonsterExtraStartDvecVector(builder, len(self.dvec))
for i in reversed(range(len(self.dvec))):
builder.PrependFloat64(self.dvec[i])
dvec = builder.EndVector()
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
if self.fvec is not None:
if np is not None and type(self.fvec) is np.ndarray:
fvec = builder.CreateNumpyVector(self.fvec)
else:
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
MonsterExtraStartFvecVector(builder, len(self.fvec))
for i in reversed(range(len(self.fvec))):
builder.PrependFloat32(self.fvec[i])
fvec = builder.EndVector()
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
MonsterExtraStart(builder)
MonsterExtraAddD0(builder, self.d0)
MonsterExtraAddD1(builder, self.d1)
MonsterExtraAddD2(builder, self.d2)
MonsterExtraAddD3(builder, self.d3)
MonsterExtraAddF0(builder, self.f0)
MonsterExtraAddF1(builder, self.f1)
MonsterExtraAddF2(builder, self.f2)
MonsterExtraAddF3(builder, self.f3)
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
if self.dvec is not None:
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
MonsterExtraAddDvec(builder, dvec)
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
if self.fvec is not None:
Keep methods with struct name and switch them to default (#6879) * Keep methods with struct name and switch them to default This PR can help fix the following two issues: 1): A set of simplified API (without struct name) was added in https://github.com/google/flatbuffers/pull/6336. It causes name conflict when merging all generated python file into a single one (the primary usage senario in Google). 2): Flatbuffers 2.0 generates absolute import path, which may cause name space conflicts. See more details in https://github.com/google/flatbuffers/issues/5840. The solution for both is to generate the merged Python code, similar C++. The merged code will not contain the simplied API, but only the method with struct name. For issue (1), it will mimic the exactly usage pattern for Google internal. For issue (2), users can generate the merged flatbuffer code, without worrying about the imports. The above idea will be implemented in the following steps: Step 1 (this PR): revert changes in https://github.com/google/flatbuffers/pull/6336 that set the simplified API as default. Remove statements that the original API will be deprecated, and reset the original API as default. Step 2 (the following PR): create a flag to generate the merged code. The Simplified API will be removed from the merged code, otherwise it will cause name conflict. * Update the generated sample code * Update the generated example code * Reverst the changes of GetRootAs * Update examples from grpc/example/generate.sh
2021-11-04 22:12:25 +00:00
MonsterExtraAddFvec(builder, fvec)
monsterExtra = MonsterExtraEnd(builder)
Flatbuffers Python Object API (#5616) * Flatbuffers Python Object API Implement the logic to generate the Python object API that can unpack the data from a buf class into an object class, and pack the data of an object class to a buf class. * Fix the build issues Remove unused parameters and replace auto in the for-loop statement with std::string to make it compatible with VS2010. * Fix the build issues. * Add support for Array type Added logic to handle Array type in Python Object API. Updated the generated code accordingly. * Fix the old style casting from int to char * Fixed another conversion from int to char * Fixed the import for typing Importing typing may cause errors when a machine do not have the moduel typing installed. This PR fixes the issue by guarding "import typing" with the "try/except" statement. * Fix issue of iterating the vector of import list * Update the generated examples using generate_code.sh * Fix the import order for typing The import list was stored in unordered_set, so that each generated codes may have different import order. Therefore, it failed in the consistency test where two generated copies need to have exactly the same apperance. * Optimize unpack using numpy Use numpy to unpack vector whenever it is possible to improve unpack performance. Also, added codegen command for Python specificly in generate_code.sh, because --no-includes cannot be turn on for Python. * Fix the import order * Update generate_code.bat for windows accordingly * Replace error message with pass Avoid printing error message for every Python2 users about typing. Replace it with pass.
2019-12-02 22:11:28 +00:00
return monsterExtra