"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4