Mailman 3 March 2006 - Python-Dev

Re: [Python-Dev] bytes.from_hex()
by Chermside, Michael 01 Mar '06

01 Mar '06

Ron Adam writes: > While playing around with the example bytes class I noticed code reads > much better when I use methods called tounicode and tostring. [...] > I'm not suggesting we start using to-type everywhere, just where it > might make things clearer over decode and encode. +1 I always find myself slightly confused by encode() and decode() despite the fact that I understand (I think) the reason for the choice of those names and by rights ought to have no trouble. I'm not arguing that it's worth the gratuitous code breakage (I don't have enough code using encode() and decode() for my opinion to count in that matter.) But I will say that if there were no legacy I'd prefer the tounicode() and tostring() (but shouldn't it be 'tobytes()' instead?) names for Python 3.0. -- Michael Chermside ***************************************************************************** This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it. *****************************************************************************

2 1

Re: [Python-Dev] str object going in Py3K
by Guido van Rossum 01 Mar '06

01 Mar '06

On 2/14/06, Just van Rossum <just(a)letterror.com> wrote: > Guido van Rossum wrote: > > [...] surely text files are more commonly used, and surely the > > most common operation should have the shorter name -- call it the > > Huffman Principle. > > +1 for two functions. > > My choice would be open() for binary and opentext() for text. I don't > find that backwards at all: the text function is going to be more > different from the current open() function then the binary function > would be since in many ways the str type is closer to bytes than to > unicode. It's still backwards because the current open function defaults to text on Windows (the only platform where it matters any more). > Maybe it's even better to use opentext() AND openbinary(), and deprecate > plain open(). We could even introduce them at the same time as bytes() > (and leave the open() deprecation for 3.0). And then, on 2/14/06, Alex Martelli <aleaxit(a)gmail.com> wrote: > What about shorter names, such as 'text' instead of 'opentext' and > 'data' instead of 'openbinary'? By eschewing the 'open' prefix we > might make it easy to eventually migrate off it. Maybe text and data > could be two subclasses of file, with file remaining initially as it > is (and perhaps becoming an abstract-only baseclass at the time 'open' > is deprecated). Plain 'text' and 'data' don't convey the fact that we're talking about opening I/O objects here. If you want, we could say textfile() and datafile(). (I'm fine with data instead of binary.) But somehow I still like the 'open' verb. It has a long and rich tradition. And it also nicely conveys that it is a factory function which may return objects of different types (though similar in API) based upon either additional arguments (e.g. buffering) or the environment (e.g. encodings) or even inspection of the file being opened. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

14 46

Proposal: defaultdict
by Guido van Rossum 01 Mar '06

01 Mar '06

A bunch of Googlers were discussing the best way of doing the following (a common idiom when maintaining a dict of lists of values relating to a key, sometimes called a multimap): if key not in d: d[key] = [] d[key].append(value) An alternative way to spell this uses setdefault(), but it's not very readable: d.setdefault(key, []).append(value) and it also suffers from creating an unnecessary list instance. (Timings were inconclusive; the approaches are within 5-10% of each other in speed.) My conclusion is that setdefault() is a failure -- it was a well-intentioned construct, but doesn't actually create more readable code. Google has an internal data type called a DefaultDict which gets passed a default value upon construction. Its __getitem__ method, instead of raising KeyError, inserts a shallow copy (!) of the given default value into the dict when the value is not found. So the above code, after d = DefaultDict([]) can be written as simply d[key].append(value) Note that of all the possible semantics for __getitem__ that could have produced similar results (e.g. not inserting the default in the underlying dict, or not copying the default value), the chosen semantics are the only ones that makes this example work. Over lunch with Alex Martelli, he proposed that a subclass of dict with this behavior (but implemented in C) would be a good addition to the language. It looks like it wouldn't be hard to implement. It could be a builtin named defaultdict. The first, required, argument to the constructor should be the default value. Remaining arguments (even keyword args) are passed unchanged to the dict constructor. Some more design subtleties: - "key in d" still returns False if the key isn't there - "d.get(key)" still returns None if the key isn't there - "d.default" should be a read-only attribute giving the default value Feedback? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

33 103

New test failure on Windows
by Tim Peters 28 Feb '06

28 Feb '06

test test_pep352 failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_pep352.py", line 54, in test_inheritance self.fail("%s not a built-in exception" % exc_name) AssertionError: WindowsError (Windows) not a built-in exception

1 0

Re: [Python-Dev] bytes.from_hex()
by Greg Ewing 28 Feb '06

28 Feb '06

Bill Janssen wrote: > Well, I can certainly understand the bytes->base64->bytes side of > thing too. The "text" produced is specified as using "a 65-character > subset of US-ASCII", so that's really bytes. But it then goes on to say that these same characters are also a subset of EBCDIC. So it seems to be talking about characters as abstract entities here, not as bit patterns. Greg

1 0