This is a nice solution to the testing need below.

It may be more clear to create a module scope function like:

def return_none():
    return None

and then in both Python 2 and 3 make the __reduce__ return return_none, ()

I'd be curious to know how that compares from a performance point of view.

Here is a not super scientific check:

In [64]: class C: 
    ...:     def __reduce__(self): 
    ...:         return getattr, (0, '', None) 
    ...:                                                                                   

In [65]: class D: 
    ...:     def __reduce__(self): 
    ...:         return type(None), () 
    ...:                                                                                   

In [66]: def return_none(): 
    ...:     return None 
    ...: class E: 
    ...:     def __reduce__(self): 
    ...:         return return_none, () 
    ...:                                                                                   

In [67]: len(pickle.dumps(C()))                                                            
Out[67]: 39

In [68]: len(pickle.dumps(D()))                                                            
Out[68]: 31

In [69]: len(pickle.dumps(E()))                                                            
Out[69]: 31

In [70]: %timeit pickle.loads(pickle.dumps(C()))                                           
3.33 µs ± 14.8 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [71]: %timeit pickle.loads(pickle.dumps(D()))                                           
3.12 µs ± 14.3 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [72]: %timeit pickle.loads(pickle.dumps(E()))                                           
2.62 µs ± 39.3 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

Looks like return_none is almost 20% faster? Which makes sense, since it doesn't do any function calls itself. 🤔

Could you try to additionally define the method in the class scope please? Global lookups are relatively slow.

I don't think defining it as a class method will work - at least in Python 2, you can't use a class method as a constructor and will get something like:

> pickle.PicklingError: Can't pickle <function _return_none at 0x7f7b13d250c8>: it's not found as __main__._return_none

But, this works to avoid the global lookup:

def _return_none(): 
    return None 
class E: 
    def __reduce__(self, _return_none=_return_none): 
        return _return_none, () 

I think we probably shouldn't be optimizing based on the speed of pickle.loads(pickle.dumps()) - almost always if you're using pickle then you are using it in an RPC or writing it to a file. Maybe on-device RPC calls through a unix socket or something are fast enough that the speed of __reduce__ calls matters, but I think if we're optimizing for speed then copy.copy() is a better metric. When I time copy.copy, all of these classes give me approximately the same speed.

If we're really micro-optimizing this function, I'd say that copy.copy should be the benchmark for speed and len(pickle.dumps(x)) should be the benchmark for size.

That said, it would be unusual to use cache_hash for a particularly small object in the first place. For a big enough object that calculating the hash is expensive, you'd also expect it to take a while to pickle it, so an extra 200ns is going to be noise on the process.

It may be more clear to create a module scope function like:

I don't know what @hynek's plans are for Python 2 support, but I assume that it won't be too long before Python 2 is gone. I feel like it would preferable to use the built-in NoneType in Python 3 since that's already a builtin that does the exact same thing. I like the getattr hack because it doesn't leave any compatibility functions lying around as critical components of the system, at the cost of needing a comment and having the pickle be a little bigger.

The biggest downside I see to the def _return_none() approach is that the pickled object will contain a reference to attr._make._return_none, meaning it'll be larger than necessary and unnecessarily fragile in the case of pickling with one version of attr and unpickling with a different one (should this ever get refactored in the future). I think the best balance of maintainability, performance, and future-proofness might be something like:

class UnpicklableInt(int):
    if six.PY2:
        def __reduce__(self, _none_constructor=getattr, _args=(0, "", None)):
            return _none_constructor, _args
    else:
        def __reduce__(self, _none_constructor=type(None), _args=()):
            return _none_constructor, _args

I like @godlygeek's version, so I updated the code to use that. I was hoping to make _none_constructor and _args keyword-only arguments in Python 3, but that's not possible in 2/3 compatible code because it's a syntax error even in the "dead code" branches. Alas.

I don't know what @hynek's plans are for Python 2 support, but I assume that it won't be too long before Python 2 is gone.

I wish: https://www.attrs.org/en/stable/python-2.html

However the rule is: optimize for Python 3. Make Python 2 work sOmEhOw.