6 ms·

> Wait! What's going on here? We just imported pathlib.Path - why are we getting this new functionality? Thats because we imported the fastcore.foundation modul

> Wait! What's going on here? We just imported pathlib.Path - why are we getting this new functionality? Thats because we imported the fastcore.foundation module, which patches this module via the @patch decorator discussed earlier. This is a recipe for disaster. Too much magic that makes it harder to debug. Especially for junior developers or people less experienced in python. I've seen fast.ai code and in terms of good practices it violates a bunch for the sake of convention. A good example is the `from module import *`.

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.
    - 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.

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.
  - 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.