aktiur
Joined 13 years ago
Joined 13 years ago
Fortunately, wide and narrow builds were abandonned in Python 3.2, with a new way of representing strings : current Python will use ASCII if there's no non-ASCII char, UCS-2 –UTF-16 without surrogate pairs — if there is no codepoint higher than U+FFFF, and UTF-32 else.
See this article for a good overview of the history of strings in Python : https://tenthousandmeters.com/blog/python-behind-the-scenes-...
`bytes.decode` (and `str.encode`) have used UTF-8 as a default since at least Python 3.
However, the default encoding used for decoding the name of files use ` sys.getfilesystemencoding()`, which is also UTF-8 on Windows and macos, but will vary with the locale on linux (specifically with CODESET).
Finally, `open` will directly use `locale.getencoding()`.
No, what was used was what sys.getdefaultencoding(), which was already UTF-8 in 3.1 (I checked the source code).
At that time, the format used for representing `str` objects in memory depended on if you used a "narrow" (UTF-16) or "wide" (UTF-32) build of Python.
Fortunately, wide and narrow builds were abandonned in Python 3.2, with a new way of representing strings : current Python will use ASCII if there's no non-ASCII char, UCS-2 –UTF-16 without surrogate pairs — if there is no codepoint higher than U+FFFF, and UTF-32 else. But that did not exist in 3.1, where you could either use the "narrow" build of python (that used UTF-16) or the "wide" build (that used UTF-32).
See this article for a good overview of the history of strings in Python : https://tenthousandmeters.com/blog/python-behind-the-scenes-...
You got it kind of backwards. `str` are sequence of unicode codepoints (not UTF-8, which is a specific encoding for unicode codepoints), without reference to any encoding. `bytes` are arbitrary sequence of octets. If you have some `bytes` object that somehow stands for text, you need to know that it is text and what its encoding is to be able to interpret it correctly (by decoding it to `str`).
And, if you got a `str` and want to serialize it (for writing or transmitting), you need to choose an encoding, because different encodings will generate different `bytes`.
As an example :
>>> "évènement".encode("utf-8") b'\xc3\xa9v\xc3\xa8nement'
>>> "évènement".encode("latin-1") b'\xe9v\xe8nement'
It makes sense when you have a small team of people that know the project very well to record everything, and they can easily maintain stringent standards, like never committing anything that breaks the tests.
Whereas for a big project that involve thousands of people mailing patches around, some of them first time contributors, you'd rather make sure that what ends up in the immutable log has is clean enough.
I would say that's basically how addiction manifests itself: even if you know that you're dealing with substance abuse, come on, one more time won't matter, will it?
And then there's also the comfort aspect: you're getting back from a hard day's work, you're feeling tired and cranky, you do deserve something nice, don't you?
N.B.: I'm not saying that not being able to drop the book or stop playing that game IS addiction, just that substance addiction might feel the same way.
N.B. 2:And I'm not talking here about the medical aspects of withdrawal, because that's not the thing an addict would usually experience (withdrawal would only happen because you're trying to stop or cannot get access to the substance you need).
If none is still being generated, there should not be any significant quantity left considering it has a half-life of only 8 days.
Because half of the general male population is criminal, of course.
The accuracy rate would be very different with a training/testing sample that takes the base rate of criminality into account.
https://sqlite.org/lockingv3.html#hot_journals