On Thu, Aug 15, 2002 at 12:42:46AM +0200, Martin v. Loewis wrote: > Oren Tirosh <oren-py-d@hishome.net> writes: > > > Nope. For me protocols are conventions to follow for performing a certain > > task. A type category is a formally defined set of types. > > ODP (Reference Model For Open Distributed Processing, ISO 10746) > defines that a type is a predicate; it implies a set (of which it is > the characteristic function). A type is a predicate about an object. A category is a predicate about a type. Objects have a type. References have a category. Well, Python references currently all have the 'any' category because Python has no type checking. Any Python reference may point to an object of any type. In a dynamically typed language there is no such thing as an 'integer variable' but it can be simulated by a reference that may only point to objects in the 'integer' category. > It is not so clear that this is what defines the iterable category. It > could also be defined as "the programmer can use to for doing > iteration, by means of the iterable protocol". Your definition is not formal and cannot be evaluated by a program. The iterable category matches the set of types implementing the iterable protocol with reasonable accuracy. It doesn't have to be perfect to be useful. > > Protocols live in documentation and lore. Type categories live in the same > > place where vector spaces and other formal systems live. > > By that definition, I'd say that Andrew's list enumerates protocols, > not type categories: they all live in lore, not in a formalism. Exactly. > For being a pure function, requiring that it does not trigger Python > code seems a bit too restrictive. That's not a formal requirement, it for robustness and efficiency. Oren
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4