python-noob - which container is appropriate for later exporting into mySql + matplotlib ?

rusi rustompmody at gmail.com
Sun Apr 14 07:17:28 EDT 2013


On Apr 14, 12:56 pm, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:
> On Sat, 13 Apr 2013 10:02:18 -0700, rusi wrote:
> > To the OP:
> > Steven is welcome to his views about use of databases.
>
> I haven't given any views about databases.

You are twisting "use of databases" to just "about databases"

And heres what you said:

> Using a database for such lightweight data as bookmarks is, in my
> opinion, gross overkill and adds to the complexity of Firefox. More
> complexity leads to more bugs…

Not that I would disagree with that for general databases, just for
something as atypical as sqlite.
In short, you are being hypnotized by the word 'database' and not
seeing that sqlite is a very strange instance of that species.
http://en.wikipedia.org/wiki/Etymological_fallacy
+
http://en.wikipedia.org/wiki/Accident_%28fallacy%29

> I've given my view on
> application developers -- specifically, Firefox -- using a not-quite ACID
> database in a way that is fragile, can cause data loss,

FUD
Are you saying that flat-files dont lose data?

> and adds lots
> more complexity to the application AND the end-user experience. And for
> what?

Strange argument: If I call a one line re.match(..) that hooks into
5000 arcane lines of the re module, on whose account is the complexity
-- mine or python's?

>From a programmer's POV if 10 lines of flat-file munging are reduced
to two lines of SQL its a reduction of 10 to 2.

> Simple data that would be much better in a simpler format, such as
> bookmarks.
>
> > Good to remember
> > that everyone does not agree with him. This includes the firefox devs as
> > well as python devs.
>
> I don't see what the Python devs have to do with it. They don't use
> Sqlite for Python's internals, and the fact that there is a module for
> sqlite doesn't mean squat. There's a module for parsing Sun AU audio
> files, that doesn't mean the Python devs recommend that they are the best
> solution to your audio processing and multimedia needs.

Python made a choice to include AU file support when Sun existed and
looked more respectable than MS. Today the support continues to exist
probably for backward compatibility reasons.  "The code's already
written. Why remove it?"
Sure but it has its costs -- memory footprint, sources-size etc --
which are deemed negligible enough to not bother.

Likewise python 2.5 made a choice to include sqlite. Following RoR's D
Hansson we may call it an 'opinionated choice.'  That choice implies
that the devs decided that a fixed-cost of bundling sqlite with python
is deemed better than each programmer installing/rolling-his-own etc


>
> I'm not saying that Sqlite doesn't have it's uses, although I personally
> haven't found them yet. And as for the Firefox devs, well, I'll just let
> Jamie Zawinski show their l33t des1gn ski11z in context:
>
> http://www.jwz.org/blog/2003/01/more-khtml/
>

Faulty generalization fallacy:
http://en.wikipedia.org/wiki/Faulty_generalization
Because some code in firefox is bad, every choice of firefox is bad?
[Actually I am surprised that you agree with *that example*: Would you
claim that a void returning, no-argument function is better than one
with arguments and return values?  Anyways thats really far away from
this discussion…]

To the OP:
Lets deconstruct ACID.

Consistency+Atomicity:
Lets say you write some stack code like this
  stack[top] = newvalue
  top += 1

And if you catch the machine state between the two assignments, you
will find an *inconsistent* stack because that code is *non-atomic*
Should you bother? Yes if you have concurrency, no if not.

Likewise Isolation is vacuously guaranteed if you are the sole guy
running your code.

As for Durability, if you randomly turn off your machine when your
program is running, yes you may lose the results of your program. You
may lose much else!

IOW if you are alone on your machine, all discussion of ACID is moot



More information about the Python-list mailing list