| Technologies | 🦀🐍 |
Subtle Paradox
- 1 Followers
- 14 Following
- 37 Posts
@dan613 yes, but you lose the conda binary compatibility guarantees with the switch. Consider pixi (https://pixi.dev) for a faster package manager over the conda ecosystem.
@dr_null yes, agents are very good at filling in a clear API with an implementation. Less so at defining the API
@fasterthanlime they call it “eventual consistency”.
@fasterthanlime the same is true of virtually every human endeavor; It’s not until the consequences are “real” that humans tackle inconvenient stuff.
@light @michalfita @alios this article has a number of good examples to start with: https://www.adacore.com/blog/memory-safety-in-rust
@sethmlarson I think the most important things to do are to be consistent, loud, and keep the deprecation window short (max 3 months — 6 if it’s more than a find/replace change). Use semver to help people reason about it, but most importantly communicate the last version something will be supported in up front. Then projects that might not want to work on it right away can pin to <= that.
@niq https://stackoverflow.com/questions/8067171/ctypes-vs-c-extension#8069179
This is still pretty accurate for current Python; the overhead is significant compared to a native module, so you’ll want to avoid calling in a hot loop (or hoist the loop into C) with ctypes.
@dalcacer @samueljohn the thing conda solves for is full *binary* compatibility of the entire environment, including non-Python dependencies. This gets more complex in the scientific/machine-learning space due to much of the ecosystem relying on C/C++ builds and GPU libraries. Most PyPI builds (wheels) compile with conservative, compatible settings. When you want to target newer CPU features, you end up unable to use the binary wheels, and must handle all the complexity yourself.