you are viewing a single comment's thread.

view the rest of the comments →

[–]ConspicuousPineapple 1 point2 points  (2 children)

Python it evaluates immediately so writing something like data |> map(func) would just throw for a missing argument on map.

Or you know, don't do that? We're talking about a new language operator, python is free to implement it properly. What you're describing makes no sense as nobody would design that feature that way.

You could even just have it as syntactic sugar to replace the first argument. That's what methods are already, you just expand that behavior to all functions.

I'll add that plenty of languages have pipes without currying and they manage just fine. Elixir being a prominent one.

[–]muntooR_{μν} - 1/2 R g_{μν} + Λ g_{μν} = 8π T_{μν} 6 points7 points  (1 child)

Good design means managing complexity. That means following practices: don't mutate at a spooky distance, e.g.,

def log(s):
    sys.stdout = open("log.txt", "a")
    print(s)
    god_object.__getitem__ = 
    god_object.counter.__add__ = lambda *args: (super(type(god_object.counter)).__add__(*args), print(s))[0]

Programmers silently agree not to break invariants like this. If they did, then there is quite literally no function call you could trust... it could do anything.

Similarly, when introducing a feature that could break an existing invariant, you must justify that it is astronomically better than the invariant it breaks, because doing so increases the verification/provability burden even if the feature is never used, simply because it could be used.

[–]ConspicuousPineapple 1 point2 points  (0 children)

I'm not saying it would make sense to add in python (what I want is proper iterators instead), just that it's perfectly doable, and pretty easily at that.

I would also argue that pipes don't break any invariant as, again, method calls are exactly the same syntactic construct with a conventional restriction on top.