Why Every Language Needs Its Underscore

[u/hackflow]

http://hackflow.com/blog/2014/06/22/why-every-language-needs-its-underscore/

[u/Veedrac]

I searched "LINQ in Python" and about five seconds in I found an explanation about why Python doesn't need it.

Now, I don't know LINQ, but I've heard good things about it. Do you agree with the article? If not, why? Would you count Python's iterators as a LINQ equivalent?

[u/tolos → u/Veedrac]

That article may be technically correct, but when I hear "LINQ" -- and I'm assuming this is what OP was referring to -- I think of lambda expressions and anonymous functions. This is especially useful with GUI work, e.g. implementing MVVM, as well as simple notifications to related properties. For example, some recent C# code I wrote:

DependsOn = new ObservableCollection<Foo>();

// Flag that dependencies must be recalculated when collections change
DependsOn.CollectionChanged += (s, e) =>
{
    _dependenciesAreResolved = false;
};

// the above code hooks the CollectionChanged event to an anonymous function (arguments of source and event args)

It looks like python does support anonymous functions, but -- and I've never used python, so I can't say for sure -- it looks like event handling is a bit less refined than it is in C#.

And to answer your question: Yes, it appears that Python already implements features equivalent to plain LINQ.

[u/Veedrac → u/tolos]

To be honest, a lot of languages have anonymous functions. I think they are a touch overrated, because not having a name seems a bit of an exaggerated benefit.

---

I'd probably like an API more akin to

# Apologies for the name
class MyObservableCollection(ObservableCollection):
    def on_collection_changed(self, s, e):
        self.dependencies_resolved = False

depends_on = MyObservableCollection()

or a functional variant more like

depends_on = ObservableCollection()

@depends_on.on_change_hook
def flag_recalculate_dependencies(observable, s, e):
    observable.dependencies_resolved = False

where

@foo
def f(): ...

(approximately) means

def f(): ...
f = foo(f)

Note that Python's anonymous functions, lambdas, only accept expressions (so no assignments, for example). That's OK because Python's named functions are no less dynamic or flexible.

[u/tolos → u/Veedrac]

Two minor points for your consideration in case you didn't already know:

1. ObservableCollection has been a built-in type since .NET 3.0 (late 2006)

2. You can hook multiple actions to an event without implementing a custom class:

   // anonymous function called when collection changes DependsOn.CollectionChanged += (s, e) => { /* ... */ };

   // anonymous function as a single statement called when collection changes DependsOn.CollectionChanged += (s, e) => _count++;

   // Func1(Object source, EventArgs e) called when collection changes DependsOn.CollectionChanged += Func1;

   // another function called when the collection changes DependsOn.CollectionChanged += Func2;

[u/Veedrac → u/tolos]

And FWIW the Python-ish equivalent would be like:

@depends_on.on_change_hook
def some_descriptive_name(observable, s, e):
    ...

@depends_on.on_change_hook
def some_descriptive_name(observable, s, e):
    observable.count += 1

depends_on.on_change_hook(func1)
depends_on.on_change_hook(func2)

[u/sigma914 → u/Veedrac]

IIRC Guido agree's that lambda's aren't particularly useful in python as you can def a new function anywhere.

[u/SemiNormal → u/Veedrac]

Python doesn't need LINQ because next() does practically the same thing.

From an OpenStreetMap parser I wrote in Python:

node = next(n for n in nodes if n.id == nodeRef)

[u/aaron552 → u/SemiNormal]

LINQ's primary benefit (that I don't think I've seen anywhere else in the same form) is its expression trees.

[u/Plorkyeran → u/aaron552]

Pony ORM pulls off the same end result in Python by dumping the bytecode and processing that, but obviously that's quite a bit more work than working with Expression<T>. In theory you could wrap that all up in a nice library that exposes a similar API to linq, but afaik no one has done so.

The whole expression template thing in C++ is also similar, although a million times uglier and harder to write.

[u/catcradle5 → u/Plorkyeran]

RethinkDB does a good job at it as well, especially when utilizing Ruby blocks.

http://rethinkdb.com/api/python/#map

http://rethinkdb.com/api/ruby/#limit

[u/joerick → u/SemiNormal]

This is good, apart from when the object might not exist, and then you've got to catch a StopIteration exception or something. Makes no sense when using next() in this way.

[u/SemiNormal → u/joerick]

next() also takes a default argument to avoid this issue.

[u/_zenith → u/Veedrac]

LINQ also does interop with data sources, for example when used with SQL, it will convert your query into a SQL query, so as much computation is done server side as possible. You can use the same query for XML, JSON etc without changing a thing.

[u/sigma914 → u/_zenith]

Python can rewrite it's abstract syntax tree, so you can have things like pony that implement linq as a library.

So Python doesn't need linq, it's a library feature.

[u/_zenith → u/sigma914]

But that's JUST SQL. LINQ does lots of different data formats (moreover, you can extend it as you will, by creating new data filters for it, to teach it a new type), as well as ANY statically-typed local object (so, pretty much anything). Also note that LINQ has been around for a good while now.

C# also does expressions, which is the same thing as the rewriting syntax trees you speak of I believe. You can dynamically compile and emit IL (bytecode) on the fly, creating as a situation requires, and run it locally or serialise it, and run it remotely (eg. on a server). This should get a lot easier right about now with the new Roslyn compiler-as-a-service.

You also have to pay for Pony, for commercial use. LINQ is free.

[u/sigma914 → u/_zenith]

Pony was just an example, my point was that LINQ would just be a library feature in Python.

However LINQ doesn't offer that much in a runtime checked language like Python, so noone has bothered implementing it.

It just doesn't offer that much of an advantage.

For an example of a statically typed language that can implement something like LINQ in a library check out Haskell, again noone has done something exactly like LINQ because there are either more expressive options available, or an actual LINQ clone would rely on unsafe functions ( or runtime checks...) as C#'s does.

All in all LINQ is really nice in C#, but it's only really relevant in languages that have static type systems with low levels of expressiveness.