other python ideas

[Steve Holden]

"Steven D. Arnold" <stevena at permanent.cc> wrote in message
news:mailman.986695630.18766.python-list at python.org...
> 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.
>
The types SIG has been working on static typing for a while, but I've seen
nothing which suggests that typing will be anythng other than an optional
optimization -- i.e. nothing which would allow signatures to select
particular methods. While this Java-like property might seem desirable, I
suspect (PEPs 245 and 246 notwithstanding) that signatures would be too
fundamental a change to find acceptnance in a mojority of the Python
community. Of course, the community will feel free to disagree... as it
often does!

> 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."
>
The best approach to this might be to extend current usage. At present "*"
does not actually mean everything: it means all names not beginning with an
underscore, which does give you the ability to specify module-private names.
In a *package* (which unfortunately is still documented by an URLfollowing a
comment indicating the author "can't be bothered to spell this out") you can
set the __all__ variable inside the __init__.py file to indicate that only
named submodules are imported by "from package import *".

Maybe modules could use a similar indication, together with "__interface__",
"__standard__" and "__minimal__" definitions, but these choices seem a
little arbitrary and subject to the whim of the developer. Hence I don't
really think they would add much value.

> 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.
>
You would need to be somewhat clearer about the "standard" meanings of the
subsets  you specify, I fear. Not a bad idea, but a bit loosely phrased.

> 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."
>
Here you are referring to the names beginning with an underscore.

> Thoughts, criticisms, etc?
>
What Python needs most of all is people (users) who are intense in their
desire to improve the language, and I think you have just demonstrated your
memebership of that set. Python is "simple but complicated", and as long as
the user community keeps coming up with suggestions like yours it will
probably remain healthy. Particularly since the user community also
persistently responds in a positive way to such suggestions. And long may it
continue to do so.

Hope this encourages you to continue thinking deeply abut how the language
should/could be improved.

i'll-stop-reading-c.l.py-when-responses-descend-to-the-"this-is-a-faq-so-eat
-s**t-and-die,-newbie"-level-ly y'rs  - steve