Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design and implement import as alternative to use #13119

Closed
bradcray opened this issue May 29, 2019 · 6 comments
Closed

Design and implement import as alternative to use #13119

bradcray opened this issue May 29, 2019 · 6 comments

Comments

@bradcray
Copy link
Member

As a Chapel programmer coming from Python who's sensitive to protecting my namespaces, I would like Chapel to support an import statement similar to Python's and opposite to Chapel's use. That is, by default, no symbols would be available without full qualification by default. Thus, import M; would be similar to use M only; or use M except *; in Chapel today.

@mppf
Copy link
Member

mppf commented Aug 13, 2019

I think that public import should make the module symbol itself visible in other modules while the a public use would only make the use'd symbols visible in other modules.

From #13524 (comment)

We could also consider enabling this behavior for public use L only; but my concern with enabling it for public use L; or public use L only someFunction would be that those statements are trying to make available specific functions within L but not the fact that they are implemented in L itself. If we chose to make public use not make the module symbol itself re-exported, while import did, that seems like something that might be a useful difference between import and use. This seems pretty intuitive to me.

@bradcray
Copy link
Member Author

@mppf: I'm not familiar enough with Python to know: Does the behavior you propose for import match Python enough that it would seem natural to programmers coming from there?

@mppf
Copy link
Member

mppf commented Aug 14, 2019

@bradcray - I think this would be similar to Python's import statement. However, I don't know if there is a difference between a "public" import and a "private" one (or how to write that at all in Python). But, it does look like Python's import statement does seem to make the fact that the module was imported publicly visible by default:

Here is an example:

# mymodule.py

import othermodule

def myfn():
  print("myfn")

print ("Hello from mymodule")
# othermodule.py

def otherfn():
  print("otherfn")

print ("Hello from othermodule")
# program.py

import mymodule

mymodule.myfn()
mymodule.othermodule.otherfn()
$ python3 program.py 
Hello from othermodule
Hello from mymodule
myfn
otherfn

@mppf
Copy link
Member

mppf commented Aug 14, 2019

@bradcray - if it's not obvious, accepting my proposal would make moving to use and import be a breaking change compared to the current use world.

@lydia-duncan
Copy link
Member

I just opened #13831

@bradcray
Copy link
Member Author

Even though there's an issue remaining here, I think it's a relatively minor one that stands OK on its own, and that we can close this epic now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants