In Exercise 13, the thing which I type in atom text editor and save as ex13.py is called as a script right!?
It’s line 3 has: script, first, second, third = argv; So script, first, second and third are called as argument variables right!?
When I run “python ex13.py a b c” so ex13.py, a, b and c are called as command line arguments, simply arguments or parameters right!? (I know these jargons exist for other languages as well, I just want to know that am I able to get their reference here or not!)
Jargon indeed. It can be a minefield at first.
Script is the file with .py extension as you said. I suppose generally a script refers to a more simple files that execute one line at a time from start to finish with little, if any user inputs. But that’s your file, yes.
The difference between arguments (or args as you may see them called) and parameters (params) is their usage. You’ll deal with functions or methods (another naming difference based on purpose) later in the book but essentially;
From a function’s perspective:
A parameter is the variable listed inside the parentheses in the function definition.
An argument is the value that are sent to the function when it is called.
a = 3
b = 4
def add_two_numbers(a, b):
return a + b
add_two_numbers(5, 9)So in this example, the variables (a and b) are declared 3 and 4 respectively.
The a and b placeholders in the line starting with def are parameters.
The arguments are 5 and 9 that are passed into a and b when the function is called.
It can start off confusing and I used to think people used such techie language for effect or to appear clever, but now I realise it’s about being accurate.
1 Like
So I think whatever I said above was right! Thanks @gpkesley.
I need your help on another thing; I am a kind of person who likes to know the basics properly but sometimes it is frustrating as well. Knowing the basics helps greatly but when I go deep into the basics then I struggle where to pause and move ahead! It also affects my pace and I think my progress with the book is slow what do you suggest I do? I would love to know your POV and then will figure out what suits me well.
1 Like
This does come up a lot and often people find themselves getting bogged down on something. I share your approach. I like to understand why something is the way that it is, not just follow it blindly. This is especially true if the way things are seems odd or inconsistent.
To be honest, this is where @zedshaw has been brilliant in my opinion. He highlights why things are the way they are, usually for historical reasons, but also explains whether you should be concerned with it or not. That helps me in deciding whether to put too much effort into really understanding something, or whether to accept it as a bad decision that just got adopted.
The other really useful thing Zed has introduced is the concept of analysing your approach to work, and the discipline of quick hacks. Learn More Python The Hard Way book open with this concept and snapped me out of trying to learn everything to the nth degree, but not actually writing any code.
You will learn so much more from trying to code things, than thinking about them.
I originally went the LPTHW once and made notes of things I didn’t quite get. Then a few months later did it again, and found that I spotted things I missed the first time round. Plus I had a few months more exposure. If you research everything in vast detail, you have a very, very long list. Trust me!
1 Like