"Martin v. Loewis" wrote: > > > This is true for the APIs in unicodeobject.c: as long as the newly > > created object hasn't "left" the Unicode implementation, the APIs > > in there are free to modify the otherwise immutable object. > > That means that PyUnicode_FromUnicode does give a guarantee to return > a fresh object, right? Let's put it this way: the internals in unicodeobject.c are allowed to modify the contents of the object even if it was prefilled with data that came from an initializer. External caller are not allowed to do this though unless u is set to NULL (just like in the corresponding string call). > Then I cannot understand why it only gives this guarantee to callers > inside unicodeobject.c, and not to other callers... Because I want to reserve the right to change the semantics *inside* unicodeobject.c at some later point. Note that currently no caching of Unicode objects takes place, but this could change in the future and indeed your patch starts into this direction. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4