[Python-Dev] [Python-checkins] cpython: Optimize string slicing to use the new API (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Wed Oct 5 18:11:15 CEST 2011
- Previous message: [Python-Dev] [Python-checkins] cpython: Optimize string slicing to use the new API
- Next message: [Python-Dev] cpython (3.2): Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I see this as a micro-optimization. IMO we should not rely on these assumptions because we cannot expect that all developers of third party modules will be able to write perfect code, and some (lazy developers!) may prefer to use a fixed maximum character (e.g. 0xFFFF).
Hmm. I'd like to declare that it is incorrect usage of the API, only allowing maxchar to be at the next boundary (i.e. 127, 255, 65536, larger).
There are always cases of incorrect usage of all API. For example, not filling out a list entirely (i.e. leaving NULL in some fields) may also cause strange results.
Users will need to learn what the API is. At the first approximation, maxchar should be the true maximum character.
To be able to rely on such assumption, we have to make sure that strings are in canonical forms (always check before using a string?).
No, we don't need that: garbage in, garbage out. If people use the API incorrectly, they will get incorrect results. It's useful to have checks in debug mode, but that's the most that people should reasonably expect.
Regards, Martin
- Previous message: [Python-Dev] [Python-checkins] cpython: Optimize string slicing to use the new API
- Next message: [Python-Dev] cpython (3.2): Issue #11956: Skip test_import.test_unwritable_directory on FreeBSD when run as
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]