Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <20131208161858.1365f2d7@bigbox.christie.dr>
References: <CA+FnnTzDjRzU65+VWnOwxfVR9FGMDgHLLmLEDOoGE0BMCptzEw@mail.gmail.com> <52A25D94.9040404@islandtraining.com> <CA+FnnTxxJc2J1SF0UHXo1DkZPdN0W5iWhOgBYzfbW1T0GtaSgg@mail.gmail.com> <CA+FnnTzBYp5Fvy1ohCySLitbL21+hHdfur9=oF4TM+Skeu-XJw@mail.gmail.com> <CA+FnnTzkHYNN_rgLaaXwvod9qGhetXRy+3v96+5+wEyhCq0LwA@mail.gmail.com> <CA+FnnTwZ3aF++ZzaAJzG0Y98usfLTge0KTzj14LfqDgh1OnsZQ@mail.gmail.com> <20131208125823.241112db@bigbox.christie.dr> <mailman.3738.1386529877.18130.python-list@python.org> <roy-E243A9.15072508122013@news.panix.com> <CA+FnnTyZzrhwkLvsY0EdvXD_PoTWK45C0=peWGWtse1uEwJC=Q@mail.gmail.com> <CA+FnnTwSKYs-RAqVT-fZpotte30+xC-oUx-qnidw_qA=uv+KSA@mail.gmail.com> <20131208161858.1365f2d7@bigbox.christie.dr>
Date: Sat, 14 Dec 2013 23:49:58 -0800
Subject: Re: Eliminate "extra" variable
From: Igor Korot <ikorot01@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.4138.1387093806.18130.python-list@python.org>
Lines: 67
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:61939

Tim,

On Sun, Dec 8, 2013 at 2:18 PM, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2013-12-08 12:58, Igor Korot wrote:
>> Also, the data comes from either SQLite or mySQL and so to eliminate
>> the difference between those engines dates are processed as strings
>> and converted to dates for the calculation purposes only.
>> Maybe I will need to refactor SQLite processing to get the dates as
>> dates and not a string, but that's probably for the future. so that
>> dates will be kept as the datetime type until the end of the
>> function. As I wrote the dates will be used as the text for the
>> plotting window axis labels and as the labels they should come out
>> as strings, hence the conversion.
>
> Sqlite can do this automatically if you tell it to upon connecting:
>
>>>> import sqlite3
>>>> conn = sqlite3.connect('x.sqlite',
> ...    detect_types=sqlite3.PARSE_DECLTYPES|sqlite3.PARSE_COLNAMES)
>>>> cur.execute("create table foo (s date);")
> <sqlite3.Cursor object at 0x7f7f31665570>
>>>> import datetime
>>>> today = datetime.date.today()
>>>> cur.execute("insert into foo(s) values (?)", (today,))
> <sqlite3.Cursor object at 0x7f7f31665570>
>>>> cur.execute("select * from foo")
> <sqlite3.Cursor object at 0x7f7f31665570>
>>>> r = cur.fetchone()
>>>> print r
> (datetime.date(2013, 12, 8),)

Interesting.
I'm using datetime rather than the date type for CREATE TABLE() command.
And when running SELECT I still see the b'1998-08-05 23:12:12' string
representation when running my program under debugger.

And it is confirmed by running this:

>>> cur.execute("CREATE TABLE foo(bar datetime);")
<sqlite3.Cursor object at 0x00E1E6A0>
>>> import datetime
>>> today = datetime.date.today()
>>> cur.execute("insert into foo(bar) values (?)", (today,))
<sqlite3.Cursor object at 0x00E1E6A0>
>>> cur.execute("select * from foo")
<sqlite3.Cursor object at 0x00E1E6A0>
>>> res = cur.fetchall()
>>> print res
[(u'2013-12-14',)]
>>>

So, I guess this is a bug in the sqlite3 python module as datetime is
legal data type on the DB engine.

Thank you.

>
>
> Note that it returns a datetime.date, the same as it was defined.
>
> -tkc
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list