5 ms·

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 o

by jph00 6y ago

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.

mkolodny 6y ago
Allowing import \* to be used safely in notebooks is one thing. Using it in a library is very different. 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.
- 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".
  - 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 :)
kyran_adept 6y ago
Not having _all_ is just part of the problem. With "import *" you also unknowingly load and potentially overwrite symbols. If you specify each symbol you use, it's very simple for even the most basic linter to figure you are doing something wrong.
- jph00 6y ago
  It's not unknowingly at all.
- nuclear_eclipse 6y ago
  Even beyond that, if you've imported `from foo import bar` and then `from something import *`, it might work just fine. Then you upgrade the `something` module, and it happens to now include an item named `bar`, and you're suddenly breaking your existing usage without ever having changed your code. 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.

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 o

by jph00 6y ago

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.

mkolodny 6y ago

Allowing import \* to be used safely in notebooks is one thing. Using it in a library is very different. 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.

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".
- 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 :)

kyran_adept 6y ago

Not having _all_ is just part of the problem. With "import *" you also unknowingly load and potentially overwrite symbols. If you specify each symbol you use, it's very simple for even the most basic linter to figure you are doing something wrong.

jph00 6y ago
It's not unknowingly at all.
nuclear_eclipse 6y ago
Even beyond that, if you've imported `from foo import bar` and then `from something import *`, it might work just fine. Then you upgrade the `something` module, and it happens to now include an item named `bar`, and you're suddenly breaking your existing usage without ever having changed your code. 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.