On Mon, 2011-03-07 at 14:28 -0500, David Malcolm wrote: > I'm not a yum developer, FWIW, I'm not keen on the proposed patch, > though from the inline comment, it's not clear whether or not the patch > is meant to be taken seriously, or just a vent of frustration.
I am, and have been, frustrated. Very much so. I'm also very serious about the patch. It would be nicer if you could just fix python, or if there was another reasonable alternative. But I haven't seen one in the last 2 years, and we are still having the same retarded problems. > Here are some alternate approaches: > - characterize the kinds of bugs that happen, write them up in the > project's developer docs (e.g. the wiki), and write unit tests to cover > them > - run the unit test suite with this in the environment: > PYTHONIOENCODING=ascii > so that over-optimisic assumptions about encodings fail even when > stdout/stderr is directly connected to a tty, avoiding the nasty gotcha > when run as a daemon. > - write a helper function to assert the type of data flowing through > the system (str vs unicode, encoding of str) and fail quickly when a > variable is of the wrong data type. > - or a subclass of str that enforces the encoding rules, or a custom > class for string data that has the encoding behavior you want. Yeh, that's nice ... sure I _could_ audit/port/test every single code path of yum ever written (or will ever be written) to make sure that nothing does anything "bad" like: x = y + z ...with the "wrong" types. Because everyone knows that the solution of "just audit every single line of code using strings" worked so well in C (and "every single line" is much easier than "every single code path"). But more seriously, yes, I considered writing our own string objects in python to replace the utterly broken default ones ... but it seemed more productive to add 2 lines of code, and see if that fixed the default objects without breaking anything else worse than they already are. > - use Toshio's code > etc Toshio's code doesn't fix the above line of code, and the biggest problem is I'm really sick of auditing lines of code like the above. > FWIW, you may want to review this thread from when my proposal to fix > this got shot down upstream: > http://thread.gmane.org/gmane.comp.python.devel/109914 Which is full of "reasons" like: When sending data to a pipe or to a file, God knows what encoding should have been used. If it's any XML file (for example), using the locale's encoding would be incorrect. ...which is sort of fine, as a theoretical statement, but: 1. ascii is never the correct encoding, and hasn't been for how many years now? 2. The patch doesn't use the locale encoding, it uses utf-8. Which is always a better choice. ...also the upstream python devs. responses like: So in general, the applications should arrange to the the encoding or encode themselves when they write to some output stream. If they fail to do so, it's a bug in the application, not in Python. ...make me want to ignore their opinions entirely. There is a vague reference to "bad things may happen", but then bad things are _already_ happening and we are hitting them way too often. _______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
