"Martin v. Loewis" wrote: > > Currently, a number of routines assume that the result of > PyUnicode_FromUnicode can be modified, i.e. they mutate the resulting > unicode object. Look at unicodeobject.c:fixup for an example, and > assume that fixfct is fixtitle (*). 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. > This is different from PyString_FromStringAndSize, whose result can be > only modified if the str argument is NULL. > > These routines broke after I applied my caching patch, since now > PyUnicode_FromUnicode may return an existing string. > > Is that difference intentional? My feeling is that it is an error to > modify a unicode object, unless it is known not to be initialized. It is an error, but only for code outside the implementation, i.e. programs using the public API may only modify the contents when calling PyUnicode_FromUnicode() with NULL as u argument. Sorry for not remembering this when reviewing your patch on SF. -- 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