1
0
mirror of https://github.com/satwikkansal/wtfpython synced 2024-11-24 12:04:24 +01:00

Proposal for issue #67

This commit is contained in:
Jonathan H 2018-02-25 17:57:04 +00:00
parent 17e49ee9db
commit 28fa624a88
3 changed files with 8 additions and 4 deletions

1
CONTRIBUTORS.md vendored
View File

@ -9,5 +9,6 @@ I'm really grateful to all the contributors. Following are the wonderful people
| tukkek | [tukkek](https://github.com/tukkek) | [#11](https:/github.com/satwikkansal/wtfpython/issues/11), [#26](https:/github.com/satwikkansal/wtfpython/issues/26) | | tukkek | [tukkek](https://github.com/tukkek) | [#11](https:/github.com/satwikkansal/wtfpython/issues/11), [#26](https:/github.com/satwikkansal/wtfpython/issues/26) |
| PiaFraus | [PiaFraus](https://github.com/PiaFraus) | [#9](https:/github.com/satwikkansal/wtfpython/issues/9) | | PiaFraus | [PiaFraus](https://github.com/PiaFraus) | [#9](https:/github.com/satwikkansal/wtfpython/issues/9) |
| chris-rands | [chris-rands](https://github.com/chris-rands) | [#32](https:/github.com/satwikkansal/wtfpython/issues/32) | | chris-rands | [chris-rands](https://github.com/chris-rands) | [#32](https:/github.com/satwikkansal/wtfpython/issues/32) |
| Jonathan H | [sheljohn](https://github.com/sheljohn) | [#67](https://github.com/satwikkansal/wtfpython/issues/67) |
Thank you all for taking out time, and helping to make this project awesome! :smile: Thank you all for taking out time, and helping to make this project awesome! :smile:

8
README.md vendored
View File

@ -194,12 +194,14 @@ False
Makes sense, right? Makes sense, right?
#### 💡 Explanation: #### 💡 Explanatios:
+ Such behavior is due to CPython optimization (called string interning) that tries to use existing immutable objects in some cases rather than creating a new object every time.
+ Such behavior is due to CPython optimization (called **string interning**) that tries to use existing immutable objects in some cases rather than creating a new object every time.
+ Note that the keyword `is` is used for _reference_ equality (unlike `==` which is used for _value_ equality); this means that `a is b` is the same as `id(a) == id(b)`, and therefore it should not be used for string comparison. It is only used here to illustrate the effects of string interning.
+ After being interned, many variables may point to the same string object in memory (thereby saving memory). + After being interned, many variables may point to the same string object in memory (thereby saving memory).
+ In the snippets above, strings are implicitly interned. The decision of when to implicitly intern a string is implementation dependent. There are some facts that can be used to guess if a string will be interned or not: + In the snippets above, strings are implicitly interned. The decision of when to implicitly intern a string is implementation dependent. There are some facts that can be used to guess if a string will be interned or not:
* All length 0 and length 1 strings are interned. * All length 0 and length 1 strings are interned.
* Strings are interned at compile time (`'wtf'` will be interned but `''.join(['w', 't', 'f']` will not be interned) * Strings are interned at compile time (`'wtf'` will be interned but `''.join(['w', 't', 'f']` will not be interned).
* Strings that are not composed of ASCII letters, digits or underscores, are not interned. This explains why `'wtf!'` was not interned due to `!`. * Strings that are not composed of ASCII letters, digits or underscores, are not interned. This explains why `'wtf!'` was not interned due to `!`.
<img src="/images/string-intern/string_intern.png" alt=""> <img src="/images/string-intern/string_intern.png" alt="">
+ When `a` and `b` are set to `"wtf!"` in the same line, the Python interpreter creates a new object, then references the second variable at the same time. If you do it on separate lines, it doesn't "know" that there's already `wtf!` as an object (because `"wtf!"` is not implicitly interned as per the facts mentioned above). It's a compiler optimization and specifically applies to the interactive environment. + When `a` and `b` are set to `"wtf!"` in the same line, the Python interpreter creates a new object, then references the second variable at the same time. If you do it on separate lines, it doesn't "know" that there's already `wtf!` as an object (because `"wtf!"` is not implicitly interned as per the facts mentioned above). It's a compiler optimization and specifically applies to the interactive environment.

View File

@ -556,10 +556,11 @@ Makes sense, right?
#### 💡 Explanation: #### 💡 Explanation:
+ Such behavior is due to CPython optimization (called string interning) that tries to use existing immutable objects in some cases rather than creating a new object every time. + Such behavior is due to CPython optimization (called string interning) that tries to use existing immutable objects in some cases rather than creating a new object every time.
+ Note that the keyword `is` is used for _reference_ equality (unlike `==` which is used for _value_ equality); this means that `a is b` is the same as `id(a) == id(b)`, and therefore it should not be used for string comparison. It is only used here to illustrate the effects of string interning.
+ After being interned, many variables may point to the same string object in memory (thereby saving memory). + After being interned, many variables may point to the same string object in memory (thereby saving memory).
+ In the snippets above, strings are implicitly interned. The decision of when to implicitly intern a string is implementation dependent. There are some facts that can be used to guess if a string will be interned or not: + In the snippets above, strings are implicitly interned. The decision of when to implicitly intern a string is implementation dependent. There are some facts that can be used to guess if a string will be interned or not:
* All length 0 and length 1 strings are interned. * All length 0 and length 1 strings are interned.
* Strings are interned at compile time (`'wtf'` will be interned but `''.join(['w', 't', 'f']` will not be interned) * Strings are interned at compile time (`'wtf'` will be interned but `''.join(['w', 't', 'f']` will not be interned).
* Strings that are not composed of ASCII letters, digits or underscores, are not interned. This explains why `'wtf!'` was not interned due to `!`. * Strings that are not composed of ASCII letters, digits or underscores, are not interned. This explains why `'wtf!'` was not interned due to `!`.
<img src="/images/string-intern/string_intern.png" alt=""> <img src="/images/string-intern/string_intern.png" alt="">
+ When `a` and `b` are set to `"wtf!"` in the same line, the Python interpreter creates a new object, then references the second variable at the same time. If you do it on separate lines, it doesn't "know" that there's already `wtf!` as an object (because `"wtf!"` is not implicitly interned as per the facts mentioned above). It's a compiler optimization and specifically applies to the interactive environment. + When `a` and `b` are set to `"wtf!"` in the same line, the Python interpreter creates a new object, then references the second variable at the same time. If you do it on separate lines, it doesn't "know" that there's already `wtf!` as an object (because `"wtf!"` is not implicitly interned as per the facts mentioned above). It's a compiler optimization and specifically applies to the interactive environment.