-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
consider renaming the "id" parameter for constructs (reserved word in Python) #3203
Comments
Hi @bverhoeve, thanks for submitting this request! We will look into this and someone will update this issue when there is movement. |
@eladb Look through the linked issues, I cannot see any discussion of this request, it appears to have been closed with no discussion. It'd be great to understand the motivations behind not doing this. |
I just tested this with CDK 2.0.0 and the sample-app, and looks like they have renamed it to 'construct_id'. class HelloCdkStack(Stack): |
@bazd that may be the case in the sample application, but the actual CDK constructs themselves still use the keyword
|
Yes, cheers for clarifying. They haven't addressed it at all which is disappointing considering v2 has just been released. |
Note: for support questions, please first reference our documentation, then use Stackoverflow. This repository's issues are intended for feature requests and bug reports.
I'm submitting a ...
What is the current behavior?
To create a new
Construct
(or any otherResource
) using CDK, the constructor in Python has the following syntax:The
id
parameter serves as a unique id for CloudFormation. Naming a parameterid
in Python is not really good practice, sinceid()
is a built-in function in the Python standard library, which represents the address of the object in memory in CPython. (see https://docs.python.org/3/library/functions.html#id)I think this could lead to potentials errors down the line for users that use the Python variant of CDK, since the
id
parameter could clash with theid()
function.What is the expected behavior (or behavior of feature suggested)?
If possible, renaming the
id
parameter to something likeidentifier
orcdk_id
would avoid having this parameter clash with the built-inid()
function.What is the motivation / use case for changing the behavior or adding this feature?
Clashes with Python standard library built-in functions.
Please tell us about your environment:
Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. associated pull-request, stackoverflow, gitter, etc)
The text was updated successfully, but these errors were encountered: