Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Issue #31 - Access name attribute of any type object #92

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
Feb 13, 2023
Merged

Issue #31 - Access name attribute of any type object #92

merged 2 commits into from
Feb 13, 2023

Conversation

erichare
Copy link
Contributor

@erichare erichare commented Feb 6, 2023

Addresses Issue #31 - we should access a string representation of the given object rather than assuming that the object itself can be concatenated with a string.

@BewareMyPower BewareMyPower added this to the 3.2.0 milestone Feb 7, 2023
BewareMyPower
BewareMyPower reviewed Feb 8, 2023
View reviewed changes
Copy link
Contributor

@BewareMyPower BewareMyPower left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can also migrate other changes from apache/pulsar#16459? For example, CustomEnum also concatenate enum_type and a string.

@erichare
Copy link
Contributor Author

erichare commented Feb 9, 2023

@BewareMyPower i agree about CustomEnum. I was less sure about the Array change in that PR - The array can be of primitive types, such as a str itself, right? do we need to check whether there exists a __name__ attribute, otherwise just try to coerce directly to a str if not? Basically just wasn't sure if we can always assume it'll have that attribute... the original PR seemed to be closed and requested not to merge because of that same issue

@BewareMyPower
Copy link
Contributor

do we need to check whether there exists a name attribute,

If so, we can create a helper function to return s.__name__ or fall back to str(s).

@erichare
Copy link
Contributor Author

@BewareMyPower thanks! I just pushed a new commit which tries to backport those other instances from the closed PR, using a helper function. Let me know if this looks okay.

eolivelli
eolivelli approved these changes Feb 13, 2023
View reviewed changes
Copy link

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@BewareMyPower BewareMyPower merged commit e3eed2d into apache:main Feb 13, 2023
@erichare erichare deleted the #31 branch February 15, 2023 03:08
@BewareMyPower BewareMyPower modified the milestones: 3.2.0, 3.1.0 Feb 16, 2023
BewareMyPower pushed a commit that referenced this pull request Feb 16, 2023
@erichare @BewareMyPower
Issue #31 - Access name attribute of any type object (#92)
e0b51d5 
Addresses Issue #31 - we should access a string representation of the given object rather than assuming that the object itself can be concatenated with a string.

(cherry picked from commit e3eed2d)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@BewareMyPower BewareMyPower BewareMyPower left review comments

@eolivelli eolivelli eolivelli approved these changes

Assignees

@erichare erichare

Labels
None yet
Projects
None yet
Milestone
3.1.0
Development

Successfully merging this pull request may close these issues.
3 participants
@erichare @BewareMyPower @eolivelli