4 ms·

> Also note that Armin has repeatedly praised Rust's text model, which is much more similar to P3's than P2's (except with static types and no messy legacy). T

> Also note that Armin has repeatedly praised Rust's text model, which is much more similar to P3's than P2's (except with static types and no messy legacy). That is incorrect. Rust's text model has (almost) free (and copyless) transmutes from bytes to strings. Python does not. The text model of rust is much closer to Python 2 than 3 in many ways.

masklinn 10y ago
> That is incorrect. […] The text model of rust is much closer to Python 2 than 3 in many ways. Rust's text model strictly separates proper strings and bytestrings, defaults to proper strings and requires that strings be properly formed (so much so that it has additional completely separated platform-dependent types for dealing with OS-originated "stuff"). The one "difference" (which is more in the realm of implementation detail than language text model) is that Rust leverages its ownership system to make UTF8 "encoding" and "decoding" free (literally for the former, essentially for the former). The encoding and decoding are still there and explicit operations though. > Rust's text model has (almost) free (and copyless) transmutes from bytes to strings. Only for the specific case of input bytes already in the language's internal encoding (which granted will be common as most inputs would be ascii or utf-8) and with the same ownership constraints as the input, and that's mostly enabled by Rust's ownership model. > Python does not. Python doesn't generally do no-alloc/0-copy operations so that's not overly surprising.
- dom0 10y ago
  > Only for the specific case of input bytes already in the language's internal encoding (which granted will be common as most inputs would be ascii or utf-8) and with the same ownership constraints as the input, and that's mostly enabled by Rust's ownership model. Except of course on operating systems where text I/O is done entirely in UTF-16. Say, Windows. Since Python strings have no fixed encoding, but choose "the most efficient one" (heuristically) when decoding, they can cope better than a fixed UTF-8 encoding in these cases. >> Python does not. > Python doesn't generally do no-alloc/0-copy operations so that's not overly surprising. Indeed. Even when the encoding is not changed, the string will be always copied. One could think of an API that does that, though, to optimize all those cases were memory is already owned by a shim in the runtime.
  - the_mitsuhiko 10y ago
    > Since Python strings have no fixed encoding, but choose "the most efficient one" (heuristically) when decoding, they can cope better than a fixed UTF-8 encoding in these cases. That is wrong. Python can never pick the most efficient encoding unless you decode from latin1.
    - dom0 10y ago
      PEP 393
      - the_mitsuhiko 10y ago
        That's why I said it can use the most appropriate encoding in the latin1 case. Before that it would never have the right encoding.
- the_mitsuhiko 10y ago
  Rust having strings that are utf-8 is a guarantee and as such allows uou to do very efficient operations on them. Puthon gives you a vagie guarantee that it gives you O(1) access to something like a glyph. These are very different and incompatible text models. At no point is Python's text model fast or overly useful.

masklinn 10y ago

> That is incorrect. […] The text model of rust is much closer to Python 2 than 3 in many ways. Rust's text model strictly separates proper strings and bytestrings, defaults to proper strings and requires that strings be properly formed (so much so that it has additional completely separated platform-dependent types for dealing with OS-originated "stuff"). The one "difference" (which is more in the realm of implementation detail than language text model) is that Rust leverages its ownership system to make UTF8 "encoding" and "decoding" free (literally for the former, essentially for the former). The encoding and decoding are still there and explicit operations though. > Rust's text model has (almost) free (and copyless) transmutes from bytes to strings. Only for the specific case of input bytes already in the language's internal encoding (which granted will be common as most inputs would be ascii or utf-8) and with the same ownership constraints as the input, and that's mostly enabled by Rust's ownership model. > Python does not. Python doesn't generally do no-alloc/0-copy operations so that's not overly surprising.

dom0 10y ago
> Only for the specific case of input bytes already in the language's internal encoding (which granted will be common as most inputs would be ascii or utf-8) and with the same ownership constraints as the input, and that's mostly enabled by Rust's ownership model. Except of course on operating systems where text I/O is done entirely in UTF-16. Say, Windows. Since Python strings have no fixed encoding, but choose "the most efficient one" (heuristically) when decoding, they can cope better than a fixed UTF-8 encoding in these cases. >> Python does not. > Python doesn't generally do no-alloc/0-copy operations so that's not overly surprising. Indeed. Even when the encoding is not changed, the string will be always copied. One could think of an API that does that, though, to optimize all those cases were memory is already owned by a shim in the runtime.
- the_mitsuhiko 10y ago
  > Since Python strings have no fixed encoding, but choose "the most efficient one" (heuristically) when decoding, they can cope better than a fixed UTF-8 encoding in these cases. That is wrong. Python can never pick the most efficient encoding unless you decode from latin1.
  - dom0 10y ago
    PEP 393
    - the_mitsuhiko 10y ago
      That's why I said it can use the most appropriate encoding in the latin1 case. Before that it would never have the right encoding.
the_mitsuhiko 10y ago
Rust having strings that are utf-8 is a guarantee and as such allows uou to do very efficient operations on them. Puthon gives you a vagie guarantee that it gives you O(1) access to something like a glyph. These are very different and incompatible text models. At no point is Python's text model fast or overly useful.