[Types-sig] File Protocol Proposal

[Tim Hochberg]

----- Original Message -----
>
>     | def isatty():
>     | return false
>
> Two thoughts of the day...
>
> We may need to add a boolean type to Python.  How would you describe
> today a method that takes a true/false flag?  There's a lot of variety
> in how you can spell true and false today.
>
> Writing a boolean class isn't hard -- I've done it at least twice
> <wink>.  Writing a boolean type was more difficult because of the old
> comparison rules; I haven't tried since richcomps have been added so
> the situation might be better now.

It's possible that this has changed, but according so section 2.1.1 of the
Library Reference, everything is a boolean type! Or am I missing something.

> There's also the common situation of accepting either None or a
> specific object.  I.e. "this method takes None or a Foobar instance".
> And what about a method that might accept any of None, a string
> (filename), or a "file-like" object?  This is all very common in
> Python programs.

The simple way is to just use union type. I called this composite in my
orginal proposal, but that may be bad terminology. Anyway, the following
should work:

def weeble(wobble : UnionOf(NoneType, String)):
   # ....

If we forced typecheck objects to all inherit from a common base class, it
would also be pretty easy to write this as:

def weeble(wobble : NoneType | String):
   # ....

By suitably overloading __or__ in the base class. One would probably also
overload __and__ while one was at it.

> Finally, another thought occurred to me, which might be based on a
> mis-remembering of what ObjC does (I don't have any of my old ObjC
> books laying around, and it's been a while).
>
> Say a method takes an object that must have a read([size]) method.
> That's all you care about.  Yes, you could define an interface that
> describes this, but what if someone passes in an object that conforms
> to a full blown "ReadableFile" interface -- i.e. it provides
> read([size]), readline(), readlines(), and maybe seek()?  Let's say
> those two interfaces are defined in unrelated and separately authored
> libraries, but I'm writing code that combines the two.  Library B
> gives me a factory that produces ReadableFiles and I'd like to pass
> those to library B's method that specifies a MustHaveRead interface.
>
> Am I screwed?

No.

>Or do I have to play convoluted games of multiple
> inheritance, mixins, interface mishmashing, etc?  To a newbie (and
> maybe a not-so-newbie), it ought to be perfectly legal.
> ReadableFile's interface is a superset of MustHaveRead so it should be
> fine, but because the interface objects aren't explicitly related,
> you're hosed.

No. Unless I'm misunderstanding you. All of this should "just work". The
__implementedby__ method of your narrow interface should just be checking
whether a given object supports read. It doesn't care if another interface
was defined in another file.

> What you want (maybe) is interface conformance based on a runtime
> check of the interface specifications.  Maybe a kind of interface
> arithmetic?

That's basically the plan. Well except for the arithmatic part.

>IIRC, this was one of the ObjC uses of categories.  A
> category is just a collection of methods, so if you have a category
> that contained only read([size]), and you declared a parameter to be
> of the "type" of that category, you could pass in any object that had
> such a method.

That's pretty close to what we're trying. The hard part is coming up with a
set of basic categories that captures much of existing usage without being
ludicrously large. Users can of course write there own typecheck classes,
but you'd like the common cases to be captured by the supplied typecheckers.

-tim