Re: Backwards incompatible API change to Python schema object "properties"

["Michael A. Smith" <mi...@smith-li.com>]

 I can use a deprecation warning on those calls, sure.

On Mon, Jul 31, 2023 at 1:14 PM Ryan Skraba <ry...@skraba.com> 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 <mi...@smith-li.com> 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?