-
Notifications
You must be signed in to change notification settings - Fork 1
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
New star #9
New star #9
Conversation
It's been replaced with star
Thanks travis-ci for catching this
Codecov Report
@@ Coverage Diff @@
## dev #9 +/- ##
==========================================
- Coverage 94.93% 93.85% -1.09%
==========================================
Files 9 9
Lines 296 309 +13
Branches 27 30 +3
==========================================
+ Hits 281 290 +9
- Misses 12 15 +3
- Partials 3 4 +1
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## dev #9 +/- ##
==========================================
- Coverage 94.93% 94.15% -0.78%
==========================================
Files 9 9
Lines 296 308 +12
Branches 27 29 +2
==========================================
+ Hits 281 290 +9
- Misses 12 15 +3
Partials 3 3
Continue to review full report at Codecov.
|
call_state should always be present
This decreases code coverage because it adds a line to the code that is only executed in a fork, which codecov still isn't picking up properly. 😞 |
The culmination of a couple of weeks of experimentation, this adds the
star
metafunction decorator.star
simply calls the wrapped metafunction with*args
instead ofargs
. It's analogous tolambda args, **kwargs: metafunction(*args, **kwargs)
.Why:
Every function in python returns a single python object (
return 1, 2
is returning atuple
). That means that within a pipeline, every function after the initial function will receive only a single arg. My goal has been to find a way to allow a function to receive multiple positional arguments. There are several reasons I think this is worthwhile:It allows passing the results of multiple functions to a single function, without having to modify the receiving function's signature:
It provides a corresponding 'split' to the 'merge' that
FunctionMerge
provides. If we consider 3 separate MetaFunctionsa
,b
, andc
(presumably each consisting of multiple functions), we can merge the results of those functions withm = (a & b & c)
(the&
operator is arbitrary, we could also have used anotherFunctionMerge
). Thanks to theFunctionMerge
call signature introduced in Merge call signature #8, we can split our input, providing different arguments toa
,b
, andc
, by callingHowever, that only works if
cmp
is the first function called. Consider the case where the merge incmp
appears later in the pipeline:Even if
func1
returns an iterable, that iterable arrives in theFunctionMerge
as a single argument, and so the entire iterable is passed to each ofa
,b
, andc
.star
solves this problem by allowing us to expand the iterable before it arrives inm
.It allows us to apply this split anywhere, even if there are no operators involved. I originally tried to solve the star expansion problem using a 'broadcast operator' (
@
, introduced in Broadcast #7), but that approach doesn't work when the functions that need star expansion are within aFunctionMerge
.star
does.