9 ms·

> I can see a name and match that to an import and match that to a package. Grabbing a function pointer works exactly as I would expect. Autoloading is one of

by qudat 5y ago

> I can see a name and match that to an import and match that to a package. Grabbing a function pointer works exactly as I would expect. Autoloading is one of the worst features ever introduced into a language/framework. https://erock.io/2021/11/01/on-autoloading.html https://erock.io/2021/11/01/on-autoloading.html

friedman23 5y ago
Ah yes, now I remember why I stopped learning ruby and was generally disgusted with the language. Along with the standard library having numerous ways to do the same thing and the general use of monkey patching (and the ruby users actually thinking monkey patching is good)
pas 5y ago
I have no problem with PHP autolading, or TS dependency injection (as seen in Angular, NestJS, TSed), or even in Scala (Play! framework via Guice). Because it's not magic (since you need to import the types you know what you are getting, for PHP there's the autoload.php generated by Composer, for TS everything is in the node_modules and in the lockfile, and for both Scala and TS the compiler checks things too. Of course in TS there are sometimes problems for non-native [ie. JS + .d.ts] libs, when the typing becomes outdated). But in Python the amount of magic shit one had to do to get things loaded in a sane manner was always somehow a serious burden. .. but in Ruby (Rails). Well, yeah, all you have is a lockfile, and nothing else. No imports, no typing. That gets crazy really fast. :)
- saila 5y ago
  You can use DI in Python too--it's an architectural pattern that can be used in any project regardless of language. I've never seen or used autoloading in Python. What would the use case for that be? I guess it could be "convenient" to avoid imports? That seems like a bad idea to me and not very "Pythonic." I'm not sure if this is relevant to your comment, but I've seen people abusing sys.path in Python projects instead of setting up a proper package and installing it. Modern Python package/dependency managers like Poetry make this nicer/easier than the old school setup() approach and they also create lock files.
  - pas 5y ago
    We had problems with circular imports back then in a Flask based backend. Also we wanted configuration based loading. Local dev, testing, prod, on premise. Plus multi-tenancy meant that everything was very-very dynamic and additional layers of configurability were present based on the request. (So basically request scoped service injection was needed. Of course we did not do that, we just passed around a bunch of parameters in a "very Pythonic way".)
    - saila 5y ago
      Circular imports often indicate an architectural issue. In any case, there are easy solutions in the rare cases where it's absolutely necessary, like putting one of the imports at the bottom of one of the modules or in a function. Regarding configuration based loading, that's something that's pretty common in Python webapps, and injecting capabilities/services per request seems like it would be pretty straightforward (and not anti-Pythonic either, depending on the implementation). I just don't see how Python makes this kind of thing more or less difficult than other languages.
      - bshipp 5y ago
        Circular imports also are most common when you use 'from module import *'.
- shakna 5y ago
  > But in Python the amount of magic shit one had to do to get things loaded in a sane manner was always somehow a serious burden. Controlling how Python imports things, seems dead easy with importlib [0] (introduced in Python 3.1). You can control the namespaces, the loader, the paths, generate code on the fly, etc. If you wanted to, say, duplicate lockfile imports using a requirements.txt file, then that's probably a teeny tiny ten line thing or something like that. Python is quite flexible if you want to rewrite how the language is doing something. [0] https://docs.python.org/3/library/importlib.html https://docs.python.org/3/library/importlib.html
  - pas 5y ago
    Agreed. I was sloppy in my previous comment, but what I wanted to explain is that we started with good old static imports, but needed a lot more dynamic stuff (heavily customizable deployments - onprem, dev, SaaS prod, etc) Python can do this, but we had to accept that yep, we need a lot of elbow grease to be able to use regular libraries plus have a highly environment and request dependent "stack".
byroot 5y ago
Again, your complaint, while valid, has nothing to do with autoloading, but with namespacing: https://news.ycombinator.com/item?id=29117535 https://news.ycombinator.com/item?id=29117535

by qudat 5y ago

friedman23 5y ago

Ah yes, now I remember why I stopped learning ruby and was generally disgusted with the language. Along with the standard library having numerous ways to do the same thing and the general use of monkey patching (and the ruby users actually thinking monkey patching is good)

pas 5y ago

I have no problem with PHP autolading, or TS dependency injection (as seen in Angular, NestJS, TSed), or even in Scala (Play! framework via Guice). Because it's not magic (since you need to import the types you know what you are getting, for PHP there's the autoload.php generated by Composer, for TS everything is in the node_modules and in the lockfile, and for both Scala and TS the compiler checks things too. Of course in TS there are sometimes problems for non-native [ie. JS + .d.ts] libs, when the typing becomes outdated). But in Python the amount of magic shit one had to do to get things loaded in a sane manner was always somehow a serious burden. .. but in Ruby (Rails). Well, yeah, all you have is a lockfile, and nothing else. No imports, no typing. That gets crazy really fast. :)

saila 5y ago
You can use DI in Python too--it's an architectural pattern that can be used in any project regardless of language. I've never seen or used autoloading in Python. What would the use case for that be? I guess it could be "convenient" to avoid imports? That seems like a bad idea to me and not very "Pythonic." I'm not sure if this is relevant to your comment, but I've seen people abusing sys.path in Python projects instead of setting up a proper package and installing it. Modern Python package/dependency managers like Poetry make this nicer/easier than the old school setup() approach and they also create lock files.
- pas 5y ago
  We had problems with circular imports back then in a Flask based backend. Also we wanted configuration based loading. Local dev, testing, prod, on premise. Plus multi-tenancy meant that everything was very-very dynamic and additional layers of configurability were present based on the request. (So basically request scoped service injection was needed. Of course we did not do that, we just passed around a bunch of parameters in a "very Pythonic way".)
  - saila 5y ago
    Circular imports often indicate an architectural issue. In any case, there are easy solutions in the rare cases where it's absolutely necessary, like putting one of the imports at the bottom of one of the modules or in a function. Regarding configuration based loading, that's something that's pretty common in Python webapps, and injecting capabilities/services per request seems like it would be pretty straightforward (and not anti-Pythonic either, depending on the implementation). I just don't see how Python makes this kind of thing more or less difficult than other languages.
    - bshipp 5y ago
      Circular imports also are most common when you use 'from module import *'.
shakna 5y ago
> But in Python the amount of magic shit one had to do to get things loaded in a sane manner was always somehow a serious burden. Controlling how Python imports things, seems dead easy with importlib [0] (introduced in Python 3.1). You can control the namespaces, the loader, the paths, generate code on the fly, etc. If you wanted to, say, duplicate lockfile imports using a requirements.txt file, then that's probably a teeny tiny ten line thing or something like that. Python is quite flexible if you want to rewrite how the language is doing something. [0] https://docs.python.org/3/library/importlib.html https://docs.python.org/3/library/importlib.html
- pas 5y ago
  Agreed. I was sloppy in my previous comment, but what I wanted to explain is that we started with good old static imports, but needed a lot more dynamic stuff (heavily customizable deployments - onprem, dev, SaaS prod, etc) Python can do this, but we had to accept that yep, we need a lot of elbow grease to be able to use regular libraries plus have a highly environment and request dependent "stack".

byroot 5y ago

Again, your complaint, while valid, has nothing to do with autoloading, but with namespacing: https://news.ycombinator.com/item?id=29117535 https://news.ycombinator.com/item?id=29117535