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

Proposal: Adding __call__ interface to containers #190

Closed
asmodehn opened this issue Jan 21, 2020 · 1 comment
Closed

Proposal: Adding __call__ interface to containers #190

asmodehn opened this issue Jan 21, 2020 · 1 comment

Comments

@asmodehn
Copy link

How about adding a __call__() interface to pyrsistent containers ?
something like

 def __call__(self, *args):
        # call just return a new container, with more content added.
        # current one is untouched
        return v(*[k for k in self], *args)

This would , imho, enable clean python syntax integration :

# we already have simple functions for constructing containers
from pyrsistent import v

# Lets create an immutable three
three = v(1, 2, 3)

# we could, just by calling, append into the vector
assert three(4,5,6) == v(1,2,3,4,5,6)

# Still immutable three stays the same
assert three == v(1,2,3)

# to actually 'register' the change, one needs to store the new vector
six = three(4,5,6)
assert six == v(1,2,3,4,5,6)

# Incidently EmptyVector == v, because one could hypothetically do :
assert EmptyVector(1,2,3) == v(1,2,3)

I feel this adds a more "functional/lazy" feel to using immutable containers, while providing a good pythonic syntax (and maybe some simplifications in the code ?)

Not sure which container this would be suitable for however. Besides vector and map, the semantic of the container would need to somehow match the structure of python's args and kwargs, and what it means to "add" an element to the container (prepend, append?, insert at key?)

@tobgu
Copy link
Owner

tobgu commented Jan 23, 2020

Thanks for your suggestion! I'm of the opinion though that it's not obvious what "calling" a vector would result in. Although the syntax is nice in a way as presented above I think I'd rather stick with the somewhat more verbose but, to me at least, more obvious ways that are already in place.

@tobgu tobgu closed this as completed Jan 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants