Alright, I've uploaded the new patch which adds the two requested bytes-oriented functions, as well as accompanying docs and tests. http://bugs.python.org/issue3300 http://bugs.python.org/file11009/parse.py.patch6 I'd rather have two pairs of functions, so that those who want to give > the readers of their code a clue can do so. I'm not opposed to having > redundant functions that accept either string or bytes though, unless > others prefer not to. > Yes, I was in a similar mindset. So the way I've implemented it, quote accepts either a bytes or a str. Then there's a new function quote_from_bytes, which is defined precisely like this: quote_from_bytes = quote > So either name can be used on either input type, with the idea being that you should use quote on a str, and quote_from_bytes on a bytes. Is this a good idea or should it be rewritten so each function permits only one input type? Sorry, I have yet to look at the tracker (only so many minutes in a day...). Ah, I didn't mean offense. Just that one could read the sordid details of my investigation on the tracker if one so desired ;) I don't mind an encoding argument, as long as it isn't used to change > the return type (as Bill was proposing). Yeah, my unquote always outputs a str, and unquote_to_bytes always outputs a bytes. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20080731/85e6eb53/attachment.htm>
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