[Types-sig] namespaces

scott scott@chronis.pobox.com
Fri, 21 Jan 2000 10:56:30 -0500

On Fri, Jan 21, 2000 at 10:09:06AM -0500, Guido van Rossum wrote:
> Nothing to worry about.  Language designers routinely specify exactly
> which kinds of expressions can be evaluated at compile time and which
> ones can't.  (E.g. C allows expressions as array bounds but requires
> that they can be evaluated at compile time.)

Sounds good.  Any ideas of what those specs might be for isinstance?

> > Now, how about:
> > 
> > if isinstance(x, GrabMeAType()): suite
> > 
> > GrabMeAType() returns a value of TypeType type or somesuch, but the
> > user may know that it returns something more specific.  You can't do
> > much with that at compile time.
> Is it really that hard to explain to users that using dynamic
> information disables the runtime typecheck?

You mean compile time check right?  Hopefully not.  It's just an
example of a problem with isinstance that doesn't exist with an
explicit grammatical construct.

> > Also, we can disambiguate like this
> > 	isinstance(x, T) and [do stuff with x assuming it's of type T]
> > 
> > Also, what if someone does this:
> >     def isinstance(x, y): return 0
> > 
> > or this:
> > 	foo = isinstance
> > 
> > so the compile time checker, in so far as it follows a function call
> > as a disambiguating agent, has potentially magnitudes of more work to
> > do than a compile time checker that uses a grammatical construct as
> > a disambiguating agent.  
> Still no biggie in my book -- if this is the only argument against
> isinstance(), and otherwise it was perfect, I am more than willing to
> do the work.

It's the argument that prevented me from going with it. Working on the
assumption that the compile time semantics must be identical to the
run time semantics makes it quite hard. FWIW, I'm more than willing to
help do the work.

> > I tried very hard to make the idea of using a builtin work as it is by
> > far the most aesthetically pleasing way of approaching this part of
> > type checking to me.  Addressing these issues in a way that is
> > _consistent_ with runtime behavior at compile time is in my estimation
> > incredibly difficult, much more so than having a grammatical construct
> > be the disambiguating agent (which itself is hard enough to warrant
> > at least more than all the work we've all put into it).  Addressing
> > these issues in a way that is _inconsistent_ with runtime behavior at
> > compile time seems less than satisfactory to me.
> Can you explain what you mean by consistency with runtime behavior?

Consistency in that there's no need for a spec (other than the
grammar) about exactly in what contexts isinstance is evaluated at
compile time.  I suppose that if such a spec were made very clear and
didn't have too steep a learning curve in terms of using isinstance,
I may well find it satisfactory.  isinstance looks a lot like existing
ways to check types in current python, and that's well worth striving