it'd be really cool if we could drop virtualenvs + requirements.txt altogether, i.e., like deno, mordern javascript and so... i.e. instead of `pip install package` and `import package` and `pip freeze > requirements.txt` for every import, we stick to, for every python script `abc = import("package", "2.*")` from imports could be done like `value = import("package", "1.*").value ` this completely removes the virtualenvs issue, and solves alot of problematic issues with python imports
I am unclear on what you mean by "for every import". I have never once done this and I maintain half a dozen packages. Do people really not know what the requirements of the package they are authoring are?
we stick to, for every python script `abc = import("package", "2.*")`
I definitely don't want to worry about which version of a package I need at a module level.
from imports could be done like `value = import("package", "1.*").value `
You might want to read about the difference between: `from package import module` and `import package.module as module` https://docs.python.org/3/reference/simple_stmts.html#the-import-statement
this completely removes the virtualenvs issue
??? Virtuelenv is amazing.
and solves alot of problematic issues with python imports
??? On Wed, Jun 10, 2020 at 9:50 AM Aditya Shankar <aditniru@gmail.com> wrote:
What if you want to import a lib in two different scripts, would you have to call your import function with the given version (and permissions I suppose, if you want to follow Deno's path) every time ? IMHO, being able to set the permissions of an imported library like Deno does could be interesting to protect Python users, but that would mean having to specify the permissions of the lib, ie. it wouldn't be able to write any file or start any kind of background process by default, unless explicitly granted by your module.
Do note that is not as easy as it seems as you would have to figure out how to manage dependencies appropriately, especially if you are going to support using different versions at the same time. Otherwise you could write your own function today to see if you can get a proof-of-concept working as the `import` statement isn't anything special and everything it does is implemented in Python already. On Wed, Jun 10, 2020 at 9:47 AM Aditya Shankar <aditniru@gmail.com> wrote:
I am unclear on what you mean by "for every import". I have never once done this and I maintain half a dozen packages. Do people really not know what the requirements of the package they are authoring are?
we stick to, for every python script `abc = import("package", "2.*")`
I definitely don't want to worry about which version of a package I need at a module level.
from imports could be done like `value = import("package", "1.*").value `
You might want to read about the difference between: `from package import module` and `import package.module as module` https://docs.python.org/3/reference/simple_stmts.html#the-import-statement
this completely removes the virtualenvs issue
??? Virtuelenv is amazing.
and solves alot of problematic issues with python imports
??? On Wed, Jun 10, 2020 at 9:50 AM Aditya Shankar <aditniru@gmail.com> wrote:
What if you want to import a lib in two different scripts, would you have to call your import function with the given version (and permissions I suppose, if you want to follow Deno's path) every time ? IMHO, being able to set the permissions of an imported library like Deno does could be interesting to protect Python users, but that would mean having to specify the permissions of the lib, ie. it wouldn't be able to write any file or start any kind of background process by default, unless explicitly granted by your module.
Do note that is not as easy as it seems as you would have to figure out how to manage dependencies appropriately, especially if you are going to support using different versions at the same time. Otherwise you could write your own function today to see if you can get a proof-of-concept working as the `import` statement isn't anything special and everything it does is implemented in Python already. On Wed, Jun 10, 2020 at 9:47 AM Aditya Shankar <aditniru@gmail.com> wrote:
participants (4)
-
Aditya Shankar -
Brett Cannon -
Caleb Donovick -
J. Pic