There's no linked lists. There's no sorted maps, no sorted sets, no maps that preserve insertion order, no queues, no priority queues, no bitsets. And there's no immutable collection in Python besides strings.

Meanwhile, Scala has all of that and more: https://docs.scala-lang.org/overviews/collections/overview.h...

Moreover, scala has synchronized collections that can work over multiple threads. I guess all collections work that way in Python, but that's because Python doesn't even support true thread parallelism in the first place!

Also, if we're talking about the number of methods on the collections, Scala has way way more. map/foreach/filter/foldl/foldr/option/drop/take/first/last etc etc.

There's also the list vs tuple thing. I can understand it from an efficiency point of view, but it isn't as consistent as just having one such data structure (e.g., a perl array)

I have to say though, that the thing that astonished me the most about Python is the Java-like "closures". I sort of thought it would be like Ruby, which I thought was closer to Scheme and JavaScript, and then I realized that Ruby isn't quite like them either. (I know Ruby is close with its lambdas and blocks, but it's not intuitive to me.)

This isn't necessarily to the detriment of Python (or Ruby) but just something I observed when trying to explain Java's lack of closures to someone who only knows Python.

I was in fact taking it as almost a given that Python lists were backed by arrays under the hood.

In Python, Arrays are sequence types and behave very much like lists[1] In other words, even in Python, arrays have similar semantics to Javascript Arrays not Java Arrays.

[1] https://docs.python.org/3.4/library/array.html

Moving from Scala to Python it was annoying at first.. but honestly the code is easier to read in most cases, so no complaints here.

Python: print(list(map(lambda x: x + 1, [1,2,3])))

Ruby: print [1,2,3].map {|x| x + 1}

So much more readable, easy to write, etc... Ruby keeps it consistent by making pretty much everything an object and you just call methods. Even Haskell has dot notation to chain functions since it's just so much easier to read and write...

Care to elaborate?

Python is a language about readability and conciseness first, performance second.

I would have liked to have seen `map` used in the list comp examples, as well as seeing the tests run on Python 3.

More abstractly, Historically, in computing "list" connotes pointers and "array" connotes sequential memory. The connotations imply engineering tradeoffs. [1] "List" may make more sense for a beginning programmer. It is an arbitrary context switch for programmers writing in multiple languages. Considering that one of the driving use cases of Python has been systems programming, "list" is misleading regarding performance characteristics. [2]

[1]: For example as in Scala https://docs.scala-lang.org/overviews/collections/performanc...

[2]: googling "python arrays" returns a lot of results explaining the difference between Python's Arrays and Python's Lists. "List" is "foo => spam" and "bar => eggs" Pythonism gone too far.

For ```list``` it says:

Lists implement all of the common and mutable sequence operations. Lists also provide the following additional method:

...where "common" and "mutable" are links.

Meaning: the methods of lists are strewn across three different location, four if you count the constructors above this sentence.

Though personally I really like itertools and list comprehensions. (And list comprehensions are pretty functional as well, they were inspired by haskell I blieve.)

As you clearly showed, Python doesn't have an uniform syntax to deal with this paradigm. I.e. there are lots of different constructs and, as you said, common idioms or patterns. Have you already argued with a Java programmer saying that these 'Design Pattern' are just a limitation of the language.. whereas in Python you'd probably just use a simple Dict (or whatever)? I'm sure you did. I feel the same with the idioms and patterns.

See, in Clojure (And Arc, and even Ruby), there is an uniform syntax.. whereas in Python we've got itertools, list comprehension, builtins map/filter, random builtins functino such as sorted().

I have to agree with you that Moka is not Pythonic in the There's only one way to solve a problem as we add a new way. However, Moka was created because there was so much inconsistent alternatives..

However, Moka is Pythonic in how it behaves. God knows I could have use all nifty hacks to make it behaves magically.. but I chose to take the explicit route by overriding list/dict. I could have used string interpolation for function (See http://osteele.com/sources/javascript/functional/); but instead went the Pythonic way with standard lambda functions. Maybe you are right about the operator keywords shortcut (i.e. using List().keep(operator.eg) instead of List().keep(eg=); However, I still feel it was a way to make it even easier to integrate with existing tools from the stdlib.

Lastly, you said:

    zen: flat is better than nested
    > Dict(a=1, b=2).update(c=3).rem(lambda x, y: x=='a')

This, however, is nested: # Taken directly from the itertools stdlib page. next(islice(iterable, n, None, default)

    # Here, this is not nested.. this is chained:
    def logged_user(self):
        return (self.users
                      .keep(User.is_logged) 
                      .keep(lambda u: u.is_active)
                      .map(lambda x: User.objects.get(id=x)))