Comment by Hugo Mota on "3 things you hate about your favorite programming language?"

Python is awesome. Buuuuut:

Although it has one of the coolest import systems out there, python still have serious problems with cyclic imports. Other languages handle it muuuuch better.
It creates .pyc files for bytecode caching that are just annoying. PHP also caches bytecode and never needed to polute the working tree. Common python :p
Packaging a python library is just stupidly hard. After doing it in python, I couldn't believe myself when I did my first npm publish. So. Much. Easier.

to me it makes sense to "populate" the local working tree because it's easier to access the separate opcodes in PHP you have to flush the whole opcode so you cannot say "just this app" so this is a classic SOC decision to me :) not to disagree with you in general just pointing out it's a reasonable implementation decision if you think about more complex architectures with several code bases one you would have to handle with several FPM instances in PHP to get the same separation :)

@chilimatic The opcodes can be identified by their respective paths. I really don't see a good reason to keep the caches close. Also, I've had numerous problems with python opcode caching, when checking out branches in git for instance. I was actually forced to turn it off in my work computer, so I'm not afraid of the cache all the time. Never happened with me in PHP. But then again, I'm no compiler engineer, so there could be a reason I'm overlooking...maybe I'll research more about the subject to see if there's plans for the future :p

@hugollm I think I do understand what you mean I just wanted to point out that different implementations have different advantages -> I worked for a shared hoster (easyname.at) where we added different docker containers for different users (5.1, .... , 7) and we actually had generate a fpm config for every user so we can keep them inside of their container + paths to disallow hacking (shared www-data access), but even than if a customer had 4 different pages for his customers (2 wordpress, 2 drupal) he still had to reset the cache for all of them. we had other caching mechanisms in place but still you can see that the missing orthogonal design created some circumstances we had to consider.

one reason not to keep it in memory could be arbitrary size of the opcode and that it's a trade of between time complexity (computation time) vs space complexity (storage-space) this is not really correct since the instructions needed to load something from the harddisk are quite costly + the slow speed of hardisks (ms vs ns) but on the other hand the MRU-Cache implementation of the harddisk could speed it up a little ... but those are just guesses since I did not read up on the python implementation. if you do and you found out why, please do tell :)

@chilimatic well, I guess it's a complex problem in any arquitecture. I probably overlooked PHPs problems since I did not bump into them in the past. About the pyc files though, I did a little search and found a PEP proposing the ability to change bytecode location: https://www.python.org/dev/peps/pep-0304/. Sadly, it's marked as "withdrawn". So far I couldn't find the reason in the document :(

@hugollm yes usually if you're not doing drupal or other classic agency work with multiple customers you don't really feel the impact of cache invalidation. We only had to consider it because we had ~ 500 - 1000 users per server which lead to an increased complexity / impact.

about the withdraw that's kinda sad maybe you find some clues in an internal document ? i could think of permission problems and that the impact of change was to costly for the community -> possible breaking change if you're on a shared system or such but just grasping for straws here :)

Search Hashnode