ButterDB | Hacker News Reader

ButterDB

pypi.python.org

198 pointsz_43 comments

Hey folks, I'm the author of this library.

I actually renamed it to 'butterdb' a while ago because some people found fuckitdb hard to swallow. You can check out the code here: https://github.com/Widdershin/butterdb. I have grown a bit as a programmer since then, but I appreciate any feedback you might have.

I actually used this in production against my own recommendation to run the matching for /r/longboarding's Secret Santa. All of our data came from Google Forms, so it just made sense.

Hit me up if you have any questions.

Thanks for writing this. Do you have plans to extend this to any locally stored spreadsheets? Ex: Excel, Calc (Libre and Open Office) and so on. I imagine even XML based documents would still present some vendor quirks to overcome.

I have considered it, and just opened an issue to track demand (https://github.com/Widdershin/butterdb/issues/14). I would probably use another library to handle parsing (and hopefully avoid some of those pitfalls), just like I rely on gspread to handle all Google Spreadsheets integration.

If you'd use butterdb if it had that feature, please let me know.

Thank you. I would use it right now actually as I do have some spreadsheets with Google. There are some I'd rather use locally like this and it would be just a nice extra. It would also avoid the need to maintain a network connection.

I'll definitely implement that at some point then. It's quite easy to swap out the database the model is backed by, so shouldn't be too hard.

I explored this a bit (based off of the javascript-based http://sheetjs.com/sexql/) but the biggest difficulty is that people use CSVs and excel files in completely different ways for the same general task. In particular, different people set up budget workbooks in very different ways. There are also input problems and invalid files to deal with, so even if you manage to craft a meaningful integration you'd still have to figure out how to determine the structure and fix subtle non-uniformities

lol, when I was younger I learned that you can't use names like "fuckitdb" in front of customers / business stakeholders. Some better known software packages have also changed their names: FCKeditor, Testacular

ORM Stands for Object Relational Mapper. ORMS are software packages that map objects (class instances) to relational database tables (among other relational structures) and vice versa.

So maybe I'm nitpicking here but this project is not an ORM. There is no relational database here. Also it doesn't do joins, doesn't instrument attributes, makes no effort to convert object hierarchies to flat tables, etc, etc.

This is a (de)serialization library for google spreadsheets. Not much different from a CSV, XLS or even html table (de)serializer.

It's a nice hack though and certainly got its uses.

This is totally true. I simply hadn't thought of a better way to put it than ORM. I think it could be best put as an object spreadsheet mapper.

"Adapter"?

Maybe just 'Mapper'? As it is exactly what it does - maps spreadsheets to Python objects

ORM-like?

While technically true, you can somewhat simulate relational data. It would be interesting to see if any object-relational impedance mismatches are addressed.

Keep in mind languages evolve over time and definitions change ;)

I'm surprised this was released under the MIT License. The WTFPL would be more appropriate.

http://www.wtfpl.net/

It would have been more inappropriate. Which could be the goal, I don't know.

But more seriously, it's legally risky to have anything to do with code licensed under WTFPL because it does not actually specify that you can do anything with the code without possible legal reprisals, from which no protection is offered. Probably safe to point and laugh at it, though.

Although the WTFPL website (http://www.wtfpl.net/faq/) does note somewhat ominously that it hasn't been tested in courts, it seems legitimate enough to me. Is there any evidence outside of its lack of history in court that would indicate it isn't suitable for production use?

EDIT: gnu.org also says "We do not recommend this license" ,pointing to the Apache license as providing better protection against 'patent treachery'. (https://www.gnu.org/licenses/license-list.html)

Track down what 'DannyBee has to say about WTFPL and licenses like it. There are good reasons not to use it even if you don't care what happens with your code.

I believe this is what tptacek is referring to: https://news.ycombinator.com/item?id=8104407

He's said scarier things about it in the past too, IIRC.

I think the main thing is that even if you literally don't care what the fuck happens with your code you should at least make a statement that absolves you of responsibility, such as "THIS SOFTWARE COMES WITH NO WARRANTY" etc.

Has that warranty statement ever been used successfully in any court to defend anyone against anything? I've always wondered.

And if so, then have the capital letters mattered? Would it be less legally operative if written in camel case?

The capitals are generally a response to the "conspicuous" requirement of the UCC:

(2)Subject to subsection (3), to exclude or modify the implied warranty of merchantability or any part of it the language must mention merchantability and in case of a writing must be conspicuous, and to exclude or modify any implied warranty of fitness the exclusion must be by a writing and conspicuous. Language to exclude all implied warranties of fitness is sufficient if it states, for example, that "There are no warranties which extend beyond the description on the face hereof."

I don't know if the definition of "conspicuous" has ever been tested in court, but that's the idea. I'd be interested to see it used as ammunition against clickwrap EULAs, though.

I'm annoyed we live in a world where such a thing isn't clearly implied by the licence.

If by "the world" you mean "the US", then yes.

The problem with WTFPL is that it's not clear that it lets you do the things that copyright usually prevents you from doing. In particular:

* It's not explicit that the user can redistribute the software freely.

* It's not explicit that you're free from warranty, meaning that, unlike basically all code ever written, you're on the hook for bugs and defects, just like a physical product.

Yes, it does say "do what you want," but that's not necessarily good enough for lawyers.

This is a good library for interacting with Google spreadsheets, I've written an app with it: https://github.com/burnash/gspread

Been using gspread for a couple of months. Love it.

butterdb is powered by gspread. Definitely a quality library.

I expected it to be a new NoSQL, "eventually consistent" database server.

ooo that's clever!

This was posted to the NZ Python User Group a couple of months back, where a bit of discussion around the name took place, https://groups.google.com/d/msg/nzpug/womO01rqF58/niM48Fn8QA...

I'm surprised it wasn't licensed under the WTFPL (https://en.wikipedia.org/wiki/Do_What_The_Fuck_You_Want)

This could be a really handy way to provide user friendly front ends to "real" database tables.

would be really nice to have as an sqlalchemy dialect.

Omg! wow this is insane. nice job guys! :)

i really liked fuckitdb better lol

This is a potentially useful project but I could never use it for fear of "FuckItDB" appearing in an exception call trace that a client might see.

Names don't have to mean anything, but certain names are still unacceptable.

Based on the "don't use this for anything important" note, I think that's probably intentional. If someone spends the time to build this into something production-ready, they can change the name, too.

I actually changed the name from fuckitdb to butterdb in response to valid criticisms that alleged the name excluded people.

I originally intended this library to be a joke library, hence the "don't use this for anything important". I think I will remove that bit and just improve any issues people run into.

According to this commit, the name was changed to butterdb about three months ago.

https://github.com/Widdershin/butterdb/commit/6a73c9199d53f5...

Digging on PyPI, I found the new package named butterdb. The version is bumped from .13 to .14, though that might just be the name change. In any case, it might be a good idea to change the submission to reflect the new name and the new package.

https://pypi.python.org/pypi/butterdb/0.1.4

We changed the title and URL to the new name.

Any chance we could add a single character flag/prefix to titles on the front and search pages to indicate post titles which have been changed?

> for fear of "FuckItDB" appearing in an exception call trace that a client might see.

Just wrap it with FuckIt.py (previously discussed at https://news.ycombinator.com/item?id=6858855 ) "to make sure your Python code runs whether it has any right to or not"

Reply on news.ycombinator.com