Michael McLay writes:
> [...]
> I've assembled a strawman list of topics for discussion. New topics
> and comments on the topics listed are certainly welcome.
> [...]
I mentioned, in direct correspondance:
I am also interested in efforts to identify (project?) the stable
elements of the language, at least for this major revision (r1). I
think this is necessary to start to convey (and even establish) the
maturity of the language. This may well be something that will have
to come once the effects of the push for including "safety" mechanisms
are seen, though.
If i understand the premises of the meeting correctly - consortium
coelescing, as well as technical discussions - i think we need to
start discussing some projections of the shape of python development,
including goals, focuses, etc.
Ie, to what degree do the participants want to chart python's future,
and what might some features of that chart be? (Personally, i'm not
crazy about any sort of hard charting, and don't even expect that
would be effective, but i do think it would be good to investigate
what degree/aspects of charting *would* be helpful, and start to do
it...)
(My own, individual perspective is that there are some items that
currently seem critical, eg resolving features for a "safe" python,
and plans for addressing those sort of issues should be made explicit.
There also, however, should be a room expressly set aside for spur-of-
the-moment and emerging projects and goals, besides the currently
apparent ones. I suspect that it would be good to begin to formulate
something providing for both these kinds of concerns.)
> Guido added:
> >
> > 12. compiling Python to a more efficient form (hard -- but not
> > impossible???)
> >
> > 14. static type checking (could help to the previous one)
I think that some type-inference could probably be used for some
simple optimizations, but i don't know enough about the technologies
to really say for sure.
> > 15. the management of large collections of modules (too many
> > Python scripts currently embed hard pathnames in their main
> > file so they can find their subordinate modules)
I can think of some simple extensions to the module load arrangements
that might go a long way to solving this problem. Like module names
that are really directories which contain collections of modules, one
of them being the main module of the collection, with the same name as
the directory. The load-path for modules loaded as directory modules
could be automatically augmented so that they can automatically
include other modules in the subdir, and so forth.
I'm interested, in general, in the list of items that guido mentioned.
Ken
ken.manheimer@nist.gov, 301 975-3539