RE: Subtracting dates to get hours and minutes

[Gronicus]

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: Tuesday, December 13, 2022 11:20 PM
To: python-list@python.org
Subject: Re: Subtracting dates to get hours and minutes

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 items to be treated as individual arguments. So:

Startt = datetime.datetime(2022, 12, 13,  5,  3, 30)
st1 = (2022, 12, 13,  5,  3, 30)
dts1 = datetime.datetime(*st1)  # NOT datetime.datetime(st1)
dts1 == Startt  # True

On 12/13/2022 10:43 PM, Gronicus@SGA.Ninja wrote:
>   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?
> 
> #-
> 
> import datetime
> #=
> # Test A   Hard coded Date/Time
> Startt = datetime.datetime(2022, 12, 13,  5,  3, 30) Stopp =  
> datetime.datetime(2022, 12, 12, 21, 15, 30)
> 
> # =
> # Test B   Date/Time data as a variable
> #Startt = (2022, 12, 13,  5,  3, 30)
> #Stopp =  (2022, 12, 12, 21, 15, 30)
> 
> #Startt = datetime.datetime(Startt)
> #Stopp =  datetime.datetime(Stopp)
> 
> # =
> c = Startt - Stopp
> minutes = c.total_seconds() / 60
> minutes = c.seconds / 60
> hours = 0
> 
> while (minutes > 59):
>  minutes = minutes - 60
>  hours += 1
> minutes = round(minutes)
> print()
> print ("   Hours =  <" + str(hours) + ">")
> print (" Minutes =  <" + str(minutes) + ">")
> 
> # 
> --
> ---
> 

--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Subtracting dates to get hours and minutes

[Thomas Passin]

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 items to be treated as individual arguments. So:


Startt = datetime.datetime(2022, 12, 13,  5,  3, 30)
st1 = (2022, 12, 13,  5,  3, 30)
dts1 = datetime.datetime(*st1)  # NOT datetime.datetime(st1)
dts1 == Startt  # True

On 12/13/2022 10:43 PM, Gronicus@SGA.Ninja wrote:

  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?

#-
import datetime
#=
# Test A   Hard coded Date/Time
Startt = datetime.datetime(2022, 12, 13,  5,  3, 30)
Stopp =  datetime.datetime(2022, 12, 12, 21, 15, 30)

# =
# Test B   Date/Time data as a variable
#Startt = (2022, 12, 13,  5,  3, 30)
#Stopp =  (2022, 12, 12, 21, 15, 30)

#Startt = datetime.datetime(Startt)
#Stopp =  datetime.datetime(Stopp)

# =
c = Startt - Stopp
minutes = c.total_seconds() / 60
minutes = c.seconds / 60
hours = 0

while (minutes > 59):
 minutes = minutes - 60
 hours += 1
minutes = round(minutes)
print()
print ("   Hours =  <" + str(hours) + ">")
print (" Minutes =  <" + str(minutes) + ">")

# -



--
https://mail.python.org/mailman/listinfo/python-list

RE: Subtracting dates to get hours and minutes

[Gronicus]

 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?

#-
import datetime
#=
# Test A   Hard coded Date/Time
Startt = datetime.datetime(2022, 12, 13,  5,  3, 30) 
Stopp =  datetime.datetime(2022, 12, 12, 21, 15, 30) 

# =
# Test B   Date/Time data as a variable
#Startt = (2022, 12, 13,  5,  3, 30)
#Stopp =  (2022, 12, 12, 21, 15, 30)

#Startt = datetime.datetime(Startt)
#Stopp =  datetime.datetime(Stopp)

# =
c = Startt - Stopp 
minutes = c.total_seconds() / 60
minutes = c.seconds / 60
hours = 0

while (minutes > 59):
minutes = minutes - 60
hours += 1
minutes = round(minutes)
print()
print ("   Hours =  <" + str(hours) + ">")
print (" Minutes =  <" + str(minutes) + ">")

# -

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

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 SQLite can be
configured, like the OP actually asked for.

I'm not advocating for one above the other, I think they complement each 
other. Having the option to change SQLite's behavior is clearly the 
better solution if/when that happens (and is released and available in 
our development environments), but that doesn't mean there's no value in 
having a workaround here and now.


--
"Most quotes are misattributed"
-- Einstein

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Chris Angelico]

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 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 identifiers that are
> > > >allowed to contain special characters.
> > > Or that are equal SQL keywords, which can be a reason to double-quote
> > > them. SQL engines sometimes add new keywords; explicitly marking string
> > > literals as string literals prevents future conflicts and confusion.
> > >
> > > 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 in MS Access and SQL Server, `` is used in MySQL) but both work in
> > > SQLite. That should prevent any ambiguity and confusion, if it doesn't
> > > bother you too much that it's not standard SQL.
> > >
> >
> > Why not just use "identifier" which is standard SQL?
>
> If you accidentally type [identifire] or `identifire`, SQLite will
> produce an unknown identifier error, alerting you immediately to your typo.
> If you accidentally type "identifire", SQLite will silently treat it as
> a string literal instead of an identifier, causing more difficult to
> diagnose problems.
>

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 SQLite can be
configured, like the OP actually asked for.

Yeah. Let's not do the wrong thing.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

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 to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

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 in MS Access and SQL Server, `` is used in MySQL) but both work in
> > SQLite. That should prevent any ambiguity and confusion, if it doesn't
> > bother you too much that it's not standard SQL.
> >
>
> Why not just use "identifier" which is standard SQL?

If you accidentally type [identifire] or `identifire`, SQLite will
produce an unknown identifier error, alerting you immediately to your typo.
If you accidentally type "identifire", SQLite will silently treat it as
a string literal instead of an identifier, causing more difficult to
diagnose problems.

Example:

-- Preparation:
sqlite> create table foo ("columna" text, "columnb" text);
sqlite> insert into foo values ("xyzzy", "xyzzy");

-- Variant with "":
sqlite> select count(*) from foo where "columna" = "colummb";
0

Not at all at first sight clear why there seem to be no matching rows, 
if you even notice straightaway that the result is not correct.


-- Variant with []:
sqlite> select count(*) from foo where [columna] = [colummb];
Error: no such column: colummb

Immediately clear that there is a problem, and what the problem is.


--
"In the old days, writers used to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

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 that they
> > >“should” have, because of this double-quoted string issue.
> >
> >In standard SQL, double quotes denote identifiers that are
> >allowed to contain special characters.
> Or that are equal SQL keywords, which can be a reason to double-quote
> them. SQL engines sometimes add new keywords; explicitly marking string
> literals as string literals prevents future conflicts and confusion.
>
> 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 in MS Access and SQL Server, `` is used in MySQL) but both work in
> SQLite. That should prevent any ambiguity and confusion, if it doesn't
> bother you too much that it's not standard SQL.
>

Why not just use "identifier" which is standard SQL?


If you accidentally type [identifire] or `identifire`, SQLite will 
produce an unknown identifier error, alerting you immediately to your typo.
If you accidentally type "identifire", SQLite will silently treat it as 
a string literal instead of an identifier, causing more difficult to 
diagnose problems.


--
"In the old days, writers used to sit in front of a typewriter and stare out of
the window. Nowadays, because of the marvels of convergent technology, the thing
you type on and the window you stare out of are now the same thing.”
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list

Re: Top level of a recursive function

[Michael F. Stemper]

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:
   return "(" + x + ")"


def rest( s ):
 return "(" + s[ 0 ] +( rest( s[1:] ) if len( s )> 1 else '' )+ ')'

def nest( s ):
 return( s[ 0 ] if s else '' )+( rest( s[1:] )if len( s )> 1 else '' )


Hey, that's slick! And if I define rest within nest, it's not going
to be externally accessible.

Thanks

--
Michael F. Stemper
No animals were harmed in the composition of this message.
--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Chris Angelico]

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 double-quoted string issue.
> >
> >In standard SQL, double quotes denote identifiers that are
> >allowed to contain special characters.
> Or that are equal SQL keywords, which can be a reason to double-quote
> them. SQL engines sometimes add new keywords; explicitly marking string
> literals as string literals prevents future conflicts and confusion.
>
> 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 in MS Access and SQL Server, `` is used in MySQL) but both work in
> SQLite. That should prevent any ambiguity and confusion, if it doesn't
> bother you too much that it's not standard SQL.
>

Why not just use "identifier" which is standard SQL?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

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 identifiers that are
   allowed to contain special characters.
Or that are equal SQL keywords, which can be a reason to double-quote 
them. SQL engines sometimes add new keywords; explicitly marking string 
literals as string literals prevents future conflicts and confusion.


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 in MS Access and SQL Server, `` is used in MySQL) but both work in 
SQLite. That should prevent any ambiguity and confusion, if it doesn't 
bother you too much that it's not standard SQL.


--
"I love science, and it pains me to think that to so many are terrified
of the subject or feel that choosing science means you cannot also
choose compassion, or the arts, or be awed by nature. Science is not
meant to cure us of mystery, but to reinvent and reinvigorate it."
-- Robert Sapolsky

--
https://mail.python.org/mailman/listinfo/python-list

Re: Calling pselect/ppoll/epoll_pwait

[Ian Pilcher]

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 "mapping"
signals to file descriptors.

There are a few ways to accomplish this.

1. Use a Linux signalfd.  There's at least one library out there that
   provides signalfd support to Python.

2. Use signal.set_wakeup_fd()[1].  I didn't really explore this, as it
   appears that there isn't any way to filter the signals that will be
   reported.

3. Roll your own.  This turned out to be really simple for my use case,
   which is simply to set an exit flag and wake my program up if it
   receives SIGINT or SIGTERM.

   _sel = selectors.DefaultSelector()
   _exit_flag = False
   _sig_pipe_r, _sig_pipe_w = os.pipe2(os.O_NONBLOCK | os.O_CLOEXEC)

   def _sig_handler(signum, frame):
   global _exit_flag
   _exit_flag = True
   os.write(_sig_pipe_w, b'\x00')

   _sel.register(_sig_pipe_r, selectors.EVENT_READ)
   # register other file descriptors of interest
   signal.signal(signal.SIGINT, _sig_handler)
   signal.signal(signal.SIGTERM, _sig_handler)
   while not _exit_flag:
   ready = _sel.select()
   # handle other file descriptors

[1] https://docs.python.org/3/library/signal.html#signal.set_wakeup_fd

--

Google  Where SkyNet meets Idiocracy


--
https://mail.python.org/mailman/listinfo/python-list

Re: Top level of a recursive function

[Chris Angelico]

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. 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 by itself?
> >>
> >
> > Why does it have to be the same function?
> >
> > def _sort_recursive(stuff, keys, start, end):
> >  """imagine a nice implementation of some sorting algorithm here"""
> >
> > def sort(stuff, key=None):
> >  if key:
> >  keys = [key(x) for x in stuff]
> >  else:
> >  keys = stuff
> >  return _sort_recursive(stuff, 0, len(stuff))
>
> if some support for this position is needed, this is roughly how the
> stdlib glob() function is implemented.
>

Yeah, lots of things are done that way. You'll find a variety of
naming conventions around different languages and libraries, including
"_low_FUNCTIONNAME" or "_internal_FUNCTIONNAME" etc. It's definitely
easier than trying to mess with tracking toplevel status.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Top level of a recursive function

[Mats Wichmann]

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 top level than in lower levels? Is there any way to tell
from within a function that it wasn't invoked by itself?



Why does it have to be the same function?

def _sort_recursive(stuff, keys, start, end):
 """imagine a nice implementation of some sorting algorithm here"""

def sort(stuff, key=None):
 if key:
 keys = [key(x) for x in stuff]
 else:
 keys = stuff
 return _sort_recursive(stuff, 0, len(stuff))


if some support for this position is needed, this is roughly how the 
stdlib glob() function is implemented.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Top level of a recursive function

[Chris Angelico]

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 there any way to tell
> from within a function that it wasn't invoked by itself?
>

Why does it have to be the same function?

def _sort_recursive(stuff, keys, start, end):
"""imagine a nice implementation of some sorting algorithm here"""

def sort(stuff, key=None):
if key:
keys = [key(x) for x in stuff]
else:
keys = stuff
return _sort_recursive(stuff, 0, len(stuff))

With purely recursive functions (where every call to the function
truly could have been a top-level call - a lot of mathematical
functions work out this way), it makes sense to call the
externally-callable function recursively; but for anything more messy,
it's usually easiest to make the recursive part internal, and then
have a top-level function that calls into the recursive one.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Top level of a recursive function

[Schachner, Joseph (US)]

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  
Sent: Tuesday, December 13, 2022 10:25 AM
To: python-list@python.org
Subject: Re: Top level of a recursive function

Supersedes: 

r...@zedat.fu-berlin.de (Stefan Ram) writes:
>def rest( s ):
>return "(" + s[ 0 ] +( rest( s[1:] ) if len( s )> 1 else '' )+ ')'
>def nest( s ):
>return( s[ 0 ] if s else '' )+( rest( s[1:] )if len( s )> 1 else '' )

  Below, I have tried to reduce repetitiveness a bit.

  (PS: Now, one "if" remains; less ifs are not possible
  in the case of controlled recursion.)

def rest( s ):
return '(' + nest( s )+ ')'

def nest( s ):
return s[ :1 ]+( rest( s[ 1: ])if s[ 1: ]else '' )

fred = nest


-- 
https://mail.python.org/mailman/listinfo/python-list

Top level of a recursive function

[Michael F. Stemper]

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 by itself?

I've come up with a hack to support different processing, by
use of an extra argument, as shown in this simplified example:

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:
  return "(" + x + ")"

Aside from being ugly, this lets the caller diddle with "toplevel",
which shouldn't really be externally modifiable.

Are there better ways to do this?
--
Michael F. Stemper
I refuse to believe that a corporation is a person until Texas executes one.
--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

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 client.


--
"Honest criticism is hard to take, particularly from a relative, a friend,
an acquaintance, or a stranger."
-- Franklin P. Jones

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

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

  cur.execute('SELECT name, location FROM persons WHERE name = 
"John

Doe"')

do

  cur.execute('SELECT name, location FROM persons WHERE name = ?',
('John Doe',))



That's the wrong behaviour though. According to the SQL standard, the
second query should be equivalent to this:

cur.execute("SELECT name, location FROM persons WHERE name = 'John 
Doe'")


What the OP wanted was like your first query, and proper DBMSes like
PostgreSQL will handle it accordingly. The question is how to get
SQLite3 to also do so.


From reading the SQLite3 documentation on this issue (not from 
personal experience), in fact the second form is actually what one 
wants, even if SQLite3 will usually handle the first form correctly.  
The rule is "Use single quotes for string values and double quotes for 
database names such as schema, table and column names; for backwards 
compatibility SQLite will accept double quotes for string values, but 
you may get a surprise if the string value looks like a database name."
What I missed at first is the case where you really want to use an 
identifier, not a string. Then you use double quotes, and would like to 
get an error ("unknown identifier" or something like that) in case of a 
typo, instead of the database engine silently presuming your 
wrongly-spelled identifier is a string. That case can't be solved with 
parametrized queries, and does really require the ability to enable more 
strict behavior.


+1 to expose the sqlite3_db_config() function, or maybe just a special 
case for this specific option.


--

"Honest criticism is hard to take, particularly from a relative, a friend,
an acquaintance, or a stranger."
-- Franklin P. Jones

--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Chris Angelico]

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, i.e. instead of
> >>
> >>   cur.execute('SELECT name, location FROM persons WHERE name = "John
> >> Doe"')
> >>
> >> do
> >>
> >>   cur.execute('SELECT name, location FROM persons WHERE name = ?',
> >> ('John Doe',))
> >>
> >
> > That's the wrong behaviour though. According to the SQL standard, the
> > second query should be equivalent to this:
> >
> > cur.execute("SELECT name, location FROM persons WHERE name = 'John Doe'")
> >
> > What the OP wanted was like your first query, and proper DBMSes like
> > PostgreSQL will handle it accordingly. The question is how to get
> > SQLite3 to also do so.
>
>  From reading the SQLite3 documentation on this issue (not from personal
> experience), in fact the second form is actually what one wants, even if
> SQLite3 will usually handle the first form correctly.

No, the two have distinct semantics. BOTH are valid, they just mean
different things.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[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

  cur.execute('SELECT name, location FROM persons WHERE name = "John
Doe"')

do

  cur.execute('SELECT name, location FROM persons WHERE name = ?',
('John Doe',))



That's the wrong behaviour though. According to the SQL standard, the
second query should be equivalent to this:

cur.execute("SELECT name, location FROM persons WHERE name = 'John Doe'")

What the OP wanted was like your first query, and proper DBMSes like
PostgreSQL will handle it accordingly. The question is how to get
SQLite3 to also do so.


From reading the SQLite3 documentation on this issue (not from personal 
experience), in fact the second form is actually what one wants, even if 
SQLite3 will usually handle the first form correctly.  The rule is "Use 
single quotes for string values and double quotes for database names 
such as schema, table and column names; for backwards compatibility 
SQLite will accept double quotes for string values, but you may get a 
surprise if the string value looks like a database name."



I don't use SQLite3 much so I'm not really one to judge, but maybe it
would be worth exposing the sqlite3_db_config() function to Python?
Yes, it would be more than a trivial change, but it should be
reasonably straight-forward. In order to be useful, it would probably
also need an associated IntEnum for all those lovely opaque numbers
that define the verbs.

ChrisA


--
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Chris Angelico]

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
>
>  cur.execute('SELECT name, location FROM persons WHERE name = ?',
> ('John Doe',))
>

That's the wrong behaviour though. According to the SQL standard, the
second query should be equivalent to this:

cur.execute("SELECT name, location FROM persons WHERE name = 'John Doe'")

What the OP wanted was like your first query, and proper DBMSes like
PostgreSQL will handle it accordingly. The question is how to get
SQLite3 to also do so.

I don't use SQLite3 much so I'm not really one to judge, but maybe it
would be worth exposing the sqlite3_db_config() function to Python?
Yes, it would be more than a trivial change, but it should be
reasonably straight-forward. In order to be useful, it would probably
also need an associated IntEnum for all those lovely opaque numbers
that define the verbs.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Roel Schroeven]

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 sqlite docs describe a way to disable this misfeature at compile 
time or by calling an `sqlite3_db_config` C-function, but I don’t see any way 
to do that in the python sqlite library [2].

Am I missing a way to manage this setting, or is it not available within 
python? This would be very useful to enable, so that python’s sqlite library 
will treat queries more like standard sql, instead of this particular version 
of MySQL. 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.

It doesn’t look like `sqlite3_db_config` is used within the python sqlite3 
codebase at all, so this might not be a trivial change? I only see two 
references to it in the cpython github.

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

    cur.execute('SELECT name, location FROM persons WHERE name = ?', 
('John Doe',))



--
"Life ain't no fairy tale
Just give me another ale
And I'll drink to Rock 'n Roll"
-- Barkeep (The Scabs)

--
https://mail.python.org/mailman/listinfo/python-list

Re: Does one have to use curses to read single characters from keyboard?

[Alan Gauld]

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 11/12/2022 21:07, dn wrote:
>> On 11/12/2022 23.09, Chris Green wrote:
>>> Is the only way to read single characters from the keyboard to use
>>> curses.cbreak() or curses.raw()?

>> You may like to re-ask this question over on the Python-Tutor list. The 
>> ListAdmin over there (literally) wrote the book on Python+curses...

Thanks for the plug David, but...

While my book is, I think, the only one specifically for curses with
Python, it's hardly a definitive tome on the subject, rather a
beginner's tutorial. An expanded HowTo if you like..

>> Did such research include the keyboard module?
>> https://pypi.org/project/keyboard/

There are several such modules, including a good one by Fred Lundh.
They are cross platform and probably the best solution for the
OP if he doesn't mind using a third party module. I think Fred's
was called terminal? But its been a while I normally just use curses
for anything terminal related.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sqlite3 double quote behavior

[Lars Liedtke]

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 could let it build the 
queries for you.

Of course, I know that this would mean a dependency and additional complexity. 
I just could not leave it unmentioned ;-)

Cheers

Lars


Lars Liedtke
Software Entwickler

[Tel.]  +49 721 98993-
[Fax]   +49 721 98993-
[E-Mail]l...@solute.de


solute GmbH
Zeppelinstraße 15
76185 Karlsruhe
Germany


[Logo Solute]


Marken der solute GmbH | brands of solute GmbH
[Marken]
[Advertising Partner]

Geschäftsführer | Managing Director: Dr. Thilo Gans, Bernd Vermaaten
Webseite | www.solute.de 
Sitz | Registered Office: Karlsruhe
Registergericht | Register Court: Amtsgericht Mannheim
Registernummer | Register No.: HRB 110579
USt-ID | VAT ID: DE234663798



Informationen zum Datenschutz | Information about privacy policy
https://www.solute.de/ger/datenschutz/grundsaetze-der-datenverarbeitung.php




Am 13.12.22 um 01:41 schrieb 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 sqlite docs describe a way to disable this misfeature at compile 
time or by calling an `sqlite3_db_config` C-function, but I don’t see any way 
to do that in the python sqlite library [2].

Am I missing a way to manage this setting, or is it not available within 
python? This would be very useful to enable, so that python’s sqlite library 
will treat queries more like standard sql, instead of this particular version 
of MySQL. 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.

It doesn’t look like `sqlite3_db_config` is used within the python sqlite3 
codebase at all, so this might not be a trivial change? I only see two 
references to it in the cpython github.

Thank you in advance for any suggestions,
John

1: https://www.sqlite.org/quirks.html#double_quoted_string_literals_are_accepted
2: https://docs.python.org/3/library/sqlite3.html

--
https://mail.python.org/mailman/listinfo/python-list