I wrote: > > > Do we need a UserString class? > > Andy Robinson: > > This will probably be useful on top of the i18n stuff in due course, > > so I'd like it. > > > > Something Mike Da Silva and I have discussed a lot is implementing a > > higher-level 'typed string' library on top of the Unicode stuff. > > A 'typed string' is like a string, but knows what encoding it is in - > > possibly Unicode, possibly a native encoding and embodies some basic > > type safety and convenience notions, like not being able to add a > > Shift-JIS and an EUC string together. Iteration would always be per > > character, not per byte; and a certain amount of magic would say that > > if the string was (say) Japanese, it would acquire a few extra methods > > for doing some Japan-specific things like expanding half-width > > katakana. > > > > Of course, we can do this anyway, but I think defining the API clearly > > in UserString is a great idea. > Guido van Rossum: > Agreed. Please somebody send a patch! I feel unable to do, what Andy proposed. What I had in mind was a simple wrapper class around the builtin string type similar to UserDict and UserList which can be used to derive other classes from. I use UserList and UserDict quite often and find them very useful. They are simple and powerful and easy to extend. May be the things Andy Robinson proposed above belong into a sub class which inherits from a simple UserString class? Do we need an additional UserUnicode class for unicode string objects? Regards, Peter -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
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