Mailman 3 March 2000 - Python-Dev

Nitpicking on UserList implementation
by pf＠artcom-gmbh.de March 22, 2000

March 22, 2000

Hi! Please have a look at the following method cited from Lib/UserList.py: def __radd__(self, other): if isinstance(other, UserList): # <-- ? return self.__class__(other.data + self.data) # <-- ? elif isinstance(other, type(self.data)): return self.__class__(other + self.data) else: return self.__class__(list(other) + self.data) The reference manual tells about the __r*__ methods: """These … [View More]

1 0

Re: [Python-Dev] Unicode and Windows
by M.-A. Lemburg March 22, 2000

March 22, 2000

Jack Jansen wrote: > > > "es#",&encoding,&buffer,&buffer_len > > -- could mean: coerce the object to Unicode, then > > encode it using the given encoding and then > > copy at most buffer_len bytes of data into > > buffer and update buffer_len to the number of bytes > > copied > > This is a possible solution, but I think I would really prefer to also have > "eS", &encoding, &… [View More]

1 0

Unicode and Windows
by Mark Hammond March 22, 2000

March 22, 2000

I would like to discuss Unicode on the Windows platform, and how it relates to MBCS that Windows uses. My main goal here is to ensure that Unicode on Windows can make a round-trip to and from native Unicode stores. As an example, let's take the registry - a Windows user should be able to read a Unicode value from the registry then write it back. The value written back should be _identical_ to the value read. Ditto for the file system: If the filesystem is Unicode, then I would expect the … [View More]

2 3

Unicode Database Compression
by Christian Tismer March 22, 2000

March 22, 2000

Hi, I have spent the last four days on compressing the Unicode database. With little decoding effort, I can bring the data down to 25kb. This would still be very fast, since codes are randomly accessible, although there are some simple shifts and masks. With a bit more effort, this can be squeezed down to 15kb by some more aggressive techniques like common prefix elimination. Speed would be *slightly* worse, since a small loop (average 8 cycles) is performed to obtain a character from a … [View More]

2 1

Set options
by Ka-Ping Yee March 21, 2000

March 21, 2000

I think that at this point the possibilities for doing sets come down to four options: 1. use lists visible changes: new methods l.include, l.exclude invisible changes: faster 'in' usage: s = [1, 2], s.include(3), s.exclude(3), if item in s, for item in s 2. use dicts visible changes: for/if x in dict means keys accept dicts without values (e.g. {1, 2}) new special non-printing value ": … [View More]Present" new method d.insert(x) means d[x] = Present invisible changes: none usage: s = {1, 2}, s.insert(3), del s[3], if item in s, for item in s 3. new type visible changes: set() built-in new <type 'set'> with methods .insert, .remove invisible changes: none usage: s = set(1, 2), s.insert(3), s.remove(3) if item in s, for item in s 4. do nothing visible changes: none invisible changes: none usage: s = {1: 1, 2: 1}, s[3] = 1, del s[3], if s.has_key(item), for item in s.keys() Let me say a couple of things about #1 and #2. I'm happy with both. I quite like the idea of using dicts this way (#2), in fact -- i think it was the first idea i remember chatting about. If i remember correctly, Guido's objection to #2 was that "in" on a dictionary would work on the keys, which isn't consistent with the fact that "in" on a list works on the values. However, this doesn't really bother me at all. It's a very simple rule, especially when you think of how people understand dictionaries. If you hand someone a *real* dictionary, and ask them Is the word "python" in the dictionary? they'll go look up "python" in the *keys* of the dictionary (the words), not the values (the definitions). So i'm quite all right with saying for x in dict: and having that loop over the keys, or saying if x in dict: and having that check whether x is a valid key. It makes perfect sense to me. My main issue with #2 was that sets would print like {"Alice": 1, "Bob": 1, "Ted": 1} and this would look weird. However, as Greg explained to me, it would be possible to introduce a default value to go with set members that just says "i'm here", such as 'Present' (read as: "Alice" is present in the set) or 'Member' or even 'None', and this value wouldn't print out -- thus s = {"Bob"} s.include("Alice") print s would produce {"Alice", "Bob"} representing a dictionary that actually contained {"Alice": Present, "Bob": Present} You'd construct set constants like this too: {2, 4, 7} Using dicts this way (rather than having a separate set type that just happened to be spelled with {}) avoids the parsing issue: no need for look-ahead; you just toss in "Present" when the text doesn't supply a colon, and move on. I'd be okay with this, though i'm not sure everyone would; and together with Guido's initial objection, that's what motivated me to propose the lists-as-sets thing: fewer changes all around, no ambiguities introduced -- just two new methods, and we're done. Hmm. I know someone who's just learning Python. I will attempt to ask some questions about what she would find natural, and see if that reveals anything interesting. -- ?!ng [View Less]

8 13

Re: [Python-Dev] Unicode and Windows
by Jack Jansen March 21, 2000

March 21, 2000

I guess we need another format specifier than "s" here. "s" does the conversion to standard-python-utf8 for wide strings, and we'd need another format for conversion to current-local-os-convention-8-bit-encoding-of-unicode- strings. I assume that that would also come in handy for MacOS, where we'll have the same problem (filenames are in Apple's proprietary 8bit encoding). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you … [View More]

3 3

re: Using lists as sets
by gvwilson＠nevex.com March 20, 2000

March 20, 2000

[After discussion with Ping, and weekend thought] I would like to vote against using lists as sets: 1. It blurs Python's categorization of containers. The rest of the world thinks of sets as unordered, associative, and binary-valued (a term I just made up to mean "containing 0 or 1 instance of X"). Lists, on the other hand, are ordered, positionally-indexed, and multi-valued. While a list is always a legal queue or stack (although lists permit state transitions that are … [View More]

6 10

list.shift()
by Ka-Ping Yee March 20, 2000

March 20, 2000

Has list.shift() been proposed? # pretend lists are implemented in Python and 'self' is a list def shift(self): item = self[0] del self[:1] return item This would make queues read nicely... use "append" and "pop" for a stack, "append" and "shift" for a queue. (This is while on the thought-train of "making built-in types do more, rather than introducing more special types", as you'll see in my next message.) -- ?!ng

6 10

Using lists as sets
by Ka-Ping Yee March 17, 2000

March 17, 2000

A different way to provide sets in Python, which occurred to me on Wednesday at Guido's talk in Mountain View (hi Guido!), is to just make lists work better. Someone asked Guido a question about the ugliness of using dicts in a certain way, and it was clear that what he wanted was a real set. Guido's objection to introducing more core data types is that it makes it more difficult to choose which data type to use, and opens the possibility of using entirely the wrong one -- a very well-taken … [View More]

3 5

Boolean type for Py3K?
by Ka-Ping Yee March 17, 2000

March 17, 2000

I wondered to myself today while reading through the Python tutorial whether it would be a good idea to have a separate boolean type in Py3K. Would this help catch common mistakes? I won't presume to truly understand the new-to-Python experience, but one might *guess* that >>> 5 > 3 true would make a little more sense to a beginner than >>> 5 > 3 1 Of course this means introducing "true" and "false" as keywords (or built-in values like None -- … [View More]

6 7