Repository navigation
Description
Use case
Arguably, it might be easier for users if an empty Dict is returned instead of None for path_parameters in APIGatewayProxyEventV2, for example.
Instead of:
@event_source(data_class=APIGatewayProxyEventV2)
def lambda_handler(event: APIGatewayProxyEventV2, context) -> None:
parameters = event.path_parameters or {}
handle(parameters["id"])it would become:
@event_source(data_class=APIGatewayProxyEventV2)
def lambda_handler(event: APIGatewayProxyEventV2, context) -> None:
handle(event.path_parameters["id"])Ultimately this approach could be followed for any return value that is either an Optional[Dict] or an Optional[List], returning an empty Dict or List instead of None in all cases:
- utilities/data_classes/api_gateway_proxy_event.py
- APIGatewayEventAuthorizer
def claims(self) -> Dict[str, Any]def scopes(self) -> List[str]
- APIGatewayProxyEvent
def multi_value_query_string_parameters(self) -> Dict[str, List[str]]def path_parameters(self) -> Dict[str, str]def stage_variables(self) -> Dict[str, str]
- RequestContextV2AuthorizerIam
def cognito_amr(self) -> List[str]
- RequestContextV2Authorizer
def jwt_claim(self) -> Dict[str, Any]def jwt_scopes(self) -> List[str]def get_lambda(self) -> Dict[str, Any]
- APIGatewayProxyEventV2
def cookies(self) -> List[str]def path_parameters(self) -> Dict[str, str]def stage_variables(self) -> Dict[str, str]
- APIGatewayEventAuthorizer
and so on...
The bottom line is: Does it matter for users to differentiate between None and an empty Dict or List for any Event Source Data Classe property? If it does for a particular one, it an exception to a rule or the rule?
This change would be backwards compatible with the previous code.
This approach was already implemented in only one place so far, as far as I could check:
- utilities/data_classes/common.py
- BaseProxyEvent
def headers(self) -> Dict[str, str]
- BaseProxyEvent
Solution/User Experience
Solution can be the same as for the headers in the BaseProxyEvent:
powertools-lambda-python/aws_lambda_powertools/utilities/data_classes/common.py
Lines 98 to 100 in 1905e4c
| @property | |
| def headers(self) -> Dict[str, str]: | |
| return self.get("headers") or {} |
Alternative solutions
No response
Acknowledgment
- This feature request meets Powertools for AWS Lambda (Python) Tenets
- Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsShipped
Activity
rubenfonseca commentedon Jun 29, 2023
Hi @ericbn thank you for sending this proposal! Two notes:
It seems to be this would be a big breaking change anyways. So we might have to open an RFC to discuss this with the larger community and consider the breaking change for v3.
ericbn commentedon Jul 11, 2023
Hi. Totally agree this is a breaking change for existing code that relies on None as a valid value. Good point. I see the change in the headers method in BaseProxyEvent was done exactly to keep backward compatibility.
I propose this change is favor of an API with multiple methods like get_query_string_value and get_header_value in BaseProxyEvent.
powertools-lambda-python/aws_lambda_powertools/utilities/data_classes/common.py
Lines 139 to 157 in 2c44207
powertools-lambda-python/aws_lambda_powertools/utilities/data_classes/common.py
Lines 159 to 186 in 2c44207
Pros:
event.query_string_parameters["foo"]orevent.query_string_parameters.get("foo")orevent.query_string_parameters.get("foo", "default_foo")in case the key is required or not, or to use other functions likefirst(event.cookies).Cons(?):
leandrodamascena commentedon Aug 17, 2023
Hello @ericbn! We've updated our roadmap and included this feature request. We are planning to release this feature in Powertools v3.
Roadmap for v3: https://docs.powertools.aws.dev/lambda/python/latest/roadmap/#v3
3 remaining items
ericbn commentedon Aug 23, 2023
Sure, I’ll wait. Makes perfect sense. Looking forward for my first contribution with a PR to the project!
heitorlessa commentedon Jun 10, 2024
Took a long time (stability/backwards compatibility) but we've started implementing for v3: #4189
ericbn commentedon Jun 10, 2024
Oi @heitorlessa. I'll be happy to work on this as a contribution to the project.
leandrodamascena commentedon Jul 29, 2024
Closed via #4606
github-actions commentedon Jul 29, 2024
This issue is now closed. Please be mindful that future comments are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.