On Fri, Apr 1, 2016, at 13:41, Michel Desmoulin wrote:

It's dangerous to talk about a new feature the 1st of April, so I'll start by saying this one is not a joke.

I read recently a proposal to allow md5 hashing doing python -m hashlib md5 filename.

I think it's a great idea, and that can extend this kind of API to other parts of Python such as:

python -m random randint 0 10 => print(random.randin(0, 10)) python -m random urandom 10 => print(os.urandom(10)) python -m uuid uuid4 => print(uuid.uuid4().hex) python -m uuid uuid3 => print(uuid.uuid3().hex)

Bikeshedding a bit, but how about just python -m uuid for print(str(uuid.uuid4()))?

On 1 April 2016 at 16:07, Victor Stinner <victor.stinner@gmail.com> wrote:

Hi,

2016-04-01 19:41 GMT+02:00 Michel Desmoulin <desmoulinmichel@gmail.com>:

...

I read recently a proposal to allow md5 hashing doing python -m hashlib md5 filename.

I think it's a great idea, and that can extend this kind of API to other parts of Python such as:

python -m random randint 0 10 => print(random.randin(0, 10))

How many times did you need this feature recently? I don't recall having to generate a random number in a range.

Well...actually, really recently (Tuesday), I did python3 -c "__import__('calendar').calendar(2016)" And just when this thread started here, I recalled it was possible to do just python -m calendar --------- That is an anecdote related with the features in question, and I myself can't decide if it is a point for or against them :-) I suppose they'd be "nice to haves" . But maybe, if instead of sprinkiling 4 - 5 lines of code in "__main__" files everywhere, would not make sense to put all of it in a single place? Maybe shutils itself? So that python -m shutils.uuid , python -m shutils.randint, and so on would each do their thing? js -><-

On 01/04/2016 21:42, Ethan Furman wrote:

On 04/01/2016 01:35 PM, Joao S. O. Bueno wrote:

...

Well...actually, really recently (Tuesday), I did python3 -c "__import__('calendar').calendar(2016)"

Wouldn't have

python3 -c "import calendar; calendar(2016)"

been clearer? and easier to type? :)

-- ~Ethan~

My understanding is that this kind of construction does not make you as much money when you are a consultant, as opposed to a mere programmer or similar. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

Joao S. O. Bueno writes:

Anyway - back to the thread - it does not seen a bad idea for me at all.

I think it's a waste of time: an invitation to endless bikeshedding and a slippery slope to very half-baked attempts at full-featured utilities in the module's "__main__" section. It won't be consistent, as many modules already have test code in there, although I suppose you could move that functionality to a "test" command (at the expense of breaking existing "install and test" scripts). Finally to the extent that the feature itself is pretty consistently present, people are going to demand that their favorite options be one-linable, and that pretty much every module grow one-line-abilty. Whatever happened to "not every 3-liner need be builtin"? The suggested scripts also seem, uh, of incredibly marginal usefulness. Except for calendar, but there, the desirable set of options is huge (did you know that many Japanese like their weeks to start with Monday, for example? and that some people care about the Mayan calendar? or of more relevance, different base years -- in Japan it's Year 28 of the Heisei Emperor). Alexander was right as to the ultimate goal (full implementations of POSIX date or GNU calendar plus whatever extensions might seem useful). But if you do more than one or two of those, you're going to end up with a confusing mishmash of CLI syntaxes, with a long script invocation: "python -m calendar ...". That said, your earlier idea taken one step farther seems like the best way to go: create a module oneline[1], put the functionality in there, put it on PyPI, and you can start lobbying for stdlib inclusion in 2018. Or better yet, create a pysh script[2] so you can omit the "-m". An advantage to this is that you can create an API, a module-level variable such as "one_line_subcommands", which would contain a dict of name-function pairs that pysh could look for and run. You could also have a global directory in pysh so that pysh can override those stubborn module maintainers who won't add your favorite one-liner to __main__. The best idea of all, perhaps, is # echo >> /etc/shells /usr/bin/python # chsh -s /usr/bin/python <your login> (Sorry, Windows users, I don't know the equivalent there.) Or make that ipython for even more shellshocking convenience. Footnotes: [1] Too bad it can't be called "1line". "oneln" is a little shorter. [2] ISTR that name is already taken but can't think of a better one. "py1line" maybe?

FYI On Linux, you can use "cat /proc/sys/kernel/random/uuid" ;-)

uuidgen -r

On Fri, Apr 1, 2016 at 8:41 PM, Michel Desmoulin <desmoulinmichel@gmail.com> wrote:

It's dangerous to talk about a new feature the 1st of April, so I'll start by saying this one is not a joke.

I read recently a proposal to allow md5 hashing doing python -m hashlib md5 filename.

I think it's a great idea, and that can extend this kind of API to other parts of Python such as:

python -m random randint 0 10 => print(random.randin(0, 10)) python -m random urandom 10 => print(os.urandom(10)) python -m uuid uuid4 => print(uuid.uuid4().hex) python -m uuid uuid3 => print(uuid.uuid3().hex)

This brings back memories :). Back when I wasn't using Python yet, I ended up needing some stuff in a shell script that was available in Python. Then, as I basically did not know any Python, I had to (1) figure out how do that in Python, and (2) how the heck to get the result cleanly out of there. Especially step 2 may have been a waste of time, even if I did eventually find out that I could do python -c and that i could do stuff like "import foo; print bar(foo)". I ended up writing a tiny bash script that did the "import foo; print " part for me so I only had to do the `bar(foo)` part. If I had had to install a package, I probably would have just found another solution. How about something like python --me module expression_in_module_namespace python --me random "randint(0,10)" or python --me module expression_assuming_module_is_imported python --me random "random.randint(0,10)" Or even python -e "random.randint(0,10)" which would automatically import stdlib if their names appear in the expression. - Koos

On Sat, Apr 2, 2016 at 11:22 AM, Random832 <random832@fastmail.com> wrote:

On Sat, Apr 2, 2016, at 02:37, Koos Zevenhoven wrote:

...

python -e "random.randint(0,10)"

which would automatically import stdlib if their names appear in the expression.

#!/usr/bin/env python3 import sys class magicdict(dict): def __getitem__(self, x): try: return super().__getitem__(x) except KeyError: try: mod = __import__(x) self[x] = mod return mod except ImportError: raise KeyError

g = magicdict() for arg in sys.argv[1:]: try: p, obj = True, eval(arg, g) except SyntaxError: p = False exec(arg, g) if p: sys.displayhook(obj)

Handling modules inside packages is left as an exercise for the reader.

Thanks :). There were some positive reactions to this in the discussions two weeks ago, so I decided to go on and implement this further. Then I kind of forgot about it, but now the other getattr thread reminded me of this, so I came back to it. The implementation now requires Python 3.5+, but I could also do it the same way as I did in my 'np' package [1], which in the newest version (released three weeks ago), uses different module-magic-method approaches for Python<3.5 and >= 3.5, so it even works on Python 2. So here's oneline.py: https://gist.github.com/k7hoven/21c5532ce19b306b08bb4e82cfe5a609 I suppose this could be on pypi, and one could do things like oneline.py "random.randint(0,10)" or python -m oneline "random.randint(0,10)" Any thoughts? -Koos [1] https://pypi.python.org/pypi/np

On Mon, Apr 18, 2016 at 10:12 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

On 18 April 2016 at 05:28, Koos Zevenhoven <k7hoven@gmail.com> wrote:

...

So here's oneline.py:

https://gist.github.com/k7hoven/21c5532ce19b306b08bb4e82cfe5a609

Neat, although you'll want to use importlib.import_module() rather than calling __import__ directly (the latter won't behave the way you want when importing submodules, as it returns the top level module for the import statement to bind in the current namespace, rather than the imported submodule)

Thanks :). That is in fact why I had worked around it by grabbing sys.modules[name] instead. Good to know import_module() already does the right thing. I now changed the code to use import_module, assuming that is the preferred way today. However, to prevent infinite recursion when importing submodules, I now do a setattr(parentmodule, submodulename, None) before the import (and delattr if the import fails).

...

I suppose this could be on pypi, and one could do things like

oneline.py "random.randint(0,10)"

or

python -m oneline "random.randint(0,10)"

Any thoughts?

There are certainly plenty of opportunities to make Python easier to invoke for one-off commands. Another interesting example is pyp: https://code.google.com/archive/p/pyp/wikis/pyp_manual.wiki

This is nice, although solves a different problem.

A completely undocumented hack I put together while playing one day was a utility to do json -> json transformations via command line pipes: https://bitbucket.org/ncoghlan/misc/src/default/pycall

So it looks like it would work like this: cat input.json | pycall "my.transformation.function" > output.json Also a different problem, but cool.

The challenge with these kinds of things is getting them from "Hey, look at this cool thing you can do" to "This will materially improve your day-to-day programming experience". The former can still be fun to work on as a hobby, but it's the latter that people need to get over the initial adoption barrier.

I think the users of oneline.py could be people that now write lots of bash scripts and work on the command line. So whenever someone asks a question somewhere about how to do X on the linux command line, we might have the answer: """ Q: On the linux commandline, how do I get only the filename from a full path that is in $FILEPATH A: Python has this. You can use the tools in os.path: Filename: $ oneline.py "os.path.basename('$FILEPATH')" Path to directory: $ oneline.py "os.path.dirname('$FILEPATH')" """ This might be more appealing than python -c. The whole point is to make Python's power available and visible for a larger audience. -Koos

On 4/2/2016 2:37 AM, Koos Zevenhoven wrote:

python -e "random.randint(0,10)"

which would automatically import stdlib if their names appear in the expression.

I like this much better than cluttering a arbitrary selection of modules with main functions with an arbitrary selection functions whose values are printed. -- Terry Jan Reedy