On Fri, 28 Oct 2016 09:02 am, BartC wrote: > I notice that when it comes to reading command-line arguments, then > Python's sys.argv presents them as a list, not one long string.
Yes, just like the shell presents it to Python. It would be silly for Python to take the list of strings it receives, join them into a single string, and then have the user split it up again. Not to mention the possible ambiguity if any of the arguments contain spaces. > And the list is just a series of strings, so needing to know whether any > parameter was a number or whatever obviously wasn't a problem. It just > makes each item into a string (actually that might be a better default > than mine). > > This is a very similar issue to reading items from a line of user input. > > So why doesn't sys.argv just return a single string if a line is so easy > to parse? I don't understand your question. Who said strings are necessarily easy to parse? Strings *might* be easy to parse if you know what the string represents ahead of time: "a sequence of integers, separated by spaces" is easy. But not all data is that simple: "a valid Perl program" is notoriously difficult. As they say, nothing but Perl can parse Perl. Likewise for C++. The shell cannot make many assumptions about the data is it passing on. All it knows is that it has received a sequence of characters. It cannot know what the receiver intends to do with them, or what those characters represent. Just because the characters are "1234" doesn't mean that they represent the integer 1234. I say *many* assumptions rather than *any* because, of course, any shell is permitted to make whatever assumptions it likes! If you don't like the shell's rules, use a different shell! But in general, shells tend towards *minimal* interpretation of arguments: spaces separate arguments unless escaped, for example, and a handful of special characters like * ? & ! are given special meaning. > (That's exactly what Windows' WinMain() function does - optional entry > point for executables under Windows. But C's main() entry point chops > the command line up into separate strings like Python. > > Also - this might some bearing on why Python does it that way - under > Linux, a parameter such as *.py is replaced by the names of ALL the > files that end in .py. That's a feature of the shell. I expect you're probably using bash, as that's the most commonly used shell, but other shells do the same. There's probably a way to turn that off, but I don't know it. If you want to pass a literal star * you need to escape it so that the shell won't treat it as a glob and expanding it: \*.py or "*.py" will probably work. (And yes, shell escaping is one of the more arcane and tricky part of Unix shell scripting.) -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list