First, quickly, the "wrong problem" is "it takes too much boilerplate to get set up with a postgres database in Python." For my money it's wrong because:

• psycopg already provides all the cursor stuff, and although the api isn't as good, it isn't actually a lot of boilerplate
• typical programs that require pg (which has setup, admin, etc involved) are large compared to this boilerplate
• typical db using programs that are small are either part of a larger project or not using pg (eg. this library would make a ton more sense if it targetted sqlite3)

Now, you're implying criticisms of this library are meritless because they are either:

• populist 'cool-to-hate' bandwaggoning
• a repetition of how a more successful library by the same author was received ("No wireless. Less space than a Nomad. Lame")

The 1st may be true to some extent, and it's something I don't like either; we should be more supportive of our peers and of people willing to put time and effort into contributing to open source. However, I see a lot of people ITT suspicious of records on technical grounds, so I think there's more there. The 2nd is simply not true of how requests was received.

In the end, the actual context for this is:

• the author is a very experienced, respected Python programmer
• the library is saddled with a presumptuous tagline

I think people, especially people who work on database code in Python, are right to take "SQL for Humans" as implicit criticism of their work (and it's why I've publically said that it's bad for the community multiple times). Since records seems to greatly misunderstand the technical motivations behind the way these libraries are written, I think it's fine to explain how and why it's not an improvement over what's already available.

This isn't to say that records has no valid use case; in fact, it seems ideal for very small scripts (data export basically, warehouse type stuff) and for interactive environments, which might have been its entire raison d'être in the first place.