Neat. I'm curious why the quotes around the commands are necessary. Why "py '3 * 1.5'" instead of just "py 3 * 1.5"?
Pythonpy – Command-line Kung Fu with Python
21–30 of 40 posts
Re: Pythonpy – Command-line Kung Fu with Python
#22Very nice. However, division behavior was unexpected in Python 2. It looks like it imports division from __future__ without asking. python -V Python 2.7.8 python -c 'print(4 / 3)' 1 In [1]: 4 / 3 Out[1]: 1 py '4 / 3' 1.33333333333 EDIT: Yes, it does do that import, and others from __future__. Unless these imports are essential to the operation of pythonpy, I suggest making these optional/configurable, and default to…
OK, someone downvoted this. That's OK, but can you say why you think it's good for the default in Python 2 to not act like Python 2?
/ for float division, // for integer division.
Re: Pythonpy – Command-line Kung Fu with Python
#23To me, the auto import is such a game changer compared to every other implementation (including my own: http://github.com/samzhang111/pit).
Re: Pythonpy – Command-line Kung Fu with Python
#24"Sys admin" type usage definitely drives adoption/popularity/usage of a language (e.g., see perl; and people like doing sysadmin stuff with ruby). I would love, love to have something close to pythonpy in the python core. The absence of being able to cleanly fit into standard UNIX pipe / 'filter' type workflows is a real downer for python for me and for others trying to do "sys admin" workflows.
If you were to invent a time machine and put something close to this (pythonpy) in core python ~15 years ago, then I literally think python would be more popular today (and even maybe chef and/or puppet might have been written in python. That said, rewinding time and playing it forward is a bit challenging, so I suppose we'll never know. ;-)
One-liners play a big role in sysadmin type usage. I'm not a sysadmin, but I have to frequently hop on different boxes to see what the heck is going on. Typical use might be something like "whoa, lot of files here... how many the heck files are there?", which is answered with a simple 'wc -l', but then you start asking other question like "how many big files" and "what's the average file size", etc., etc., and you start putting together longer one liners chaining together sed and awk and gawk and sh and bash and perl (including to pick up a convenient modern regex engine, which awk is not), etc., and doing it all in an extremely fast iterative run/press up arrow a few times/edit/run cycle... but for me, even though I like python, only very rarely do I use a python one-liner.
In general, some one liners sometimes grow, and then grow some more, and then some graduate to a script that then graduates to a full-fledged project. Python sometimes effectively gets eliminated from the running for a project at step 0.
I like using the right language for the job, and have no problem using multiple languages on a large or medium sized project... but it slows me down and causes me some mental agita to use 2-3 languages on a tiny project like a one liner (where I'm counting mini-languages like awk/sed here).
I'd love to use python as my default "go to language" for one liners... This project (pythonpy) and other projects help, but really for me good support for python one liners needs to be in the core default python so that when I hop on some random box to troubleshoot something for one of many teams, that capability is there waiting for me (and the absence of that "just being there waiting" is what killed my usage of my own version of a simple "improved one-liner support for python" package; our environment was too diverse and too often in practice it ended up being faster for me to use perl or ___, rather than going through the hurdle of installing a python module, which in some cases is more or less frowned upon for production boxes).
Based on a quick initial review, pythonpy looks better than some of the alternative efforts. Love the tab completion!
Re: Pythonpy – Command-line Kung Fu with Python
#25I've been looking for this since I last saw it. Thanks for posting it! To me, the auto import is such a game changer compared to every other implementation (including my own: http://github.com/samzhang111/pit ).
Re: Pythonpy – Command-line Kung Fu with Python
#26- sony did a project like this : power at prompt (https://code.google.com/p/pyp/).
- an alternative exists to both : pyped (https://pypi.python.org/pypi/Pyped/1.4) I like it better because it packs many utilities, but that's a matter of taste.
- other projects like that existed prior this one doing the same thing. The author choose to reinvent the wheel instead of contributing. I tend to dislike this behavior.
- both alternatives uses the "pyp" command, instead of the "py" command. The reason is that the "py" command is now an official command in Python on Windows. Installing pythonpy will cause a conflict.
Re: Pythonpy – Command-line Kung Fu with Python
#27Very nice. However, division behavior was unexpected in Python 2. It looks like it imports division from __future__ without asking. python -V Python 2.7.8 python -c 'print(4 / 3)' 1 In [1]: 4 / 3 Out[1]: 1 py '4 / 3' 1.33333333333 EDIT: Yes, it does do that import, and others from __future__. Unless these imports are essential to the operation of pythonpy, I suggest making these optional/configurable, and default to…
Plus, it's easier to type // to get the old behavior than it would be to type from operator import truediv to get the new behavior otherwise.
Re: Pythonpy – Command-line Kung Fu with Python
#28Re: Pythonpy – Command-line Kung Fu with Python
#29* Python expressions on the command line
* That are connected by piping
* But in a single python process
* And adding distribution
* And database access
Re: Pythonpy – Command-line Kung Fu with Python
#30Note that : - sony did a project like this : power at prompt ( https://code.google.com/p/pyp/ ). - an alternative exists to both : pyped ( https://pypi.python.org/pypi/Pyped/1.4 ) I like it better because it packs many utilities, but that's a matter of taste. - other projects like that existed prior this one doing the same thing. The author choose to reinvent the wheel instead of contributing. I tend to dislike this…