copy/deepcopy didn't know what to do with user objects due to custom
__new__. Since __new__ returns an existing user if possible anyway, just
have copy/deepcopy return the same user instance that is being copied.
If with_host() is called before we fully know our ident and host, we'll
set the host but keep ident as None, which breaks everything down the
line. I could've fixed this in general in users._add, but that would
require more extensive changes than this patch (aka may break other
things).
Thank you for purchasing the ACME® Commit Message Kit! We specialize in
providing the finest commit message kits. Should you find your kit not
up to your satisfaction, contact your Customer Support Representative
for a full refund.
To use this kit, please assemble the following components into your
desired commit message. Using ACME® BottomlessBits® technology, you can
use each component in the kit as many times as you'd like!
Components:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.,;'"/
This was originally done so that we wouldn't need to iterate through the (presumably large) set of users. However, when this raises, we have no idea which users actually match the criterias. By waiting until after, the traceback will actually print off the list of all potential users.
This takes a different code path because of slightly different conditions; in the first case, the ident and host are both known, and so the instance is hashable. Being hashable, it can be checked for set containment, and exactly one instance in that set will be equal (since the hash is based off of the ident and host, and the comparisons check for all non-None attributes, two instances cannot possibly be equal while having a different hash).
In the second case (the new one), however, at least the ident or the host is missing, and so the hash cannot be calculated. This means that two instances may compare equal and hash to different values (since only non-None attributes are compared), so we need to run through the entire set no matter what to make sure that one - and only one - instance in that set compares equal with the new one. We can't know in advance whether or not there is an instance that compares equal to the new one in that set, nor can we know if there are multiple instances that are going to compare equal.
The two code paths are separated so that the difference in functionality is obvious (and this commit description, as well as the comment in the code, should help with that), and that the distinction remains clear.
We don't use it, as the only places where we'd need to, it's only one channel, and the surrounding code needs to add the user to the channel and vice-versa, so that's pretty pointless.
