Skip to content
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

Merged
merged 1 commit into from
May 23, 2018

Conversation

maxim-belkin
Copy link
Contributor

No description provided.

@maxim-belkin maxim-belkin merged commit 9bffe66 into swcarpentry:gh-pages May 23, 2018
@maxim-belkin maxim-belkin deleted the redo-numpy branch May 23, 2018 21:10
Copy link
Contributor

@ldko ldko left a 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:
Copy link
Contributor

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".

Copy link
Contributor Author

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`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: "variabe"

Copy link
Contributor Author

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
Copy link
Contributor

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?

Copy link
Contributor Author

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:
Copy link
Contributor

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".

Copy link
Contributor Author

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:
Copy link
Contributor

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"?

Copy link
Contributor Author

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.
Copy link
Contributor

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"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you

@alee
Copy link
Member

alee commented May 23, 2018

👍 @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/

@maxim-belkin
Copy link
Contributor Author

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.

I raised this question during maintainer onboarding.
Basically, there is no policy. But we do practice it when time permits and changes are more noticeable: see, for example, #536 where I requested a review from @annefou. The main change in this PR is, as you noticed, is that I mention strings without deviating away from the main story-line + headers.

maxim-belkin added a commit to maxim-belkin/python-novice-inflammation that referenced this pull request May 24, 2018
@ldko
Copy link
Contributor

ldko commented May 24, 2018

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!

@maxim-belkin
Copy link
Contributor Author

It is subjective on what changes are considered noticeable though.

100% agree.

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.

  1. This PR does not change multiple explanations.
  2. Typos are typos.

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:
a) there is no way it can be taught in 30 minutes. It requires more like an hour.
b) it is difficult for learners because it goes through a lot of material (including slicing numpy arrays and grouping plots in matplotlib!!!!!)
c) all exercises are at the very end!

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:

There should be an agreement on what topics/concepts have to be covered but "consistent text" would not make much sense, I think...

zkamvar pushed a commit that referenced this pull request Apr 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants