That sounds like there's something going wrong, because that definitely shouldn't be the case! Although it sound like you've given up on it: if you have any example to send me in the right direction I can look into that for you. I'd love to know if there's something I can relay to the team.
You can find it in the migration guide. Let me know if you miss anything, if you'd like you can make an issue and I'll make sure to get to it before the 2.0 release!
Yes, this (as the even shorter c.colname) and the fact that you can do var= in place of assign in with_columns/agg changed my whole outlook on polars. Have been using it as my main driver for the past year.
Polars is indeed more verbose when coming from pandas, but in my experience it is an advantage for when you're reading that same code after not having touched it for months.
pandas is write-optimized, so you can quickly and powerfully transform your data. Once you're used to it, it allows you to quickly get your work done. But figuring out what is happening in that code after returning to it a while later is a lot harder compared to Polars, which is more read-optimized. This read-optimized API coincidentally allows the engine to perform more optimizations because all implicit knowledge about data must be typed out instead of kept in your head.
I don't agree that more verbose code is necessarily more readable when the shorter code looks like familiar math. All you have to do is learn how operators broadcast across array-like structures, how slicing and filtering works. Perhaps with more complicated examples the shorter code becomes harder to read after months away? Mathematicians are able to handle a lot of compact equations.
No doubt some of this comes down to preference as to what's considered readable. I never really bought that argument that regular expressions create more problems than they're worth. Perhaps I side on the expressivity end of the readability debate.
Oh I don't mean to say verbose makes it more readable by default, I agree with you on that. I mostly meant that because the API is declarative (more geared at describing the result you want instead of the operations) it is easier to understand what's going on. A side effect of that is that it might be more verbose, which is the case of Polars vs pandas.
In the end it's a personal thing which one you like the most. I do believe that if your deliverable is insights you get out of your analysis I can imagine that a less verbose API is practical to get things done quickly. But if you create pipelines that your colleagues have to quickly understand (or you in a couple of months) a read-optimized one makes more sense, even though it might take slightly more effort to write.
That's why Ritchie is very active on, and often refers to, Stackoverflow as well! Exactly to document frequent questions, instead of losing them to chat history.
Thijs, DevRel @ Polars