I can use a deprecation warning on those calls, sure.
On Mon, Jul 31, 2023 at 1:14 PM Ryan Skraba <[email protected]> wrote: > > Hello! I think this sounds alright to me -- I noticed that your draft > PR didn't delete the get_/set_props methods. Is there a mechanism we > can use to mark them as deprecated for the length of one major release > before removing them? > > I have no objection to improving the Python API :D Your PR is pretty > readable! > > All my best, Ryan > > On Sat, Jul 29, 2023 at 2:02 AM Michael A. Smith <[email protected]> wrote: > > > > Please take a look at AVRO-3816. I'm proposing a backwards > > incompatible change to the python schema implementation. So far I have > > a PR in draft that I believe _is_ backwards-compatible, but is just a > > step on the way - it doesn't solve the problem entirely. > > > > I'd like to get to the following advantages: > > > > 1. The standard and canonical properties are typed, able to benefit > > both core developers and api users. > > 2. The standard and canonical properties are slotted > > (https://docs.python.org/3/reference/datamodel.html#slots), providing > > a space savings when only standard attributes are in use. > > 3. Custom properties are part of the schema instance's __dict__ > > (dunder-dict) attribute, so standard python introspection tools like > > dir() and attribute access just work. > > > > To clarify, I don't think this will be backwards incompatible for > > people who just use the python implementation. The only > > incompatibility here is that I'm proposing to get rid of a handful of > > public methods like get_prop and set_prop, and change the underlying > > implementation. If any API users are directly accessing those methods, > > that will need to change. > > > > What do you think?
