On Thu, Sep 23, 2010 at 7:31 PM, Ender Wiggin <wiggi...@gmail.com> wrote: > Sorry for the late reply. I would really like to see this fixed. > >>> Or we [...] deprecate binascii.(un)hexlify(). > ... >>> binascii is the legacy approach here, so if anything was to go, those >>> functions would be it > ... > > I'm not entirely convinced binascii is the legacy approach. What makes this > module "legacy"?
Because the binascii functions predate the bytes type, and we added the bytes methods knowing full well that the hexlify/unhexlify functions already existed. > On the contrary, I'm pretty sure modularity is better than sticking all the > functionality in the core. > As was written in this issue: > http://psf.upfronthosting.co.za/roundup/tracker/issue3532 > "If you wanted to produce base-85 (say), then you can extend the > functionality of bytes by providing a > function that does that, whereas you can't extend the existing bytes type." > This example shows that "hex" is actually getting a special treatment by > having builtin methods associated > with the bytes type. Why don't we add ".base64" methods? Or even ".zlib"? > After all, these options were present > in Python 2.x using the "encode" method of string. In my opinion, having > modules to deal with these types of > conversions is better, and this is why I suggested sticking to binascii. This *is* a matter of opinion, but python-dev's collective opinion was already expressed in the decision to include these methods in the bytes API. Base 16 *is* given special treatment by many parts of Python, precisely because it *is* special: it's the most convenient way to express binary numbers in a vaguely human readable format. No other coding even comes close to that level of importance in computer science. > If no one else is willing to do it (that would be a > little disappoiting) Why would it be disappointing? While it's untidy, nothing's actually broken and there are ways for programmers to do everything they want to do. I (and many others here) already have a pretty long list of "things I'd like to improve/fix but haven't got around to yet", so it isn't uncommon for things to have to wait awhile before someone looks at them. As Terry said though, there *are* ways to expedite that process (In this case, providing a patch that adds a .hex method in accordance with PEP 358, or, as a more ambitious, extensible alternative, consider updating the hex builtin to support the PEP 3118 API, which would allow it to automatically provide a hex dump of any object that exposes a view of a contiguous sequence of data bytes). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
