On Jun 22, 2010, at 03:08 AM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
Would it make sense to have "encoding-carrying" bytes and str types?
Why limit that to bytes and str? Why not have all objects carry their serializer/deserializer around with them?
Only because the .encoding attribute isn't really a serializer/deserializer. That's still bytes() and str() or the equivalent. This is just a hint to a specific serializer for parameters to that action.
I think the answer is "no", though, because (1) it would constitute an attractive nuisance (the default would be abused, it would work fine in Kansas, and all hell would break loose in Kagoshima, simply delaying the pain and/or passing it on to third parties), and (2) you really want this under control of higher level objects that have access to some knowledge of the environment, rather than the lowest level.
I'm still not sure ebytes solves the problem, but it avoids one I'm most concerned about seeing proposed. I really really do not want to add encoding=blah arguments to boatloads of function signatures. -Barry