- 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.
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 Python 2 defaults, i.e. don't import.
Since the tool is available for Python 2 and 3, it makes sense. It's a shell tool, not a programming tool. You want to have the same behavior as much as possible everywhere, and not have to think about which Python you are using right now. Any system other than windows will likely have several versions of Python installed.
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.
It wasn't me, but I can understand that for sharing scripts this should be quite useful. Also, I think the Python 3 division is way more logical (like most things in Python 3) and the old division is only one / more away. (// is integer division)
Also in a shared code base where you use division this is almost always necessary, or at least easier.
I had used a very similar one for a while https://github.com/ksamuel/Pyped and found it quite useful. In that other utility they mention "'py' has been renamed to 'pyp' to avoid conflict with the new tool in the Python stdlib named 'py'" I wonder if such a problem would arise for your project.
Yes, the name is controversial. But it's also highly functional. I do recommend that you try out pythonpy even though you have already tried one of the other similar tools. I think you'll find it to be simpler, without losing much in terms of functionality. Also, the others haven't implemented ipython style tab completion from the command line.
You're not really addressing the one concern voiced in the post you are replying to. As much as you might find the above information interesting, I'm sure tucif wasn't looking for a sales pitch.
I've reinvented the wheel myself and made "pype" (link below).
I've been using python on the command line for quite a while, but I found that I tend to use it when I'm doing something a little more advanced than what can easily be done with standard Linux tools - and command line python would often fail me, because I couldn't easily do conditions or loops, because of the requirement for whitespace indenting. So pype contains a simple parser that'll convert bracket indented code to regular whitespace indented code, besides supporting all the stuff you want on the command line.
I didn't think I'd need something like this but it actually seems like it could be quite useful.
I think the "killer" feature is the -x modifer to apply the scriptlet to every line of input. it seems like a nice way of sticking a quick python function into a pipe of commands for when you want that little bit more than the shell (or sed) is offering you.
This is awesome...Right now I'm teaching a class that starts off with bash and doing everything from the command line, and then moving into Python...the more that I can have students do from the command-line, the easier it is to get the concept of functional programming/pipes/filters across.
It's required to prevent the shell from interpreting and expanding special characters. e.g. in the example you provide, without quotes * will be expanded to a list of files in the current directory.
"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!
My thoughts as well. Sure I know there is an apparent wealth of command line utilities that can do everything you want and more. But not everyone knows those.
Take me for instance: I know a couple of programming laguages pretty well and know how to do most of the typical awk/sed/grep/... functionality in them by hart. I don't do a lot of command line work though, and never came around to learning it properly, so when I do and have to do something like 'move all files if some condition is true'/'do x for files containing y' and so on it's always the same struggle - couple of options:
- start googling around till solution found using awk/sed/... crawl through sometimes awkward syntax and require multiple dummy runs or on copies od data (not nice if it's in the TB ranges) to make sure I don't screw something up
- once and for all learn the ins and outs of awk/sed/...; not sure if the amount of time I'd have to spend on it is worth it
- start an IDE, write some C++ or C#, enter debugger and fix things on the go until correct. The process is usually way faster than the above one since I know syntax and needed methods by hart
- write Python/MsBuild script
- use something like pythonpy
Usually any of these except the first two seem a better idea in my case. So next time I'm definitely going to try the last one out.
You could certainly make an argument that people who are just starting to learn Python should learn Python 3 instead of 2 no? And that being the case, it'd be nice if they could just use what they are used to instead of having to learn all the changes on top of the language itself
You could make that statement, but without giving a reason its less reason and more religion. Either way, I'd counter that for someone starting out, python 2 vs 3 is irrelevant - learning core features, pythonic style, exception handling and testing should be the focus. In fact, even more so if they ultimately intend to use python 3 because they're going to have to refactor or completely rewrite the huge number of third party libraries which haven't been ported yet.
FWIW, I've been working as an enterprise dev in finance tech for a decade and have yet to see or hear of anyone using python 3 in that setting. My current firm is a global industry leader with arguably the most advanced and costly system of its kind ever conceived - it runs on 32 bit Python 2.6.
In general, if you want to have gainful employment you're best served by not being attached to any one language because most of enterprise runs everything a few versions back as they've learned the cutting edge is not a cliche - it's literal.
I think you misunderstand me; I was only trying to answer your question, "why sad face?"
I didn't give a reason because I wasn't trying to say Python 3 is better than Python 2. I was only stating that one could make the argument that a beginner would be better off learning Python 3 instead of Python 2, being that it's generally accepted that neither are necessarily bad. And from that it seems reasonable to assume some people have learned Python 3 but not Python 2. And finally, being that there are people who have learned Python 3 but not 2, someone might post a "sad face" because they want to use what they are comfortable with instead of being forced to learn something new.
I don't disagree with any of your points. But I don't think it should be hard to imagine there might be some people out there with different backgrounds or goals who would be better suited to learning Python 3 or at least for who the choice would not lean too heavily one way or the other.
Obviously not everyone is planning to work in your industry or even learning Python for the sake of using it for a (future) job.
- 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.