https://news.ycombinator.com/item?id=27562931
The arguments put forth seemed weak, but wondered what you thought
I'm biased, but I think Python as your daily driver language is a great choice.
So here's the question - what's your take on how to package a Python program as an executable (wherein package does not mean Python package, but generate a click-and-run Windows executable)? Anything on that in the book? I can't tell from the 'Contents' list, but it seems not, right?
Congrats on the book. I'll take some time to go over the Extracts (and thanks for those, too!)
I'm at peace, now, with having to prune and bound my imports to account for that. But it is a negative thing that I have to change my code from what it'd normally be to make it remotely passable...
This is definitely a relatively smalln and maybe rare, but still a disadvantage of Python (that, in retrospect, I should've obviously have anticipated, so that's on me)
Yeah, you are correct---the book does not cover packaging a Python program as a click and run style executable.
It's definitely a tricky problem. (Depending on the audience for the tools (e.g. if it's developers), one potential option might be to package your code in a Docker image and distribute it that way---although that's not without its own drawbacks.)
Other commenters have posted potential tools to check out too.
E.g. [pp], [py2exe].
[pp]: https://metacpan.org/pod/pp
[py2exe]:https://github.com/py2exe/py2exe
> Python is slow. Like, really slow. On average, you’ll need about 2–10 times longer to complete a task with Python than with any other language.
But that is real nonsense. It is comparable with Ruby or Perl or other dynamic languages.
> In Python, inner scopes can only see outer scopes, but not change them.
Unless you explicitly declare your intent with a `nonlocal` declaration.
> This distinction between expressions and statements is rather arbitrary, and doesn’t occur in other languages.
This is technically true, but the phrasing is potentially misleading. There are some other languages where every statement is an expression, but most make a firm distinction. Including 2/3 of the languages that the article proposes as alternatives to Python.
There are genuine issues with Python: no mobile story (but how many other languages do?), and distribution is harder than it needs to be. The second is getting some attention, hopefully it'll be better soon.
Hard to be *exact* but presumably they have impeded growth in mobile? Swift has a 2% market share according to Google. Probably some performance people have migrated to rust or julia or stayed with the C family too?
It's just possible that not every thing needs to be everything.
Are there things about Python that make it great as a general programming languages, but not for mobile.
Perhaps the ease with which people reach for libs that wrap C? I dunno.
I'm not interested in arguing about the relative merits of dynamic typing in any sort of absolute sense, but I will say that there are a lot of use cases where I like it, and they happen to overlap nicely with Python's core use cases. But they're also a problem on mobile, where you're more resource-constrained, including having to worry about battery usage. All that pointer chasing does have a cost.
On the other hand, non-GC languages like C, Rust and Swift make sense on mobile, where you want consistently low UI latency and you're trying to keep memory usage down. But there are lots of back-end development scenarios where I'd rather not have to think much about memory.