Python Forum
An unexplainable error in .format statement - but only in a larger piece of code?
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
An unexplainable error in .format statement - but only in a larger piece of code?
#1
I have a larger piece of python code, called from Apache2 on a Raspberry Pi. Python release is 3.11.4 on my Raspberry. The code snippet which creates strange behavior is:
(input data is a tuple of a dict and the result of a MariaDB query)

def jsonify(input_data):
  l_request=input_data[0]
  result=input_data[1]
  first_record=True
  for record in result.fetchall():
    if (l_request['TYP']=="LUFTE"): 
      if record[2]=="ON": oper=40
      else: oper=0
    t=record[1].strftime('%Y-%m-%d %H:%M:%S')
    if first_record:
      match l_request['TYP']:
        case "LUFTE":
          answer='[{{"ti":"{:s}","OP":{:d},"t":{:.1f},"h":{:.1f},"l":{:d}}}'.format(t,oper,record[3],record[4],record[5])
        case "TEMP":
          print (t)
          print (type(t))
          print (record[2])
          print (type(record[2]))
          answer='[{{“ti":"{:s}","t":{:.1f}}}'.format(t,record[2])      <======  generates strange extra characters !!
          print (answer)
          print (type(answer))
        case _:
          print ("jsonify no valid TYP:")
          print (l_request)
          return(1000)      
      first_record=False
    else:
      match l_request['TYP']:
        case "LUFTE":
          answer=answer+',{{"ti":"{:s}","OP":{:d},"t":{:.1f},"h":{:.1f},"l":{:d}}}'.format(t,oper,record[3],record[4],record[5]) 
        case "TEMP":
          answer=answer+',{{"ti":"{:s}","t":{:.1f}}}'.format(t,record[2])
        case _: 
          print ("jsonify 2 no valid TYP:")
          print (l_request)
          return(1000)    
  answer=answer+']'
  return(answer)  


Please look at the arrow: "<===== generates strange extra characters"

The output of the print statements of this program are (as found in the apache2 error log:
(as you can see, "t" is a timestamp and record[2] a floating point (temperature) value.
But watch the "(hex) e2,80,x9" bytes in front of the answer string - where do these come from ??
About 6 lines above the marked line, there is a similar construct, with more characters and variables which works perfect over and over again)

Output:
[Tue Sep 05 13:03:40.059054 2023] [wsgi:error] [pid 17430] [client 192.168.1.5:59518] 2023-09-05 12:59:23, referer: http://192.168.1.199/temp.html [Tue Sep 05 13:03:40.059131 2023] [wsgi:error] [pid 17430] [client 192.168.1.5:59518] <class 'str'>, referer: http://192.168.1.199/temp.html [Tue Sep 05 13:03:40.059164 2023] [wsgi:error] [pid 17430] [client 192.168.1.5:59518] 22.0, referer: http://192.168.1.199/temp.html [Tue Sep 05 13:03:40.059192 2023] [wsgi:error] [pid 17430] [client 192.168.1.5:59518] <class 'float'>, referer: http://192.168.1.199/temp.html [Tue Sep 05 13:03:40.059238 2023] [wsgi:error] [pid 17430] [client 192.168.1.5:59518] [{\xe2\x80\x9cti":"2023-09-05 12:59:23","t":22.0}, referer: http://192.168.1.199/temp.html [Tue Sep 05 13:03:40.059266 2023] [wsgi:error] [pid 17430] [client 192.168.1.5:59518] <class 'str'>, referer: http://192.168.1.199/temp.html
I also tried the code in a stand-alone program:
t="2023-09-03 16:18:31"
print (type(t))
record=21.3
print (type(record))
answer='[{{“ti":"{:s}","t":{:.1f}}}'.format(t,record)
print(answer)
print (type(answer))
which produces correct results:

Output:
<class 'str'> <class 'float'> [{“ti":"2023-09-03 16:18:31","t":21.3} <class 'str'>
I am aware that possibly some errors in the code elsewhere in the program can cause this, though in my experience this turns into another error once I change the program slightly (like e.g. adding the print statements) - this is not the case.

Is there anyone who can either shed some light on this strange behavior, or tell me how I can debug this more.

As a full reference I added the full code file as a file.

Attached Files

.py   test_wsgi_script_no_PW.py (Size: 6.41 KB / Downloads: 75)
Reply
#2
The leading double quote character is wrong. Cannot see this in the post, because the post converts the character to a ascii double quote, but you can see it in the file.
ToniE likes this post
Reply
#3
(Sep-05-2023, 12:19 PM)deanhystad Wrote: The leading double quote character is wrong. Cannot see this in the post, because the post converts the character to a ascii double quote, but you can see it in the file.

Many THANKS !!!! good eyes !!!
Reply
#4
It is obvious when you stop trying to overanalyze. Think simple. The output showed the bytes where you expect to see ". Where is the "? I knew what I was going to see before I opened the file.
Reply
#5
(Sep-05-2023, 12:34 PM)deanhystad Wrote: It is obvious when you stop trying to overanalyze. Think simple. The output showed the bytes where you expect to see ". Where is the "? I knew what I was going to see before I opened the file.

You must have had a bit of previous knowledge: that \xe2\x80\x9c is the Figure Dash in UTF-8 - I noticed that the quotation mark was gone, but never figured why it became now three bytes... And being 68 makes one sometimes sees a bit less sharp...

Anyway thanks a lot Heart ... this has cost me some hours. Debugging an apache script is time consuming always through the error.log.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
Photo Python code: While loop with if statement HAMOUDA 1 581 Sep-18-2023, 11:18 AM
Last Post: deanhystad
  First piece of code Bearwulf 2 770 Aug-02-2023, 04:03 PM
Last Post: deanhystad
  code won't advance to next statement MCL169 2 761 Apr-11-2023, 09:44 PM
Last Post: Larz60+
  Adding a subroutine to a larger program Led_Zeppelin 2 915 Jan-18-2023, 11:02 PM
Last Post: deanhystad
  Invalid format specifier Error Led_Zeppelin 2 7,861 Jul-11-2022, 03:55 PM
Last Post: Led_Zeppelin
  Error in Using INPUT statement gunwaba 1 2,094 Jul-03-2022, 10:22 PM
Last Post: deanhystad
  List Creation and Position of Continue Statement In Regular Expression Code new_coder_231013 3 1,679 Jun-15-2022, 12:00 PM
Last Post: new_coder_231013
  Date format error getting weekday value Aggie64 2 1,427 May-29-2022, 07:04 PM
Last Post: Aggie64
  Understanding a piece of code Michael1 4 1,420 Jan-20-2022, 07:14 PM
Last Post: Michael1
  Cryptic Error with import statement Led_Zeppelin 2 2,560 Jan-11-2022, 01:13 PM
Last Post: Led_Zeppelin

Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020