I realized it had something to do with tupilation
The simple fix is to add the * into the original code.
Startt = datetime.datetime(*Startt)
I am not sure what "dts1 == Startt # True" does
Thank you.
-Original Message-
From: Python-list On
Behalf Of Thomas Passin
Sent:
Your problem is that datetime.datetime does not accept a tuple as an
argument. It expects an integer value for the first argument, but you
supplied a tuple. In Python, you can use a sequence (e.g., tuple or
list) the way you want by prefixing it with an asterisk. This causes
the sequence of
As is, Test A works.
Comment out Test A and uncomment Test B it fails.
In Test B, I move the data into a variable resulting with the report:
"TypeError: an integer is required (got type tuple)
How do I fix this?
Chris Angelico schreef op 13/12/2022 om 22:58:
Okay, so. exactly the same as if you use standard double quotes,
but change the configuration option. So the options are: make
everything worse for everyone by exacerbating the problem of
non-standard identifier quoting, or get this API so
On Wed, 14 Dec 2022 at 08:19, Roel Schroeven wrote:
>
> Chris Angelico schreef op 13/12/2022 om 20:01:
> > On Wed, 14 Dec 2022 at 06:00, Roel Schroeven wrote:
> > >
> > > Stefan Ram schreef op 13/12/2022 om 8:42:
> > > > "John K. Parejko" writes:
> > > > >I was just burned by this, where some
Roel Schroeven schreef op 13/12/2022 om 22:36:
sqlite> insert into foo values ("xyzzy", "xyzzy");
SQLite accepts it like that, but I really should have used single quotes
there instead of double quotes. It's a bad habit from using MySQL for
too long I guess.
--
"In the old days, writers used
Roel Schroeven schreef op 13/12/2022 om 22:18:
Chris Angelico schreef op 13/12/2022 om 20:01:
> > Perhaps it's a better idea to use [identifier] or `identifier` instead
> > though (I just learned about those on
> > https://sqlite.org/lang_keywords.html). Both are not standard SQL ([] is
> > used
Chris Angelico schreef op 13/12/2022 om 20:01:
On Wed, 14 Dec 2022 at 06:00, Roel Schroeven wrote:
>
> Stefan Ram schreef op 13/12/2022 om 8:42:
> > "John K. Parejko" writes:
> > >I was just burned by this, where some tests I’d written
> > >against an sqlite database did not fail in the way
On 13/12/2022 09.03, Stefan Ram wrote:
"Michael F. Stemper" writes:
def fred(cf,toplevel=True):
x = cf[0]
if len(cf)>1:
if toplevel:
return x + fred(cf[1:],False)
else:
return "(" + x + fred(cf[1:],False) + ")"
else:
if toplevel:
return x
else:
On Wed, 14 Dec 2022 at 06:00, Roel Schroeven wrote:
>
> Stefan Ram schreef op 13/12/2022 om 8:42:
> > "John K. Parejko" writes:
> > >I was just burned by this, where some tests I’d written
> > >against an sqlite database did not fail in the way that they
> > >“should” have, because of this
Stefan Ram schreef op 13/12/2022 om 8:42:
"John K. Parejko" writes:
>I was just burned by this, where some tests I’d written
>against an sqlite database did not fail in the way that they
>“should” have, because of this double-quoted string issue.
In standard SQL, double quotes denote
On 12/2/22 14:00, Ian Pilcher wrote:
Does Python provide any way to call the "p" variants of the I/O
multiplexing functions?
Just to close this out ...
As others suggested, there's no easy way to call the "p" variants of the
I/O multiplexing functions, but this can be worked around by
On Wed, 14 Dec 2022 at 05:01, Mats Wichmann wrote:
>
> On 12/13/22 10:36, Chris Angelico wrote:
> > On Wed, 14 Dec 2022 at 03:35, Michael F. Stemper
> > wrote:
> >>
> >> It's easy enough -- in fact necessary -- to handle the bottom
> >> level of a function differently than the levels above it.
On 12/13/22 10:36, Chris Angelico wrote:
On Wed, 14 Dec 2022 at 03:35, Michael F. Stemper
wrote:
It's easy enough -- in fact necessary -- to handle the bottom
level of a function differently than the levels above it. What
about the case where you want to handle something differently
in the
On Wed, 14 Dec 2022 at 03:35, Michael F. Stemper
wrote:
>
> It's easy enough -- in fact necessary -- to handle the bottom
> level of a function differently than the levels above it. What
> about the case where you want to handle something differently
> in the top level than in lower levels? Is
Reducing repetitiveness has made this code harder to read. I had to think about
what it is doing. It might be slightly faster, but in my opinion it is not
worth it.
--- Joseph S.
Teledyne Confidential; Commercially Sensitive Business Data
-Original Message-
From: Stefan Ram
It's easy enough -- in fact necessary -- to handle the bottom
level of a function differently than the levels above it. What
about the case where you want to handle something differently
in the top level than in lower levels? Is there any way to tell
from within a function that it wasn't invoked
Op 13/12/2022 om 15:15 schreef Roel Schroeven:
+1 to expose the sqlite3_db_config() function, or maybe just a special
case for this specific option.
Actually I'm surprised SQLite doesn't have a PRAGMA command to customize
this behavior. That would make it possible to customize from any
Op 13/12/2022 om 14:23 schreef Thomas Passin:
On 12/13/2022 4:09 AM, Chris Angelico wrote:
On Tue, 13 Dec 2022 at 19:52, Roel Schroeven
wrote:
Like Lars Liedtke this is not an exact answer to your question, but you
can side-step the issue by using parametrized queries, i.e. instead of
On Wed, 14 Dec 2022 at 00:30, Thomas Passin wrote:
>
> On 12/13/2022 4:09 AM, Chris Angelico wrote:
> > On Tue, 13 Dec 2022 at 19:52, Roel Schroeven wrote:
> >> Like Lars Liedtke this is not an exact answer to your question, but you
> >> can side-step the issue by using parametrized queries,
On 12/13/2022 4:09 AM, Chris Angelico wrote:
On Tue, 13 Dec 2022 at 19:52, Roel Schroeven wrote:
Like Lars Liedtke this is not an exact answer to your question, but you
can side-step the issue by using parametrized queries, i.e. instead of
cur.execute('SELECT name, location FROM persons
On Tue, 13 Dec 2022 at 19:52, Roel Schroeven wrote:
> Like Lars Liedtke this is not an exact answer to your question, but you
> can side-step the issue by using parametrized queries, i.e. instead of
>
> cur.execute('SELECT name, location FROM persons WHERE name = "John
> Doe"')
>
> do
>
>
Op 13/12/2022 om 1:41 schreef John K. Parejko:
Asking here before I file an improvement request issue on the python GitHub:
sqlite has a known misfeature with double-quoted strings, whereby they will be
interpreted as string literals if they don’t match a valid identifier [1]. The
note in the
On 12/12/2022 17:45, Alan Gauld wrote:
Absolutely nothing apparently!
But in practce I did pen some esponses to Davids post. However
this list seems to strip out what I've written, its happened
a few times now. Not every time but enough that I rarely post
here.
But I'll try once more...
> On
Hey,
this might be not the answer you are searching for at all, and it is only a
mitigation. But as far as I know, sqlalchemy (and other ORMs) do that for you.
I am mention sqlalchemy, because it has got a query builder as well. So you
don't have to change your DB-Layer to full ORM, but you
25 matches
Mail list logo
