[Types-sig] PyDL RFC 0.02

[scott]

On Mon, Dec 27, 1999 at 12:54:54PM -0500, Paul Prescod wrote:
> scott wrote:
> > 
> > One thing to consider is that windows/dos users can't have a 4-char
> > suffix on a file name reliably.
> 
> Well, DOS users....Windows 9x/NT users will have no problem. I'm not
> sure if I care enough about DOS to think that we should change this.

Don't piss off the DOS users!  That's dangerous ;) On the other hand,
it does seem prudent to have a suffix that works on the Denial Of
Service platform if all it takes is a shorter set of suffixes.  plus,
that would mean less typing and neater output to `ls'.  Minor, Minor
point though.  

> 
> > and it would facilitate some of the problems with working
> > with extra files... like permissions denying writes of the interface
> > file and what not.
> 
> I don't follow you at all. We have extra files. One or two, you are
> going to have potential problems with permissions. That's one reason to
> NOT use generated interface files in some circumstances.

2 extra files with potential permissions problems leads to more
combinations of problem scenarios to deal with than a single one. It's
not that big a deal to me one way or the other, though. 2 files is
fine.

> 
> > I believe greg has a good point here.  
> 
> I think I've addressed it. The Python interpreter should not be looking
> at each namespace in turn. I would expect that in the future we will
> allow an infinite number of nested namespaces without any performance
> penalty.

Perhaps, but when?  I haven't seen any indication that this will
happen in the near future, and predicting such things in the longer
run seems to be asking for problems both in the meantime and in how
the long run might actually work out.

IMO, the most important goal is modularity of the system, the second
most important goal is clean accessibility, and the least important
goal is performance.  Does this seem like a reasonable set of goals
for deciding where to store this info?  

One thing to think about with the extra run-time namespace scheme is
accidentally overwriting the values of typedefs and what not.  It may
well be more modular to put this stuff in a special place which does
not affect the regular run-time environment at all.


> 
> > Any pointers to this discussion?
> 
> I don't have any. I think we just said: "we'll figure out const later."
> There may not have been a big discussion.

Sounds good to me.

scott