Live data from Hacker News

ButterDB

pypi.python.org

21–30 of 45 posts

Re: ButterDB

#21
post #17

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 Sec…

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.

Re: ButterDB

#22
post #4
post #2

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.

Re: ButterDB

#23
post #17

Earlier quoted context omitted.

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.

Re: ButterDB

#24
post #7

Earlier quoted context omitted.

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 trea…

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?

Re: ButterDB

#25
post #17

Earlier quoted context omitted.

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.

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

Re: ButterDB

#26
post #23

Earlier quoted context omitted.

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.

Re: ButterDB

#27
post #18
post #15

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.

Re: ButterDB

#28
post #7
post #6

Earlier quoted context omitted.

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 trea…

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.

Re: ButterDB

#29

Earlier quoted context omitted.

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.

Post reply on HN