Caveat: It doesn't look like the submitter is the author, and the author doesn't have any indication on project that I can see about what the intention of the repo is. Any project is fine if you're just learning or screwing around and there's nothing that says you can't put it up on github or do whatever you like. The remainder of my post here will be from the point of view that it is public on the thought that other people should find it and use it in their own code; if that is not the case, I invite the author to ignore these criticisms.
It's rarely, if ever, a good idea to program X in Y, but it's certainly not a good idea when the inner-platform implementation of X is inferior to what Y already has. The distinguishing characteristic of Go's concurrency is arguably the multi-channel select, not the syntax around starting threads. In Python, you just shouldn't program that way and do other things. The built-in Queue object is already a decent approximation of a Go channel that can't participate in "select". Go is hardly the only language with that level of easy syntax to start a thread, and wrapping something around the threading in Python is so trivial I'm sure there are literally thousands of such functions in the wild. So that's not a terribly useful change.
Python doesn't need some faked up "defer", it has "with", which in the context of Python can already do quite a lot of useful things. It's a lot more powerful and complex than defer, but defer-like behavior is easily obtained by simply not using the other bits of complexity in "with" handlers.
All of the listed todo items would be better done by learning how to use the Python primitives for them than trying to bash Go idioms into the language.
I'd suggest adding a note to the top that this shouldn't be actually used. Unfortunately it seems like anything that doesn't get such a note will get pulled into production codebases otherwise, based on what I've found in said code bases. It's helpful to your fellow programmers to label code as not being intended for production.
It's rarely, if ever, a good idea to program X in Y, but it's certainly not a good idea when the inner-platform implementation of X is inferior to what Y already has. The distinguishing characteristic of Go's concurrency is arguably the multi-channel select, not the syntax around starting threads. In Python, you just shouldn't program that way and do other things. The built-in Queue object is already a decent approximation of a Go channel that can't participate in "select". Go is hardly the only language with that level of easy syntax to start a thread, and wrapping something around the threading in Python is so trivial I'm sure there are literally thousands of such functions in the wild. So that's not a terribly useful change.
Python doesn't need some faked up "defer", it has "with", which in the context of Python can already do quite a lot of useful things. It's a lot more powerful and complex than defer, but defer-like behavior is easily obtained by simply not using the other bits of complexity in "with" handlers.
All of the listed todo items would be better done by learning how to use the Python primitives for them than trying to bash Go idioms into the language.
I'd suggest adding a note to the top that this shouldn't be actually used. Unfortunately it seems like anything that doesn't get such a note will get pulled into production codebases otherwise, based on what I've found in said code bases. It's helpful to your fellow programmers to label code as not being intended for production.