On Wed, Apr 14, 2021 at 2:23 PM Paul Moore <[email protected]> wrote:
> >> because PEP 440 versions are fundamental to packaging. > > > > Are you suggesting that users should have to install an external module > to tell what version of packages they are using?! > > No. To tell what version of a package they are using, a string is > sufficient. > exactly -- if we do anything at all here, it should probably be at least. if you provide a __version__ attribute, it should be a PEP 440 compliant string. That would at least make the use __version__ a touch more consistent. The next, more controversial, step would be to suggest that people SHOULD provide a __version__string on all top-level packages. I would like that -- the current situation where many, but not all packages have __version__ is really annoying. They only need a version object if they want to do additional > processing (like comparing versions, or checking whether a version > meets a constraint). > And indeed, we could add the ability for packaging.version.Version objects to be able to compare themselves with compatible strings -- I think that would be pretty handy. Given that the packaging ecosystem already has a canonical version > object (provided by the packaging library), which has been used and > tested extensively in many environments, inventing a different API > seems at best ill-advised. absolutely. > Whether the stdlib needs a version object. > rather than leaving that functionality to a 3rd party library, is the > same question that comes up for *any* functionality that's proposed > for the stdlib, and I have no particular opinion in this case. > I don't think it's the same as any functionality -- if we do want to better standardize package versioning in Python, and I think we should, then the Version object may become something useful to, and maybe even needed by, virtually every third party package. Which makes it a pretty prime candidate for the stdlib. Alternatively, the packaging package is pretty small, but if it grows, it might be good to split out the run-time vs build-time pieces. It's designed for programmatic use, not interactive use, yes. But > that's sort of my point, why do you want anything more than the bare > string in the REPL? What are you planning on doing with it? > there is something in between the REPL and full on system development -- something simple for quickly scripts is nice too. But a simple standardised version string is fine for that. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/BWIF72TLNB6A63SXYUO3KMSR6ZUNTALS/ Code of Conduct: http://python.org/psf/codeofconduct/