Skip to content

Commit 2f429af

Browse files
committed
fixing oopsies and improving things
1 parent 548ec80 commit 2f429af

File tree

2 files changed

+38
-36
lines changed

2 files changed

+38
-36
lines changed

advanced/iters.md

Lines changed: 24 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -105,9 +105,8 @@ this:
105105

106106
## Iterating manually
107107

108-
Iterators have a magic method called `__next__`, and there's a built-in
109-
function called `next()` for calling that. Calling `next()` on an
110-
iterator gets the next value and moves it forward. Like this:
108+
Iterators have a magic method called `__next__` that gets next value and
109+
moves the iterator forward.
111110

112111
```python
113112
>>> e = enumerate('abc')
@@ -146,9 +145,11 @@ StopIteration
146145
```
147146

148147
There is usually not a good way to check if the iterator is at the end,
149-
and it's best to just try to get a value from it and catch
150-
StopIteration. That's actually what for looping over an iterator does.
151-
For example, this code...
148+
and it's best to just try to get a value from it and
149+
[catch](../basics/exceptions.md#catching-exceptions) StopIteration.
150+
151+
That's actually what for loops do. For example,
152+
this code...
152153

153154
```python
154155
for pair in enumerate('hello'):
@@ -170,7 +171,7 @@ while True:
170171
```
171172

172173
The for loop version is much simpler to write and I wrote the while loop
173-
version just to explain what the for loop does.
174+
version just to show how the for loop works.
174175

175176
## Converting to iterators
176177

@@ -282,13 +283,15 @@ Let's try out our thingy function and see how it works.
282283
```
283284

284285
What the heck? We don't return anything from the function, but it still
285-
doesn't return None! Putting a `yield` anywhere in a function makes it
286-
return **generators** instead of returning anything. **Generators are
287-
iterators** with some more features that we don't need to care about.
286+
doesn't return None!
287+
288+
Putting a `yield` anywhere in a function makes it return **generators**.
289+
**Generators are iterators** with some more features that we don't need
290+
to care about.
288291

289292
![Generators.](../images/generators.png)
290293

291-
The generator we got works just like other iterators:
294+
The generators that thingy gives us work just like other iterators:
292295

293296
```python
294297
>>> t = thingy()
@@ -373,10 +376,10 @@ Here's a drawing of what's going on:
373376

374377
![A picture of printygen.](../images/freeze-melt.png)
375378

376-
The good news is that **usually we don't need to worry about when the
377-
parts between the yields run**. Actually we don't even need to use
378-
`iter()` or `next()` most of the time, but I think it's nice to know how
379-
for loops work.
379+
The good news is that **usually we don't need to worry about when
380+
exactly the parts between the yields run**. Actually we don't even need
381+
to use `iter()` and `next()` most of the time, but I think it's nice to
382+
know how for loops work.
380383

381384
`yield` is useful when we want the function to output so many things
382385
that making a list of them would be too slow or the list wouldn't fit in
@@ -426,20 +429,19 @@ number of things:
426429
```
427430

428431
[The itertools module](https://docs.python.org/3/library/itertools.html)
429-
contains many useful functions like this. For example,
430-
`itertools.count(1)` does the same thing as our `count()`.
432+
contains many useful things like this. For example, `itertools.count(1)`
433+
does the same thing as our `count()`.
431434

432435
## Summary
433436

434437
- An iterable is something that we can for loop over.
435438
- An iterator is an iterable that remembers its position.
436439
- For loops create an iterator of the iterable and call its `__next__`
437440
method until it raises a StopIteration.
438-
- Functions that contain yields return generators. Iterating the
439-
generator runs the function bit by bit and gives us the values it
440-
yields.
441-
- The itertools module contains many useful functions that return
442-
iterators.
441+
- Functions that contain yields return generators. Calling `next()` on a
442+
generator runs it to the next yield and gives us the value it yielded.
443+
- [The itertools module](https://docs.python.org/3/library/itertools.html)
444+
contains many useful iterator-related things.
443445

444446
***
445447

basics/exceptions.md

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -214,7 +214,7 @@ TypeError("unsupported operand type(s) for +: 'int' and 'str'",)
214214

215215
## When should we catch exceptions?
216216

217-
Never do things like this:
217+
Do **not** do things like this:
218218

219219
```python
220220
try:
@@ -225,9 +225,9 @@ except Exception:
225225

226226
There's many things that can go wrong in the `try` block. If something
227227
goes wrong all we have is an oops message that doesn't tell us which
228-
line caused the problem. This makes fixing problems a lot harder. If we
229-
want to catch exceptions we need to be specific about what exactly we
230-
want to catch and where instead of catching everything we can in the
228+
line caused the problem. This makes fixing the program really annoying.
229+
If we want to catch exceptions we need to be specific about what exactly
230+
we want to catch and where instead of catching everything we can in the
231231
whole program.
232232

233233
There's nothing wrong with doing things like this:
@@ -311,16 +311,16 @@ Back in [the module chapter](modules.md) we learned to display error
311311
messages by printing to `sys.stderr` and then calling `sys.exit(1)`, so
312312
when should we use that and when should we raise an exception?
313313

314-
Exceptions are meant for **programmers**, so if we are writing a module
315-
that other people will import we should probably use exceptions. For
316-
other errors (for example, if the **user** of the program has done
317-
something wrong) it's usually better to use `sys.stderr` and `sys.exit`.
314+
Exceptions are meant for **programmers**, so if we are writing something
315+
that other people will import we should use exceptions. If our program
316+
is working like it should be and the **user** has done something wrong,
317+
it's usually better to use `sys.stderr` and `sys.exit`.
318318

319319
## Exception hierarchy
320320

321-
Exceptions are organized like this. I made this tree diagram with
322-
[this program](https://github.com/Akuli/classtree/) on Python 3.4. You
323-
may have more or less exceptions than I have if your Python is newer or
321+
Exceptions are organized like this. I made this tree with [this
322+
program](https://github.com/Akuli/classtree/) on Python 3.4. You may
323+
have more or less exceptions than I have if your Python is newer or
324324
older than mine, but they should be mostly similar.
325325

326326
Exception
@@ -387,9 +387,9 @@ get when [processing files](files.md), and catching Exception catches
387387
all of these errors. You don't need to remember this tree, running
388388
`help('builtins')` should display a larger tree that this is a part of.
389389

390-
There's also a few exceptions that are not in this tree like SystemExit
391-
and KeyboardInterrupt, but most of the time we shouldn't catch them.
392-
Catching Exception doesn't catch them either.
390+
There are also a few exceptions that are not in this tree like
391+
SystemExit and KeyboardInterrupt, but most of the time we shouldn't
392+
catch them. Catching Exception doesn't catch them either.
393393

394394
## Summary
395395

0 commit comments

Comments
 (0)