4 ms·

Could you not do that today? import version2 try: version2.load_data(input) except ValidationError: import version1 version1.loa

Could you not do that today? import version2 try: version2.load_data(input) except ValidationError: import version1 version1.load_data(input) (Assuming version in name like this example version2 or lib2 etc.)

ForHackernews 2y ago
Only if the library is renamed for each new version, which seems a bit impractical.
- CraigJPerry 2y ago
  I guess that’s my central thesis against the need for this work - it’s not impractical to rename an import. With a tool like rope, I feel fairly confident I can refactor a source available, pure python dependency, pretty quickly. Where I get less comfortable with my idea is that not every dependency has source available (e.g. db2 database driver as an example). Another case is where some deps which have source available but the python module dependency is in C/C++/Rust - e.g. scipy
zahlman 2y ago
The pseudocode in GP fails to capture the idea. Right now, two different versions of the same third-party library, would ordinarily have the same `import` name in the code. Even if you somehow hacked Pip or otherwise managed to install multiple versions of the library side-by-side in the same Python environment, there would be no way, at the level of Python syntax, to specify which one to use. The default import machinery would simply choose a) whatever's cached in `sys.modules`; b) failing that, whatever is found first by the `sys.path` search process. There are many hooks provided to customize this process, but there would be no way to specify the version to use in the `import` syntax, aside from using separate names. Of course, you can change the import name between versions. That's one of the upsides of not tying the import name to the distribution name, and many real-world projects actually do this as part of a deprecation cycle (for example, `imageio` has been doing it with recent versions, offering "v2" and "v3" APIs). But in the general case, you'd have to change it with every version (since your transitive dependencies might want different minor/patch versions for some obscure reason - semver is only an ideal, after all), which in turn means your users would always have to pin their dependency to the exact version described by the code.

ForHackernews 2y ago

Only if the library is renamed for each new version, which seems a bit impractical.

CraigJPerry 2y ago
I guess that’s my central thesis against the need for this work - it’s not impractical to rename an import. With a tool like rope, I feel fairly confident I can refactor a source available, pure python dependency, pretty quickly. Where I get less comfortable with my idea is that not every dependency has source available (e.g. db2 database driver as an example). Another case is where some deps which have source available but the python module dependency is in C/C++/Rust - e.g. scipy

zahlman 2y ago

The pseudocode in GP fails to capture the idea. Right now, two different versions of the same third-party library, would ordinarily have the same `import` name in the code. Even if you somehow hacked Pip or otherwise managed to install multiple versions of the library side-by-side in the same Python environment, there would be no way, at the level of Python syntax, to specify which one to use. The default import machinery would simply choose a) whatever's cached in `sys.modules`; b) failing that, whatever is found first by the `sys.path` search process. There are many hooks provided to customize this process, but there would be no way to specify the version to use in the `import` syntax, aside from using separate names. Of course, you can change the import name between versions. That's one of the upsides of not tying the import name to the distribution name, and many real-world projects actually do this as part of a deprecation cycle (for example, `imageio` has been doing it with recent versions, offering "v2" and "v3" APIs). But in the general case, you'd have to change it with every version (since your transitive dependencies might want different minor/patch versions for some obscure reason - semver is only an ideal, after all), which in turn means your users would always have to pin their dependency to the exact version described by the code.