From scott@chronis.pobox.com Tue Feb 1 14:26:27 2000 From: scott@chronis.pobox.com (scott) Date: Tue, 1 Feb 2000 09:26:27 -0500 Subject: [Types-sig] STICK - static type and interface checking for python In-Reply-To: <20000128190645.A26999@chronis.pobox.com> References: <20000128190645.A26999@chronis.pobox.com> Message-ID: <20000201092627.A51081@chronis.pobox.com> On Fri, Jan 28, 2000 at 07:06:45PM -0500, scott wrote: [...] > It is available at > > ftp://chronis.pobox.com/pub/python/stick-20000128.tgz > It has come to my attention (finally!) that my ftp server was rendered useless to the outside world by my firewall. I'd like to announce that it's up and running correctly now, and that there's a newer version available at ftp://chronis.pobox.com/pub/python/stick-20000201.tgz Below is the introduction at the head of the README file. scott --------------------------------------------------------------------------- Welcome to STICK, a Static Type and Interface Checker for python. STICK is primarily a tool to help develop a proposal for a means to include static type and interface checking in some future version of python. Since this is a pretty complex domain, it turns out that the only way to create a convincingly viable means of doing this is to create a prototype implementation of python with static type and interface checking built right in, or atleast enough of a working working to show that a complete system would work. Taking this approach has forced me to address many of the real issues of a typing system for python in a concrete way, and will hopefully help us all understand the constraints that we are working with more thoroughly as well as demonstrate atleast one way to effectively deal with these constraints. From scott@chronis.pobox.com Sat Feb 5 01:02:15 2000 From: scott@chronis.pobox.com (scott) Date: Fri, 4 Feb 2000 20:02:15 -0500 Subject: [Types-sig] STICK - update and overhaul Message-ID: <20000204200215.A90332@chronis.pobox.com> STICK has undergone a large facelift in all areas: code, features, and notes. Major changes include: None as the type-emptyset. Makes life in static type land much nicer :) supprt for type checking classes, class hierarchies, and interfaces added, with simple syntax and reasonable flexibility. many more samples demonstrating specific type checking issues. Additionally, some of the code has been reorganized, and the NOTES file updated with newly discovered information and implications. Soon, STICK will have a web page. I've put this off because maintaining it would be a hindrance to the goal of exploration and learning through implementation. However, STICK is very near the point where that will no longer be the case. In the mean time, I'd like to promote old fashioned ASCII as your friend -- download it and read the README in your favorite pager or text editor to get started. Try it out, post some feedback. I'd love to hear some :) the latest snapshot is available at ftp://chronis.pobox.com/pub/python/stick-20000204.tgz scott From scott@chronis.pobox.com Mon Feb 7 20:48:12 2000 From: scott@chronis.pobox.com (scott) Date: Mon, 7 Feb 2000 15:48:12 -0500 Subject: [Types-sig] more web pages Message-ID: <20000207154812.A4811@chronis.pobox.com> There are now more web pages available regarding type checking and python. The pages are part of the STICK project and offer a collection of notes about type checking and python organized in a hierarchical manner. Very much under construction, and very much content based rather than prettified. Please take a look if you're interested in this stuff, there are a lot of fundamental things summarized there, as well as some clarification of typing concepts. http://chronis.pobox.com/~scott/stick scott From paul@prescod.net Sun Feb 27 18:55:59 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 27 Feb 2000 10:55:59 -0800 Subject: [Types-sig] Apologies and proposal Message-ID: <38B9733F.F251C817@prescod.net> I apologize for neglecting the types sig. I've been working on the code for XML support in Python 1.6. We have an opportunity to do something really cool there which will change the world's view of XML in Python and hopefully attract alot of new users and perhaps even a few big corporate backers. And of course beside that there is my day job, blah blah blah, excuse, excuse, excuse. What I would like to ask you participants is whether we our first goal should be to push ahead with an end-game proposal or rather push for an incremental 20/80 proposal. Arguably, the most pythonic 20% of "ERR" is helping people to avoid simple mistakes like passing lists where strings are expected and mappings where lists are expected and the most pythonic 20% of "OPT" is being able to map integers to C/Java integers, strings to C/Java strings and so forth. And I think that "DOC" is similar. And of course the point of 20/80 is that we should get a huge amount of benefit for the small investment and then worry about the rest of the enchilada later. If I'm right, then we should consider moving as quickly as possible (1.6 or 1.7) to providing that 20% and using it as input in our decisions on the hard 80%. I hear screams of pain on the mention of 1.6 but I would prefer that we didn't rule it out until we think through what the actual implementation costs are. Maybe all we do in 1.6 is change the grammar so that we have that experimentation with checkers and introspectors is possible. Here is a minimal proposal: * inline declarations (either using "decl" or really inline in function defs) * checked at runtime depending on command line option * there is a syntax for declaring the type objects and methods in an extension class * declarations can refer to class objects or "reflected" type objects * declarations can also refer to a finite set of pre-declared "protocol" or "interface" objects: mapping, sequence, file/stream, number, callable, type. * we adopt VERY conservative rules about what class objects can be referred to so that we can later debate about extending them to objects that are not trivially available at runtime. Among the issues we would not address: * exception declarations * templates * user defined interfaces/protocols * signatures * er, static type checking Okay, arguably if we don't do static type checking then we have failed to meet our goals. But we could also see the laying down of infrastructure TOWARD static type checking as being part of the framework. We should explicitly NOT allow anything in our proposal that would prevent static type checking but we should also not expect that in version 1 we will do the full inter-module, inter-class analysis that is required to do static type checking "right". I was brought in to do a "minimal proposal" and it was the requirement that we work out all details of completely safe static* type checking that brought in all of the complexity. Once you say that you need to be able to check an "average module" at compile time you invariably bring in a huge load of issues because the "average module" does alot of method calls and then we get into issues of subtyping, genericity etc. I want to get back to minimalism and to me that means jettisoning compile time safety except (perhaps) for trivial functions/methods that work only on simple inputs. (still, in terms of 20/80 OPT, there may be a lot you can do with "inner loops" that use only simple types) Implementation would require a change to the grammar, some extra information attached to method objects (perhaps just a list of parameter type pointers), an extra check at runtime (a loop over the args and the type pointers, maybe even implemented as a bytecode hack). At its heart, the goal of this proposal is to provide a standard syntax for static type declarations which can be used by tools *like* static type checkers, documentation engines, reflection engines, and runtime type checkers. It doesn't matter much whether we use a new syntax, or docstrings but I think that the interpreter needs to make that information available at runtime and it should probably have optional runtime checking as *an inducement* to actually doing the declarations. So the four central goals would be: * syntax for a simple subset * API for reflection * runtime checking based on the API * do not cut off path to external static checking tool If someone *writes* a static type checking tool "in time" (whatever that means) then it should go in the tools directory. In my opinion, though, any tool built on this basis should be consider "static type checking lint" because we haven't yet said what is or is not legal in terms of dozens of subtle, tricky issues such as runtime instance modification, subclass method overrides (contravariant, covariant), exception handling etc. etc. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made possible the modern world." - from "Advent of the Algorithm" David Berlinski http://www.opengroup.com/mabooks/015/0151003386.shtml From scott@chronis.pobox.com Mon Feb 28 00:51:10 2000 From: scott@chronis.pobox.com (scott) Date: Sun, 27 Feb 2000 19:51:10 -0500 Subject: [Types-sig] Apologies and proposal In-Reply-To: <38B9733F.F251C817@prescod.net>; from paul@prescod.net on Sun, Feb 27, 2000 at 10:55:59AM -0800 References: <38B9733F.F251C817@prescod.net> Message-ID: <20000227195110.A3106@chronis.pobox.com> While I'm all for putting in what we can as soon as possible, I have some reservations about pushing ahead on 20% of the goals. Specifically, I don't think the remaining 80% have been thought through well enough to know how we can accomplish 20% without really damaging the potential of static types. The issues are subtle and complex, and, I have found even seemingly innocent assumptions about a static type system can cause all kinds of problems in an overall system. That said, I'm all for 20% now, I just don't want to see any assumptions about a static type _system_ in that 20%, and I'm not sure how useful 20% would be if it were really future proof. Also, I may well be in the minority here, but there's a problem with releasing software before it's overall design is done -- you have to support things in a backwards compatible way, and backwards-compatible is usually patently broken. Even if you say you won't make that commitment, the temptation is strong. I don't want static types for python to end up even harder to do than it needs to be, even if that means wait for a while. sctt On Sun, Feb 27, 2000 at 10:55:59AM -0800, Paul Prescod wrote: [...] > > What I would like to ask you participants is whether we our first goal > should be to push ahead with an end-game proposal or rather push for an > incremental 20/80 proposal. Arguably, the most pythonic 20% of "ERR" is > helping people to avoid simple mistakes like passing lists where strings > are expected and mappings where lists are expected and the most pythonic > 20% of "OPT" is being able to map integers to C/Java integers, strings > to C/Java strings and so forth. And I think that "DOC" is similar. And > of course the point of 20/80 is that we should get a huge amount of > benefit for the small investment and then worry about the rest of the > enchilada later. > > If I'm right, then we should consider moving as quickly as possible (1.6 > or 1.7) to providing that 20% and using it as input in our decisions on > the hard 80%. I hear screams of pain on the mention of 1.6 but I would > prefer that we didn't rule it out until we think through what the actual > implementation costs are. Maybe all we do in 1.6 is change the grammar > so that we have that experimentation with checkers and introspectors is > possible. > > Here is a minimal proposal: > > * inline declarations (either using "decl" or really inline in function > defs) > * checked at runtime depending on command line option > * there is a syntax for declaring the type objects and methods in an > extension class > * declarations can refer to class objects or "reflected" type objects > * declarations can also refer to a finite set of pre-declared > "protocol" or "interface" objects: mapping, sequence, file/stream, > number, callable, type. > * we adopt VERY conservative rules about what class objects can be > referred to so that we can later debate about extending them to objects > that are not trivially available at runtime. > > Among the issues we would not address: > > * exception declarations > * templates > * user defined interfaces/protocols > * signatures > * er, static type checking > > Okay, arguably if we don't do static type checking then we have failed > to meet our goals. But we could also see the laying down of > infrastructure TOWARD static type checking as being part of the > framework. We should explicitly NOT allow anything in our proposal that > would prevent static type checking but we should also not expect that in > version 1 we will do the full inter-module, inter-class analysis that is > required to do static type checking "right". > > I was brought in to do a "minimal proposal" and it was the requirement > that we work out all details of completely safe static* type checking > that > brought in all of the complexity. Once you say that you need to be able > to check an "average module" at compile time you invariably bring in > a huge load of issues because the "average module" does alot of > method calls and then we get into issues of subtyping, genericity etc. > I want to get back to minimalism and to me that means jettisoning > compile time safety except (perhaps) for trivial functions/methods > that work only on simple inputs. > > (still, in terms of 20/80 OPT, there may be a lot you can do with > "inner loops" that use only simple types) > > Implementation would require a change to the grammar, some extra > information attached to method objects (perhaps just a list of parameter > type pointers), an extra check at runtime (a loop over the args and the > type pointers, maybe even implemented as a bytecode hack). > > At its heart, the goal of this proposal is to provide a standard syntax > for static type declarations which can be used by tools *like* static > type checkers, documentation engines, reflection engines, and runtime > type checkers. It doesn't matter much whether we use a new syntax, or > docstrings but I think that the interpreter needs to make that > information available at runtime and it should probably have optional > runtime checking as *an inducement* to actually doing the declarations. > > So the four central goals would be: > > * syntax for a simple subset > * API for reflection > * runtime checking based on the API > * do not cut off path to external static checking tool > > If someone *writes* a static type checking tool "in time" (whatever that > means) then it should go in the tools directory. > > In my opinion, though, any tool built on this basis should be consider > "static type checking lint" because we haven't yet said what is or > is not legal in terms of dozens of subtle, tricky issues such as > runtime instance modification, subclass method overrides > (contravariant, covariant), exception handling etc. etc. > > -- > Paul Prescod - ISOGEN Consulting Engineer speaking for himself > "The calculus and the rich body of mathematical analysis to which it > gave rise made modern science possible, but it was the algorithm that > made possible the modern world." > - from "Advent of the Algorithm" David Berlinski > http://www.opengroup.com/mabooks/015/0151003386.shtml > > > > _______________________________________________ > Types-SIG mailing list > Types-SIG@python.org > http://www.python.org/mailman/listinfo/types-sig From paul@prescod.net Mon Feb 28 09:44:02 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 28 Feb 2000 01:44:02 -0800 Subject: [Types-sig] Apologies and proposal References: <38B9733F.F251C817@prescod.net> <20000227195110.A3106@chronis.pobox.com> Message-ID: <38BA4362.A85082B6@prescod.net> scott wrote: > > While I'm all for putting in what we can as soon as possible, I have > some reservations about pushing ahead on 20% of the goals. > Specifically, I don't think the remaining 80% have been thought > through well enough to know how we can accomplish 20% without really > damaging the potential of static types. The issues are subtle and > complex, and, I have found even seemingly innocent assumptions about a > static type system can cause all kinds of problems in an overall > system. There are risks also to trying to design a huge, complex system all in one go. I do not consider the approach I suggest to be particularly risk from a backwards compatibility standpoint. We are all very familiar with this approach from other programming languges. The chances of a final Python static type system NOT being a superset of the system I describe seem quite remote. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made possible the modern world." - from "Advent of the Algorithm" David Berlinski http://www.opengroup.com/mabooks/015/0151003386.shtml From paul@prescod.net Tue Feb 29 04:28:22 2000 From: paul@prescod.net (Paul Prescod) Date: Mon, 28 Feb 2000 20:28:22 -0800 Subject: [Fwd: Re: [Types-sig] Apologies and proposal] Message-ID: <38BB4AE5.9B62A04C@prescod.net> Forwarded for Scott. -------- Original Message -------- Subject: Re: [Types-sig] Apologies and proposal Date: Mon, 28 Feb 2000 12:01:07 -0500 From: scott To: Paul Prescod References: <38B9733F.F251C817@prescod.net> <20000227195110.A3106@chronis.pobox.com> <38BA4362.A85082B6@prescod.net> On Mon, Feb 28, 2000 at 01:44:02AM -0800, Paul Prescod wrote: > scott wrote: > > > > While I'm all for putting in what we can as soon as possible, I have > > some reservations about pushing ahead on 20% of the goals. > > Specifically, I don't think the remaining 80% have been thought > > through well enough to know how we can accomplish 20% without really > > damaging the potential of static types. The issues are subtle and > > complex, and, I have found even seemingly innocent assumptions about a > > static type system can cause all kinds of problems in an overall > > system. > > There are risks also to trying to design a huge, complex system all in > one go. Perhaps. But all other static type checking systems that I know of are the result of atleast an intial core system with add ons, not a 20% system with an incomplete infrastructure -- or even blueprint. > I do not consider the approach I suggest to be particularly risk > from a backwards compatibility standpoint. We are all very familiar with > this approach from other programming languges. not with regards to type checking -- there always seems to be a complete infrastructure first, small changes and add-on functionality later. Please let me know of any even marginally successful counter examples to this claim. >The chances of a final > Python static type system NOT being a superset of the system I describe > seem quite remote. There are some things that you said before that seem to imply to me direct things about a static type system for python that may not be true. Earlier Paul wrote: > Implementation would require a change to the grammar, some extra > information attached to method objects (perhaps just a list of parameter > type pointers), an extra check at runtime (a loop over the args and the > type pointers, maybe even implemented as a bytecode hack). This, for example, makes me think that some might want to overlap static types and dynamic types by making static info dynamic. Which may really not be a good idea. See the language reference for Cecil about some of the findings about mixing the two in general. For example, http://www.cs.washington.edu/research/projects/cecil/cecil/www/www/www/Release/doc-cecil-lang/cecil-spec-78.html#HEADING78-0 > > At its heart, the goal of this proposal is to provide a standard syntax > for static type declarations which can be used by tools *like* static > type checkers, documentation engines, reflection engines, and runtime > type checkers. It doesn't matter much whether we use a new syntax, or > docstrings but I think that the interpreter needs to make that > information available at runtime and it should probably have optional > runtime checking as *an inducement* to actually doing the declarations. While some subset of a syntax is easily workable in any static type checking system for python, eg "decl foo: int", other very fundamental parts have a very dramatic effect. For example, can a person declare something to be of type "none" (aka NoneType)? If something like the ability to declare a variable as type "none" is included in a 20% plan, there are some _big_ implications for the usability of any polymorphic static type system which may not be what we want. There are several things along these lines which, IMO would be quite dangerous to set in stone in a 20% plan. 20% functionality is fine, I'm just skeptical about the ability to provide it without a real understanding of how an 85 or 90% plan would _work_. Maybe it's possible, but issues like the above will continue to creep up at every stage. Seems to me that it's better that they be made apparent now. scott From guido@python.org Tue Feb 29 14:12:23 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 29 Feb 2000 09:12:23 -0500 Subject: [Fwd: Re: [Types-sig] Apologies and proposal] In-Reply-To: Your message of "Mon, 28 Feb 2000 20:28:22 PST." <38BB4AE5.9B62A04C@prescod.net> References: <38BB4AE5.9B62A04C@prescod.net> Message-ID: <200002291412.JAA05485@eric.cnri.reston.va.us> [Scott] > Perhaps. But all other static type checking systems that I know of > are the result of atleast an intial core system with add ons, not a > 20% system with an incomplete infrastructure -- or even blueprint. [Paul] > > I do not consider the approach I suggest to be particularly risk > > from a backwards compatibility standpoint. We are all very familiar with > > this approach from other programming languges. > > not with regards to type checking -- there always seems to be a > complete infrastructure first, small changes and add-on functionality > later. Please let me know of any even marginally successful counter > examples to this claim. OUt of context perhaps, but I would think that C++ qualifies. It started with C's type system, lock stock and barrel, and added: classes; inheritance; virtual functions; private, protected and public; multiple inheritance; templates. (Not in that order.) I believe classes and single inheritance were in place before templates were even considered. C's type system is probably less than 20% of C++'s type system; and even "old C++" with only single inheritance is probably less than 20% of what's now available. We can discuss this more at the DC Piggies event on March 13 in Reston! --Guido van Rossum (home page: http://www.python.org/~guido/) From paul@prescod.net Tue Feb 29 14:16:33 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 29 Feb 2000 06:16:33 -0800 Subject: [Fwd: Re: [Types-sig] Apologies and proposal] References: <38BB4AE5.9B62A04C@prescod.net> <200002291412.JAA05485@eric.cnri.reston.va.us> Message-ID: <38BBD4C1.E33B2BCC@prescod.net> Guido van Rossum wrote: > > OUt of context perhaps, but I would think that C++ qualifies. It > started with C's type system, lock stock and barrel, and added: > classes; inheritance; virtual functions; private, protected and > public; multiple inheritance; templates. (Not in that order.) I > believe classes and single inheritance were in place before templates > were even considered. C's type system is probably less than 20% of > C++'s type system; and even "old C++" with only single inheritance is > probably less than 20% of what's now available. That's an example I was thinking of. One could argue that the resulting language is sub-optimal but I think that that has a lot more to do with bad design principles than bad design process. Another example is Visual Basic which has accreted a more and more sophisticated type system as the years have gone by. Or Pascal to Object Pascal. Anyhow, neither of these is really an appropriate analogy because when Visual Basic 1 or K&R C were developed, nobody was thinking about extending them to OOP in 5 or 25 years. I do not propose that we design the system with NO forethought. Rather, I think that we need not work out every detail of where we are going in order to start the journey. If my proposed process is inherently doomed to failure than our entire project is doomed to failure because Python 1.0's type system did not make specific allowance for the later addition of a static type checking system. I believe that good (incremental) design back then will meld with good (incremental) design now to make a good result. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made possible the modern world." - from "Advent of the Algorithm" David Berlinski http://www.opengroup.com/mabooks/015/0151003386.shtml From scott@chronis.pobox.com Tue Feb 29 19:11:16 2000 From: scott@chronis.pobox.com (scott) Date: Tue, 29 Feb 2000 14:11:16 -0500 Subject: [Types-sig] yet another type disambiguator idea Message-ID: <20000229141116.A30960@chronis.pobox.com> I came across another idea about typecase or type disambiguations that seemed kindof neat: Python already has a dynamic type system, and a notion of a type hierarchy described at http://www.python.org/doc/ref/types.html. Dynamic type information is already present at runtime and provides a good deal of type expressivity (though not really enough for static types). Below is a little module which builds something much like that dynamic type hierarchy into a class hierarchy, and then uses it in a function called 'astype', which if coded as a builtin function could supply a static type system with a runtime type disambiguating function that could be checked at compile time and used like this: def foo(x): decl x: string | file decl z: file z = astype(x, file) if z is None: z = open(astype(x, string)) By leveraging the existing dynamic type system, there is no significant additional overhead to runtime python, and the disambiguation of types is quite naturally limited to using the information already available at runtime -- the information present in the dynamic type system. I suspect that providing a hierarchical interface to the dynamic types and treating static types as a parallell hierarchy with more required info in places could help propel a more incremental approach in other ways as well. Cheers, scott """ class hierarchy representation of dynamic type hierarchy. under the system that the sample type checker works with, these classes would replace the 'types' as they occur in python 1.5.2. note there is no instance type or none type. The static type hierarchy is the same, but more information is called for in the cases of tuples, lists, dicts, and callables. object sizable sequencable immutable_sequence tuple string buffer mutable_sequence list mapping dict callable class any_function builtin_function function any_method any_instance_method builtin_instance_method instance_method class_method numeric rational any_int int long float complex module file internal code frame traceback slice ellipsis """ # # all objects are of this type # class object_node: name = "object" def __repr__(self): return "" % self.name # # top level subtypes. we can add comparable # later if we want. # class sizeable_node(object_node): name = "sizeable" class callable_node(object_node): name = "callable" class numeric_node(object_node): name = "numeric" class module_node(object_node): name = "module" class file_node(object_node): name = "file" class internal_node(object_node): name = "internal" # # ***sizable types*** # class sequencable_node(sizeable_node): name = "sequencable" class immutable_sequence_node(sequencable_node): name = "immutable_sequence" class tuple_node(immutable_sequence_node): name = "tuple" class string_node(immutable_sequence_node): name = "string" class buffer_node(immutable_sequence_node): name = "buffer" class mutable_sequence_node(sequencable_node): name = "mutable_sequence" class list_node(mutable_sequence_node): name = "list" class mapping_node(sizeable_node): name = "mapping" class dict_node(mapping_node): name = "dict" # # ***callable types*** # class klass_node(callable_node): name = "klass" class any_function_node(callable_node): name = "any_function" class builtin_function_node(any_function_node): name = "builtin_function" class function_node(any_function_node): name = "function" class any_method_node(callable_node): name = "any_method" class any_instance_method_node(any_method_node): name = "any_instance_method" class builtin_instance_method_node(any_instance_method_node): name = "builtin_instance_method" class instance_method_node(any_instance_method_node): name = "instance_method" class class_method_node(any_method_node): name = "class_method" # # ***numeric types*** # class rational_node(numeric_node): name = "rational" class any_int_node(rational_node): name = "any_int" class int_node(any_int_node): name = "int" class long_node(any_int_node): name = "long" class float_node(rational_node): name = "float" class complex_node(numeric_node): name = "complex" # # ** internal types # class code_node(internal_node): name = "code" class frame_node(internal_node): name = "frame" class traceback_node(internal_node): name = "traceback" class slice_node(internal_node): name = "slice" class ellipsis_node(internal_node): name = "ellipsis" object = object_node() sizeable = sizeable_node() callable = callable_node() numeric = numeric_node() module = module_node() file = file_node() internal = internal_node() sequencable = sequencable_node() immutable_sequence = immutable_sequence_node() tuple = tuple_node() string = string_node() buffer = buffer_node() mutable_sequence = mutable_sequence_node() list = list_node() mapping = mapping_node() dict = dict_node() klass = klass_node() any_function = any_function_node() builtin_function = builtin_function_node() function = function_node() any_method = any_method_node() any_instance_method = any_instance_method_node() instance_method = instance_method_node() builtin_instance_method = builtin_instance_method_node() class_method = class_method_node() rational = rational_node() any_int = any_int_node() int = int_node() long = long_node() float = float_node() complex = complex_node() code = code_node() frame = frame_node() traceback = traceback_node() slice = slice_node() ellipsis = ellipsis_node() # # this this will never type check as python code, it would # have to be a new builtin. It's the type disambiguator, and # it *only* works with dynamic types, but the relationship # between dynamic and static types is such that all callable # static types are subtypes of dynamic type callable, so it's # still useful for static types at run time. # def astype(value, subtype): if not isinstance(subtype, object.__class__): raise TypeError("cannot call astype with non dynamic type second argument") # we're missing a few still that are hard to map # into the type hierarchy or are just dropped to help # make the system as a whole more clear. I think # these can be seen as exceptional situations and we # might either just let them break or provide some weird # workarounds. at any rate, the missing types from module # types are irrelevant this early in the game, i think. import types mapping = { types.BufferType: buffer, types.BuiltinFunctionType: builtin_function, types.BuiltinMethodType: builtin_instance_method, types.ClassType: klass, types.CodeType: code, types.ComplexType: complex, types.DictType: dict, types.DictionaryType: dict, types.EllipsisType: ellipsis, types.FileType: file, types.FloatType: float, types.FrameType: frame, types.FunctionType: function, types.InstanceType: object, types.IntType: int, types.ListType: list, types.LongType: long, types.MethodType: any_instance_method, types.ModuleType: module, types.SliceType: slice, types.StringType: string, types.TracebackType: traceback, types.TupleType: tuple, types.UnboundMethodType: class_method} dyntyp = mapping.get(type(value), object) if not isinstance(dyntyp, subtype.__class__): return None return value if __name__ == '__main__': seq = "foo" # this finds the right value str = astype(seq, string) print "str is %s" % str seq = (1, 3) # this returns None, which is always OK str = astype(seq, string) print "str is %s" % str From scott@chronis.pobox.com Tue Feb 29 19:12:03 2000 From: scott@chronis.pobox.com (scott) Date: Tue, 29 Feb 2000 14:12:03 -0500 Subject: [Fwd: Re: [Types-sig] Apologies and proposal] Message-ID: <20000229141203.B30960@chronis.pobox.com> On Tue, Feb 29, 2000 at 06:16:33AM -0800, Paul Prescod wrote: > > If my proposed process is inherently doomed to failure than our entire > project is doomed to failure because Python 1.0's type system did not > make specific allowance for the later addition of a static type checking > system. I believe that good (incremental) design back then will meld > with good (incremental) design now to make a good result. Sorry to sound so negative. I'm just trying to say be careful! My last response gave some examples of things that I thought needed consideration because they didn't supply a foundation that is a common to all reasonable static type systems python could adopt. If that message screamed doom and gloom, I'm sorry, it was intended to offer another perspective and some things that I think should be addressed in a 20% plan, nothing more. Cheers, scott From paul@prescod.net Tue Feb 29 20:47:35 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 29 Feb 2000 12:47:35 -0800 Subject: [Types-sig] Anybody out there?? References: <20000229141203.B30960@chronis.pobox.com> Message-ID: <38BC3067.90414B76@prescod.net> scott wrote: > > > Sorry to sound so negative. I'm just trying to say be careful! I agree. Should I count that as a vote to carefully, cautiously, forward-thinkingly move forward on a minimal solution that has a clear path to a well-defined but not entirely specified future? In other words I think that we should have a plan of where we are going, but not a formal specification, and a formal specification for a subset that could be reasonably debated, implemented and tested in the short-term. I'd like a few more votes whether they be yea/nay! -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "The calculus and the rich body of mathematical analysis to which it gave rise made modern science possible, but it was the algorithm that made possible the modern world." - from "Advent of the Algorithm" David Berlinski http://www.opengroup.com/mabooks/015/0151003386.shtml From scott@chronis.pobox.com Tue Feb 29 21:14:40 2000 From: scott@chronis.pobox.com (scott) Date: Tue, 29 Feb 2000 16:14:40 -0500 Subject: [Types-sig] Anybody out there?? In-Reply-To: <38BC3067.90414B76@prescod.net>; from paul@prescod.net on Tue, Feb 29, 2000 at 12:47:35PM -0800 References: <20000229141203.B30960@chronis.pobox.com> <38BC3067.90414B76@prescod.net> Message-ID: <20000229161440.A31711@chronis.pobox.com> On Tue, Feb 29, 2000 at 12:47:35PM -0800, Paul Prescod wrote: > scott wrote: > > > > > > Sorry to sound so negative. I'm just trying to say be careful! > > I agree. Should I count that as a vote to carefully, cautiously, > forward-thinkingly move forward on a minimal solution that has a clear > path to a well-defined but not entirely specified future? Yes. To me, carefully and cautiously means that there's got to be an initial period where various fresh starts are considered, and formal specs grow out of understanding of how different models might work rather than how a specific model will work. scott