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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20100621/dda14ec7/attachment.pgp>
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