Nick Timkovich wrote: > Part of the argument was about using pure standard library so a > self-contained script/repo could run anywhere Python is in order to (e.g.) > bootstrap other testing environments and/or work within restricted ones, > just like your average shell script. A gigantic step up from there is using > *anything* not in the stdlib because you may need to copy a bunch of files > (venv creation), and download executable things from *the Internet* > (horrific to some). >
In my experience (though I am curious about yours!) of environments where this sort of constraint applies, it applies just as strongly to the use of a version of Python that's newer than the one the system came with. That means that adding something to the stdlib isn't a route to getting to use it particularly soon in such environments, either. Availability in environments that are conservative about new or additional software is just inherently a long-term project. As a thought experiment, imagine there were consensus today on adding some library of this flavor to the stdlib, and the work rapidly got done and got merged. It'd be released in Python 3.9, circa early 2021. That in turn would be picked up in the next Ubuntu LTS in 2022... and the next RHEL/CentOS perhaps in 2024, and its derivatives like Amazon Linux sometime after that. When would you predict it might be "just always there" in the environments you work with? In the parts of the industry I'm most familiar with, in fact, the lag from publication to practical availability is much shorter through PyPI than through the stdlib: it's common to run the system Python from an old Ubuntu release that's pushing the limit of its 5-year supported lifespan, but for better and worse to cheerfully run the latest anything that any developer at the company wants to pull in from PyPI. so a self-contained script/repo could run anywhere Python is in order to > (e.g.) bootstrap other testing environments and/or work within restricted > ones > For specifically this side of the constraints, though, I think there is hope for a technical solution! Doesn't help if you really can't pull in new code, but it does make bootstrapping far simpler at a technical level. The PyOxidizer project: https://github.com/indygreg/PyOxidizer makes it possible to bundle up (a) CPython including (a') the stdlib together with (b) some arbitrary set of Python libraries of your choice, all as a single statically-linked executable file. Then you can distribute that one file to other machines, and run it there, without needing to create temporary files or download stuff from the Internet or anything like that. In particular, you can have the executable behave just like `python` -- it runs scripts, offers a REPL, etc. -- except that it comes with not only the usual stdlib but also the extra libraries you bundled into it. So that's one thing I intend to do for Pysh, the library I described in a sibling thread: https://mail.python.org/archives/list/python-ideas@python.org/thread/DR6I2PYZHT5JUBNKBFOULTICBNFRZHKI/ You'll be able to write scripts with e.g. `#!/usr/bin/env python-pysh`, and then `python-pysh` is a single binary file which you just need to stick in `/usr/local/bin/` or `~/.local/bin/`; and in those scripts `import pysh` will work just as smoothly as `import subprocess`. (Or you can ignore that and get the library for your usual Python interpreter in the usual ways.) Greg On Mon, Aug 12, 2019 at 11:49 AM Nick Timkovich <prometheus...@gmail.com> wrote: > I actually gave a talk along these lines at the Chicago Python (ChiPy) > meetup last week: slides > https://docs.google.com/presentation/d/1v5z4f-FQkS-bQYE-Xv5SvA6cyaTiqlxs2w2CI1yZcAU/edit?usp=sharing > > Part of the argument was about using pure standard library so a > self-contained script/repo could run anywhere Python is in order to (e.g.) > bootstrap other testing environments and/or work within restricted ones, > just like your average shell script. A gigantic step up from there is using > *anything* not in the stdlib because you may need to copy a bunch of files > (venv creation), and download executable things from *the Internet* > (horrific to some). > > On Sat, Aug 10, 2019 at 11:03 PM David Mertz <me...@gnosis.cx> wrote: > >> In various different ways, also: >> >> https://pypi.org/project/bash/ >> >> https://pypi.org/project/python-pipe/ >> >> https://pypi.org/project/pypette/ >> >> https://pypi.org/project/shell/ >> >> Just a few I've seen before. Xonsh is pretty cool also. >> >> >> On Sat, Aug 10, 2019, 9:55 PM Christopher Barker <python...@gmail.com> >> wrote: >> >>> On Sat, Aug 10, 2019 at 6:53 AM David Mertz <me...@gnosis.cx> wrote: >>> >>>> Something very similar to this had been done many times in third party >>>> libraries. >>>> >>> >>> Check out Xonch for example: >>> >>> https://xon.sh/ >>> >>> -CHB >>> >>> >>> >>> >>>> None of those have become hugely popular, including none quite >>>> compelling me personally to do more than try them out as toys. >>>> >>>> It's too bad, in a way, since I love bash and use it all the time when >>>> it seems easier than Python. >>>> >>>> Your library is 100% certainly not going to become part of the standard >>>> library unless it can first become popular as a third party tool. If it >>>> does become popular that way, I wouldn't put it's odds of eventual soon to >>>> the standard library as higher than 5-10%. But that doesn't really matter, >>>> widespread use his 'pip install' world be a good thing in itself. >>>> >>>> On Sat, Aug 10, 2019, 7:52 AM Thiago Padilha <tpadilh...@gmail.com> >>>> wrote: >>>> >>>>> Python is often used a shell scripting language due to it being more >>>>> robust than traditional Unix shells for managing complex programs, but >>>>> it is significantly more verbose than Bash & friends for doing common >>>>> shell scripting tasks such as writing pipelines and redirection . >>>>> >>>>> I propose adding an idiomatic shell scripting API that uses Python >>>>> operator overloading in a way that allows invoking commands in a >>>>> Bash-like way. >>>>> >>>>> A fully working implementation (which I've been using in my personal >>>>> scripts) can be found at https://github.com/tarruda/python-ush/. Here >>>>> I will describe the basics of the API, more details in the github >>>>> README.rst (which is also a doctest for the project). >>>>> >>>>> Here's how one can create commands: >>>>> >>>>> >>> from shell import Shell >>>>> >>> sh = Shell() >>>>> >>> cat = sh('cat') >>>>> >>> ls = sh('ls') >>>>> >>> sort = sh('sort') >>>>> # or something like this: >>>>> >>> cat, ls, sort = sh('cat', 'ls', 'sort') >>>>> >>>>> The Shell class is the entry point of the API and it is used as a >>>>> factory for Command objects. For convenience we can add a builtin >>>>> Shell instance which is a also module from where commands can be >>>>> quickly imported from (idea taken from sh.py >>>>> http://amoffat.github.io/sh/): >>>>> >>>>> >>> from shell.sh import cat, ls, sort >>>>> >>>>> We can construct more complex commands by calling it with certain >>>>> arguments: >>>>> >>>>> >>> ls('-l', '-a', env={'LANG': 'C.UTF-8'}) >>>>> >>>>> And we can invoke the command by calling it without arguments: >>>>> >>>>> >>> ls() >>>>> # or >>>>> >>> ls('-l', '-a', env={'LANG': 'C.UTF-8'})() >>>>> >>>>> Invoking the command returns a tuple with the status code: >>>>> >>>>> >>> ls() >>>>> (0,) >>>>> >>>>> The are more ways to invoke a command other than calling it without >>>>> arguments. One such example is by iterating through it, which >>>>> automatically takes care of piping the output back to python: >>>>> >>>>> >>> files = [] >>>>> >>> for line in ls: >>>>> ... files.append(line) >>>>> >>>>> Pipelines can be easily created with the `|` operator: >>>>> >>>>> >>> ls = ls('--hide=*.txt', env={'LANG': 'C.UTF-8'}) >>>>> >>> sort = sort('--reverse') >>>>> >>> ls | sort >>>>> ls --hide=*.txt (env={'LANG': 'C.UTF-8'}) | sort --reverse >>>>> >>>>> Everything that can be done with Command objects, can also be done >>>>> with Pipeline objects: >>>>> >>>>> >>> (ls | sort)() >>>>> (0, 0) # single commands return a tuple to make the return value >>>>> compatible with Pipelines >>>>> >>> list(ls | sort) >>>>> [u'tests', u'setup.cfg', u'pytest.ini', u'bin', u'README.rst'] >>>>> >>>>> We also use the Pipeline syntax for redirecting input/output. >>>>> >>>>> # piping to a filename string redirects output to the file >>>>> >>> (ls | sort | '.stdout')() >>>>> (0, 0) >>>>> >>> str(cat('.stdout')) >>>>> 'tests\nsetup.cfg\npytest.ini\nbin\nREADME.rst\n' >>>>> # piping from a filename string redirects input from the file >>>>> >>> str('setup.cfg' | cat) >>>>> '[metadata]\ndescription-file = >>>>> README.rst\n\n[bdist_wheel]\nuniversal=1\n' >>>>> >>>>> This is the basic idea. The current implementation only supports the >>>>> classic subprocess API, but I can probably make it compatible with >>>>> asyncio (to create async shells which spawns commands compatible with >>>>> `await`). >>>>> >>>>> Thoughts? Is it worth writing a PEP for this? >>>>> >>>>> Best regards, >>>>> Thiago. >>>>> _______________________________________________ >>>>> Python-ideas mailing list -- python-ideas@python.org >>>>> To unsubscribe send an email to python-ideas-le...@python.org >>>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>>>> Message archived at >>>>> https://mail.python.org/archives/list/python-ideas@python.org/message/NZSFQXBXCSRUR7HMJFEQBDFBQFN4P3SH/ >>>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>>> >>>> _______________________________________________ >>>> Python-ideas mailing list -- python-ideas@python.org >>>> To unsubscribe send an email to python-ideas-le...@python.org >>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>>> Message archived at >>>> https://mail.python.org/archives/list/python-ideas@python.org/message/ZTQQ3UF7CHTM7RIEHD4ZS3FXWJOCSJVA/ >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>> >>> >>> -- >>> Christopher Barker, PhD >>> >>> Python Language Consulting >>> - Teaching >>> - Scientific Software Development >>> - Desktop GUI and Web Development >>> - wxPython, numpy, scipy, Cython >>> _______________________________________________ >>> Python-ideas mailing list -- python-ideas@python.org >>> To unsubscribe send an email to python-ideas-le...@python.org >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/python-ideas@python.org/message/GETC2BB25PT4Q6UJOE4JYS3K3SLKFSDR/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> _______________________________________________ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/L7T4XRMWUXJQ7QAKDRNGYDONT7BK2JRV/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/BXD7HL4NFVW3OFKLHL3HVKANQSEMNDKT/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5XZLY6NQCQCHZFVIWO2LS222ULDTY37S/ Code of Conduct: http://python.org/psf/codeofconduct/
