
Go Syntax Implementation in Python - okcy1016
https://github.com/luoyusang2007/GoStyle
======
jerf
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.

~~~
rob74
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.

~~~
luoyusang2007
That is true, and you are right.

------
swiley
Idk, creating threads is something that should be done extremely carefully, it
almost always introduces a lot of complexity and the syntax around it is
probably the least of your problems.

------
ekimekim
If you're after golang-style concurrency in python, I suggest looking at
gevent.

It uses "greenlets" \- lightweight threads implemented in userspace - and
monkey patches the standard library to do cooperative multitasking. For
example, when you call socket.recv(), under the hood it will register with the
event loop to be woken up when that socket is readable, then yield to allow
other greenlets to run while it waits.

(note this is slightly different to golang's concurrency, which works
similarly but runs multiple OS threads so multiple goroutines can run at the
same time)

The equivalent to "go fn(1, 2, 3)" in gevent is "gevent.spawn(fn, 1, 2, 3)".
Any callable can be spawned this way, you don't need to pre-register functions
as "startable" like in OP's library.

~~~
luoyusang2007
Your opinion is great.

Actually we want to combine "threading", "gevent" and "multiprocessing"
together in this package. We can offer a unified API to handle different types
of concurrency in your application if your application is light-weight and is
not very performance-dependent. We don't know if it is necessary.

Additionally, if you don't want a "startable" statement in your code, you can
use our library in the following way: "go(fn)(arg1,arg2)". You don't have to
declare that the function is startable.

Happy 2020 anyhow~

------
h8hawk
It would be better to emulate _difer_ with _with_ context manager.

~~~
luoyusang2007
Actually we failed to do that. the "with" statement relies on "__exit__"
method. It is useful but too "Python" to emulate "defer" for us.

Thanks for your opinion!

------
timothycrosley
Reminder that we officially live in a post Python 2.x world. I think at this
point the correct answer to the awkwardness of threads is to use async.

------
pensatoio
Why not just use go?

