When I use the path way to import a module, I face a strange problem. The code may look like this:
#[path = "../../models.rs"]
mod models;
This would work. But somebody told me that this way is not recommended. To better understand the Rust import, I have the following questions:
In what situation we should using #[path = "../../xxx.rs"] to import a module?
What are the advantages and disadvantages of this way to import module?
Should we avoid using this way to import module in future?
I searched the Internet, but nobody seem to have these questions.
In what situation we should using #[path = "../../xxx.rs"] to import a module?
It is, as far as I know, never necessary. It could be a way to handle a special situation such as using conditional compilation to import different implementations of a single module, but you can also use pub use to get that effect. For example, the standard library uses both techniques in the same place, for some reason.
What are the advantages and disadvantages of this way to import module?
It lets you place a module's source code in a non-standard location. The disadvantages are that you are placing it in a non-standard location (which may be surprising to readers, including yourself) and that it makes it easy to accidentally duplicate a module.
The second point is the main reason why you hear not to use it: misunderstanding how the module system works leads to people trying to use #[path] to use a module from multiple other modules, and they instead end up duplicating the module, leading to strange errors as the module gets compiled twice in different contexts.
#[path] is an “advanced” feature for special circumstances. It is never necessary to write normal Rust code no matter how many files the code is divided into, and it can be confusing to readers, and therefore it should be avoided unless necessary.
Related
Different people have told me that in order to improve my Python programming skills, it helps to go and look how existing projects are implemented. But I am struggeling a bit to navigate through the projects and find the parts of the code I'm interested in.
Let's say I'm using butter of the scipy.signal package, and I want to know how it is implemented, so I'm going to scipy's github repo and move to the signal folder. Now, where is the first place I should start looking for the implementation of butter?
I am also a bit confused about what a module/package/class/function is. Is scipy a module? Or a package? And then what is signal? Is there some kind of pattern like module.class.function? (Or another example: matplotlib.pyplot...)
It sounds like you have two questions here. First, how do you find where scipy.signal.butter is implemented? Second, what are the different hierarchical units of Python code (and how do they relate to that butter thing)?
The first one actually has an easy solution. If you follow the link you gave for the butter function, you will see a [source] link just to the right of the function signature. Clicking on that will take you directly to the source of the function in the github repository (pinned to the commit that matches the version of the docs you were reading, which is probably what you want). Not all API documentation will have that kind of link, but when it does it makes things really easy!
As for the second question, I'm not going to fully explain each level, but here are some broad strokes, starting with the most narrow way of organizing code and moving to the more broad ways.
Functions are reusable chunks of code that you can call from other code. Functions have a local namespace when they are running.
Classes are ways of organizing data together with one or more functions. Functions defined in classes are called methods (but not all functions need to be in a class). Classes have a class namespace, and each instance of a class also has its own instance namespace.
Modules are groups of code, often functions or methods (but sometimes other stuff like data too). Each module has a global namespace. Generally speaking, each .py file will create a module when it is loaded. One module can access another module by using an import statement.
Packages are a special kind of module that's defined by a folder foo/, rather than a foo.py file. This lets you organize whole groups of modules, rather than everything being at the same level. Packages can have further sub-packages (represented with nested folders like foo/bar/). In addition to the modules and subpackages that can be imported, a package will also have its own regular module namespace, which will be populated by running the foo/__init__.py file.
To bring this back around to your specific question, in your case, scipy is a top-level package, and scipy.signal is a sub-package within it. The name butter is a function, but it's actually defined in the scipy/signal/_filter_design.py file. You can access it directly from scipy.signal because scipy/signal/__init__.py imports it (and all the other names defined in its module) with from ._filter_design import * (see here).
The design of implementing something in an inner module and then importing it for use in the package's __init__.py file is a pretty common one. It helps modules that would be excessively large to be subdivided, for ease of their developers, while still having a single place to access a big chuck of the API. It is, however, very confusing to work out for yourself, so don't feel bad if you couldn't figure it out yourself. Sometimes you may need to search the repository to find the definition of something, even if you know where you're importing it from.
As definition say, To use any built-in functions we need to first import the respective modules in the program
But how we are using print(), input(), len(), etc many more function without importing any modules in python
Please someone clarify it..
(sorry if my question is not relevant)
Because the Python language designers chose to make them available by default, on the assumption that they were useful enough to always be available. This is especially common for:
The simplest I/O functions (e.g. print/input) that it's nice to have access to, especially when playing around with stuff in the interactive interpreter
Functions that are wrappers around special methods (e.g. len for __len__, iter for __iter__), as it reduces the risk of people calling special methods directly just to avoid an import
Built-in classes (e.g. int, set, str, etc.), which aren't technically functions, but they're used frequently (possibly available as literals), and the definition of the class needs to be loaded for basic operation of the interpreter anyway
In short, you have access to them automatically because they might have to load them anyway (in the case of built-in classes), it's convenient to have access to them automatically, and the designers thought it was likely they'd be frequently used, nothing more complicated than that. The "likely to be frequently used" is important; some modules on the CPython reference interpreter are actually baked into the interpreter itself, rather than existing as separate modules on the file system (e.g. sys), but the contents of those modules were not considered important/commonly used enough to be worth injecting into the built-in namespace (where they'd be likely to collide with user-defined names).
The built-ins are provided through the builtins module, so if you want to see what's there (or, being terrible, change what's available as a built-in everywhere), you can import it and perform normal attribute manipulation on it to query/add/remove/change the set of available built-ins (the site module does this to inject the exit quasi-built-in for instance).
Here's something I tried to do, and it works well. I find it useful, but it feels like a hack, so I'm afraid it will break in the future.
I'm working on converting a large project to Bazel, and we have lots of local wrappers, something like:
my_cc_library(name='a', srcs=['lib.c'])
my_cc_binary(name='b', deps=['a'], srcs=['main.c'])
This requires lots of load commands, which are annoying and a repeating source of errors.
If it was normal Python, I'd simply import a whole module. But Skylark requires loading functions one by one.
I can remove the need for individual loads, using a struct.
In my.bzl:
def _my_cc_library(...): ...
def _my_cc_binary(...): ...
my = struct(cc_library=_my_cc_library, cc_binary=_my_cc_binary)
In various BUILD files:
load('//my.bzl', 'my')
my.cc_library(name='a', srcs=['lib.c'])
my.cc_binary(name='b', deps=['a'], srcs=['main.c'])
As I wrote above, it all works well. I can use if for wrappers to native rules, and for various other functions.
But an I abusing the language? Is it prone to break in the future?
Thanks.
This pattern is used in other places (e.g. https://github.com/bazelbuild/bazel-skylib/blob/master/lib/collections.bzl), it's safe to use it.
Not all tools support it well, though. For example, you won't be able to update your BUILD files with Buildozer - although it's something that can be fixed.
This requires lots of load commands, which are annoying and a repeating source of errors.
I agree it's annoying. In the future, we should have better tooling for updating load lines (to automatically add/remove them).
Rules in BUILD files look like my_cc_library(...) due to historical reasons. For a long time, load didn't exist and all rules were hard-coded in Bazel. Maybe we should encourage the my.cc_library(...) syntax and make it easier to use.
I really like the way NodeJS (and it's browser-side counterparts) handle modules:
var $ = require('jquery');
var config = require('./config.json');
module.exports = function(){};
module.exports = {...}
I am actually rather disappointed by the ES2015 'import' spec which is very similar to the majority of languages.
Out of curiosity, I decided to look for other languages which implement or even support a similar export/import style, but to no avail.
Perhaps I'm missing something, or more likely, my Google Foo isn't up to scratch, but it would be really interesting to see which other languages work in a similar way.
Has anyone come across similar systems?
Or maybe someone can even provide reasons that it isn't used all that often.
It is nearly impossible to properly compare these features. One can only compare their implementation in specific languages. I collected my experience mostly with the language Java and nodejs.
I observed these differences:
You can use require for more than just making other modules available to your module. For example, you can use it to parse a JSON file.
You can use require everywhere in your code, while import is only available at the top of a file.
require actually executes the required module (if it was not yet executed), while import has a more declarative nature. This might not be true for all languages, but it is a tendency.
require can load private dependencies from sub directories, while import often uses one global namespace for all the code. Again, this is also not true in general, but merely a tendency.
Responsibilities
As you can see, the require method has multiple responsibilities: declaring module dependencies and reading data. This is better separated with the import approach, since import is supposed to only handle module dependencies. I guess, what you like about being able to use the require method for reading JSON is, that it provides a really easy interface to the programmer. I agree that it is nice to have this kind of easy JSON reading interface, however there is no need to mix it with the module dependency mechanism. There can just be another method, for example readJson(). This would separate the concerns, so the require method would only be needed for declaring module dependencies.
Location in the Code
Now, that we only use require for module dependencies, it is a bad practice to use it anywhere else than at the top of your module. It just makes it hard to see the module dependencies when you use it everywhere in your code. This is why you can use the import statement only on top of your code.
I don't see the point where import creates a global variable. It merely creates a consistent identifier for each dependency, which is limited to the current file. As I said above, I recommend doing the same with the require method by using it only at the top of the file. It really helps to increase the readability of the code.
How it works
Executing code when loading a module can also be a problem, especially in big programs. You might run into a loop where one module transitively requires itself. This can be really hard to resolve. To my knowledge, nodejs handles this situation like so: When A requires B and B requires A and you start by requiring A, then:
the module system remembers that it currently loads A
it executes the code in A
it remembers that is currently loads B
it executes the code in B
it tries to load A, but A is already loading
A is not yet finished loading
it returns the half loaded A to B
B does not expect A to be half loaded
This might be a problem. Now, one can argue that cyclic dependencies should really be avoided and I agree with this. However, cyclic dependencies should only be avoided between separate components of a program. Classes in a component often have cyclic dependencies. Now, the module system can be used for both abstraction layers: Classes and Components. This might be an issue.
Next, the require approach often leads to singleton modules, which cannot be used multiple times in the same program, because they store global state. However, this is not really the fault of the system but the programmers fault how uses the system in the wrong way. Still, my observation is that the require approach misleads especially new programmers to do this.
Dependency Management
The dependency management that underlays the different approaches is indeed an interesting point. For example Java still misses a proper module system in the current version. Again, it is announced for the next version, but who knows whether this will ever become true. Currently, you can only get modules using OSGi, which is far from easy to use.
The dependency management underlaying nodejs is very powerful. However, it is also not perfect. For example non-private dependencies, which are dependencies that are exposed via the modules API, are always a problem. However, this is a common problem for dependency management so it is not limited to nodejs.
Conclusion
I guess both are not that bad, since each is used successfully. However, in my opinion, import has some objective advantages over require, like the separation of responsibilities. It follows that import can be restricted to the top of the code, which means there is only one place to search for module dependencies. Also, import might be a better fit for compiled languages, since these do not need to execute code to load code.
I'm working on my 1st Node.js module, and having to do common utility stuff like check types, looping etc.
The native JS for some of this stuff is pretty ugly. Underscore.js makes it more readable and adds a lot of new features too. But if I don't need the new stuff, should I use Underscore or just do it the hard way?
Thanks!
In node.is you can rely on having some ES5 stuff, array iteration functions and utility functions like isArray. In my node modules I never used underscore and had, due to array iteration functions like map, forEach never the need to use underscore or lodash.
I would not avoid a underscore dependency in case I'd really need it. The node.js platform relies on small modules depending on a couple of small modules itself. So why not depend on underscore.
I see no reason to avoid using a module that makes your life easier. And, it just so happens, that underscore.js is the most depended upon package in the npm registry (as of the time of this answer, according to https://npmjs.org/). So yea, no reason to avoid it.
I've never used underscore nor async on real projects. Once you know how to code good javascript it's not necessary to use any helper library. For example, functions that should execute in serie and are asynchronous it's pretty easy to do with a simple "recursive while loop", you don't need to load any library.
But at the end this is a personal preference. Use external libraries if you feel comfortable with them.
Advice: Don't look at the github starts or npm installations to decide which module to use. Being popular doesn't mean being good. I've tried a lot of popular modules and about a 40% of them are just bad/bugged/not really useful. There are a lot of modules that are not popular that are really good. Being popular helps to take a decision but you should not install and use a module just because it's popular.
Underscore does the right thing, which is check for all the native es5 methods first, meaning you won't have much in the way of performance loss on native methods getting replaced with slower non-native versions that basically do the same thing (code here):
var
nativeForEach = ArrayProto.forEach,
nativeMap = ArrayProto.map,
nativeReduce = ArrayProto.reduce,
nativeReduceRight = ArrayProto.reduceRight,
nativeFilter = ArrayProto.filter,
nativeEvery = ArrayProto.every,
nativeSome = ArrayProto.some,
nativeIndexOf = ArrayProto.indexOf,
nativeLastIndexOf = ArrayProto.lastIndexOf,
nativeIsArray = Array.isArray,
nativeKeys = Object.keys,
nativeBind = FuncProto.bind;
Note: prototypes assigned to "Proto" vars earlier.
That said, I'm pretty sure V8 has most if not all of these. Being of client-side dev origins I'd be delighted simply to use the raw naked thing without having to think about how or what library is best for dragging IE kicking and screaming out of the stone age this time, providing the built-in methods aren't as ugly as the DOM API and I would say these aren't.
If underscore does more for you than the above then by all means use it. If it doesn't, I'd consider it a waste of space. All it really does on the browser is give you fallback methods for the older browsers which aren't a going concern in Node. It's light though. I wouldn't object either way if you were on my team and didn't want to write your own versions of something uniquely handled by underscore but would prefer the direct native method names/args, etc. in my own code on the principle of disliking dependencies anywhere I don't need them.
I use underscore in modules that are shared with the browser, not to depend on ES5. Also Underscore has quite a few very useful methods that are not available in ES5, so it would make sense to read their manual page.