On Thu, Apr 15, 2021 at 10:53 AM Antoine Pitrou <anto...@python.org> wrote:
> On Thu, 15 Apr 2021 10:28:53 -0700 > Brett Cannon <br...@python.org> wrote: > > On Thu, Apr 15, 2021 at 8:50 AM Christopher Barker <python...@gmail.com> > > wrote: > > > > > On Thu, Apr 15, 2021 at 2:40 AM Victor Stinner <vstin...@python.org> > > > wrote: > > > > > >> Paul Bryan: > > >> > Seems like this is something that should make its way into stdlib? > > >> > > >> In the last 10 years, the trend is more to remove anything related to > > >> packaging *outside* the stdlib :-) > > > > > > > > > Well, maybe all of us don't think that's a good idea ;-) > > > > > > > As an active participant in the PyPA side of the packaging ecosystem and > > one of the maintainers of 'packaging', I am definitely NOT in favour of > > moving any of 'packaging' into the stdlib, nor breaking it up. We are > > taking distutils out of the stdlib for a reason. Backsliding on plans > that > > have been in place for years is not something I would want to see happen > as > > the motivations have not changed. > > This seems gratuitously dogmatic. Version numbers are a simple feature > that is stably encoded in PEP 440. It's purely computational, does > not involve reading or saving any persistent state in the filesystem, > making any network access, etc. Why wouldn't it have its place in the > stdlib? > Technically PyPA specs might start as PEPs but their official home is packaging.python.org and updates can occur there outside of the PEP process. In the case of version specifiers ( https://packaging.python.org/specifications/version-specifiers/), they point back to the original PEP, but that is not universally true nor guaranteed to hold in the future. In other words I personally don't view the fact that it's a PEP as a reason to have it in the stdlib (else pretty much every single packaging PEP is missing). We also have other things standardized in PEPs and not covered in the stdlib, e.g. @ as an operator. So I don't think version comparison occurs often enough to be in the stdlib, and the fact that an external project exists which isn't interested in being put in the stdlib suggests to me it isn't worth doing. But that's a separate topic to discuss at the language summit. :) > > > > But anyway, I would say removing anything *related* to packaging > outside > > > the stdlib is a bad idea -- requiring an external tool to build a > package > > > is OK, but requireing an external use packages, not so much. > > > > > > > You can totally use a package already as things exist today and will in > the > > future; you're just wanting a specific way to interpret a package's > > metadata which I don't view as the same thing. > > That specific way is a Python standard (PEP 440). Having the > functionality in the stdlib would encourage people to use it. Not > having it in the stdlib encourages people to use adhoc version parsing, > or worse, naive string comparison. > I don't know if I draw the same line since the packaging community is relying on 'packaging' without issue for this exact thing. > > > So asking every Python project to set a > > __version__ isn't going to change accessibility of version numbers when > it > > comes to installed projects. > > That doesn't have much to do with the suggestion of shipping a Version > class in the stdlib, though. Many projects already provide a > __version__, and that field is often inspected programmatically in > dependent packages (to work around behaviour changes, for example). > But this thread is about standardizing on __version__ which then led to wanting to bring in some Version object into the stdlib to make that more useful. So to me they are tied together, else a separate thread should probably be started if a new module *just *for version parsing support is desired.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AYJ4JBTIVQTJY7IQYZMYCUY6VSXSMXXY/ Code of Conduct: http://python.org/psf/codeofconduct/
