Is there a reason you didn't make a helper function (just a private guy) that is explicitly for properties? It looks like literally every instance you changed could have been

from .cbookimport_deprecate_prop...prop=_deprecate_prop("3.X",lambdaself:self.whatever())

instead of

from .importcbook...prop=cbook.deprecated("3.X",property(lambda:self.whatever()))

My "feeling" is that I might have not even complained about the multiline stuff it it had also been moved to the top of the class, but leaving what looks like a class variable hiding between method definitions felt funny to me.

I agree especially that in places liketexmanager this greatly reduces visual clutter.

I feel that just stashing all the deprecated properties into a single block with no blank lines in between makes it easier to ignore that block.

I'd approve if

1. the "block" was moved above__init__, where class variables are typically defined
2. fix the RendererCairo case to actually make this block easy to "see" as you're scrolling (see the one comment above)

I think in that case you wouldn'treally have to revert any of the multi-line ones to makeme happy, but in cases where you've just takenone method of a class and instead made it into a multi-line class variable definition, this might have just made this harder to understand quickly with no real benefit in terms of having things in a "block", since there's just one "thing".

Not going to die on the "these should go above__init__ hill, since I can just open a separate PR to impose my opinions about this, and I will be wanting this lambda syntax for the deprecation-spree I'm about to go on.

So feel free to ignore, but I marked everywhere where they're not currently above__init__. I would say that there is one place left where you didn't put all the deprecations into a single block, which was your original purpose I think (TextBox in widgets.py).