Fredrik Lundh wrote:
... dynamic typing != random typing.
So true. To get a really good random typing going, you need a
cryptographically strong random number generator to feed the
application of type constructors to values during the execution
of a program. Perhaps the best way to do this is
Paul Boddie wrote:
Well, if the client is free not to bother signalling anything about
erroneous value types, one has to wonder why there's so much of a
specification.
If you read it, I think you'll notice that the committee has
managed to produce a lot of text without spending too much
ink on
Tim Chase [EMAIL PROTECTED] wrote:
To: Steve Holden [EMAIL PROTECTED]
But honestly, boss, I didn't write this code! It was my
evil alter-ego that puts VARCHAR values containing Gilbert
Sullivan lyrics into the Amount_Due CURRENCY fields!
Hence the phrase Going for a song?
I am
From: Steve Holden [EMAIL PROTECTED] wrote:
snip
These kids wi' their Oracle databases didn't know they were born. I can
remember 'avin' to optimise programs by making sure that the next
instruction were comin' under the heads of t' drum just as the last
instruction were finishing.
But yer
First of all, anyone with extensive experience in database systems
understand that validating and cleaning input is an unavoidable task.
Static typing can help identify some of the problems, but far from
all, and there is often data processing done before the data enters
the database, so it's
[EMAIL PROTECTED] wrote:
What was Richard Hipp's justification for slandering the
writers of the SQL Language Specification?
First of all, if you read the text you quoted and understand
English, you should be able to see that the author of the
text is clearly expressing an opinion, not stating
Paul Boddie wrote:
To be fair, that text originates in section 12.3, referring to input
parameters to procedures. Meanwhile, the following text (subclause
13.8, insert statement) appears to be more pertinent:
If the data type of the target identified by the i-th column name is
an exact
Magnus Lycka wrote:
Paul Boddie wrote:
To be fair, that text originates in section 12.3, referring to input
parameters to procedures. Meanwhile, the following text (subclause
13.8, insert statement) appears to be more pertinent:
If the data type of the target identified by the i-th
Gabriel Genellina wrote:
At Tuesday 5/9/2006 16:23, [EMAIL PROTECTED] wrote:
I would be surprised if they had never used ANY database. A little
thing like dynamic field typing will simply make it impossible to
migrate your Sqlite data to a *real* database.
Why not? Because it breaks the
[EMAIL PROTECTED] wrote:
But it was stated in the sqlite docs that ALL SQL databases
use static types implying that sqlite will be incompatible
with any heavy database should the need arise to migrate
upwards. The issue is not that there will be compatibilty
problems with any data migration
Mike Owens [EMAIL PROTECTED] writes:
No it doesn't. If you don't like SQLite's design decisions, write your
own embedded relational database, and stop yapping about something you
didn't lift a finger to create, but are clearly trying to benefit
from.
That's silly. The sqlite developers are
Mike Owens wrote:
Crackpot? And now we get to why I took the flamebait -- wonderfully
constructive comments such as this.
I know SQLite's author. Besides being a nice and clearly very
intelligent person, he also holds a master's degree in electrical
engineering from Georgia Tech and a PhD
Steve Holden wrote:
Sure. But if you go back to the start of the thread you'll remember the
OP was originally complaining that SQLite was being promoted in the
Python docs as SQL compliant. It clearly isn't if its response to the
insertion of a data value that conflicts with the declared
Paul Rubin wrote:
Mike Owens [EMAIL PROTECTED] writes:
No it doesn't. If you don't like SQLite's design decisions, write your
own embedded relational database, and stop yapping about something you
didn't lift a finger to create, but are clearly trying to benefit
from.
That's silly. The
On 11 Sep 2006 21:35:28 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Mike Owens wrote:
On 11 Sep 2006 18:23:50 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Can you run your car on diesel fuel?
Why not?
Because your car's specification says to use gasoline?
If
Mike Owens [EMAIL PROTECTED] writes:
It's not the job of the System Test Engineer to design things.
It's his job to find fault with everything. I just happen to be very
good at finding faults with things.
And apparently not very good at providing any constructive solutions.
As he says,
On 11 Sep 2006 23:29:28 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
But it was stated in the sqlite docs that ALL SQL databases
use static types implying that sqlite will be incompatible
with any heavy database should the need arise to migrate
upwards. The issue is not that there will
Fredrik Lundh wrote:
Steve Holden wrote:
Sure. But if you go back to the start of the thread you'll remember the
OP was originally complaining that SQLite was being promoted in the
Python docs as SQL compliant. It clearly isn't if its response to the
insertion of a data value that
Mike Owens wrote:
On 11 Sep 2006 21:35:28 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Mike Owens wrote:
On 11 Sep 2006 18:23:50 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Can you run your car on diesel fuel?
Why not?
Because your car's specification
On 12 Sep 2006 08:29:34 -0700, Paul Rubin
http://phr.cx@nospam.invalid wrote:
But no one appreciates my finding those faults.
No one appreciates the tone in which you report these alleged faults,
Your tone is not so great either.
And what would you expect after someone who has take
Paul Boddie wrote:
Fredrik Lundh wrote:
Steve Holden wrote:
Sure. But if you go back to the start of the thread you'll remember the
OP was originally complaining that SQLite was being promoted in the
Python docs as SQL compliant. It clearly isn't if its response to the
insertion of a data
Paul Boddie wrote:
To be fair, that text originates in section 12.3, referring to input
parameters to procedures.
which is the section that section 4.1 (data types) refers to for more
details on mappings between host data and SQL data. guess it depends on
how you look at the different
On 12 Sep 2006 09:31:54 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
To use your specious analogy, it represents another way of doing
things, which you admit yourself works. That's your justification for
calling Richard Hipp a crackpot?
What was Richard Hipp's justification for
Mike Owens wrote:
On 11 Sep 2006 23:29:28 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
But it was stated in the sqlite docs that ALL SQL databases
use static types implying that sqlite will be incompatible
with any heavy database should the need arise to migrate
upwards. The issue
[EMAIL PROTECTED] wrote:
So, knowing that, would you agree that
quote Python Library Reference 13.13
If switching to a larger database such as PostgreSQL or Oracle
is later necessary, the switch should be relatively easy.
/quote
is misleading if not outright untruthful?
eh? if you've
Mike Owens wrote:
On 12 Sep 2006 09:31:54 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
To use your specious analogy, it represents another way of doing
things, which you admit yourself works. That's your justification for
calling Richard Hipp a crackpot?
What was Richard
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
So, knowing that, would you agree that
quote Python Library Reference 13.13
If switching to a larger database such as PostgreSQL or Oracle
is later necessary, the switch should be relatively easy.
/quote
is misleading if not outright
On Tue, 2006-09-12 at 13:01 +0200, Fredrik Lundh wrote:
Mike Owens wrote:
Crackpot? And now we get to why I took the flamebait -- wonderfully
constructive comments such as this.
I know SQLite's author. Besides being a nice and clearly very
intelligent person, he also holds a master's
On 12 Sep 2006 10:24:00 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So, knowing that, would you agree that
quote Python Library Reference 13.13
If switching to a larger database such as PostgreSQL or Oracle
is later necessary, the switch should be relatively easy.
/quote
is
On 12 Sep 2006 10:47:22 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So you admit that Richard Hipp's characterization of SQL was
rude. And now that we've established what you are, we're just
haggling over price.
No, you've just managed to try and take the heat off of yourself. I
never
[EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
So, knowing that, would you agree that
quote Python Library Reference 13.13
If switching to a larger database such as PostgreSQL or Oracle
is later necessary, the switch should be relatively easy.
/quote
is misleading if
[EMAIL PROTECTED] wrote:
Because I can extrapolate. I *know* before even trying it that
if I export all my data from a sqlite db to a csv file and then try
to import it into Access that there will be problems if the fields
aren't static typed.
that's just the old C++/Java is better than
On 12 Sep 2006 10:24:00 -0700,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So, knowing that, would you agree that
quote Python Library Reference 13.13
If switching to a larger database such as PostgreSQL or Oracle
is later necessary, the switch should be relatively easy.
/quote
is
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
Because I can extrapolate. I *know* before even trying it that
if I export all my data from a sqlite db to a csv file and then try
to import it into Access that there will be problems if the fields
aren't static typed.
that's just the old
[EMAIL PROTECTED] wrote:
that's just the old C++/Java is better than Smalltalk/Python/Ruby
crap. we've seen it before, and it's no more true when it comes from
you than when it comes from some Java head. people who've actually used
dynamic typing knows that it doesn't mean that all objects
On 12 Sep 2006 10:47:22 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Why? I'm not requesting that dynamic typing be removed from
sqlite. I'm not even requesting that the slander in the sqlite docs
be removed. What I'm requesting is that these features of
sqlite be better presented in the
A.M. Kuchling wrote:
On 12 Sep 2006 10:24:00 -0700,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So, knowing that, would you agree that
quote Python Library Reference 13.13
If switching to a larger database such as PostgreSQL or Oracle
is later necessary, the switch should be
dynamic typing != random typing. if your program is using the
DB-API to add data to an SQLite database, who, exactly, is
inserting the values? who's producing the data? under what
circumstances would that code produce or insert arbitrarily
typed data?
Must be the code written by a Dr.
Mike Owens wrote:
On 12 Sep 2006 10:47:22 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Why? I'm not requesting that dynamic typing be removed from
sqlite. I'm not even requesting that the slander in the sqlite docs
be removed. What I'm requesting is that these features of
sqlite be
Tim Chase wrote:
dynamic typing != random typing. if your program is using the
DB-API to add data to an SQLite database, who, exactly, is
inserting the values? who's producing the data? under what
circumstances would that code produce or insert arbitrarily
typed data?
Must be the code
[EMAIL PROTECTED] wrote:
A.M. Kuchling wrote:
On 12 Sep 2006 10:24:00 -0700,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
So, knowing that, would you agree that
quote Python Library Reference 13.13
If switching to a larger database such as PostgreSQL or Oracle
is later necessary, the
On 12 Sep 2006 13:03:09 -0700,
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Ok, I appologize for saying that. Got a little carried away
by the flames.
Apology accepted; no problem.
That and fixing the broken examples.
That's also done. I fixed the executescript.py example, and tried
On Tue, 12 Sep 2006 15:54:25 -0500,
A.M. Kuchling [EMAIL PROTECTED] wrote:
(Any new changes won't get in 2.5c2, which should be
released tomorrow, but will get into 2.5final if the fixes are made by
about the 17th.)
And in fact the formatted development version no longer reflects
But honestly, boss, I didn't write this code! It was my
evil alter-ego that puts VARCHAR values containing Gilbert
Sullivan lyrics into the Amount_Due CURRENCY fields!
Hence the phrase Going for a song?
I am the very model of a modern major database,
For gigabytes of information gathered
Fredrik Lundh wrote:
Paul Boddie wrote:
To be fair, that text originates in section 12.3, referring to input
parameters to procedures.
which is the section that section 4.1 (data types) refers to for more
details on mappings between host data and SQL data. guess it depends on
how you
Paul Boddie wrote:
Don't ask me! :-) I found it awkward enough scrolling up and down an n
* 100 page plain text document formatted for a line printer in my Web
browser, let alone spending time working out the cross-references
throughout the text, all in the five to ten minutes I spent looking
Paul Boddie wrote:
Don't ask me! :-) I found it awkward enough scrolling up and down an n
* 100 page plain text document formatted for a line printer in my Web
browser, let alone spending time working out the cross-references
throughout the text, all in the five to ten minutes I spent
Tim Chase wrote:
But honestly, boss, I didn't write this code! It was my
evil alter-ego that puts VARCHAR values containing Gilbert
Sullivan lyrics into the Amount_Due CURRENCY fields!
Hence the phrase Going for a song?
I am the very model of a modern major database,
For gigabytes
[EMAIL PROTECTED] wrote:
I think an explanation of how Sqlite3 differs from SQL and
a better set of examples is still warranted.
In general, Python standard library modules that are wrappers
for third party libraries are very thinly documented, and they
should probably remain that way, because
Kay Schluehr wrote:
[EMAIL PROTECTED] wrote:
I wouldn't be at all surprised if the pysqlite author operated under that
assumption. That the Python developers didn't pick up on the issue is not
surprising. I'm not sure how many of them are (py)sqlite users, probably
relatively few.
Skip
Unfortunately, I don't think they are going to duplicate the 200 or
so page O'Reilly SQLite book as part of the help system (even if that
book is quite out-of-date; there is one skinny chapter near the end that
explains what changes will appear in the version that has been
available for
Mike Owens wrote:
I coworker pointed me to this thread.
and why it isn't SQL.
It isn't SQL simply because SQL won't let you insert text
into a numeric field.
Yup, I have to agree that's pretty crappy. (Makes mental note to limit
use of SQLite).
Ever heard of check constraints?
On 9/11/06, Steve Holden [EMAIL PROTECTED] wrote:
Sure. But if you go back to the start of the thread you'll remember the
OP was originally complaining that SQLite was being promoted in the
Python docs as SQL compliant.
Define SQL compliant. That's about as technically precise as saying
that
Mike Owens wrote:
On 9/11/06, Steve Holden [EMAIL PROTECTED] wrote:
Sure. But if you go back to the start of the thread you'll remember the
OP was originally complaining that SQLite was being promoted in the
Python docs as SQL compliant.
Define SQL compliant. That's about as technically
Mike Owens wrote:
On 9/11/06, Steve Holden [EMAIL PROTECTED] wrote:
Sure. But if you go back to the start of the thread you'll remember the
OP was originally complaining that SQLite was being promoted in the
Python docs as SQL compliant.
Define SQL compliant. That's about as technically
On 11 Sep 2006 18:23:50 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Can you run your car on diesel fuel?
Why not?
Because your car's specification says to use gasoline?
If your car has been designed to run on diesel, you shouldn't
be saying it has gasoline engine. Duh.
No but you
On 9/11/06, Steve Holden [EMAIL PROTECTED] wrote:
Furthermore, I'm not responding to Python's representation of one
thing or another. I am responding to some of the ridiculous and unfair
criticisms directed at SQLite. Whatever Python did or didn't do, or
whatever PySQLite does or doesn't
Mike Owens wrote:
On 9/11/06, Steve Holden [EMAIL PROTECTED] wrote:
Furthermore, I'm not responding to Python's representation of one
thing or another. I am responding to some of the ridiculous and unfair
criticisms directed at SQLite. Whatever Python did or didn't do, or
whatever PySQLite
Mike Owens wrote:
On 11 Sep 2006 18:23:50 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Can you run your car on diesel fuel?
Why not?
Because your car's specification says to use gasoline?
If your car has been designed to run on diesel, you shouldn't
be saying it has gasoline
At Tuesday 5/9/2006 16:23, [EMAIL PROTECTED] wrote:
I would be surprised if they had never used ANY database. A little
thing like dynamic field typing will simply make it impossible to
migrate your Sqlite data to a *real* database.
Why not? Because it breaks the relational model rules? That
Dennis Lee Bieber wrote:
Talking to myself again, I see...
Not quite. ;-)
[...]
How interesting... With MySQL/MySQLdb I did NOT get exceptions or
error results on inserting bad numeric data supplied as character string
format (ie, as read from the CSV). Instead, MySQL SILENTLY converted
Dennis Lee Bieber wrote:
Guess I lied...
On Sat, 09 Sep 2006 05:22:20 GMT, Dennis Lee Bieber
[EMAIL PROTECTED] declaimed the following in comp.lang.python:
Talking to myself again, I see...
snip
rs = cr.execute(insert into invoice_1
(CustNo,
[EMAIL PROTECTED] wrote:
I wouldn't be at all surprised if the pysqlite author operated under that
assumption. That the Python developers didn't pick up on the issue is not
surprising. I'm not sure how many of them are (py)sqlite users, probably
relatively few.
Skip
Who has reviewed
Kay Schluehr wrote:
[Quoting Marc 'BlackJack' Rintsch...]
If you are so fond of static typing, why are you using Python in the first
place? Just see it as consistency -- dynamically typed language →
dynamically typed DB columns. ;-)
I have to admit I find this bogus too. It has by no
I've made the following edits:
Index: whatsnew25.tex
===
--- whatsnew25.tex (revision 51828)
+++ whatsnew25.tex (working copy)
@@ -2116,14 +2116,16 @@
SQLite embedded database, has been added to the standard library under
Magnus Lycka wrote:
While I can understand your frustration, I think it is
important to think about the tone in our postings here.
Hydrocephalus is one of the most common birth defects,
and it's not terribly unlikely that someone who reads
this has a family member or someone else in his
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
As long as it's included in the standard library, I'm going
to use it. There is nothing wrong with the idea of a lite
database. It is very misleading, though, to claim it's SQL.
Maybe it could be renamed by changing the t in lite to k.
--
It's not a bug, it's a feature. And answered as third point in the
FAQ:
http://www.sqlite.org/faq.html#q3
I think your whole experience is based on it. Live with it or use a
real RDBMS.
If you are so fond of static typing, why are you using Python in the first
place? Just see it as
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I think your whole experience is based on it.
But shouldn't a significant feature like that be explained in the
Python manuals? Why should I go dig up Sqlite FAQs to learn what
should have been in the manuals?
I don't know, but
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I think your whole experience is based on it.
But shouldn't a significant feature like that be explained in the
Python manuals? Why should I go dig up Sqlite FAQs to learn what
should have been in the manuals?
I don't know, but
[EMAIL PROTECTED] wrote:
(snip)
But shouldn't a significant feature like that be explained
in the Python manuals?
Why should it ? It's a SQLite feature, not a Python one.
Why should I go dig up Sqlite
FAQs to learn what should have been in the manuals?
Why should you read the manuals at
Bruno Desthuilliers wrote:
[EMAIL PROTECTED] wrote:
I don't mind living with it as long as it's documented.
It is. In SQLite manual. Or do you hope the Python manual to also fully
document PostgreSQL, MySQL, Oracle, Apache, Posix, Win32 etc ?
With those other applications, you have a
Bruno Desthuilliers [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
(snip)
But shouldn't a significant feature like that be explained
in the Python manuals?
Why should it ? It's a SQLite feature, not a Python one.
You have missed the key point that, as of Python 2.5, SQLite 3 is part of
[EMAIL PROTECTED] wrote:
Probably just me. I've only been using Access and SQL Server
for 12 years, so I'm sure my opinions don't count for anything.
[...]
Ok, next issue, what the fuck are [varchar] and [decimal]?
[..]
It's still fuckin' goofy.
Language ...
regards
Steve
--
Steve
[EMAIL PROTECTED] wrote:
Probably just me. I've only been using Access and SQL Server
for 12 years, so I'm sure my opinions don't count for anything.
SQLite never pretended to be a full-blown RDBMS - just a lightweight
simple embedded database as SQL-compliant as possible. In it's category,
Marc 'BlackJack' Rintsch wrote:
In [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
But watch this: being clueless (but not stupid) is a gift I have
for troubleshooting. I tried (incorrectly) to insert another record:
cur.execute(insert into book(title, author, published) values ('Dirk
I think your whole experience is based on it.
But shouldn't a significant feature like that be explained in the
Python manuals? Why should I go dig up Sqlite FAQs to learn what
should have been in the manuals?
I don't know, but I will take a stab at a plausible explanation.
[EMAIL PROTECTED] wrote:
I think your whole experience is based on it.
But shouldn't a significant feature like that be explained in the
Python manuals? Why should I go dig up Sqlite FAQs to learn what
should have been in the manuals?
I don't know, but I will take a stab at
What I'll do is re-format my rant, suggest how *I* would do the
documentation, fix the errors I found in the examples and send it off
to the Python bug tracking as suggested in the manuals.
How's that as a plan?
That's fine. Reformat your rant as a documentation bug report
In [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
But watch this: being clueless (but not stupid) is a gift I have
for troubleshooting. I tried (incorrectly) to insert another record:
cur.execute(insert into book(title, author, published) values ('Dirk
Gently''s Holistic Detective
80 matches
Mail list logo
