From jeremy@digicool.com Fri Jun 1 21:01:54 2001 From: jeremy@digicool.com (Jeremy Hylton) Date: Fri, 1 Jun 2001 16:01:54 -0400 (EDT) Subject: [Types-sig] Re: documenting Python constraints on types In-Reply-To: <3B153436.EB8FAECE@arakne.com> References: <3B143FEB.F6FCC264@arakne.com> <15125.5480.380570.78206@cj42289-a.reston1.va.home.com> <3B153436.EB8FAECE@arakne.com> Message-ID: <15127.62642.866065.123897@slothrop.digicool.com> >>>>> "FG" == Frederic Giacometti writes: FG> "Fred L. Drake, Jr." wrote: >> I don't think that's quite it, though it certainly has an affect >> on the interest in documenting the types. Part of the lack of >> type information is a matter of there not being a shared set of >> names for abstract types that is also sufficient to be precise. >> (For example: What does it mean for an object to be a "mapping"? >> Perhaps has_key() is sufficient in one context, but get() and >> setdefault() are needed in another.) FG> A 'mapping' is an object that 'implements' the object protocol FG> (PyMapping_Check()... ok). I think that everybody's interessest FG> is in working for a small set of standard interface definitions. What's a sequence then? If you say anything that PySequence_Check() says okay for, then there is almost no code that accepts a sequence. In both cases, we would appear to skip instances that implement the sequence or mapping protocols, which are accepted most places that sequences or mappings are accepted. Jeremy From tim.one@home.com Fri Jun 1 21:11:31 2001 From: tim.one@home.com (Tim Peters) Date: Fri, 1 Jun 2001 16:11:31 -0400 Subject: [Types-sig] Re: documenting Python constraints on types In-Reply-To: <15127.62642.866065.123897@slothrop.digicool.com> Message-ID: [Jeremy Hylton] > What's a sequence then? If you say anything that PySequence_Check() > says okay for, then there is almost no code that accepts a sequence. ? Isn't that backwards? PySequence_Check() says "yes" to every instance, and in 2.2 even says "yes" to dictionaries too (because Guido filled in PyDict_Type's tp_as_sequence slot in order to get at sq_contains). From frederic.giacometti@arakne.com Sat Jun 2 13:03:28 2001 From: frederic.giacometti@arakne.com (Frederic Giacometti) Date: Sat, 02 Jun 2001 08:03:28 -0400 Subject: [Types-sig] Re: documenting Python constraints on types References: <3B143FEB.F6FCC264@arakne.com> <15125.5480.380570.78206@cj42289-a.reston1.va.home.com> <3B153436.EB8FAECE@arakne.com> <15127.62642.866065.123897@slothrop.digicool.com> Message-ID: <3B18D610.5AEBBB83@arakne.com> Jeremy Hylton wrote: > >>>>> "FG" == Frederic Giacometti writes: > > > FG> A 'mapping' is an object that 'implements' the object protocol > FG> (PyMapping_Check()... ok). I think that everybody's interessest > FG> is in working for a small set of standard interface definitions. > > What's a sequence then? If you say anything that PySequence_Check() > says okay for, then there is almost no code that accepts a sequence. > In both cases, we would appear to skip instances that implement the > sequence or mapping protocols, which are accepted most places that > sequences or mappings are accepted. OK. Taking the C check function as reference may not be the right thing (Then you might ask; Are the PySequence_Check and PyMapping_Check functions of any use other than checking that the the desiring protocol field has a non-null value in the C type defintion? ... but that's another debate). I guess some further definition and formalizing work is required for the basic Python types / protocol. Here is a step forward: In the same spirit as in the read-only / writable Mapping, you may define: - "Tuple" (as a non-mutable read-only sequence0 - "Vector" (items can be changed, but the sequence size is frozen, just like in a vector object) - List (anything can be done on it; modifying items, adding/removing items; just like a plain list). Here again, with these three hierarchical protocol/interfaces (each one add feature the previous did not have), you cover 98% of the sequence situations. FG From tim.one@home.com Sat Jun 2 23:30:17 2001 From: tim.one@home.com (Tim Peters) Date: Sat, 2 Jun 2001 18:30:17 -0400 Subject: [Types-sig] Re: documenting Python constraints on types In-Reply-To: <3B18D610.5AEBBB83@arakne.com> Message-ID: [Frederic Giacometti] > OK. Taking the C check function as reference may not be the right thing > (Then you might ask; Are the PySequence_Check and PyMapping_Check > functions of any use other than checking that the the desiring protocol > field has a non-null value in the C type defintion? No, they aren't. > ... but that's another debate). ? They do what they do. Whether that's useful depends on the purpose you have in mind. I'm sure Guido would prefer to drop the operator.isXXXType() functions, since they don't *usually* do what people "think" they do. But what people think they *ought* to do varies by person, so it's unclear how to improve the situation. > I guess some further definition and formalizing work is required > for the basic Python types / protocol. Have you looked at Paul Prescod's recent work here? Unfortunately, the Types-SIG home page doesn't seem to have a reference to it. Paul? > Here is a step forward: > In the same spirit as in the read-only / writable Mapping, you may > define: > > - "Tuple" (as a non-mutable read-only sequence Is that enough? Sometimes the distinction of interest is that it's-- unlike all tuples --immutable "all the way down". This is akin to the distinction the hash() builtin makes: not all tuples are hashable. This is a "shallow vs deep" thing, e.g. (1, 2, 3) vs (1, [2], 3). We *call* both of those "immutable" today, but the value of the latter (as seen by "==") may actually change over time. > - "Vector" (items can be changed, but the sequence size is > frozen, just like in a vector object) What's "a vector object" ? > - List (anything can be done on it; modifying items, adding/removing > items; just like a plain list). Including, e.g., list.sort()? You have to be very specific -- I'm afraid "just like" is never adequate, as different people read different things into any gap in precision. > Here again, with these three hierarchical protocol/interfaces > (each one add feature the previous did not have), you cover 98% of > the sequence situations. I would have guessed 97.9% . From frederic.giacometti@arakne.com Tue Jun 5 23:32:44 2001 From: frederic.giacometti@arakne.com (Frederic Giacometti) Date: Tue, 05 Jun 2001 18:32:44 -0400 Subject: [Types-sig] Re: documenting Python constraints on types References: Message-ID: <3B1D5E0C.5FC4CB0@arakne.com> Tim Peters wrote: > > I guess some further definition and formalizing work is required > > for the basic Python types / protocol. > > Have you looked at Paul Prescod's recent work here? Unfortunately, the > Types-SIG home page doesn't seem to have a reference to it. Paul? No, I'm not aware of it. Could Tim could give a reference to it ? > > > Here is a step forward: > > In the same spirit as in the read-only / writable Mapping, you may > > define: > > > > - "Tuple" (as a non-mutable read-only sequence > > Is that enough? Sometimes the distinction of interest is that it's-- unlike > all tuples --immutable "all the way down". It is consistent with Python; and defining 'immutability all the way down' is a Grail guest; you'll never be able to contain all possible side effects with Python, and then you'll have missed some. Besides, personnally, I see minor practical need for it, too. In any way, Tuple type need to be specified, since Tuple is a major Python type, and you can't get around without it. > This is akin to the distinction > the hash() builtin makes: not all tuples are hashable. This is a "shallow > vs deep" thing, e.g. (1, 2, 3) vs (1, [2], 3). We *call* both of those > "immutable" today, but the value of the latter (as seen by "==") may > actually change over time. Doing hashing with tuple as key is something fairly rare (for instance, you might want to count these situations in Python standard lib...). The case would have to be documented as an extra in the function/method definition. [[ Actually, in all practical cases of hashable tuples I know of, the type of each Tuple item is specified, so the problem does not occur there... Ex: (String, Int, Int) is a hashable tuple; no problem. ]] But let me remind the spirit of the thing: Make it fit the most common cases, the few other cases will require additional documentation. That makes sense to me :)) I'd rather have something that works in 80% of the cases, than nothing at all as it is presently the case. I'm not looking for any Grail; I'm just being practical :)) > > > - "Vector" (items can be changed, but the sequence size is > > frozen, just like in a vector objec > What's "a vector object" ? What does PyNumerical works with, for instance? It says it: <>; just like a C array.... A 3D vector of Floats can be specified as Vector( 3)[ Float], or as [Float, Float, Float]. Anybody normally connected understands such a notation (I hope :)). > > - List (anything can be done on it; modifying items, adding/removing > > items; just like a plain list). > > Including, e.g., list.sort()? You have to be very specific -- I'm afraid > "just like" is never adequate, as different people read different things > into any gap in precision. Well, we have to start from something, don't we? :)) We're no God who can create from nothing :)) Again, I'd rather start from a loose definition and narrow it down, that not do anything by fear of not getting it right the first time :))) (that's RAD, incremental quality improvement, small steps, U-name-it). Given that I know that I will never be 'perfectly specific', I'll be looking forward to being 'more and more specific'... Personally, I'd keep the sort() method outside (not required), and explicitely document it whenever it is required. Again, this is used in only a very small minority of functions. FG From tim.one@home.com Sun Jun 10 06:22:05 2001 From: tim.one@home.com (Tim Peters) Date: Sun, 10 Jun 2001 01:22:05 -0400 Subject: [Types-sig] Re: documenting Python constraints on types In-Reply-To: <3B1D5E0C.5FC4CB0@arakne.com> Message-ID: [Frederic Giacometti] >>> I guess some further definition and formalizing work is required >>> for the basic Python types / protocol. [Tim] >> Have you looked at Paul Prescod's recent work here? Unfortunately, the >> Types-SIG home page doesn't seem to have a reference to it. Paul? [Frederic] > No, I'm not aware of it. > Could Tim could give a reference to it ? I delayed replying hoping to find enough time to search the list archives, but it looks like I'm never going to get to that. Paul, you there? I believe your work here was very much in tune what Frederic is looking for. From paulp@ActiveState.com Tue Jun 12 00:37:04 2001 From: paulp@ActiveState.com (Paul Prescod) Date: Mon, 11 Jun 2001 16:37:04 -0700 Subject: [Types-sig] Re: documenting Python constraints on types References: Message-ID: <3B255620.73B2D0C9@ActiveState.com> Tim Peters wrote: > >... > > > I guess some further definition and formalizing work is required > > for the basic Python types / protocol. > > Have you looked at Paul Prescod's recent work here? Unfortunately, the > Types-SIG home page doesn't seem to have a reference to it. Paul? http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbox/typecheck/src/typecheck.py Here's the definition of a sequence (right now): def _isseq(obj, valuetype=Undefined): if type(obj)==types.InstanceType: if not hasattr( obj, "__getitem__"): return 0 elif not operator.isSequenceType(obj): return 0 if valuetype is not Undefined: try: # check first and last -- that's an approximation! if not checkType(obj[1], valuetype): return 0 if not checkType(obj[-1], valuetype): return 0 except IndexError: pass # empty list is considered good enough return 1 # passed all tests! Sequence = Interface("Sequence", "Some kind of sequence", _isseq) The stuff in the middle about "valuetype" is a constant-time approximation of checking "sequence of strings" versus "sequence of integers". I didn't drill down into tuple versus list versus vector because my goal was never to be as precise as Java interfaces but rather to catch mistakes people make. I could be convinced that the mutable/immutable distinction is important but then you get into issues of deepness and immutable dictionaries and ... Type declarations look like this: def execl(file: String, args: Sequence(String)) http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbox/typecheck/lib/os.pyt -- Take a recipe. Leave a recipe. Python Cookbook! http://www.ActiveState.com/pythoncookbook