[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?
On Sat, 2 Oct 2021 at 12:20, Thomas Grainger wrote: > > I raised an issue about this: https://github.com/pypa/pip/issues/10530 I agree with the comment made on that issue - this isn't the right way to handle the problem. We need to encourage projects to opt into the new approach and remove the legacy path once it's no longer needed. We should *not* maintain the "old style" approach indefinitely, hiding the fact that it's no longer the correct approach by having some sort of "auto convert" logic in the tools. Doing that has the *opposite* effect to what we're trying to achieve - adoption of cleaner modern approaches will take *longer*, because we're actively allowing projects to continue using their existing approach with no consequences. Paul ___ 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/YACJ6OZ2PQ5DLGZUE2IJLYKR6M3SKAP7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?
I raised an issue about this: https://github.com/pypa/pip/issues/10530 ___ 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/HYMTJHEWY5OAWADN4IZSZT4CODSRTOCR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?
On Sat, 2 Oct 2021 at 03:27, Illia Volochii wrote: > > Hi everyone, > > ensurepip includes private copies of pip and setuptools. But PEP 453 states > that "once pip is able to run pip install --upgrade pip without needing > setuptools installed first, then the private copy of setuptools will be > removed from ensurepip in subsequent CPython releases." > https://www.python.org/dev/peps/pep-0453/#automatic-installation-of-setuptools Interesting. Pip does not need setuptools installed to upgrade itself, so a strict reading of the PEP would seem to imply that we need to remove setuptools, as you say. However, looking at things more practically, pip still needs setuptools to do "legacy" installs of source distributions (when the project does not include a `pyproject.toml`) and for editable installs of setuptools-based projects. If we stopped shipping setuptools as part of ensurepip, I imagine people would complain that we'd "broken" things. Telling them that it's not broken, all they need to do is `pip install setuptools`, and we only ever promised that the supplied pip could be used to bootstrap a full environment, doesn't seem likely to go down well IMO. (Technically, some aspects of pip don't work, or fall back to "legacy" code paths, if the `wheel` project isn't installed, so ensurepip "needs" wheel in the same sense as it "needs" setuptools, but the breakage is less significant, and people who care are used to the current situation and know what to do. So yes, that argues we could do the same to setuptools, it's just a bigger impact.) > At the moment pip itself includes a needed part of setuptools. > https://github.com/pypa/pip/tree/9c474d4862907ae220ced0fcdbd76660955ff732/src/pip/_vendor/pkg_resources That's internal to pip, and the pip code that uses that, does not need an externally-supplied setuptools. > I experimented with modifying ensurepip in the main branch not to install > setuptools, and then used it to install pip. It worked fine. > Then I run `./python -m pip install --upgrade pip`, and it upgraded pip > successfully. > > Does this mean that we can drop the copy of setuptools? IMO, it's too early to consider dropping setuptools, notwithstanding what a strict reading of the PEP says. When pip has removed more of the "legacy" code paths, this situation could change, but we're not there yet. Paul ___ 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/AM7ATX4IWLNXKG54Z34GYZ2D7RJWQUNC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should I care what -3.14 // inf produces?
On 30/09/2021 08:57, Serhiy Storchaka wrote: Decimals use a different rule than integers and floats: the modulus has the same sign as the dividend. It was discussed using this rule for floats (perhaps there is even FAQ or HOWTO for this), there are advantages of using it for floats (the result is more accurate). But the current rule (the modulus has the same sign as the divisor) is much much more convenient for integers, and having different rules for integers and floats is a source of bugs. Thanks Serhiy and Victor. I hadn't realised decimal was so different from float. So decimal is not useful as a comparator. It's not an idealisation of intended float behaviour. The question is about floor-division of two Python built-in floats, involving non-finite operands, and whether this is standardised in Python the language. I couldn't find a FAQ/HOW-TO and nothing in the IEEE standard bears directly on floor division. I found an interesting discussion (https://mail.python.org/pipermail/python-dev/2007-January/070707.html) but it is having so much trouble with finite arguments that it barely mentions extended values a float might take. Tim makes good sense as always. Observing behaviour (Windows and Linux), it is consistent now but was divergent in the past. In Python 2.7.16 (Windows): >>> -3.14 // inf nan In 3.8 (Windows and Linux) and 2.7 (Linux): >>> -3.14 // inf -1.0 I would put the change down to improving fmod conformance in MSC, rather than a Python language change. But the cause doesn't matter. The fact that both were acceptable suggests that floor division is not standardised for non-finite operands. Pragmatically, however, it is seldom a good idea to differ from CPython. A bit of extra work at run-time, to check the divsor, is not a big penalty. -- Jeff Allen ___ 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/S62T3SHVDEVW4ZWDDKSE76KFYWK5TAQT/ Code of Conduct: http://python.org/psf/codeofconduct/
