It's clearly not designed for doing anything advanced, though: it's not like you can get access to platform-specific APIs outside of the basics without doing a lot of work.
You have the stdlib ctypes of course, but also pypy's cffi for an even better story.
We even have specialized ready to use tools for those, such as pywin32 to manipulate the windows api and registry, pyqt to leverage the c++ qt lib and all it's tooling, or watchdog to survey file changes, using the native api when possible.
In fact, mac and linuxes implement natively of lot of tools in their os for this reason.
There is also a reason it's one of the few languages allowed in prod at google. It's the best at nothing, but it's damn good at most things.
Not something I would call seamless.
> pyqt to leverage the c++ qt lib and all it's tooling
This isn't native.
> mac and linuxes implement natively of lot of tools in their os for this reason
Generally command line scripts, which is something that Python is good at.
> There is also a reason it's one of the few languages allowed in prod at google.
What Google allows in production has only an oblique relevance to whether it should be used for a specific task.
Can you explain how platform-specific stuff takes "a lot of work" with Python, and wouldn't with some other language that is not Python?
Sure, just look at a modern Cocoa app written in Swift, or Android one in Java, and compare it to the amount of work you'd have to do to shoehorn Python in there.
About 15.5 years ago while I was still a grad student, I released a (horribly designed, mostly self-experimentation) editor in Python + wxPython that I initially wrote to run on Windows. I didn't run it regularly in Linux or OS X until 2008, and it all just worked. OS X was a little laggy with my editor, but hey, write once run on 3 platforms.
Python is really solid on multi-platform, because there are so many Python users already using every platform that want to bring Python there.
You can do it hand-written assembly too, but usually it's more trouble than it's worth.
It's crossplatform, the task has not bottleneck for this vm, and it takes complexity down to one language. One language that as the very specific characteristic of being the best at nothing, but pretty good at everything, which in such an heterogenous software is what you want.
Which is why Dropbox uses 100% of the CPU while syncing? It's pretty clear that trying to handle thousands of files is not a trivial operation. Sure, Python can do the job, but something native will probably do the job faster.
> in such an heterogenous software is what you want
No, not really. I'd rather the software work well, and I'd rate Dropbox as "passable" rather than "great".
I'd say it's just a hard problem.
After all, the fs routines in python are all written in c, file watching uses the os api such as inotify, so python speed has little impact on those operations. Same for the gui. Same for the network since you only have a few connections to one server.
Dropbox doesn't even index the file content, so basically not many stri g or numerical operations. I've got 15 years of python behind me, and i'm pretty good at guessing what workload it's going to be slow at. This is not one of those.
Many people tried to compete with dropbox. None of them won, because eventually, their software either can't match the features, the perfs, the availability, the price, or the ease of use.
I should know, i tried to escape dropbox, as i don't like the company ethic stance, and tried many alterntive.
Dropbox is just very, very good.
iCloud Drive works pretty well for me.
> After all, the fs routines in python are all written in c, file watching uses the os api such as inotify, so python speed has little impact on those operations. Same for the gui. Same for the network since you only have a few connections to one server.
You'll notice that these aren't the things I mentioned as things you shouldn't be doing in Python, aside from the GUI, which I will maintain should not be done in Python. Writing parts of Dropbox in Python is fine, but there are places where they really shouldn't.