From CoinBureau:
Vyper is a smart contract language paradigm deriving from Python 3 syntax and conventions and targeting the Ethereum Virtual Machine (EVM).
The EVM is a simulated global singleton computer which runs parallel to the block-chained ledger on Ethereum, allowing for the construction of more complex transactions and conditional self-executing agreements encoded smart contract objects.
The Ethereum platform itself is featureless and value agnostic, providing only the backbone of how smart contracts are to be put together and in the context of what applications.
Vyper is intended to be leveraged with the upcoming transition to Proof-of-Stake (Casper) and provide a more pragmatic minimalist regime for reading and writing of smart contracts, with focus on auditability, syntactical simplicity and straightforwardness.
In that, Vyper deviates sharply from the de facto mainstream Solidity. Since on-chain computations are resource constrained, they should be as strictly defined within the bare minimum necessity of their intended function, and Vyper takes this reductive approach to smart contracts, framing them as easily readable user roles and stories while leaving almost everything else out.
An immediately noticeable departure from Solidity is the doing away with inheritance so as to keep things “on the same page” rather than getting lost in jumping between multiple contract files in the hierarchy of their precedence in order to piece together the scattered fragments of what a program is doing under the hood.
Instead, emphasis is put on refined, stripped down composition and modularity (with types like owner, maintainer, token, deadline and possible expressions like “while gas left”) without, at the same time, relaxing any security assumptions, but rather enforcing syntactical transparency of making things immediately obvious and easily auditable, in line with the nature of contracts and distributed ledgers.
Security Features
Security is paramount in the context of smart contracts in a consensus integrated, globally distributed environment intended to function as a transparent notary and generalized institutional agency for writing trustless business logic.
In line with these goals, Vyper focuses on clarity of expression, rigorous clear-cut unambiguity and strong typing, and as such does away with operator overloading, trying to be as non-fragmented and articulate as possible (focus on the strictly necessary) in order to make it hard to write misleading code. In fact, it deliberately forbids some things in order to make them harder with the goal of increasing smart contract security by way of enforcing obvious, self-explanatory code patterns.
Recursive callings and infinite length loops are also excluded as opening the possibility for gas limit attacks and instead, Vyper aims to optimize gas metrics by estimating precise upper bounds for the gas consumption of any function call. Bounds and overflow checking for array accesses and arithmetic operations are included (no SafeMath library necessary) and no modifiers or constants are allowed to change the state.
Compiler Internals and Code Syntax
Vyper tries to stick to syntactical conventions close to the core of what they are describing, namely the EVM. Vyper scripts compile directly to EVM bytecode rather than get interpreted, unusual way of thinking about Python as this may be. Under the hood, both Vyper and Solidity compile to bytecode in the same fashion and sequence of steps, so they are largely inter-operable (and able to make external calls between each other’s contracts).
In brief, the code is taken up by a parser which disassembles it into an abstract syntax tree representation of the instructions, and from there a type checking process iterates through the tree assigning their corresponding types from bottom upward. After performing static analysis checks the bytecode is generated.
Syntactical structure, examples, etc. further below.