BTW, looks like https://www.python.org/dev/peps/pep-0562/ will provide a way to deprecate the attribute w/o making it a property in 3.7.

Might be worth sticking that code snippet in as a test? Otherwise looks 👍 to me

I didn’t because I think we need to decide if Cartopy should be accessing default_params this way. Also, what is the proper way for a child locator to modify the defaults if not via this global? Finally if we don’t think this is correct why keep the global at all? It seems like a thoroughly confusing way to define the defaults.

We can probably also use a custom descritor on the class, something like

class Foo:
    
    def __get__(self, obj, objtype):
        return objtype._default_params

class Bar:
    _default_params = {'a': 'b'}
    default_params = Foo()

but I am also 👍 on reverting this for 3.1 and re-addressing in 3.2.

Will also need to remove the deprecation note.

Will also need to remove the deprecation note.

Removed the note....

The fancy workarounds to deprecate this are a bit beyond my ability. As I said, it seems that py3.7 will allow this to be deprecated in a straightforward way, so when we drop 3.6 we can do this. I think its a nice cleanup, but not worth breaking downstream packages for.

I think pep562 is about module level, not class level attributes....

I would like @timhoffm to weigh on this one way or the other.

I think the deprecation should stay and cartopy should do the much simpler

class Foo(MaxNLocator):
    def __init__(self, *, nbins=8, dms=False, **kwargs):
        super().__init__(nbins=nbins, **kwargs)  # I guess dms doesn't need to be passed up
        ...

which is the normal way to override defaults...

I’d agree but the deprecation mechanism causes an exception.

OK, we'll make the deprecation machinery better :p

Can you copy a property?

No, but you can write a class that looks like property but is also correctly triggered on class access.

Cartopy needs a .copy operation on update_params. If you can make that work then shouldn’t be a problem. I have a PR in at Cartopy for them to override defaults at init instead of on the attribute but we shouldn’t break Cartopy by changing the type of this public attribute if we can help it

@jklymak #13992 (comment) <- that is an attempt to get what @anntzer is describing to work.

I am 👍 on still deprecating this, just pushing it to 3.2 because it is relatively low-stakes to get done and relatively complex to do correctly.

Actually I already tried doing this in #12247 and this runs into #12650; I guess, sure, we could have a deprecated-property-that-warns-on-class-access and a deprecated-property-that-doesn't but I'm not sure it's really worth it, or we could just wait for cartopy to fix this, do the deprecation in the docs and kill this without in-the-code deprecation in 3.3/3.4...

did #12247 get reverted? I am confused why that did not work in this case....

Cartopy does default_params.copy() and we changed default_params from a dictionary to a property and that then fails.

#12247 got reverted in #12653 because warning when accessing on the class really gives you a lot of warnings everywhere.