Closed ponytailer closed 1 year ago
Patch coverage: 100.00
% and no project coverage change.
Comparison is base (
a4cd31c
) 98.08% compared to head (a0d165b
) 98.09%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Thanks for the interest in adding new features!
As with other new API additions, is there a pre-existing API in python (eg, itertools or functools) or related (e.g., spark or scala) that this is based on? Similarly, could the use case be satisfied by using custom registering/extend (this really should be in README.md regardless...) https://github.com/EntilZha/PyFunctional/pull/144? As with other new API additions, I'm in general hesitant to add too much, but if there is a good case for it being (1) commonly used and/or (2) difficult to replicate otherwise, then I could be convinced (e.g., I am mostly convinced about https://github.com/EntilZha/PyFunctional/pull/183/files, just need to look over it again since it looks like there was some comments on the code by others).
Aside from that, the current PyFunctional APIs are pretty functional, going from the unit test examples, source.remove_all()
looks like it happens in place, which doesn't conform to the rest of the API. As @FlavioAmurrioCS mentions, the library API is built around returning sequences that apply the changes. For example, something that would confirm to the current API style would be:
source = self.seq([1, 2, 3, 1]).map(lambda x: x)
new_source = source.remove_all([3, 100])
# new_source now doesn't have 3
Thanks for the interest in adding new features!
As with other new API additions, is there a pre-existing API in python (eg, itertools or functools) or related (e.g., spark or scala) that this is based on? Similarly, could the use case be satisfied by using custom registering/extend (this really should be in README.md regardless...) #144? As with other new API additions, I'm in general hesitant to add too much, but if there is a good case for it being (1) commonly used and/or (2) difficult to replicate otherwise, then I could be convinced (e.g., I am mostly convinced about https://github.com/EntilZha/PyFunctional/pull/183/files, just need to look over it again since it looks like there was some comments on the code by others).
Aside from that, the current PyFunctional APIs are pretty functional, going from the unit test examples,
source.remove_all()
looks like it happens in place, which doesn't conform to the rest of the API. As @FlavioAmurrioCS mentions, the library API is built around returning sequences that apply the changes. For example, something that would confirm to the current API style would be:source = self.seq([1, 2, 3, 1]).map(lambda x: x) new_source = source.remove_all([3, 100]) # new_source now doesn't have 3
OK, I understood.
remove the members which in seq.