# \[Python API feedback\] Additional properties
**URL:** https://forum.weaviate.io/t/python-api-feedback-additional-properties/359
**Category:** General
**Created:** [July 11, 2023, 8:55pm UTC](https://forum.weaviate.io/t/python-api-feedback-additional-properties/359 "2023-07-11T20:55:34Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@jphwang](https://forum.weaviate.io/u/jphwang)
#### Post date: [July 11, 2023, 8:55pm UTC](https://forum.weaviate.io/t/python-api-feedback-additional-properties/359/1 "2023-07-11T20:55:35Z")
Hi Weaviate community - we are looking for your feedback on some **experimental** changes to the Python API.
One area is how we specify additional properties. What do you think about this proposal?
```auto
from weaviate import AdditionalProperties
results = (
client.query.get("Article", ['title'])
.with_additional(
AdditionalProperties(
vector=True,
uuid=True,
creationTimeUnix=True,
lastUpdateTimeUnix=True,
distance=True,
)
)
.with_limit(2)
.do()
)
```
This would replace:
```auto
results = (
client.query.get("Article", ['title'])
.with_additional(
["vector", "id", "creationTimeUnix", "lastUpdateTimeUnix", "distance"]
)
.with_limit(2)
.do()
)
```
We would love to get your thoughts on the idea, and the specific syntax. Let us know in the thread!
To test this out - I believe you’ll need to pull the latest version of the Python client from the [repo](https://github.com/weaviate/weaviate-python-client), and on this server:
```auto
client = weaviate.Client(
url="https://edu-demo.weaviate.network",
auth_client_secret=weaviate.AuthApiKey(api_key="learn-weaviate"),
)
```
---
### Author:  [@tsmith023](https://forum.weaviate.io/u/tsmith023)
#### Post date: [July 12, 2023, 4:43pm UTC](https://forum.weaviate.io/t/python-api-feedback-additional-properties/359/2 "2023-07-12T16:43:07Z")
Looks like a great progression towards abstracting away the underlying GraphQL protocol from the user, well done team! I like this syntax as it achieves a similar feel to the implementation that can be achieved within TypeScript like `.withAdditional({ vector: true })`.
Can it also be safely assumed that not all the kwargs need be specified? _I.e._, `AdditionalProperties(vector=True)` is valid returning only the `vector` field since the other kwargs default to `None` and are interpreted as `False`?
Finally, will this syntax be developed further to account for nested Additional Properties, like `classification` and `group` as documented [here](https://weaviate.io/developers/weaviate/api/graphql/additional-properties#classification)?
---
### Author:  [@gabriel](https://forum.weaviate.io/u/gabriel)
#### Post date: [July 13, 2023, 6:35pm UTC](https://forum.weaviate.io/t/python-api-feedback-additional-properties/359/3 "2023-07-13T18:35:19Z")
I like the change – however, is the AdditionalProperties wrapper necessary?
---
### Author:  [@Dirk](https://forum.weaviate.io/u/Dirk)
#### Post date: [July 15, 2023, 8:04am UTC](https://forum.weaviate.io/t/python-api-feedback-additional-properties/359/4 "2023-07-15T08:04:32Z")
> [@gabriel](#):
>
> however, is the AdditionalProperties wrapper necessary?
Now you’re saying it, no, not really 😅 . I’ll make a PR without it and see how it feels
---
### Author:  [@Dirk](https://forum.weaviate.io/u/Dirk)
#### Post date: [July 15, 2023, 8:32am UTC](https://forum.weaviate.io/t/python-api-feedback-additional-properties/359/5 "2023-07-15T08:32:53Z")
> [@tsmith023](#):
>
> Finally, will this syntax be developed further to account for nested Additional Properties, like `classification` and `group` as documented [here](https://weaviate.io/developers/weaviate/api/graphql/additional-properties#classification)?
yes, that is the goal. But we wanted to get some feedback for the general mechanism before implementing more
---
### Author:  [@Dirk](https://forum.weaviate.io/u/Dirk)
#### Post date: [July 15, 2023, 9:20am UTC](https://forum.weaviate.io/t/python-api-feedback-additional-properties/359/6 "2023-07-15T09:20:39Z")
[Add with\_metadata by dirkkul · Pull Request #381 · weaviate/weaviate-python-client · GitHub](https://github.com/weaviate/weaviate-python-client/pull/381) - please have a look here 🙂
I’m taking proposals for better names. In general we want to try to hide the inner workings of GQL in the basic commands