Skip to content

Conversation

@adaminsky
Copy link
Contributor

This PR tries to make the __repr__ methods for messages and primitives more consistent in test/functional/test_framework/messages.py by making repr return a string with a valid constructor call to the message/primitive if that is possible, or returning information in angle brackets to show the internal state of the message/primitive.

Also, all hashes and other hex data is prefixed with "0x" and the correct minimum length of the hex string is set with the format string. I think the leading "0x" can be useful since then it is obvious what is an integer vs. hex. These functions are only used for logging, so this is meant to make it clearer how to reconstruct an object if necessary and what the size of the printed hex types are.

Some of the repr methods return actual executable code which could be
used to recreate the exact object and some of them just represent the
interal state of the object being printed. For the objects which do not
have a repr string that is a valid constructor call, I use angle
brackets to show that it is the internal state of the object being
printed and not a valid way to construct the object. This commit also
changes the `%` style formatting to use `.format` Python formatting and
prefixes all printed hex with "0x".
@fanquake fanquake added the Tests label Sep 5, 2020
@theStack
Copy link
Contributor

Concept ACK -- consistent formatting and more clarity w.r.t. numbers base (hex vs decimal) are definitely desirable

@fanquake fanquake requested a review from maflcko September 21, 2020 00:30
return r

def __repr__(self):
return "CAddress(nServices=%i ip=%s port=%i)" % (self.nServices,
Copy link
Member

Choose a reason for hiding this comment

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

Any reason to not allow this constructor?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems like the common pattern to create CAddress objects is to call CAddress() and then manually change time, nServices, ip, and port from their default value, so I don't see any reason why not to add these as optional arguments to the constructor. I think a couple other primitives could have their constructor take optional arguments too.

Copy link

@niVelion niVelion Jan 17, 2022

Choose a reason for hiding this comment

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

I agree it's a common pattern to, to give another example, for a CTransaction with nVersion 2 to be created by calling CTransaction() and then manually changing nVersion.

However, I think it's out of scope for this PR to change how objects are instantiated and configured.

@DrahtBot
Copy link
Contributor

DrahtBot commented Sep 28, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@DrahtBot
Copy link
Contributor

🐙 This pull request conflicts with the target branch and needs rebase.

Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".

@DrahtBot
Copy link
Contributor

There hasn't been much activity lately and the patch still needs rebase. What is the status here?
  • Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
  • Is it no longer relevant? ➡️ Please close.
  • Did the author lose interest or time to work on this? ➡️ Please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future.

@niVelion
Copy link

Concept ACK, looks like a great improvement. Happy to test and review changes after rebase.

@maflcko
Copy link
Member

maflcko commented Feb 22, 2022

Closing for now. This can be reopened any time or a new pull can be created (either by this author or another author).

@maflcko maflcko closed this Feb 22, 2022
@bitcoin bitcoin locked and limited conversation to collaborators Feb 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants