4 ms·

Even if they changed the standard library from version to version... the result would be that people would stop using the standard library, migration tools or n

Even if they changed the standard library from version to version... the result would be that people would stop using the standard library, migration tools or no tools. Nobody really wants to deal with being pinned to a specific minor version and no older/newer - especially libraries.

rubber_duck 10y ago
The correct solution is to version the standard library separately from the language and allow for versioned dependencies, then a new language/VM update doesn't imply a new library that breaks everything, and vice versa. But python grew up in an enviroment where this sort of thing was not practical, and the batteries included is actually a good approach for what python tries to do - scripting. It just doesn't scale well in to maintainability.
- vertex-four 10y ago
  Once you have the standard library split apart, you might as well split it up, though, and then you don't really have a standard library any more. You could go the Haskell Platform route... which isn't a wonderful idea.
  - rubber_duck 10y ago
    I think if Python was developed from scratch now you would have a very small classic standard library and then stuff like HTTP server/client and JSON parsers would be separate libraries handled by package manager, but since python is a scripting language it would make sense to ship with some packages by default (so not a standard library, but say core packages) - this would let you version the core packages like any other package, but it would still let you run scripts without internet access/need to pull random dependencies for a script run.
    - vertex-four 10y ago
      That is pretty much the Haskell Platform. Haskell people have issues with it because it contains a whole bunch of really useful packages, but essentially pins them at old versions globally. Upgrading them, then, is a global thing, and if someone depends on an older version... you're stuck. The solution to this, of course, is sandboxing - never install libraries globally, only on a project-specific basis, and then their dependencies can override global ones. But it's fiddly to get the UX right - in Python, managing that involves two separate tools. And you'd need to create a project directory to get a repl with some library in it, unless you had extensions to the repl to install things temporarily - and then you'd likely have two separate UXes for installing things, whether you're doing it for a REPL or a project.
  - marcosdumay 10y ago
    > Haskell Platform route... which isn't a wonderful idea It's a bad idea, on short timeframes. But it's a hell of an adaptability bonus that ensures the language will keep improving. Just like Haskell's extension system, or its loose dependency on Prelude, or its multiparadigm emulation. I keep hopping something better than Haskell appears and people move on - but it probably won't happen any time soon, as soon as something better gets traction, Haskell will simply devour it and keep growing.
- joesb 10y ago
  Then people will complain that you need to specify dependencies just to use leftPad function.

rubber_duck 10y ago

The correct solution is to version the standard library separately from the language and allow for versioned dependencies, then a new language/VM update doesn't imply a new library that breaks everything, and vice versa. But python grew up in an enviroment where this sort of thing was not practical, and the batteries included is actually a good approach for what python tries to do - scripting. It just doesn't scale well in to maintainability.

vertex-four 10y ago
Once you have the standard library split apart, you might as well split it up, though, and then you don't really have a standard library any more. You could go the Haskell Platform route... which isn't a wonderful idea.
- rubber_duck 10y ago
  I think if Python was developed from scratch now you would have a very small classic standard library and then stuff like HTTP server/client and JSON parsers would be separate libraries handled by package manager, but since python is a scripting language it would make sense to ship with some packages by default (so not a standard library, but say core packages) - this would let you version the core packages like any other package, but it would still let you run scripts without internet access/need to pull random dependencies for a script run.
  - vertex-four 10y ago
    That is pretty much the Haskell Platform. Haskell people have issues with it because it contains a whole bunch of really useful packages, but essentially pins them at old versions globally. Upgrading them, then, is a global thing, and if someone depends on an older version... you're stuck. The solution to this, of course, is sandboxing - never install libraries globally, only on a project-specific basis, and then their dependencies can override global ones. But it's fiddly to get the UX right - in Python, managing that involves two separate tools. And you'd need to create a project directory to get a repl with some library in it, unless you had extensions to the repl to install things temporarily - and then you'd likely have two separate UXes for installing things, whether you're doing it for a REPL or a project.
- marcosdumay 10y ago
  > Haskell Platform route... which isn't a wonderful idea It's a bad idea, on short timeframes. But it's a hell of an adaptability bonus that ensures the language will keep improving. Just like Haskell's extension system, or its loose dependency on Prelude, or its multiparadigm emulation. I keep hopping something better than Haskell appears and people move on - but it probably won't happen any time soon, as soon as something better gets traction, Haskell will simply devour it and keep growing.
joesb 10y ago
Then people will complain that you need to specify dependencies just to use leftPad function.