Congratulations on your book! I am fortunate enough to know quite a few languages, so I decided to pick one for all my needs and it seemed Python fit them. Then I recently read on HN "Why Python is not the Language of the Future"
I think Python definitely has its drawbacks, and it's not fast. The other downsides listed in that article (whitespace, variable scoping, lambdas, mobile, etc.) may also be get in your way sometimes, but seems doubtful that they are language killers...I agree the argument presented in that article is weak.
I'm biased, but I think Python as your daily driver language is a great choice.
Preamble: I like Python - it seems to fit my mental models well, and I'm productive writing in it. However, only just recently I tried to develop a more-than-trivial program to deploy as an executable for my Windows-using friends. This may sound naive, but I'd never thought about how hard it is, especially when mostly everything else in Python is well-tooled, well-documented, and works. If you check my post history you'll see I've been following this subject lately... in the hopes I won't have to re-write my stuff in C# or something. I got it done, but am thoroughly underwhelmed by the experience and the resulting size of the executable (due to cascading dependencies that I'd really rather not pick apart).
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!)
Hey, I did try it - it was how I got it to work at all. Relatively simpler than the alternatives, IMHO, but still suffering from the large executable size due to dependency cascades
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.
That article is very strange. All the weaknesses it lists have been around since the start. And how exactly have they impeded Python's growth till now?
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.
> And how exactly have they impeded Python's growth till now?
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?
I'm having a hard time seeing failure to take over mobile as a serious problem, any more than I see it as a serious problem that I can't take people waterskiing with my bicycle. I would even argue that many of the things that make my bike a terrible watercraft also happen to make it great as a light terrestrial vehicle.
It's just possible that not every thing needs to be everything.
For starters, being just-in-time compiled makes for a nice short feedback cycle when you're developing. That's great for scripting, data science, exploratory development, even Web development since it facilitates a nice hot code reloading experience. But it also completely disqualifies it from running on iOS, which enforces a (understandable, IMO) ban on JITing.
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.
> 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.
https://news.ycombinator.com/item?id=27562931
The arguments put forth seemed weak, but wondered what you thought
reply