That's not a good example at all.
Every fast.ai module defines __all__, and is carefully designed to allow "import *" to be used safely. I'm not aware of any other library that goes to this trouble.
Every fast.ai module defines __all__, and is carefully designed to allow "import *" to be used safely. I'm not aware of any other library that goes to this trouble.
import \* is convenient to use in a shell. But it makes code more difficult to read. If code doesn't explicitly say where variables were imported from, it takes extra time to figure out where variables were imported from - especially if you're reading code on GitHub.
Reading the import line to find where a symbol comes from is really clunky.
I see there the typical pattern of the 'expert beginner' developer.
If you read yourself,you are saying that you know well that it is better to rely on a specific platform (Github) or editor to be able to resolve your mess than having self descriptive/sufficient code...
For the module using a library, when you do an 'import *' it can easily create a very big mess. For example, as a dev you see a piece of code and you don't necessarily know where all the symbols come from and so the associated dependencies. And so if you have to move this piece of code to another place you can have a hard time to ensure and fix imports on the other side to be sure that it matches.
I'm sorry if I'm not clear, but it is so wrong on so many points in an obvious way that I don't even know what to start with.
I see the typical pattern of someone being a jerk calling people "junior developers" without first doing their research on the person and finding out (1) how long they have been a developer and (2) the work that they have created.
Debate why the methods are incorrect instead of saying "you look ugly".
The author has a completely different development environment than you that supports this paradigm (https://nbdev.fast.ai/) that you likely you aren't using. If you read the docs of the library references to this is well documented. However, that isn't going to be apparent to someone who engages in drive-by comments without doing the proper research.
And yes, it does look like a personal attack. Stop it with the lazy take and actually try to read before jumping to conclusions.
The problem is with the effect that `import *` has on others' experience of trying to orient themselves to a codebase.
-------------
One of the great things about python is that when you see a variable or method name, you can look up and see where it comes from. This genuinely reduces the cognitive cost of reading a python codebase. Throwing that away has a real impact on people.
I'll own that part of my reaction comes from the fact that I've been writing ruby professionally for 4 years now and I miss python namespaces ever so terribly.
What I said is that from his comments, and based on my personal experience, I think that we are in a case of an "expert beginner" as described by this blog:
https://daedtech.com/how-developers-stop-learning-rise-of-th...
The meaning of that is probably better explained in the blog post than by me here. But if I would try to summarize the idea, it is like some people that think that they are the smartest devs because they create "code generators" and some very complex code/machinery, when in fact the problem is their useless complexity, and that a good dev would do something a lot simpler.
If we look at the "import " case, this guy is pretending that he knows better; that it is a "better/cleaner way" to do python code. But, saying that, he contradicts the very large experience of a lot of really experienced devs and even the spirit of the Python language.
https://www.python.org/dev/peps/pep-0008/
<<
Wildcard imports (from <module> import ) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools.
>>
https://www.python.org/dev/peps/pep-0020/ (Zen of Python)
<<
Explicit is better than implicit.
Simple is better than complex.
...
In the face of ambiguity, refuse the temptation to guess.
>>
Probably not exhaustive, but a blog post attempting to explain the kind of issues to be expected with "import *":
https://medium.com/@s16h/importing-star-in-python-88fe9e8bd4...
So, even if it is a little bit arbitrary, when someone declare "extending Python" to improve it but does not understand the basic design ideas behind Python, I have the feeling that I'm facing an "Expert beginner".
You say this and there is no good reason to doubt you:
> my goal was not to say something like "you look ugly"
But do your words _achieve_ that goal? You can judge the probability that I and others are wrong to say no. You can judge your comfort with that risk. You can judge if using this mental model would make others really listen to you:
-----------------------------------------------------------------------------------------
Words often lead people to hold ideas in their mind. You want your words to do that. To have influence means that when someone else goes to make relevant a choice, your words are the mixtape that plays in their mind. In order to for brains to do things, they need to anticipate some reward -- a feeling of discovery, relief, vindication, determination, clarity. If you imagine your words playing in someone's head, you can make a guess at what will give them that feeling. Succeed, and folks want to keep reading and keep considering your ideas.
Words have power. And the most powerful words to a person conjures ideas about who that person is -- or who they can grow to be. Following that, words merely about what people did or can do also have power. Following that, are words about nonliving objects.
* Identity
* Action
* Objects
So what do you think plays in the mind of someone who initially likes Fastcore and reads "Some people that think that they are the smartest devs because they create "code generators" and some very complex code/machinery, when in fact the problem is their useless complexity, and that a good dev would do something a lot simpler."?
Pay attention to some of the words there:
> the smartest devs
> a good dev
These are both statements about Identity. "Who is she?" - "Not a good dev."
Imagine that I thought that these things that Fastcore are good ideas. Then to hold these ideas in mind requires me to endure for a little bit of time the thought that I am the opposite of a smart dev or good dev. When I am my wisest self, whatever. They're just you words, who cares about them? But when I am a bit more of a suggestible mood, planting that idea in my mind prompts an aggressive rejection from my ego. Is my ego response your problem? Not unless you choose to care about how much your words influence my thought.
> this guy is pretending that he knows better
To call someone a liar is a powerful way to make an enemy. I can work with someone who thinks I am mistaken or that I've failed. Science and Engineering draw their power from a keen understanding of error and failure.
But someone who will be lightning-quick to judge me a liar? I cannot trust them any more than they can trust me.
So my advice this: Read your words and exercise care over what they say about a person, their intent, and their actions.
------------------------------------------------------
Do I always do this? No, not at all. This is a discipline -- and I am many things but I am not a disciplined man.
Does this always succeed? No, but when it fails, it fails in better ways.
Is thinking like this manipulative? Well, it genuinely can be: I am talking about power after all. But thinking like this can also stop you from using the power of your words carelessly. ... or not. The only thing that can stop you from using any power for evil is your own sense of responsibility to clarity, kindness, or truthfulness.
After coding nearly every day for over 30 years, across many languages, I've come to a view that computers should do our work for us where possible, and that valuable programmer time should be spent doing the things that computers can't do for them.
Most languages do not require the programmer to list every single symbol that they use at the top of the file, or expect programmers to read that entire list to figure out where a symbol comes from. Pretty much every modern editor, IDE, and live coding environment will do that for you. Asking the programmer to make a manual list for you really isn't reasonable, IMO.
The reason that `import *` is dangerous in Python is that most people don't define __all__, and unfortunately Python doesn't have an easy way to avoid namespace pollution without that. Many in the Python community have now convinced themselves that's a feature.
I think C is the only major language I can think of off the top of my head that doesn't suggest namespacing symbols.
> Asking the programmer to make a manual list for you really isn't reasonable, IMO.
I prefer the clarity, it's worth my time. In the same way that most of the modern tooling will handle resolving which symbols are from which packages, most tooling will also handle adding imports for you if you give it a namespace. I just have to carry the mental load of remembering which package has the symbol I need. It's not an issue most of the time because I usually either know the library well enough that I know the symbol and thus the package, or I don't and I have the docs up on a screen.
There are insidious ways both that and the import all resolution can fail. One is if the symbol exists in more than one package. Then all of a sudden the ordering of your imports matters, which I despise. Another way the __all__ imports can fail in weird ways is if you upgrade a package and it stops exporting a symbol you use. Namespaced symbols will start throwing errors that the symbols doesn't exist in the package. __all__ imports mean you now have to figure out where that symbol even came from originally. You can check what got upgraded and go backwards from there, but it's going to confuse junior devs and your DevOps people.
There might also be performance implications. I don't know if Python has the ability to avoid parsing unused parts of modules or not. It's probably generally negligible unless you're writing small CLI tools.
By the way, I love your courses, and I appreciate that you've contributed a ton to the community :) I just think the import \* thing could use changing. It's something that's helpful for experimenting, but unhelpful for library users. I've played around with fastai2 a bunch, and I think showing imports would've helped me understand the codebase a lot faster. It's also a pretty simple change that could probably be automated.
Star imports are convenient, but dangerous in so many subtle ways. There's a very good reason that every major Python linter will call this out as bad behavior.