Skip to content
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

Make addresses a class instead of a list ($50) #137

Open
MoritzS opened this issue Jun 8, 2013 · 3 comments

Comments

Projects
None yet
2 participants
@MoritzS
Copy link
Contributor

commented Jun 8, 2013

We should make a address class, that should have the methods that currently are in ejtp.address.
If it is a desired functionality, the address class could still implement the __getitem__ method so that code that assumes the address is a list will still work.

I see following advantages with doing that:

  • for converting and creating addresses you will just use methods instead of (in my opinion) ugly auxiliary methods
  • addresses themselves will be more descriptive, so a programmer will better understand how the address works while reading the source code
@campadrenalin

This comment has been minimized.

Copy link
Owner

commented Jun 8, 2013

I'm inclined to agree. This seems like a perfect fit for named tuples, if
it's supported in all our Python versions. If not, we can just go manual.
We also have to consider serialization - I'll check later if JSON can
nicely serialize arbitrary objects that provide the iteration interface.

On Sat, Jun 8, 2013 at 8:47 AM, Moritz Sichert notifications@github.comwrote:

We should make a address class, that should have the methods that
currently are in ejtp.address.
If it is a desired functionality, the address class could still implement
the getitem method so that code that assumes the address is a list
will still work.

I see following advantages with doing that:

  • for converting and creating addresses you will just use methods
    instead of (in my opinion) ugly auxiliary methods
  • addresses themselves will be more descriptive, so a programmer will
    better understand how the address works while reading the source code


Reply to this email directly or view it on GitHubhttps://github.com//issues/137
.

@campadrenalin

This comment has been minimized.

Copy link
Owner

commented Jun 8, 2013

Looks like the JSON module is compatible with namedtuples, but not arbitrary iterables. And namedtuples can be subclassed if we want anything special. All of which is supported in Python 2.6+. So this is definitely the way forward, IMHO.

http://docs.python.org/dev/library/collections.html#collections.namedtuple

@campadrenalin

This comment has been minimized.

Copy link
Owner

commented Jun 8, 2013

Bounty is $50.

http://www.freedomsponsors.org/core/issue/275/make-addresses-a-class-instead-of-a-list


(Copied from acceptance criteria)

Create a namedtuple subclass for EJTP addresses, overriding the init function such that passing in a single string as an argument will automatically JSON decode the string and use that for initialization arguments. Then replace every usage of list addresses with the new Address class, wherever the replacement isn't totally insane. If you're not sure, ask in a Github comment, discussion is fun.

rht pushed a commit to rht/EJTP-lib-python that referenced this issue Oct 26, 2014

rht
Implement Address class in ejtp/address.py
Essentially a namedtuple.
Most of the code has been implemented by @MoritzS in campadrenalin#138
Fixes campadrenalin#137.

@rht rht referenced a pull request that will close this issue Oct 26, 2014

Open

Implement Address class in ejtp/address.py #146

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.