It sounds to me like you will simply be handing these files to another piece of software to actually read them in. If that's the case, use python or ruby or whatever easy to use high level language you have on hand because this program isn't actually IO intensive.
Now, if you are actually reading the contents of files in yourself to process on your own then I would say if the language you normally use doesn't have any interoperability for making OS level calls, don't use that language.
Ideally in this case you'd want a high level language with low level facilities.
C# for instance does this well in allowing high level handling of the simple stuff like processing the user input from command line and organizing the steps of your task or whatever else, but then allowing OS calls and direct memory management for highest possible performance (if necessary!). Java may do similarly? Not certain. Haskell is very high level as well as having facilities for direct memory manipulation, though Haskell has an extremely high barrier for learning if you don't already know it. C++ is probably the most commonly used language for this type of task for this exact purpose, it is a high level language and with C in it's roots it has complete low level facilities available.
That said, beware of premature optimization. Writing a program in a language that isn't your strongest language will likely under perform the one you could write in your native language as you wouldn't be aware of available optimizations or be using the language appropriately. Further the only way to know if the quickest most robust route of using your main language won't work is by giving it a go which would be far quicker than going all in on a language you don't know. So prototype something and see how it performs, if you don't think it does well enough then whip up a quick prototype in other languages and compare.
Prototyping as a part of your technical solution analysis is an ever important skill for all programmers, so take advantage of this task to practice it. In the scientific method we don't try to prove our hypothesis as that leads to bias, rather we try to disprove them. Your hypothesis is your normal language won't perform well enough for this task, so start by trying to disprove that.
Edit:
Based on your edit, your program is absolutely not IO intensive, so write it in the language you are most comfortable with
This is an unsolved problem in our field. There's no way to be sure that your code will indefinitely work. Even if your code was truly perfect in the forwards-compatible sense (and if it is, please come work for my company! ;) ), if it runs on, uses, or is used by any other software which gets a bug or changes in any way, your code may not work.
So I can't give you a list of things to do that, if you follow them, will guarantee success. But what you can do is minimize the risk of future breakages and minimize their impacts. A more knowledgeable Pythonist would be able to give you advice more specific to Python, so I will have to be more general:
write unit tests. Even for things that you know don't need them.
using popular/well-designed/stable libraries and technologies, avoiding unpopular (and thus likely to soon be unsupported) ones
avoid writing code that exploits implementation details. Code to interfaces, not implementations. Code against multiple implementations of the same interface. For example, run your code in CPython, Jython, and IronPython and see what happens. This will give you some great feedback about your code. This might not be helpful for Python3 though -- last I heard, some implementations were still in Python2.
write simple, clear code that is explicit about its assumptions
write modular, composable code. If some code must do something dangerous (in the future-proof sense), separate it so that even if it has to change, the rest of the code doesn't.
have a specification of some form. This is similar to the points about unit tests, if you use tests as a spec, and interfaces, which can also be used as specs. (I mean interface in the general sense, not the Java keyword sense).
Doing any of these things may/will increase the amount of work you have to do. I think that makes sense -- a lot of these points can also be made for how to write good code, which is quite difficult (in my opinion). Sometimes you may need to violate some of these suggestions. That is perfectly acceptable, but be aware of the costs.
It's great that the Python team is thinking about this, and for sure they are far more talented and skilled than I will ever be. Still, I would estimate there's a 100% that somebody's code somewhere will stop working the way the want it's intended to when Python is upgraded.
Best Answer
In shell languages of the Bourne family, the
:command, which does nothing at all, is typically used in two situations:Placeholder for when something expects a mandatory command, e.g.
since
dorequires at least one command.Discarding the arguments, but performing side effects inside the argument list, e.g.
I'm sure there are probably other applications that shell experts would know :)
In Python (and other languages) it's used less frequently. It can act as an argument to a higher-order function when you don't actually want to do anything. For example, say you have a function that submits a form and allows an function to be called asynchronously after submission is complete:
This way, if the
callbackis not provided, the submission will still go through but no further actions will be performed. If you had usedNoneas the default value, you'd have to explicitly check whether the callback wasNone, adding clutter to the code.