This appears to be related to https://github.com/pypa/pip/pull/3225, where
pip would generate overbroad wheel names in the cache. So to proceed on
this issue, setuptools will assume that generated wheels are valid for the
specific python implementation only (eg. wheels generated for CPython will
not be valid for pypy).
Again, let me repeat that: wheels generated using setuptools are valid for
CPython only if build on CPython. This is not the current setuptools
behavior but will be for all setuptools build backend calls (I assume
legacy will remain the same).
Jacob, Paul, Donald, is everyone okay with that? And does everyone
understand the reason for this?
2017-08-30 18:29 GMT-05:00 xoviat
So while I was working on pip, I noticed a parameter called 'autobuilding' in wheel.py. What this does (I think) is that if pip decides that it needs to be enabled (which is an implementation detail not relevant here), it adds the following to the "setup.py bdist_wheel" call:
["--python-tag", python_tag]
This switches the output of the bdist_wheel filename to include something like "cp36" rather than "py36," which indicates the Python implementation. The question is this: this behavior isn't captured (I think) in the build_wheel function, possibly (probably) for good reason. So that means once everything goes through the PEP 517 protocol, pip will not be able to let setuptools know about this information. Which means that we need to decide:
Should the PEP 517 backend for setuptools assume "cp36" in python_tag OR Should the PEP 517 backend for setuptools assume "py36" in python_tag
2017-08-29 18:51 GMT-05:00 Matthew Brett
: Hi,
For me, using NotImplemented is a misuse of the singleton since I know what it's meant to be used for (and so I cringe every time I hear it brought up as a solution).
I hate to reiterate too much, but I think that you are correct here: NotImplemented is not Pythonic. It's a complete hack that I would think people would like to quarantine to the limited use case of binary operations. Even with the poorly contextualized email that Guido received, I think it was clear that he thought it wasn't appropriate outside of
case either (I don't think better context would have changed that).
Personally, I was willing to overlook that for the sake of a speedy resolution. But reading the email chain, it seems that only Thomas and Daniel are currently in favor of using NotImplemented, which is a shift from the earlier situation. So now it seems that NotImplemented is not
On Tue, Aug 29, 2017 at 8:30 PM, xoviat
wrote: that use likely to be used.
Just for the record, I thought Nathaniel's NotImplemented suggestion was a good one, and his explanation of why, was clear and convincing, but he's already accepted the alternative, of a custom error, so I don't think there's much point on going back over that.
Also just for the record, I'd like to warmly thank y'all for your great patience in this long discussion.
Cheers,
Matthew