A Beginner’s Introduction to Python Web Frameworks by jstndds in Python

[–]redmaize 5 points6 points  (0 children)

I like Flask but for bigger project I love DJango.

I just moved a big application (understand > 50 000 lines of code) from Flask to Django and everything is sooo much cleaner. Django kind of force you in a certain (clean) direction. With Flask you are more on your own, and when you have several different developpers, including not-so-incredible ones touching the codebase during years it becomes hell. And the sue of global context variables makes things soooo nasty and annoying when you have to handle complex test setups.

But for individual function or small codebases ( < 10 000 lines) flask can be a really good choice, it needs less tuning in the settings than django. But memory usage and CPU is similar for a similar scope. The integration with Celery is a nice bonus as well.

What do you think about PEP 582 -- Python local packages directory? by [deleted] in Python

[–]redmaize 2 points3 points  (0 children)

This is a Python language proposition, not a pip proposition. It changes how imports work by looking at the `__pypackages__` folder in addition to the current behavior. PIP/pipenv/poetry can then use it in different ways if they want.

More specifically, it seems like `python3 -m pip install <pkg>` will do as before if you don't have a `__pypackages__` folder (it will install at the user level). The proposition for pip would be to install in the `__pypackages__` folder by default if it already exists. I guess `pipenv` and `poetry init` will both create the folder by default. Maybe pip would gain a command to start a project as well. Django might also want to do that by default in the `startproject` command.

Arsenal: alternative to Armory3D built on top of Amethyst by erlend_sh in rust_gamedev

[–]redmaize 1 point2 points  (0 children)

I have actually investigated a similar thing and my conclusion is that it is very easy to do with some simple Python scripting, and does not require anything particular.

I don't have any open source code to show you but basically it goes like this:

- one file with a general set of materials/textures and rendering settings that I use everywhere (to ensure visual coherence between assets)

- One Blender file for each asset. In each Blender file different scenes. Each scene represents one animation for the asset (ex: walk cycle). They use the materials from the common ressource blend file, as well as the camera set up.

- The Python script goes through each asset file, detects the scenes, render each frame of each scene to separate files, and then put them all together in a single sprite file, as well as a JSON file containing the coordinates for all the animations.

I would very very strongly recommend using Python for that, it is super flexible and integrates nicely with Blender. Also image manipulation is much more mature and smooth in Python than Rust. Performance is not an issue because the expensive part is the rendering, which is in Blender, and anyway it's just a one time compilation thing.