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
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
