HeadersCollection usability

[andreaTP]

As demonstrated in microsoft/kiota#3962 I think we are facing a usability regression.
I don't have a strong opinion on where to go from here but either:

• an extra constructor
• more methods overload, e.g.get_all that accepts also a plain Dict, or similar.

cc. @baywet

[baywet]

Thanks for reporting this, is this something you'd be willing to take on?

[andreaTP]

is this something you'd be willing to take on?

It's easy enough, yes, I can pick it up, what would be the preferred solution?

[baywet]

We'd need something that feels "natural" in python.
For example in dotnet, because it implements the IDictionary interface the collection can be initialized with the dedicated notation:

new RequestHeaders {
   {"foo":  "bar"}
};

which feels natural to a dotnet developer

In Go, that's not supported, so we have two constructors (one empty, one that accepts a map)

It needs to feel like a map/dictionary API wise.

[andreaTP]

I have been taking a closer look at this, and ... I'm not sure 😢 .

Having headers as a publicly exposed field of RequestInformation makes any change I'm attempting a breaking change and, since Python is GA, we would need to wait for version 2 to introduce it.

Other than that, HeadersCollection should, probably, not be exposed to the users at all and this change requires again breaking changes to the API.

Looking for guidance on how to proceed here, or a Python expert that can show me the way 🙂 .

[baywet]

From you initial post it sounded like all the changes you wanted to make were additional.
Can you outline what changes might be breaking?

[andreaTP]

I thought that the changes were only additional ... but when attempting to implement it I found out that either we duplicate the headers field or we have to take into account the two types everywhere with a great maintenance burden.

In either case, since the headers field is used (and mutated) in this code-base and by the user this is causing great confusion.

[baywet]

Could we imagine having:

• a private backing field that's a header collection
• a getter and setter that are union type of header collection and map/dictionary
• when the setter is called, type test the value being set, and if it's a maps, convert it to the collection
• when the getter is called, always return the collection. (to avoid a breaking change)

Thoughts?