There are a lot of situations where Rust Vyper could emulate Python Vyper's syntax, but it seems sub-optimal to do that because Python Vyper's syntax seems to have been designed mostly to accommodate the Python parser.

From the point of view of Rust Vyper, it seems more and more like the Python parser is underpowered because it was designed for a dynamic language in which methods and variables don't require much annotation. This is because there aren't many restrictions on how methods and variables can be used in Python.

Here's a concrete example. If Rust Vyper followed Python Vyper's syntax, here are two different ways that things would be annotated to indicate that they're "public":

contract GuestBook:
    guest_book: public(map[address, bytes[100]])

    @public
    def sign(book_msg: bytes[100]):
        ...

Frankly, this is ugly and here are some reasons why:

• Storage variables and methods are being annotated in two entirely different ways. Storage variables use something like a "pseudo-function" called public that "returns" a new type public(map[address, bytes[100]]). On the other hand, methods use the python decorator syntax. Public methods are annotated by placing a @public directive on the line preceding the method declaration.
• Being forced to use the pseudo-function syntax for variable annotations means that having more than one annotation (if we ever want a feature like that) makes things very unreadable and forces the inclusion of lots of nested parentheses.

Now consider this alternative syntax:

contract GuestBook:
    pub guest_book: map[address, bytes[100]]

    pub def sign(book_msg: bytes[100]):
        ...

In my opinion, this is far more readable for the following reasons:

• Both property and method annotations use the same syntax.
• The annotations are at the front of the line where they are most visible.
• The keyword "pub" is shorter but no less expressive.

It seems like we could also elect to keep the decorator syntax in case we also want modifiers (which are a feature that I think was unfairly excluded from Vyper). But the qualification of a method as public or not could use a prefix keyword on the line of the method declaration.