{"action":"created","issue":{"url":"https://api.github.com/repos/atsepkov/RapydScript/issues/66","labels_url":"https://api.github.com/repos/atsepkov/RapydScript/issues/66/labels{/name}","comments_url":"https://api.github.com/repos/atsepkov/RapydScript/issues/66/comments","events_url":"https://api.github.com/repos/atsepkov/RapydScript/issues/66/events","html_url":"https://github.com/atsepkov/RapydScript/issues/66","id":90004328,"number":66,"title":"Improve the module/import system","user":{"login":"kovidgoyal","id":1308621,"avatar_url":"https://avatars.githubusercontent.com/u/1308621?v=3","gravatar_id":"","url":"https://api.github.com/users/kovidgoyal","html_url":"https://github.com/kovidgoyal","followers_url":"https://api.github.com/users/kovidgoyal/followers","following_url":"https://api.github.com/users/kovidgoyal/following{/other_user}","gists_url":"https://api.github.com/users/kovidgoyal/gists{/gist_id}","starred_url":"https://api.github.com/users/kovidgoyal/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kovidgoyal/subscriptions","organizations_url":"https://api.github.com/users/kovidgoyal/orgs","repos_url":"https://api.github.com/users/kovidgoyal/repos","events_url":"https://api.github.com/users/kovidgoyal/events{/privacy}","received_events_url":"https://api.github.com/users/kovidgoyal/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/atsepkov/RapydScript/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":23,"created_at":"2015-06-22T04:04:18Z","updated_at":"2015-07-03T16:20:09Z","closed_at":null,"body":"First, let me thank you for the work you have already done. RapydScript is just what I was looking for. And apologies for the long winded post below.\r\n\r\nI would like the module/import system to be more like python. I am sure you are already familiar with this, but for my own clarity, I list some problems with the current implementation below. \r\n\r\n 1. If you create a module without a ```module name:``` decoration importing it imports all its symbols into the global namespace of the \"main\" module. This is unworkable for a large codebase.\r\n\r\n 2. If you use ```from x import y``` and y uses ```module something:``` you are left with\r\nvar something={y:whatever}\r\ninstead of var y = something.y\r\n\r\n 3. The use of the ```module:``` is pointless and confusing, it causes imports to be bound to the name from the ```module:``` directive instead of the name used in the local import statement. And it means that all code has to be at at least one level of indentation. Instead all modules should be imported once, but bound into the namespace of the module doing the importing using the names defined by the import statement. So ```import os.path``` should result in ```var os = {path:<all symbols from path module>}``` **not**  ```var name_from_module_declaration = {...}```\r\n\r\n 4. There is no support for aliasing (i.e. import x as y)\r\n\r\nI am willing to do the work to fix these issues and make the import system work like python. Basically, there would be a global (global to the main modules' scope) variable called ```_$rapyd$_modules``` (corresponding to sys.modules in python) which contains all imported modules. \r\n\r\nActual ```import``` and ```from import``` statements will be converted into\r\n\r\n```js\r\nvar x = _$rapyd$_modules[whatever].whatever\r\n```\r\nso that those names are bound only in the local scope of the module doing the importing. \r\n\r\nThe problem is these changes are not backwards compatible, and I dont know if this is a direction you are willing to move in. If you are, then I will try to do the work in way that makes it easy for you to merge, if not, I will proceed with an incompatible fork. \r\n\r\nIt may be that there is some reason for the current design of the import system and what I am proposing is not feasible, after all, I am a noob at RapydScript. If so, I would appreciate it if you would let me know, to save me the trouble of discovering it on my own :)"},"comment":{"url":"https://api.github.com/repos/atsepkov/RapydScript/issues/comments/118386226","html_url":"https://github.com/atsepkov/RapydScript/issues/66#issuecomment-118386226","issue_url":"https://api.github.com/repos/atsepkov/RapydScript/issues/66","id":118386226,"user":{"login":"atsepkov","id":2549997,"avatar_url":"https://avatars.githubusercontent.com/u/2549997?v=3","gravatar_id":"","url":"https://api.github.com/users/atsepkov","html_url":"https://github.com/atsepkov","followers_url":"https://api.github.com/users/atsepkov/followers","following_url":"https://api.github.com/users/atsepkov/following{/other_user}","gists_url":"https://api.github.com/users/atsepkov/gists{/gist_id}","starred_url":"https://api.github.com/users/atsepkov/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/atsepkov/subscriptions","organizations_url":"https://api.github.com/users/atsepkov/orgs","repos_url":"https://api.github.com/users/atsepkov/repos","events_url":"https://api.github.com/users/atsepkov/events{/privacy}","received_events_url":"https://api.github.com/users/atsepkov/received_events","type":"User","site_admin":false},"created_at":"2015-07-03T16:20:09Z","updated_at":"2015-07-03T16:20:09Z","body":"@joystein I'll be merging the changes shortly. I'm unfortunately only able to work on this towards weekends, I tried merging the changes last week but wanted to resolve the licensing issue first. Kovid's fork also broke some standard libraries (math.pyj, random.pyj, etc.) that I will need to fix before adding it to official fork.\r\n\r\nAlso, @kovidgoyal , your stance doesn't upset me. Your attitude towards those who don't share your stance does. Let's not dwell on this anymore.\r\n\r\nAs far as the problem you describe, I see your point. But in my opinion it's a result of poor design in other areas. First of all, all global constants should be declared in the same location. Most of the time there is no need for a constant to be global (see math.PI and math.E declarations). If one of my reports submitted code with X and Y declared globally in his own module, I'd send it back for recode. And if these re-declarations exist in the same module, wrapping it in its own namespace would do nothing to mitigate the issue. An approach that would help, however, is having compiler complain if developer redeclares a variable in global scope."}}