Being as cynical as I am, how does this play together with all the other stacking functions ;)? What I mean is, can you write to the mailing list as usual, because it is a new function, plus I think we can probably find a better name.

Another thing I think, we limit the outer scope to list/tuple explicitly anyway (not much choice there I guess), so if we add it, maybe make it N-dimensional?

Oh, about doctests... Those are not run currently, so not sure if they are sufficient, but add them as normal tests too at least. (Since I like at least some failure tests often, there probably should be a few more tests anyway)

By the way, this looks similar to bmat.

How would anyone know, none of the devs use matrices ;)

none of the devs use matrices ;)

This would explain why numpy/scipy functions related to np.matrix are so buggy :)

I think that is mostly because of the intrinsic problems with matrices if you don't want to constantly check matrices explicitly... But enough for that.

The one thing I'm not super happy with is that 1-D arrays are treated as row vectors and I personally think of them as column vectors.

Why?

They sure look like rows when printed:

In [8]: np.arange(10)
Out[8]: array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])

I updated my PR. Because of the discussion here #5605 I renamed the function to block because you basically create a block matrix. I moved the tests into a proper TestCase.

Some remarks:

• I also played with the implementation of bmat as skeleton for block. But the implementation is too complex for my liking. And block in the current form does everything I want.
• On the mailinglist we discussed more advanced versions of block but I think the current version actually versatile enough.

Feedback welcome!

@abalkin it's just my personal pet I guess :) It does not really matter for the pull request.

Do you think this is ready to be merged?

One of my new year's resolution is to get my pull requests merged. So, what do you think?

One of my new year's resolution is to get my pull requests merged. So, what do you think?

Sorry that this didn't get reviewed yet Stefan. It seems useful to multiple people and isn't hard to review, so let's make sure we have a serious look before the next release (I gave it the 1.12.0 milestone).

I can't see the forest for the trees so I talked to my rubber duck.

What do we expect? Do we want block([A, B]) to be equivalent to vstack([A, B]), i.e., should A and B be stacked in a row? Of course, right? But what about block([A, [B, C]]) then? On first glance this looks like the first example. Do we have to analyse the complete structure of the nested arrays? Should we throw an Exception there? Maybe we should enforce explicit brackets?
block([[A, B]]) and block([[A], [B, C]] are clear, but they are verbose.

If we use *args it's less verbose block(A, [B, C]) and I think it's also clear that block([A, B]) is equivalent to vstack([A, B]). (Also, when using *args the implementation is clean because *args is always a tuple where each element represents a row.)

Now, I'm actually inclined to use *args despite my general dislike of it.

@sotte Take a look at the commit message guidelines: doc/source/dev/gitwash/development_workflow.rst. You also need to squash your commits and redo the message(s), you can use git rebase -i HEAD~7 for that followed by a force push git push -f origin HEAD.

Updated in #7768, so closing this. Thanks @sotte .

@charris I guess I'm too late. Thanks a lot! Was a lot of fun...as always!