You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When compile Vyper contracts, also generate external callable Python Object Contract Mapper code, similar to Object Document Mapper in MongoDB.
Users can create or retrieve a Vyper contract, interact with it using Python methods, getting type hints and type validations using Pydantic inside IDE.
Motivation
EVM languages are typically without any OCM. They require users to figure out the boilerplate code and is highly error-prone, just like the early days in using SQL to interact with databases.
Vyper compiler is written in Python, and it shall be pretty natural to generate Python interfaces to interact with existing Python code. This can greatly enhance the capability of Vyper and reduce development time, encouraging more Python developers using Vyper as their first Web3 smart contract language.
Specification
The OCM can be obtained in two ways. One is to generate the OCM by contract ABI, the other is to write the OCM by hand.
OCM shall be a normal Python class, containing the constructor of the contract, method to retrieve existing contract by address, and all callable methods of the contract with type safe hints, also necessary method property like "pure" as docstring. In the future there might be some docstrings in Solidity or Vyper, and OCM shall extract them as well as generated method docstring.
Backwards Compatibility
This proposal is available for all EVM compilers that generates ABI. The compatibility shall only be related to the specification of ABI. For docstring extraction, it would be related to the Vyper language specification.
Dependencies
Pydantic: a popular Pythonic data validation library.
References
Brownie currrently includes an interactive environment but does not generate OCM Python code to interact with existing contracts. I have posted a similar issue here.
Boa is doing similar things like Brownie. I consider this as a generally unsolved problem in the Web3 world, along with the absence of a less storage and computation intensive blockchain node backend.
i guess i don't really understand this issue. the core vyper repository doesn't provide an environment for interacting with vyper contracts. that's the job of frameworks like titanoboa
In the sense of design, you are correct. However I just want to suggest the possibility of using pure Python to write smart contracts, just like Solana using Rust as smart contract language. Can we both compile and call smart contracts using the same Python file?
Simple Summary
When compile Vyper contracts, also generate external callable Python Object Contract Mapper code, similar to Object Document Mapper in MongoDB.
Users can create or retrieve a Vyper contract, interact with it using Python methods, getting type hints and type validations using Pydantic inside IDE.
Motivation
EVM languages are typically without any OCM. They require users to figure out the boilerplate code and is highly error-prone, just like the early days in using SQL to interact with databases.
Vyper compiler is written in Python, and it shall be pretty natural to generate Python interfaces to interact with existing Python code. This can greatly enhance the capability of Vyper and reduce development time, encouraging more Python developers using Vyper as their first Web3 smart contract language.
Specification
The OCM can be obtained in two ways. One is to generate the OCM by contract ABI, the other is to write the OCM by hand.
OCM shall be a normal Python class, containing the constructor of the contract, method to retrieve existing contract by address, and all callable methods of the contract with type safe hints, also necessary method property like "pure" as docstring. In the future there might be some docstrings in Solidity or Vyper, and OCM shall extract them as well as generated method docstring.
Backwards Compatibility
This proposal is available for all EVM compilers that generates ABI. The compatibility shall only be related to the specification of ABI. For docstring extraction, it would be related to the Vyper language specification.
Dependencies
Pydantic: a popular Pythonic data validation library.
References
Brownie currrently includes an interactive environment but does not generate OCM Python code to interact with existing contracts. I have posted a similar issue here.
Copyright
Copyright and related rights waived via CC0
The text was updated successfully, but these errors were encountered: