> Why not load something like node_modules automatically? There is a lot to say about that, and that could fill an entire article, so I'll skip it for now.
Could you provide a summary of the reasoning behind this? I've had this question for years but have never found a clear answer.
> I'll have to write a series on how to create packages, won't I?
TL;DR: python is used as a system language, a scripting language and a plugin language with full access to the filesystem and process popping abilities in mac and linux. Loading automatically from current directory is a security risk that would need to be mitigated and there is no good story for that for now. There is few things to unpack in that statements, hence the need for an article.
Also, python envs can't install multiple versions of the same lib in the same envs, so any sufficiently complex projects will actually have multiple envs.
Fantastic article. I was around for much of that history, but many things seemed confusing and esoteric. Placing it all into a history like that has helped to make sense of it all. Filled in many gaps in my understanding, thank you! 🙏
- How to write a web app from dev machine setup to coding to server deployment.
- POO.
- Building and publishing a package.
- Design patterns
Now, given the series on Testing took me 6 months to create so far and that I have a company to run, I would recommend not to be too much in a hurry :)
> Because of the way the Python import system works (another design decision that shows its age), any module or package in the Python Path is importable.
Would you be willing to elaborate on this please? I realized I’ve no idea how more modern interpreted languages/runtimes solve this :) Or what the key differences/improvements compared to Python are, because Python is what I’m most familiar with.
I assume the main problem is that imports can be accidentally/maliciously hijacked by fiddling witht PYTHONPATH? How can this be mitigated? By having some sort of manifest which explicitly lists which packages have been intentionally installed and where?
Sorry for not being clear :) I’m interested in the latter — what are the ways in which it shows it age? What would be done differently today?
(I assumed that a more modern import system would be safer/less error-prone, which is what my 2nd paragraph was getting at, but maybe that’s not what you meant?)
Right now because it find the first importable name on the python path, and syntax doesn't give you any control over anything else than name, you can only install one version of something.
This means you cannot opt in to install 2 versions of the same lib for the sake of compat. Well, you can, but you have to vendor it manually, which is a lot of work.
NodeJS is the opposite, it will always let you install as many versions of any deps as sub deps request so you end up with 2000 times the same lib.
A middle ground would help a lot with complex envs: opt-in way to install and import alternative versions of the same lib. E.G: one for you old deps, and one for your own modern code, while you wait for the upgrade to become possible.
Thanks for another great article! My RSS-Reader makes me smile every time a new bite code! article pops up. Entertaining writing style and there is a bunch of stuff to learn from every article for an intermediate pythonista like me.
Amazing article! Thanks a lot.
> Why not load something like node_modules automatically? There is a lot to say about that, and that could fill an entire article, so I'll skip it for now.
Could you provide a summary of the reasoning behind this? I've had this question for years but have never found a clear answer.
> I'll have to write a series on how to create packages, won't I?
Please do that. I for one would really enjoy it.
TL;DR: python is used as a system language, a scripting language and a plugin language with full access to the filesystem and process popping abilities in mac and linux. Loading automatically from current directory is a security risk that would need to be mitigated and there is no good story for that for now. There is few things to unpack in that statements, hence the need for an article.
Also, python envs can't install multiple versions of the same lib in the same envs, so any sufficiently complex projects will actually have multiple envs.
Excelent article!! Thanks for write and sharer !!
The Python evolution! We doing our best effort on each epoch !!
Fantastic article. I was around for much of that history, but many things seemed confusing and esoteric. Placing it all into a history like that has helped to make sense of it all. Filled in many gaps in my understanding, thank you! 🙏
Hopefully in 6 months I'll tell everyone to not bother and just learn two letters: u and v.
100% - that project looks super exciting!
I would love to read your take on how to do number 3 of the "3 sides to this story" you mentioned in the beginning of the article
> 1. Building a package.
> 2. Installing a package.
> 3.Configuring tooling for a project.
Yes, that would be a good series to write.
Also in the pipeline:
- How to write a web app from dev machine setup to coding to server deployment.
- POO.
- Building and publishing a package.
- Design patterns
Now, given the series on Testing took me 6 months to create so far and that I have a company to run, I would recommend not to be too much in a hurry :)
> Because of the way the Python import system works (another design decision that shows its age), any module or package in the Python Path is importable.
Would you be willing to elaborate on this please? I realized I’ve no idea how more modern interpreted languages/runtimes solve this :) Or what the key differences/improvements compared to Python are, because Python is what I’m most familiar with.
I assume the main problem is that imports can be accidentally/maliciously hijacked by fiddling witht PYTHONPATH? How can this be mitigated? By having some sort of manifest which explicitly lists which packages have been intentionally installed and where?
Or did you have something else in mind?
Not sure what the question is. You want me to elaborate on the mechanism, the fact it shows its age, or something else?
Sorry for not being clear :) I’m interested in the latter — what are the ways in which it shows it age? What would be done differently today?
(I assumed that a more modern import system would be safer/less error-prone, which is what my 2nd paragraph was getting at, but maybe that’s not what you meant?)
Right now because it find the first importable name on the python path, and syntax doesn't give you any control over anything else than name, you can only install one version of something.
This means you cannot opt in to install 2 versions of the same lib for the sake of compat. Well, you can, but you have to vendor it manually, which is a lot of work.
NodeJS is the opposite, it will always let you install as many versions of any deps as sub deps request so you end up with 2000 times the same lib.
A middle ground would help a lot with complex envs: opt-in way to install and import alternative versions of the same lib. E.G: one for you old deps, and one for your own modern code, while you wait for the upgrade to become possible.
Thanks for another great article! My RSS-Reader makes me smile every time a new bite code! article pops up. Entertaining writing style and there is a bunch of stuff to learn from every article for an intermediate pythonista like me.
>>> I'll have to write a series on how to create packages, won't I?
Looking forward to that!