Skip to content

Conversation

@encukou
Copy link
Member

@encukou encukou commented Jun 8, 2020

In in-person courses, I tended to explain strings in more depth than what the materials provided.
There's enough depth in quoting and characters (esp. special characters) to make it a separate lesson; same goes for the new concepts of indexing/slicing and methods.

This splits the material into:

  • String literals (how to write strings; what is a character)
  • String indexing and slicing
  • String methods
  • F-strings (split out earlier)

String comparisons might come later :)

Please review the changes as a whole, don't look at individual commits. But, to make cherry-picking easier, don't squash when merging.

encukou added 5 commits June 8, 2020 15:46
In in-person courses, I tended to explain strings in more depth
than what the materials provided. There's enough depth in quoting
 and characters (esp. special characters) to make it a separate
lesson; same goes for the new concepts of indexing/slicing
and methods.

This splits the matrial into:

- String literals (how to write strings; what is a character)
- String indexing and slicing
- String methods
- F-strings (split out earlier)

String comparisons might come later.
@Kobzol
Copy link
Member

Kobzol commented Jun 8, 2020

It looks good to me! One thing that I think could be improved, but it's not a big deal:
Maybe we should attempt to justify zero-based indexing without resorting to statements such as "it's black magic"? Pointer-based reasoning is too complex and also not really applicable to Python, but maybe we can find better justifications.

There are multiple reasons why 0-based indexing is useful (open-closed intervals, multi-dimensional indexing, arrays represented with pointers to their first element, using modulo to calculate indices etc.). Some of them are too difficult for this part of the course, but maybe we can pick some examples that they can understand? Or if we can't find any, say that we will show some examples later and add specific references to zero-based indexing later. For example:

Jak sis možná už všiml{{a}}, programátoři počítají od nuly.
...
Proč je tomu tak? Zjednodušeně řečeno je to z mnoha důvodů praktičtější.
Některé důvody jsou zatím moc komplikované a odkážeme se na ně později, ale prozatím si například můžeš všimnout, že:

<< intuitivní a jednoduchý příklad >>
<< např.: K indexování používáme v Pythonu celá čísla. Kladné indexy nám vrací prvky od začátku řetězce, záporné indexy prvky od konce řetězce, ale pokud bychom začali počítat od jedničky, jaký prvek by poté vrátil index 0? Bylo by nepraktické mít hodnotu indexu, která by nikdy nebyla validní >>

Počítání od nuly se používá ve většině programovacích jazyků, a i když ti prozatím může přijít zvláštní, časem si na něj určitě zvykneš. Můžeš si to představovat tak, že (kladný) index N udává počet prvků od začátku řetězce/pole, o které se musíš posunout, aby ses dostal(a) k žádanému prvku.

Later, for example in slicing/substrings (s[0:n]), we can refer to this with something like "Zde je příklad toho, proč je indexování od 0 přirozenější" and talk about open-closed intervals.

@encukou
Copy link
Member Author

encukou commented Jun 8, 2020

Thanks! I opened #631 with this idea.

I would like to have this PR merged if it is an improvement, not if it is perfect. The PR doesn't change the explanation of zero-based indexing, so IMO this review is not a place to improve it.
Also, as with any idea for the materials, I'd like to test yours in a live class before it's merged to the self-study course.

@Kobzol
Copy link
Member

Kobzol commented Jun 8, 2020

You're right, it's a separate discussion.

Comment on lines +153 to +170
Zkus si, jestli zvládneš předpovědět výsledek těchto výrazů:

```plain
[0] [1] [2] [3] [4] [5] [6] [7]
[-8][-7][-6][-5][-4][-3][-2][-1]
╭───┬───┬───┬───┬───┬───┬───┬───╮
│ Č │ o │ k │ o │ l │ á │ d │ a │
╰───┴───┴───┴───┴───┴───┴───┴───╯
```pycon
>>> print(".\".")
>>> len(".\".")
>>> ".\"."
```
{% endfilter %}

Řetězce umí i jiné triky.
Třeba můžeš zjistit, jak je řetězec dlouhý
nebo jestli v sobě obsahuje daný menší řetězec.

<table class="table">
<tr>
<th>Zápis</th>
<th>Popis</th>
<th>Příklad</th>
</tr>
<tr>
<td><code>len(r)</code></td>
<td>Délka řetězce</td>
<td><code>len('čokoláda')</code></td>
</tr>
<tr>
<td><code>x&nbsp;in&nbsp;r</code></td>
<td>True pokud je řetězec <code>x</code> obsažen v <code>r</code></td>
<td><code>'oko' in 'čokoláda'</code></td>
</tr>
<tr>
<td><code>x&nbsp;not&nbsp;in&nbsp;r</code></td>
<td>Opak <code>x in r</code></td>
<td><code>'dub' not in 'čokoláda</code></td>
</tr>
</table>

Řetězce vždy berou v potaz velikost písmen,
takže např. `'ČOKO' in 'čokoláda'` je `False`.
Kdybys chtěl{{a}} porovnávat bez ohledu na velikost písmen,
musel{{a}} bys oba řetězce převést třeba na malá písmena
a pak je porovnat.

A jak se převádí na malá písmena?
K tomu budeme potřebovat další novou vlastnost Pythonu: metody.

## Metody

*Metoda* (angl. *method*) je jako funkce – něco, co se dá zavolat.
Na rozdíl od funkce je svázaná s nějakým *objektem* (hodnotou).
Volá se tak, že se za objekt napíše tečka,
za ní jméno metody a za to celé se, jako u funkcí, připojí závorky
s případnými argumenty.

Řetězcové metody `upper()` a `lower()`
převádí text na velká, respektive malá písmena.

```python
retezec = 'Ahoj'
print(retezec.upper())
print(retezec.lower())
print(retezec)
{% filter solution %}
```pycon
>>> print(".\".")
.".
>>> len(".\".")
3
>>> ".\"."
'.".'
```
{% endfilter %}
Copy link
Contributor

Choose a reason for hiding this comment

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

This can be an interesting part for experimenting, but IMHO should be all hidden by default and the box with this part would display when clicked on: Zkus si, jestli zvládneš předpovědět výsledek těchto výrazů

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think this should be hidden. People struggle with the fact that \" denotes a single character. The teacher could show these as an example, or skip this and use some other way to explain it, but IMO it is necessary to show the fact again, from a different angle.

```pycon
>>> print("a\tb") # Výpis "pro lidi"
a b
>>> "a\tb" # Výpis "pro programátory"
Copy link
Contributor

Choose a reason for hiding this comment

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

Výpis "pro programátor(k)y" ... I suggest fixing of all occurrences (I mean those which are part of this PR)

Copy link
Member Author

Choose a reason for hiding this comment

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

IMO, that would be a suggestion for all the texts on naucse.
I don't see (k) used anywhere else yet. Generally I try to address the user with {{a}} (hoping that in the future, the page can adjust for logged-in users), but in cases like these use the Czech default.

a b
>>> "a\tb" # Výpis "pro programátory"
'a\tb'
>>> len("a\tb") # Počet znaků v řetězci
Copy link
Contributor

@fivaldi fivaldi Jun 11, 2020

Choose a reason for hiding this comment

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

I think this is even more self-explaining of how len() considers the chars (includes not only explanation for "\" but also for "\t" as a whole, when it comes to pritning) than the experimenting section above, so this should be enough. The course teacher can use this example here to quickly/easily explain the behaviour...

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not sure what you're suggesting here.

standardu Unicode.
Stačí přesné jméno nebo číslo znát (nebo třeba dohledat na internetu).
V následujících řetězcích jsou takové znaky pro přehlednost mezi dvěma
pomlčkami `-`. Délka každého řetězce je tedy celkem 3:
Copy link
Contributor

Choose a reason for hiding this comment

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

Here again it's well-explained.

@fivaldi
Copy link
Contributor

fivaldi commented Jun 11, 2020

I have just some small comments in the code. One major comment for a separate issue/PR, when the materials grow over time, some parts should be hidden and marked somehow (e.g. ℹ️ or ⚠️) and being visible just when clicked. This would help the teacher to go moderate speed, focus on what he/she needs to focus on, and use these "boxes" only when there's enough time for it. Or during recap lessons.

@encukou
Copy link
Member Author

encukou commented Jun 15, 2020

One major comment for a separate issue/PR, when the materials grow over time, some parts should be hidden and marked somehow (e.g. ℹ️ or ⚠️) and being visible just when clicked. This would help the teacher to go moderate speed, focus on what he/she needs to focus on, and use these "boxes" only when there's enough time for it. Or during recap lessons.

We already have info and warning boxes, except they're not hidden by default.
I don't think showing them by default makes them harder to skip for the teacher, though. Do you think the different styling is not enough?

Also, the materials should be usable when printed out (for both teachers and students). Hidden boxes make this more complicated. Of course, this can be solved (and I hope it has been solved for the solutions).

encukou and others added 2 commits June 15, 2020 15:37
Co-authored-by: Karolina <33810531+befeleme@users.noreply.github.com>
Copy link
Contributor

@fivaldi fivaldi left a comment

Choose a reason for hiding this comment

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

There's a commit msg typo, but other than that looks good to me.

Thanks also for commenting on reviews.

There should be subsequent issues opened aiming on re-structuring of the content on major materials additions which make it difficult to choose the most important stuff for live lessons, as the materials keep growing.

Stats with this PR: +1,006 −266

OK, feel free to merge to move things forward, but let's keep in mind how it's gonna affect course teachers sooner or later. They need to pay more attention on what's really the most important and choose those parts.

Thank you!

@encukou
Copy link
Member Author

encukou commented Jun 22, 2020

Thanks for the review!

There should be subsequent issues opened aiming on re-structuring of the content on major materials additions which make it difficult to choose the most important stuff for live lessons, as the materials keep growing.

The best way to do this to teach a course, and send PRs or report back what you thought was good to leave out!
I'll definitely try that in future iterations.
Meanwhile,I suggest teaching functions (def) and strings in separate sessions; my next PR should be about that.

@encukou encukou merged commit f8de71a into pyvec:master Jun 22, 2020
@encukou encukou deleted the rework-str branch June 22, 2020 13:08
@frenzymadness
Copy link
Member

I like it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants