-
-
Notifications
You must be signed in to change notification settings - Fork 780
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
01-numpy: add a few section headers. Improve text #538
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am excited about the content this merged request added to the Python lesson regarding an introduction to variable types and what makes a string etc. I did notice some things in the PR that might need changing, and I am wondering if there is any sort of policy or common practice on a maintainer having a second maintainer review a PR of his/hers before merging it.
|
||
We can also change a variable's value by assigning it a new one: | ||
To change variable's value, we have to assign it a new one: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depending on the type of variable (immutable vs. mutable), it is not true that "we have to assign it a new one" to change the value. I find the old wording more accurate. If you want to use the new wording, it should say "a variable's value".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm.... interesting point. How about
To change value of `weight_kg` variable, we have to assign it a new one:
If you want to use the new wording, it should say "a variable's value".
I believe this contradicts the first statement:
Depending on the type of variable (immutable vs. mutable), it is not true that "we have to assign it a new one
* floating point numbers, and | ||
* strings. | ||
|
||
In the example above, variabe `weight_kg` has an integer value of `60`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: "variabe"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you
|
||
In Python, variable names: | ||
|
||
- must begin with a letter, and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize that the statement "must begin with a letter" is not new to the episode here, but variable names are not actually required to begin with a letter. They could begin with an underscore. Would it make sense to specify that the variable names can include upper and lowercase letters, numbers, and underscores, but cannot start with a number?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
variable names can include upper and lowercase letters, numbers, and underscores, but cannot start with a number
sounds reasonable. Shall we distinguish numbers and digits?
- `weight` and `Weight` are different variables | ||
|
||
## Types of data | ||
Python knows various types of data. The most common ones are: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these "the most common"? It could say "Three common ones".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good
{: .language-python} | ||
|
||
## Using Variables in Python | ||
To display the value of a variable to the screen in Python, we can use `print` function: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this say "the print
function"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good
If we imagine the variable as a sticky note with a name written on it, | ||
assignment is like putting the sticky note on a particular value: | ||
A variable is analoguous to a sticky note with a name written on it: | ||
assigning value to a variable is like putting that sticky note on a particular value. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: analoguous
Should be "assigning a value"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you
👍 @ldko It'd be great to communally establish across all @swcarpentry/python-maintainers some consistent text that introduces these types of core programming language concepts - we have similar content here: http://swcarpentry.github.io/python-novice-gapminder/02-variables/ |
I raised this question during maintainer onboarding. |
See discussion here: swcarpentry#538
Thanks for the explanation about maintainer review policy, @maxim-belkin . It makes sense to me. It is subjective on what changes are considered noticeable though. Not specific to the Carpentries, I tend to think of PRs that could skip review (because of noticeability and time sensitivity) things like fixing a broken link, whereas PRs that change multiple explanations would benefit from a review, if not just for the sake of catching typos, because what seems clear and absolute to one person may not be interpreted the same by others. By the way, I appreciate all the effort and time you have been volunteering to maintain this lesson. Thank you! |
100% agree.
This PR formally mentions strings, introduces a few "headers", and moves Notebook-specific text outside. At present, it is more important to pay attention to the overall state of the episode:
There should be an agreement on what topics/concepts have to be covered but "consistent text" would not make much sense, I think... |
No description provided.