Go Syntax Implementation in Python | Hacker News Reader

Go Syntax Implementation in Python

github.com

45 pointsokcy101613 comments

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.

That is true, and you are right.

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.

Thanks again :D

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. (￣▽￣)"

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.

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.

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~

It would be better to emulate difer with with context manager.

I guess you're talking about _defer_? https://gist.github.com/adisbladis/6e6241e1f0cc1b3ed8c183198...

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!

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.

Why not just use go?

Reply on news.ycombinator.com