Charles Cooper

note: several of these are resolved as of v0.4.0b1 (b53a020c74857de33cf4fd1a6d24a398539758b1) but some still will not compile.

> I would imagine there's also the added benefit of no longer having to worry about anything related to Python when discussing features and syntax. This is a double edged...

i think constants can be thought of similarly to class or module-level variables in python, whereas immutables and storage variables are analogous to instance members. so i don't think the...

i think the `"pc_debugger"` is probably also dead. but i'm not convinced we want to give up some of the machinery here -- it could be useful to put PC...

we might just want to have a separate `types` section in the ast export

@0xalpharush is this fixed by https://github.com/vyperlang/vyper/pull/3829?

@trocher thanks for finding, will fix before release

> Note that with commit [d48438e](https://github.com/vyperlang/vyper/commit/d48438e10722db8fc9e74d8ed434745e3b0d31cf) > > The codegen no longer prevent the bug in certain case, leading contracts with side effect in `range` to compiles successfully: > >...

> Yes I agree, in this case there is no ambiguity or anything, my concern was rather about the semantics of `range` as I understood that it must always be...

I think the assertion is there for historical implementation reasons. There used to be a `clear()` function which performed what assigning to empty does now. The type was generated internally...