other python ideas

Steven D. Arnold stevena at permanent.cc
Tue May 23 01:24:01 EDT 2000


If we do allow typing in a future version of Python, perhaps we should also 
allow function overloading.  This would permit having several, for example, 
__init__ functions, each taking different parameters.  Of course, with 
Python's named parameter facility, that may be unnecessary, but I tend to 
think it's better to have several small and simple functions rather than 
one large and complex one.

Also, it seems to me Python's importing mechanism could use some 
work.  Here are some ideas, meant both as interesting ideas in themselves 
as well as sparks that may introduce even better ways of solving the problem.

Perhaps we could allow the programmer of a module to specify sets of names 
to be exported.  Some conventional export sets would be `*', `interface', 
`standard' and `minimal'.  Asterisk is already in use and would continue to 
mean what it does now -- all top-level names in the module would be 
exported.  The `interface' tag means "give me everything that is part of 
the public interface."  The `standard' tag is similar -- it means "give me 
the most-used names, the typical ones recommended by the developer."  The 
`minimal' tag means "give me only the most important names."

Of course, you could import specific names, too, or a combination of name 
sets and individual names.  For example:

from foo import standard, bar

It would be up to the developer to determine what name sets to export.  The 
name sets mentioned above would be only conventions -- you could create a 
named set called anything you want.  As with most conventions, people will 
be less confused if you go with the standard, unless there is a compelling 
reason to do otherwise.

The programmer should be able to mark certain names as 
"not-for-export."  The `*' set would not export such names, though if the 
module user were to import the name specifically, that would override the 
"not-for-export" flag.  Actually, perhaps it would be simpler to 
automatically assume that anything not in the `interface' set is 
"not-for-export."

Thoughts, criticisms, etc?


steve

--
Steven D. Arnold          Que quiero sera           stevena at permanent.cc
"We choose to go to the moon in this decade and do the other things, not
because they are easy, but because they are hard."    -- John F. Kennedy





More information about the Python-list mailing list