7 ms·

On GitHub you can click the symbol to see where it comes from. Any decent editor should provide similar functionality. Reading the import line to find where a

by jph00 6y ago

On GitHub you can click the symbol to see where it comes from. Any decent editor should provide similar functionality. Reading the import line to find where a symbol comes from is really clunky.

orf 6y ago
It’s not reading the import line. It’s reading “requests.get(...)” instead of “get(...)”
greatgib 6y ago
I hope that it will not look like a personal attack but, honestly, without looking at fastai, your replies on this comment thread does not let me think that the library is of very good quality. 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.
- mloncode 6y ago
  > I see there the typical pattern of the 'expert beginner' developer. 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/ 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.
  - afarrell 6y ago
    I agree with the core of greatgib's comment but disagree with framing around the person. The problem is not with the developer. We're all trying to write code to help each other grapple with complexity. 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.
  - greatgib 6y ago
    As I stated, my goal was not to say something like "you look ugly", and I did not want to pretend that he is a "junior developer". 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-the-expert-beginner/ 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/ 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/ 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-88fe9e8bd4d2 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".
- jph00 6y ago
  What you describe as "wrong" is how a great many languages work. 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.
  - curryst 6y ago
    Most recently created (I'm counting 20 years as recent) major languages do require or suggest that you specify the namespace a symbol is from if it isn't local. Off the top of my head, Javascript/Typescript, Python, Go, Java, I think it's good practice in Ruby but I'm not positive. 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.
mkolodny 6y ago
I just looked at the fastai library on the GitHub app on my phone, and tapping on symbols doesn't show where they come from. 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.
- jph00 6y ago
  Heh fair enough - reading the code online on a phone is perhaps not the best way to study the library :)

by jph00 6y ago

On GitHub you can click the symbol to see where it comes from. Any decent editor should provide similar functionality. Reading the import line to find where a symbol comes from is really clunky.

orf 6y ago

It’s not reading the import line. It’s reading “requests.get(...)” instead of “get(...)”

greatgib 6y ago

I hope that it will not look like a personal attack but, honestly, without looking at fastai, your replies on this comment thread does not let me think that the library is of very good quality. 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.

mloncode 6y ago
> I see there the typical pattern of the 'expert beginner' developer. 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/ 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.
- afarrell 6y ago
  I agree with the core of greatgib's comment but disagree with framing around the person. The problem is not with the developer. We're all trying to write code to help each other grapple with complexity. 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.
- greatgib 6y ago
  As I stated, my goal was not to say something like "you look ugly", and I did not want to pretend that he is a "junior developer". 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-the-expert-beginner/ 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/ 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/ 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-88fe9e8bd4d2 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".
jph00 6y ago
What you describe as "wrong" is how a great many languages work. 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.
- curryst 6y ago
  Most recently created (I'm counting 20 years as recent) major languages do require or suggest that you specify the namespace a symbol is from if it isn't local. Off the top of my head, Javascript/Typescript, Python, Go, Java, I think it's good practice in Ruby but I'm not positive. 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.

mkolodny 6y ago

I just looked at the fastai library on the GitHub app on my phone, and tapping on symbols doesn't show where they come from. 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.

jph00 6y ago
Heh fair enough - reading the code online on a phone is perhaps not the best way to study the library :)