On Jan 5, 2020, at 00:17, James Lu <jamtlu@gmail.com> wrote:

 I use macOS, and using Python is very confusing.

- Apple's bundled Python 2.7.

Apple has made a mess of things, but they’ve actually fixed that mess in 10.15—they now give you 3.7 and 2.7, and neither one is broken or weird. That being said, I don’t think anyone trusts them to not to change their minds again and leave everything without updates for half a decade to the point where their pre-installed Python is more of a nuisance than helpful. So everyone is still using Homebrew or Anaconda, and you probably should as well. I think there’s more reason than ever for developers to learn virtual environments early and never have to think about all the different Pythons they have installed except whole setting up a new env. But you’re apparently concerned about end users, not devs here. So:

Python, Be Bold captures the spirit of it should not be a shame to have the interpreter/VM installed on end-users machines. It also facilitates the work of other python devs. You installed it because of one Python program, other programs benefit from it. It also proposes enhancements to the VM to better facilitate that.

There’s already a better solution for end users today. You don’t install Python to run Spam, you just `brew install spam`, and if Spam requires Python 3.7 and you don’t have it, Homebrew installs it for you. And if you just `brew install eggs` and Eggs also requires 3.7 and you’ve already got it from installing Spam, it uses the same 3.7. You don’t even have to know you have Python installed, much less know which versions you have. Of course this means someone has to build a Homebrew recipe—and RPM and DEB and Portage and Choco—for every application, but people have already been doing that for decades, and it works. For users who do want to know they have Python installed, there are a lot of “power user” apps that they can install the same way they do libraries: `pip install cheese`. This also already works today. I suppose it would be even better if the whole world used one single package manager that worked the same on every platform, and pip/setuptools could just be a trivial way to hook into that rather than an entirely separate system. But I don’t see any way to solve that from inside the Python ecosystem. The closest you can get is probably Anaconda—which already exists and already works fine.

One big reason the web is a popular platform today among the general public

is because it offers strong sandboxing,

The web was popular long before it offered strong sandboxing. That sandboxing had to be wedged in after the fact, because the web had become so popular that millions of people who didn’t know how to deal with security issues were visiting dynamic websites with IE4 and Netscape and getting hacked, tracked, scammed, and spammed.

and privelges are granted per-site, opt out by default. Another reason the web is popular is because it loads quickly. I suggest python apps feature sandboxing with a way to opt-in to special permissions.

How? In CPython, unlike the browser, you have direct access to the filesystem, and the sockets layer. You even have hooks to load any dylib/so/dll and call functions out of it. So it can only be sandboxed the same way C can be sandboxed. Which means only the OS can do it. There have been attempts to build a useful environment out of Python by removing all of those features, and then adding in other, more restricted ways of doing the things you really need to do (access sandboxed local storage, talk to web services, accept connections as a web service, etc.). The most successful is probably Google App Engine. But GAE Python doesn’t feel the same as Python. It can’t do a lot of the things you can do with a normal Python install. And with version 2.0, Google scrapped all of that and went back to building things around a normal Python instead. If you wanted to do the same thing for end users instead of web services, you’d need to provide some way to run a GUI, to accept local files by some mechanism like drag&drop, etc. At which point you’re just designing a web browser. You might as well just write a Python interpreter that runs in the browser, and then add hooks to talk to the DOM and do WebSockets and make AJAX requests and so on the same way JS does. And there are already multiple projects to do that.

Perhaps, like the web, it could have a uniform distribution mechanism. I suggest DNS.

Why not just use URIs the same way browser JS and most of the existing browser Python projects do? What benefit do you get from building a custom package manager when every app has to be sandboxed and therefore can’t share packages with any other app?

I am suggesting Python compete with the web by implementing strong language sandboxing. I imagine a browser that can load regular web and "PyWeb."

A web browser is both a kernel and a VM for the web. The kernel interfaces with the underlying OS: Linux, windows, MacOS. I do not see "PyWeb" as a kernel, but I do see it as a VM. PyWeb would merely provide a secure gatekeeper to the underlying operating system. Like the Mac App Store, PyWeb could give each app its own sandboxed file system.

The Mac App Store doesn’t do that; macOS’s sandbox and related APIs and services do. All the App Store does is give you a way to get apps signed by Apple so that (by default) macOS assumes the entitlements are ok without popping up a bunch of dialogs asking you. And that only works because you left those defaults alone because trust Apple to vet everything carefully and not sign apps that silently abuse entitlements (or break any of the other rules required in their documentation). And that only works because Apple pays a team of hundreds of highly trained people doing that vetting. Who would do the same for your idea? The web works because it goes about things the opposite way. Somewhat like GAE, it doesn’t provide a filesystem or sockets or ctypes and try to sandbox them; it leaves all of that out entirely, and then adds in ways to do much more limited things. And there are plenty of things you can’t easily do in a web app. You can’t run as a filter on the command line, or a droplet on the desktop, or use native UI widgets. You can’t interface with hardware over a serial port. You can’t act as a service to other applications. You can’t scan the user’s iTunes libraries for tracks, or load the user’s installed Audio Unit effects plugins, or access multiple audio interfaces. You can’t access hardware acceleration for video decoding except by asking the browser to play the video. And so on. There are a lot of useful things you _can_ do in a web app, but again, the easiest way to do the same for Python is to just run Python inside the same environment with the same features, which there are already projects to do. If you instead want to reinvent that whole wheel, you might come up with something better, but you’re looking at a gigantic task—and one that’s way outside the mission of Python; it would be an entirely separate project that you’d have to organize and recruit people for that just makes use of Python. And why even make it Python-specific? Why not also provide JS, Ruby, Lua, etc. bindings to your environment? The fact that the browser environment wasn’t originally designed for anything but JS is the only reason “Python in the browser” is a major project rather than trivial.

On Jan 5, 2020, at 00:17, James Lu <jamtlu@gmail.com> wrote:

 I use macOS, and using Python is very confusing.

- Apple's bundled Python 2.7.

Apple has made a mess of things, but they’ve actually fixed that mess in 10.15—they now give you 3.7 and 2.7, and neither one is broken or weird. That being said, I don’t think anyone trusts them to not to change their minds again and leave everything without updates for half a decade to the point where their pre-installed Python is more of a nuisance than helpful. So everyone is still using Homebrew or Anaconda, and you probably should as well. I think there’s more reason than ever for developers to learn virtual environments early and never have to think about all the different Pythons they have installed except whole setting up a new env. But you’re apparently concerned about end users, not devs here. So:

Python, Be Bold captures the spirit of it should not be a shame to have the interpreter/VM installed on end-users machines. It also facilitates the work of other python devs. You installed it because of one Python program, other programs benefit from it. It also proposes enhancements to the VM to better facilitate that.

There’s already a better solution for end users today. You don’t install Python to run Spam, you just `brew install spam`, and if Spam requires Python 3.7 and you don’t have it, Homebrew installs it for you. And if you just `brew install eggs` and Eggs also requires 3.7 and you’ve already got it from installing Spam, it uses the same 3.7. You don’t even have to know you have Python installed, much less know which versions you have. Of course this means someone has to build a Homebrew recipe—and RPM and DEB and Portage and Choco—for every application, but people have already been doing that for decades, and it works. For users who do want to know they have Python installed, there are a lot of “power user” apps that they can install the same way they do libraries: `pip install cheese`. This also already works today. I suppose it would be even better if the whole world used one single package manager that worked the same on every platform, and pip/setuptools could just be a trivial way to hook into that rather than an entirely separate system. But I don’t see any way to solve that from inside the Python ecosystem. The closest you can get is probably Anaconda—which already exists and already works fine.

One big reason the web is a popular platform today among the general public

is because it offers strong sandboxing,

The web was popular long before it offered strong sandboxing. That sandboxing had to be wedged in after the fact, because the web had become so popular that millions of people who didn’t know how to deal with security issues were visiting dynamic websites with IE4 and Netscape and getting hacked, tracked, scammed, and spammed.

and privelges are granted per-site, opt out by default. Another reason the web is popular is because it loads quickly. I suggest python apps feature sandboxing with a way to opt-in to special permissions.

How? In CPython, unlike the browser, you have direct access to the filesystem, and the sockets layer. You even have hooks to load any dylib/so/dll and call functions out of it. So it can only be sandboxed the same way C can be sandboxed. Which means only the OS can do it. There have been attempts to build a useful environment out of Python by removing all of those features, and then adding in other, more restricted ways of doing the things you really need to do (access sandboxed local storage, talk to web services, accept connections as a web service, etc.). The most successful is probably Google App Engine. But GAE Python doesn’t feel the same as Python. It can’t do a lot of the things you can do with a normal Python install. And with version 2.0, Google scrapped all of that and went back to building things around a normal Python instead. If you wanted to do the same thing for end users instead of web services, you’d need to provide some way to run a GUI, to accept local files by some mechanism like drag&drop, etc. At which point you’re just designing a web browser. You might as well just write a Python interpreter that runs in the browser, and then add hooks to talk to the DOM and do WebSockets and make AJAX requests and so on the same way JS does. And there are already multiple projects to do that.

Perhaps, like the web, it could have a uniform distribution mechanism. I suggest DNS.

Why not just use URIs the same way browser JS and most of the existing browser Python projects do? What benefit do you get from building a custom package manager when every app has to be sandboxed and therefore can’t share packages with any other app?

I am suggesting Python compete with the web by implementing strong language sandboxing. I imagine a browser that can load regular web and "PyWeb."

A web browser is both a kernel and a VM for the web. The kernel interfaces with the underlying OS: Linux, windows, MacOS. I do not see "PyWeb" as a kernel, but I do see it as a VM. PyWeb would merely provide a secure gatekeeper to the underlying operating system. Like the Mac App Store, PyWeb could give each app its own sandboxed file system.

The Mac App Store doesn’t do that; macOS’s sandbox and related APIs and services do. All the App Store does is give you a way to get apps signed by Apple so that (by default) macOS assumes the entitlements are ok without popping up a bunch of dialogs asking you. And that only works because you left those defaults alone because trust Apple to vet everything carefully and not sign apps that silently abuse entitlements (or break any of the other rules required in their documentation). And that only works because Apple pays a team of hundreds of highly trained people doing that vetting. Who would do the same for your idea? The web works because it goes about things the opposite way. Somewhat like GAE, it doesn’t provide a filesystem or sockets or ctypes and try to sandbox them; it leaves all of that out entirely, and then adds in ways to do much more limited things. And there are plenty of things you can’t easily do in a web app. You can’t run as a filter on the command line, or a droplet on the desktop, or use native UI widgets. You can’t interface with hardware over a serial port. You can’t act as a service to other applications. You can’t scan the user’s iTunes libraries for tracks, or load the user’s installed Audio Unit effects plugins, or access multiple audio interfaces. You can’t access hardware acceleration for video decoding except by asking the browser to play the video. And so on. There are a lot of useful things you _can_ do in a web app, but again, the easiest way to do the same for Python is to just run Python inside the same environment with the same features, which there are already projects to do. If you instead want to reinvent that whole wheel, you might come up with something better, but you’re looking at a gigantic task—and one that’s way outside the mission of Python; it would be an entirely separate project that you’d have to organize and recruit people for that just makes use of Python. And why even make it Python-specific? Why not also provide JS, Ruby, Lua, etc. bindings to your environment? The fact that the browser environment wasn’t originally designed for anything but JS is the only reason “Python in the browser” is a major project rather than trivial.