lauriat

There is https://github.com/lauriat/funct which has some of those higher level functions.

Neat. There's also sc but I wanted to make something light and simple.

Thanks for the feedback! Redesigned swiss-army-knife is well put.

I’m sure Array’s not for everyone, but for some, including me it’s a nifty tool. I don’t expect people to memorise all the features of the library - the aim was to name and document each feature clearly such that finding the right method would be easy with the help of an IDE.

Fair enough. Readability is subjective but I understand the sentiment. Constructing list comprehensions of such long chained expressions can be rather tedious and error prone, though (as your example shows).

That's why the A is capitalised ;)

cheers!

I agree, and yes, the line may be a bit excessive. The idea of Arrays is not just to cram a heap of functions to a single line. The readability (at least to me) is improved even with e.g. a single map

  arr.map(func)

vs.

  list(map(func, arr))

If you're doing matrix multiplication or other math operations on fixed size sequences, you shouldn't.

If, however, you need the dynamic nature of the built-in list or functional methods with a touch of numpyness, you should give Array a spin.

Fair enough, the example is a bit exaggerated. You could implement it with comprehensions

  all(func3(y) for y in (func1(x) for x in zip(a, b)) if func2(y))

It most likely is a bit faster, but I wouldn't say it's more readable.

You can already do that with

  d.get("non_existant_key", default)

My explanation was pretty poor, let me rephrase

For example, when calling

  Array((x, y), (z, w)).index((z, w))

the following piece of code is executed

  bool(Array((x, y)).__eq__((z, w)))
  = bool(Array(False, False))
 

If __bool__ returned whether the Array is nonempty, bool(Array(False, False)) would evaluate to True and the method would wrongly return 0.

You're right that it would be more clear if __bool__ would behave similarly, but since Array computes operations element-wise, it isn't possible.

I understand the unpythonic nature of Arrays may startle some hardcore pythonistas, but ability to chain functions was one of the main reasons why I wrote the package as I find nested function calls ugly and sometimes rather hard to decipher.

Regarding the perfomance, Arrays aren't meant to be super high performing but rather a simple way to manipulate sequences. For the best performance you should go with generic python, toolz or other.

Thanks!

Good point. However setting

  def __bool__(self): return self.nonEmpty

would mess up certain methods e.g. .index for nested Arrays as __eq__ is computed elementwise and bool(Array(False, False)) would evaluate to True.

Maybe a warning would be appropriate? (as is the case with ndarrays)

Thank you for taking the time to check it out!

Naturally if you're dealing with big arrays/tensors, numpy is the best choice for operating on sequences.

However, ndarrays have downsides for certain use cases - as ndarrays are fixed size, adding elements is very slow, also they don't support functional methods (or rather you have to create a new array every time you apply e.g. a map), and ndarrays of any other type than numbers doesn't really make sense.

Many of the methods are wrappers for built-ins, but I find the syntax of Arrays cleaner than the weirdness of the builtins.

For example, while applying an async "starmap" to an Array is just a method call, with built-in lists you would have go through the whole hassle of importing both ThreadPoolExecutor and starmap, creating an executor, scheduling the function, and finally converting the result back to a list.