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.
Adding to that, it's important to keep in mind that goroutines are not OS threads but coroutines, which are more lightweight. Providing a "go" function that starts a thread may be a footgun if someone assumes that it can be used as extensively as it is possible in Go.
Thanks for your opinion. This project is so tiny, and it is based on package `threading`. We used the 'wild ways' as you mentioned before, but we just don't want to copy the same code into every project or to pass the original arguments as a tuple(like 'threading.Thread' does). So we made a pip package.
As for 'defer'... The original reason why we implement 'defer' is that the name 'gogo' is used by someone else. Since 'gostyle' is the only choice, we tried to implement something else other than 'go' statement. So now we have 'defer' here...
Python can do everything, so can golang. There would be nothing wrong if someone thinks that nothing is needed to be created. I believe everybody here knows how to use 'with' in python... But think about the cross-language packages(actually we are writing our project in go and python simultaneously), those packages can not rely on 'with'. If you are facing a cross-language package with no `__exit__` method implemented, I don't think having a 'defer' available is bad.
Everyone can use this package for fun or use it for just avoiding creating threads with arguments passed via a tuple. This package is so tiny, using it is costless anyhow.
(￣▽￣)"
This is an amateur project of my friend, and we're appreciate that you have provided so much useful opinions and thoughts of this project. We will take care and consider your delightful view carefully.
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.