[Types-sig] PyDL RFC 0.02

[Greg Stein]

On Mon, 27 Dec 1999, Paul Prescod wrote:
> PyDL is a pun. These files behave just like IDL in COM and CORBA. They
> are a separate language, at least for now. 

Let's name it for its purpose, not a pun. Please. I know where the
derivation came from, and the file is an interface file. The file is not a
"python definition language."

If it uses a separate language, then that still doesn't mean we're talking
about something other than an interface file.

> Greg Stein wrote:
> > The notion of two types of files just adds complexity. There is no reason
> > that a generated file would be *any* different in form/syntax than a
> > human's file. The human just gets to add funky comments, indentation, etc.
> 
> >From PyDL RFC 0.03:
> 
> We have two different files so that hand-crafted PyDL files will not be
> overwritten by generated ones. The syntax of the files is identical.

In my reply to Scott: I think we should be choosing one or the other
rather than taking two files and combining them.

> > In other words: design around a single file.
> 
> I did. The existence of two files affects the language semantics not one
> whit but it makes the system much more safe and arguably much more
> usable.

Two more files for each module doesn't make it more usable. Having zero
extra files (and inline declarations) is more usable/maintainable.

How does it make it more safe?

> > Search *another* namespace? Eek! We're already seeing people avoiding the
> > time with things like:
> > 
> >   def foo(len=len):
> >     ...
> > 
> > Adding another namespace will just exacerbate the situation.
> 
> The whole point of static type checking is that the checks of the
> namespaces should be done at *compile time*.

Duh.

> It isn't like a name
> reference from six levels of lexical nesting in a C++ file requires more
> time to look up than a "local" reference. That's just a temporary Python
> bug that we're trying to fix.

Per my other email: we should not be relying on vapor to solve our
problems. We should avoid exacerbating the situation.

Regardless, I haven't seen a good rationale for needing a new namespace
yet. There has been conversation where people have thrown out "well, just
move it into a separate namespace," but I haven't seen a clear/cogent
description of the real need.

I think these names should follow standard Python rules. It goes into the
global, local, or class namespace depending upon the context.

> > Wasn't the notion of "const" (successfully) argued against inclusion?
> 
> Maybe. But I think that the situation changed when I moved from talking
> about "lists", "tuples" and "dictionaries" to talking about "sequences",
> "mappings" and "records" because we have no way of saying "read-only
> record." Maybe that's a big deal for version 1. Maybe it isn't. I'm open
> to opinions.

Record? How is that different from a sequence? That is new terminology,
and it seems it is just a bare cover for saying "tuple." Why don't we
stick to "tuple" instead of introducing a new term.

> > I don't think this is going to work as you expect. The Python interpreter
> > can't work with "Undefined" unless it is an object (otherwise, you're
> > talking about a near-impossible revamp). Therefore, Undefined is an object
> > and you're going to have some *real* serious issues trying to keep that
> > out of some kind of assignment or other usage.
> > 
> > Pass it as a parameter? Shove it into a list or tuple? Check for Undefined
> > on every name binding? What about indexed or slice assignment?
> 
> I think that there are finite number of such issues and you've listed
> most of them. In each of these parts of the interpreter we need to add
> two or three lines of C code. From a performance perspective, we will
> just be doing a pointer comparison and branch which is tiny compared to
> the rest of the interpreter overhead.

It is a lot more prevalent than what I just listed. I was just spouting
off some examples Some more: tuple unpacking, in an "is" expression, in an
"==" expression, or passed to the __cmp__() instance method. I bet that I
could come up with more.

That latter one should throw a nice screw into the machine.

Next up: you suggested pre-assigning all names to the Undefined object.
Now dir(some_instance) produces an incorrect list of valid names. Or
some_instance.__dict__.items() (uh oh! how does the items() return a
two-tuple with Undefined in there?!). But don't just look at class
instances, we have the same issue at the global level. Right here in
Lib/symbol.py, I see a globals().items() on line 73. 

And what does __builtins__['Undefined'] return? If I'm trying to establish
a restricted mode of execution, how do I insert Undefined into the
constructed builtins dictionary?

When I'm writing a C extension, do I have to check for the Undefined
object now? What happens if I see one? Raise an error? Can I return one?

I would venture that the Undefined concept would require a pretty
fundamental change to Python's (internal) object model. Given more
thought, I might find additional issues, and that worries me.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/