Skip to content

Commit 092dd09

Browse files
committed
Expand strings and backslashes
Resolves satwikkansal#69
1 parent e0cb30b commit 092dd09

File tree

1 file changed

+34
-17
lines changed

1 file changed

+34
-17
lines changed

README.md

Lines changed: 34 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -469,7 +469,7 @@ array_4 = [400, 500, 600]
469469
- In the first case, `array_1` is binded to the new object `[1,2,3,4,5]` and since the `in` clause is evaluated at the declaration time it still refers to the old object `[1,2,3,4]` (which is not destroyed).
470470
- In the second case, the slice assignment to `array_2` updates the same old object `[1,2,3,4]` to `[1,2,3,4,5]`. Hence both the `g2` and `array_2` still have reference to the same object (which has now been updated to `[1,2,3,4,5]`).
471471
- Okay, going by the logic discussed so far, shouldn't be the value of `list(g)` in the third snippet be `[11, 21, 31, 12, 22, 32, 13, 23, 33]`? (because `array_3` and `array_4` are going to behave just like `array_1`). The reason why (only) `array_4` values got updated is explained in [PEP-289](https://www.python.org/dev/peps/pep-0289/#the-details)
472-
472+
473473
> Only the outermost for-expression is evaluated immediately, the other expressions are deferred until the generator is run.
474474
475475
---
@@ -702,30 +702,47 @@ SyntaxError: invalid syntax
702702
703703
---
704704
705-
### ▶ Backslashes at the end of string
705+
### ▶ Strings and the backslashes\
706706
707707
**Output:**
708-
```
709-
>>> print("\\ C:\\")
710-
\ C:\
711-
>>> print(r"\ C:")
712-
\ C:
713-
>>> print(r"\ C:\")
708+
```py
709+
>>> print("\"")
710+
"
714711
715-
File "<stdin>", line 1
716-
print(r"\ C:\")
717-
^
712+
>>> print(r"\"")
713+
\"
714+
715+
>>> print(r"\")
716+
File "<stdin>", line 1
717+
print(r"\")
718+
^
718719
SyntaxError: EOL while scanning string literal
720+
721+
>>> r'\'' == "\\'"
722+
True
719723
```
720724
721725
#### 💡 Explanation
722726
723-
- In a raw string literal, as indicated by the prefix `r`, the backslash doesn't have the special meaning.
724-
```py
725-
>>> print(repr(r"wt\"f"))
726-
'wt\\"f'
727-
```
728-
- What the interpreter actually does, though, is simply change the behavior of backslashes, so they pass themselves and the following character through. That's why backslashes don't work at the end of a raw string.
727+
- In a normal python string, the backslash is used to escape characters that may have special meaning (like single-quote, double-quote and the backslash itself).
728+
```py
729+
>>> 'wt\"f'
730+
'wt"f'
731+
```
732+
- In a raw string literal (as indicated by the prefix `r`), the backslashes pass themselves as is along with the behavior of escaping the following character.
733+
```py
734+
>>> r'wt\"f' == 'wt\\"f'
735+
True
736+
>>> print(repr(r'wt\"f')
737+
'wt\\"f'
738+
739+
>>> print("\n")
740+
741+
742+
>>> print(r"\\n")
743+
'\\\\n'
744+
```
745+
- This means when a parser encounters a backslash in a raw string, it expects another character following it. And in our case (`print(r"\")`), the backslash escaped the trailing quote, leaving the parser without a terminating quote (hence the `SyntaxError`). That's why backslashes don't work at the end of a raw string.
729746
730747
---
731748

0 commit comments

Comments
 (0)