Jon Ribbens wrote: >> since it doesn't deal with encodings at all. > > Why does it need to? cgi.escape is (or should be) dealing with > character strings, not byte sequences. I must admit, > internationalisation is not my forte, so if there's something > I'm missing here I'd love to hear about it.
If you're really serious about making things easier to use, shouldn't you look at the whole picture? HTML documents are byte streams, so any transformation from internal character data to HTML must take both escaping and encoding into account. If you and Lawrence have a hard time remembering how to use the existing cgi.escape function, despite it's utter simplicity, surely it would make your life even easier if there was an alternative API that would handle both the easy part (escaping) and the hard part (encoding) ? > By the way, if you could try and put across your proposed arguments as > to why you don't favour this suggested change without the insults and > general rudeness, it would be appreciated. I've already explained that, but since you're convinced that your use case is more important than other use cases, and you don't care about things like stability and respect for existing users of an API, nor the cost for others to update their code and unit tests, I don't see much need to repeat myself. Breaking things just because you think you can simply isn't the Python way of doing things. </F> -- http://mail.python.org/mailman/listinfo/python-list
