[HN Gopher] Should You Use Upper Bound Version Constraints (In P...
       ___________________________________________________________________
        
       Should You Use Upper Bound Version Constraints (In Python)?
        
       Author : BerislavLopac
       Score  : 18 points
       Date   : 2024-04-16 06:33 UTC (16 hours ago)
        
 (HTM) web link (iscinumpy.dev)
 (TXT) w3m dump (iscinumpy.dev)
        
       | dannyz wrote:
       | I agree, I think upper bound constraints go against what is
       | commonly accepted and used in the Python ecosystem. What I try to
       | do on my projects now is to always have a nightly CI test step,
       | in theory if an updated package breaks my package it will be
       | caught fairly quickly
        
       | bruce343434 wrote:
       | This whole problem is because in python you can not specify
       | interfaces and say "I need a function called f that takes an x of
       | type T and returns a U", so instead you encode that in an
       | indirect way, like "I know version x.y.z works so I'll just
       | require that".
       | 
       | Any other way risks _runtime_ errors. And to people about to
       | mention types in python: those are also checked at _runtime_.
       | 
       | People keep using these hyper dynamic languages and then running
       | into these robustness issues and scaling limitations brought on
       | by their very dynamism. It makes me mad and sad.
        
         | teaearlgraycold wrote:
         | Just use TypeScript when possible.
        
         | 317070 wrote:
         | There are static type checkers, though:
         | https://github.com/google/pytype
         | 
         | So you can specify interfaces (protocols) and check them in
         | your installation process.
        
         | leni536 wrote:
         | Function interfaces are better, but not necessarily sufficient.
         | Semantics of functions can also change in a breaking way.
        
         | LegionMammal978 wrote:
         | Since when has static typing eliminated backward-compatibility
         | problems in interfaces? Not all visible runtime behavior can be
         | encoded in the type system, unless you're using a proof
         | assistant or formal-verification system.
        
       | leni536 wrote:
       | Capping at major version level is just common sense, IMO. It
       | almost shouldn't be even possible to leave the major version out
       | when declaring package dependencies. A new version might as well
       | be an entirely unrelated library/application from the viewpoint
       | of compatibility, so it might as well be part of the name of the
       | package. Not unlike how the python major version is part of the
       | name of the interpreter.
       | 
       | Major versions going EOL'd and unmaintained is unfortunate, but
       | that's not a purely technical problem. Releasing a new major
       | version and breaking compatibility with existing users is as much
       | a social decision as a technical one.
       | 
       | I'm not sold on the "semver doesn't work anyway" angle here
       | either, although I admit that it's not perfect.
        
       ___________________________________________________________________
       (page generated 2024-04-16 23:00 UTC)