Re: [Tutor] String module; Count
[EMAIL PROTECTED] wrote think), but since I'm new to this thing, I thought I'd do the safe thing and try a second time. I personally didn't see the earlier one so can't say if it got here or not. But I'll throw in some comments below. But first I will say that you seem to be going out of your way to make easy things hard! CODE: def conversion(n): b = '' while n 0: So this returns the empty string when n is negative. Is that really what you want? r = n%2 n = n/2 r = str(r) b = r+b return b No real comments other than you might consider putting the code to pad with zeros in here. Then in the main code you only need to convert the leftmost bit to 1 if negative... In fact you could move that here too sonce arguably its part of conversion... def signed_mag(): n = int(raw_input(Please enter a signed integer: )) bits = int(raw_input(Please enter the number of bits: )) count = conversion(n).count(0) + conversion(n).count(1) \ count = len(conversion(n)) But recall from above that conversion(n) returns an empty string for negative numbers. Also to save calling conversion(n) multiple times you could introduce a new variable to store the result. #count the amount of digits to know how many 0s to add append_zeros = bits - count if bits - 1 count: print Out of range. else: if n 0: n = abs(n) Now you change n so that conversion(n) will now work on negative inputs... if append_zeros 0: print -n, is encoded as,1+(append_zeros-4)*0 \ +conversion(n),in Signed Magnitude. This confused me, why are you subtracting 4? Surely you just want to change a single bit? elif n 0: if append_zeros 0: print n,is encoded as,0 + (append_zeros-1)*0 \ +conversion(n),in Signed Magnitude. And why subtract 1 then add a 0? Why not just append_zeros*0 else: print That is not an valid signed interger. Why is zero not a valid signed integer? I know the problem is at the '(append_zeros-4)' bit, but I'm not sure what to change/add. Thanks in advance. I think a problem may also be in the fact that the first call to conversion(n) returns whereas subsequent calls return a bit pattern. In general it would be better to get your conversion function to handle all of the bit generation , padding and signing of the number. That only leaves the presentation logic outside in signed_mag() HTH, -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] calling a variable name
Bryan Fodness [EMAIL PROTECTED] wrote
I want to get a variable name dependent on another variable.
Thats usually a bad idea, but...
I have tried,
'fs' + str(int(round(unblockedFS))) for fs13
I have no idea what you think this will do.
It gives a syntax error for me, which is what I expected.
and I get an invalid literal.
Can you post real code and real error messages please?
If I code in the fs13, everything works. Is
it possible to do this?
I'm not sure because I'm not sure what you are really
trying to do. Creating new variable names on the fly
is usually not the best approach but without a context
we can't offer an alternative. The code snippet above
is no help since it is not valid Python.
unblockedFS=13.4
for line in file('21Ex6MV_tmr.dat'):
d, fs1, fs2, fs3, fs4, fs5, fs6, fs7, fs8, fs9, fs10, fs11, fs12,
fs13,
fs14, fs15, fs16, fs17, fs18 = line.split()
BTW, Since all your variables are of the form fsNN it is probably
as easy(and less typing) to do:
fs = line.split()
and just refer to them by index (extracting d if required):
if float(d) == round(calc_depth):
if float(fs[0]) == round(calc_depth)
b = float(fs13)
b = float(fs[13])
etc...
--
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] calling a variable name
Here is the actual snippet of code
calc_depth =8.1 # which is actually d
unblockedFS = 13.4 # which is the indexed fs
for line in file('21Ex6MV_tmr.dat'):
d, fs1, fs2, fs3, fs4, fs5, fs6, fs7, fs8, fs9, fs10, fs11, fs12, fs13,
fs14, fs15, fs16, fs17, fs18, fs19, fs20, fs21, fs22, fs23, fs24, fs25,
fs26, fs27, fs28, fs29, fs30, fs31, fs32, fs33, fs34, fs35, fs36, fs37,
fs38, fs39, fs40 = line.split()
if float(d) == round(calc_depth):
print float('fs' + str(int(round(unblockedFS
On 10/22/07, Alan Gauld [EMAIL PROTECTED] wrote:
Bryan Fodness [EMAIL PROTECTED] wrote
I want to get a variable name dependent on another variable.
Thats usually a bad idea, but...
I have tried,
'fs' + str(int(round(unblockedFS))) for fs13
I have no idea what you think this will do.
It gives a syntax error for me, which is what I expected.
and I get an invalid literal.
Can you post real code and real error messages please?
If I code in the fs13, everything works. Is
it possible to do this?
I'm not sure because I'm not sure what you are really
trying to do. Creating new variable names on the fly
is usually not the best approach but without a context
we can't offer an alternative. The code snippet above
is no help since it is not valid Python.
unblockedFS=13.4
for line in file('21Ex6MV_tmr.dat'):
d, fs1, fs2, fs3, fs4, fs5, fs6, fs7, fs8, fs9, fs10, fs11, fs12,
fs13,
fs14, fs15, fs16, fs17, fs18 = line.split()
BTW, Since all your variables are of the form fsNN it is probably
as easy(and less typing) to do:
fs = line.split()
and just refer to them by index (extracting d if required):
if float(d) == round(calc_depth):
if float(fs[0]) == round(calc_depth)
b = float(fs13)
b = float(fs[13])
etc...
--
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] calling a variable name
On 10/21/07, Bryan Fodness [EMAIL PROTECTED] wrote:
I want to get a variable name dependent on another variable. I have
tried,
'fs' + str(int(round(unblockedFS))) for fs13
and I get an invalid literal. If I code in the fs13, everything works. Is
it possible to do this?
unblockedFS=13.4
for line in file('21Ex6MV_tmr.dat'):
d, fs1, fs2, fs3, fs4, fs5, fs6, fs7, fs8, fs9, fs10, fs11, fs12,
fs13, fs14, fs15, fs16, fs17, fs18 = line.split()
if float(d) == round(calc_depth):
b = float( fs13)
print float(fs13)
Thanks,
Bryan
Hi Bryan,
Have you thought about using a dictionary instead of slew of
variables? IHMO, that will cut down on the number of variables that you have
to juggle. So instead of
fs1,fs2,fs3...
you would have
fs={}
fs[1]=
...
fs[18=..
-HTH,
Tino
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] standard output: Broken pipe
Eric Brunson wrote: I'm coming in late to the discussion and thought that someone would explain it succinctly, but there have been so many correct statements which I feel fail to nail down the problem that I thought I'd chime in. Hi Eric, Thank you for your considerate response. Your analysis is spot on -- speaking for myself, of course -- I'm mostly just flailing here; not having a very strong grasp of how all the components work together (kernel, shell, python, and the subprocess module). But I'm really enjoying this thread and learning a lot in the 'process' ... ahem, sorry for the pun ... painful :) Here's the important concepts to understand. The pipe is a construct of the shell, you are spawning a shell to run your entire command line. When the make finishes and stops accepting the input from yes, the kernel sends a SIGPIPE to the parent process, i.e. the shell. The shell's default behavior when receiving the SIGPIPE is to print an error message. You're right. Considering the shell is definitely important and I missed it. Yet given the following, slightly adapted from the subprocess module docs (your reference link below) ... from subprocess import Popen, PIPE p1 = Popen([yes, Hello], stdout=PIPE) p2 = Popen([head, -n, 10], stdin=p1.stdout, stdout=PIPE) output = p2.communicate()[0] ... still produces ... yes: standard output: Broken pipe yes: write error If run as a script, the message above shows up in the terminal after the python script terminates (or apparently so; shell prompt first, then error). And when using the interactive interpreter... nothing until exiting the interpreter, when the message again appears in the terminal. Perhaps this is some peculiarity of my environment, or more likely I am still missing something. Your problem, as I interpret it, is that you don't like seeing the error message. So you have two choices: 1) find some way to filter it, because all it is is a message, or 2) get rid of the shell and handle the management of the subprocesses yourself. It's been discussed how to suppress the output and it's been discussed how to intercept the signal, but I don't thing that anyone has pointed to the definitive python construct to handle it properly. You've had several responses that correctly tell you how to handle a signal, but without any testing I'm pretty sure that none of that will do you any good with the subprocess.call() construct you're using. The shell is your subprocess and it is already handling the signal, so you should never see it. The trick is to spawn both processes via python *without* an intervening shell to interfere. Here's the canonical example: http://docs.python.org/lib/node536.html. You can spawn each subprocess, 'yes' and 'make' without the shell being required to pipe the output of one to the other, you can do it all completely in python. Based on my own tests, I don't think it makes a difference. I suspect the python override for sigpipe is inherited by all child processes, shell or otherwise, and the SIG_IGN is allowing 'yes' to see the broken pipe, report it and terminate -- where the default action would normally be to terminate only. This is, of course, not that far from wild speculation. Though, I am curious if others observe the same behavior. Then again, the error is *not* displayed for any of tests where signal.signal(signal.SIGPIPE, signal.SIG_DFL) is added, in either the global scope or in the form of a preexec_fn argument passed to subprocess, with shell=True or without. IMHO, this is certainly a tripping point if true. Granted, probably a fringe case and relatively rare since it requires spawning a subprocess, which writes to a pipe that is broken before the subprocess ends, and is not implemented to handle the event gracefully. But I still find it weirdly intriguing. Again, sorry to come in late, but while reading many absolutely factual off-topic-blather As far as I'm concerned, no apologies are necessary -- not that you are apologizing to me necessarily :) But nonetheless, thank you for helping. In fact, a big thank you to all the tutors. I've been a member of the list for quite a few years now, reaping the benefits of your collective experience (like many others I would imagine), mostly by lurking. You provide a tremendous service to the python community, especially those new to python or programming in general, with near super-human patience and skill. Quite a feat! FWIW, thanks. /off-topic-blather Marty an correct responses, they all seemed to be either handling the output or discussing signal handling without, in my mind, pointing out that it's the shell that's giving you the problems. I think it's Python's default behavior to ignore SIGPIPE, as Martin comments on in his latest reply. It's just that the shell has already accepted and handled the signal. Interestingly, when you eliminate the shell and use something similar to the
Re: [Tutor] calling a variable name
Bryan Fodness wrote:
Here is the actual snippet of code
calc_depth =8.1 # which is actually d
unblockedFS = 13.4 # which is the indexed fs
for line in file('21Ex6MV_tmr.dat'):
d, fs1, fs2, fs3, fs4, fs5, fs6, fs7, fs8, fs9, fs10, fs11, fs12,
fs13, fs14, fs15, fs16, fs17, fs18, fs19, fs20, fs21, fs22, fs23, fs24,
fs25, fs26, fs27, fs28, fs29, fs30, fs31, fs32, fs33, fs34, fs35, fs36,
fs37, fs38, fs39, fs40 = line.split()
if float(d) == round(calc_depth):
print float('fs' + str(int(round(unblockedFS
I think I would just keep the data in a list and index it:
for line in file('21Ex6MV_tmr.dat'):
data = line.split()
d = data[0]
if float(d) == round(calc_depth):
print float(data[int(round(unblockedFS))])
Kent
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] calling a variable name
Here is the actual snippet of code
calc_depth =8.1 # which is actually d
unblockedFS = 13.4 # which is the indexed fs
for line in file('21Ex6MV_tmr.dat'):
d, fs1, fs2, fs3, fs4, fs5, fs6, fs7, fs8, fs9, fs10, fs11, fs12,
fs13, fs14, fs15, fs16, fs17, fs18, fs19, fs20, fs21, fs22, fs23,
fs24,
fs25, fs26, fs27, fs28, fs29, fs30, fs31, fs32, fs33, fs34, fs35,
fs36,
fs37, fs38, fs39, fs40 = line.split()
if float(d) == round(calc_depth):
print float('fs' + str(int(round(unblockedFS
Totally beside the point, but isn't it a bad idea in general to
compare two floats like that? It'll probably work, thanks to the
round function I guess (although shouldn't then 'float(d)' also be
rounded?), but I would have compared for a minimal difference between
two floats.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] standard output: Broken pipe
Martin Walsh wrote: Eric Brunson wrote: I'm coming in late to the discussion and thought that someone would explain it succinctly, but there have been so many correct statements which I feel fail to nail down the problem that I thought I'd chime in. Hi Eric, Thank you for your considerate response. Your analysis is spot on -- speaking for myself, of course -- I'm mostly just flailing here; not having a very strong grasp of how all the components work together (kernel, shell, python, and the subprocess module). But I'm really enjoying this thread and learning a lot in the 'process' ... ahem, sorry for the pun ... painful :) Here's the important concepts to understand. The pipe is a construct of the shell, you are spawning a shell to run your entire command line. When the make finishes and stops accepting the input from yes, the kernel sends a SIGPIPE to the parent process, i.e. the shell. The shell's default behavior when receiving the SIGPIPE is to print an error message. You're right. Considering the shell is definitely important and I missed it. Yet given the following, slightly adapted from the subprocess module docs (your reference link below) ... from subprocess import Popen, PIPE p1 = Popen([yes, Hello], stdout=PIPE) p2 = Popen([head, -n, 10], stdin=p1.stdout, stdout=PIPE) output = p2.communicate()[0] ... still produces ... yes: standard output: Broken pipe yes: write error Looks like the yes command is getting the SIGPIPE and not the shell, as I originally thought. I must have glossed over the yes: at the beginning. If run as a script, the message above shows up in the terminal after the python script terminates (or apparently so; shell prompt first, then error). And when using the interactive interpreter... nothing until exiting the interpreter, when the message again appears in the terminal. Perhaps this is some peculiarity of my environment, or more likely I am still missing something. Your problem, as I interpret it, is that you don't like seeing the error message. So you have two choices: 1) find some way to filter it, because all it is is a message, or 2) get rid of the shell and handle the management of the subprocesses yourself. It's been discussed how to suppress the output and it's been discussed how to intercept the signal, but I don't thing that anyone has pointed to the definitive python construct to handle it properly. You've had several responses that correctly tell you how to handle a signal, but without any testing I'm pretty sure that none of that will do you any good with the subprocess.call() construct you're using. The shell is your subprocess and it is already handling the signal, so you should never see it. The trick is to spawn both processes via python *without* an intervening shell to interfere. Here's the canonical example: http://docs.python.org/lib/node536.html. You can spawn each subprocess, 'yes' and 'make' without the shell being required to pipe the output of one to the other, you can do it all completely in python. Based on my own tests, I don't think it makes a difference. I suspect the python override for sigpipe is inherited by all child processes, shell or otherwise, and the SIG_IGN is allowing 'yes' to see the broken pipe, report it and terminate -- where the default action would normally be to terminate only. This is, of course, not that far from wild speculation. Though, I am curious if others observe the same behavior. I'd have to break out some documentation to review signal mask inheritance, it's been so long it escapes me. Then again, the error is *not* displayed for any of tests where signal.signal(signal.SIGPIPE, signal.SIG_DFL) is added, in either the global scope or in the form of a preexec_fn argument passed to subprocess, with shell=True or without. IMHO, this is certainly a tripping point if true. Granted, probably a fringe case and relatively rare since it requires spawning a subprocess, which writes to a pipe that is broken before the subprocess ends, and is not implemented to handle the event gracefully. But I still find it weirdly intriguing. Since yes is designed to spit out its output indefinitely, it seems like a bad behavior to print a message on SIGPIPE. It's always going to happen, it's the expected result. The versions of yes on my linux box here and a solaris box at work don't seem to elicit the same error message. Just another reason why I would look for a solution that would avoid the yes altogether. :-) Again, sorry to come in late, but while reading many absolutely factual off-topic-blather As far as I'm concerned, no apologies are necessary -- not that you are apologizing to me necessarily :) But nonetheless, thank you for helping. In fact, a big thank you to all the tutors. I've been a member of the list for quite a few years now, reaping the
Re: [Tutor] calling a variable name
Thank you. This works well. I am still trying to figure out the pros and
cons of using an array, dictionary or list.
On 10/22/07, Kent Johnson [EMAIL PROTECTED] wrote:
Bryan Fodness wrote:
Here is the actual snippet of code
calc_depth =8.1 # which is actually d
unblockedFS = 13.4 # which is the indexed fs
for line in file('21Ex6MV_tmr.dat'):
d, fs1, fs2, fs3, fs4, fs5, fs6, fs7, fs8, fs9, fs10, fs11, fs12,
fs13, fs14, fs15, fs16, fs17, fs18, fs19, fs20, fs21, fs22, fs23, fs24,
fs25, fs26, fs27, fs28, fs29, fs30, fs31, fs32, fs33, fs34, fs35, fs36,
fs37, fs38, fs39, fs40 = line.split()
if float(d) == round(calc_depth):
print float('fs' + str(int(round(unblockedFS
I think I would just keep the data in a list and index it:
for line in file('21Ex6MV_tmr.dat'):
data = line.split()
d = data[0]
if float(d) == round(calc_depth):
print float(data[int(round(unblockedFS))])
Kent
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] calling a variable name
Bryan Fodness wrote: Thank you. This works well. I am still trying to figure out the pros and cons of using an array, dictionary or list. Array is specialized, you probably want list or dict. Use list when you want a sequence of items indexed by sequential integers. Lists - preserve order - are fast for indexed lookup - are relatively slow (O(n)) for adding, deleting and searching (though for small lists this should not be a consideration) Use dict when you want to index by something other than sequential integers Dicts - do not preserve order - are fast for adding, deleting and lookup - can be used to replace a list search with a lookup I'm sure there is more that I have missed. For your case I would start with a list, I don't see anything requiring a dict. Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] how to read from a csv file?
Hi, this is a module i wrote to catch some data from a csv file:
##
#module csv data reader
# open a csv file and return its data
import csv
import sys
def __init__(self):
rawdata = []
f = open('datalisting_000.csv','r')
try:
reader = csv.reader(f)
for row in reader:
rawdata.append(row)
finally:
f.close()
def rawdata():
return rawdata
if __name__ == __main__:
print This is a module. You can't run it directly. Try to import it.
raw_input(\n\nPress any key to exit.)
#
But when i try to use like:
##
import csvdatareader
print csvdatareader.rawdata()
##
It didn't print anything. Where is the mistake?
Cheers.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] how to read from a csv file?
pierre cutellic wrote: Hi, this is a module i wrote to catch some data from a csv file: ## #module csv data reader # open a csv file and return its data import csv import sys def __init__(self): Stop right there. You're confusing modules and classes. A class has a (meaningful) __init__ method, which is called when the class is instantiated. You *can* have an __init__ in a module, but it doesn't do anything special. You really just want to rename __init__ to rawdata and drop the redundant return rawdata function. TJG ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] pgdb and unicode
Hi there.
I have a small system in production with wxPython and PostgreSQL running on
a machine with Centos 5.
At first everytihing was running ok but now a weird bug was discovered:
they can't insert characters like á é í ó ú ä ë ñ (non english characters)
Does anyone knows how can I make pgdb accept that kind of characters?
I wrote a little script...
But first
CREATE DATABASE test;
CREATE TABLE tabla(
cad character varying
) ;
#!/usr/bin/python
# -*- coding: utf8 -*-
import pgdb
con = pgdb.connect(user=farfan, password='00', host='localhost',
database='test')
cur = con.cursor()
cur.execute(INSERT INTO tabla VALUES ('é'))
con.commit()
cur.execute(uINSERT INTO tabla VALUES ('é'))
con.commit()
and this is the result
python Aplicacion.py
Traceback (most recent call last):
File Aplicacion.py, line 10, in ?
cur.execute(uINSERT INTO tabla VALUES ('é'))
File /usr/lib/python2.4/site-packages/pgdb.py, line 175, in execute
self.executemany(operation, (params,))
File /usr/lib/python2.4/site-packages/pgdb.py, line 198, in executemany
raise OperationalError, internal error in '%s': %s % (sql,err)
[EMAIL PROTECTED] ~]$ python Aplicacion.py
Traceback (most recent call last):
File Aplicacion.py, line 8, in ?
cur.execute(uINSERT INTO tabla VALUES ('é'))
File /usr/lib/python2.4/site-packages/pgdb.py, line 175, in execute
self.executemany(operation, (params,))
File /usr/lib/python2.4/site-packages/pgdb.py, line 198, in executemany
raise OperationalError, internal error in '%s': %s % (sql,err)
pg.OperationalError
As you can see, the first insert statement is executed in ascii format and is
succeful,
the second, which is in Unicode, fails
the problem is thas wxPython will allways send the script in unicode format...
any ideas on how to fix it?
rb3m dijo: Un buen programador no es uno que se sepa un lenguaje al derecho y
al revés, sino el que sabe resolver un problema y después implementar la
solución en el lenguaje más adecuado.
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] pgdb and unicode
Ismael Farfán Estrada wrote:
Hi there.
I have a small system in production with wxPython and PostgreSQL running on
a machine with Centos 5.
At first everytihing was running ok but now a weird bug was discovered:
they can't insert characters like á é í ó ú ä ë ñ (non english
characters)
Does anyone knows how can I make pgdb accept that kind of characters?
I wrote a little script...
But first
CREATE DATABASE test;
CREATE TABLE tabla(
cad character varying
) ;
#!/usr/bin/python
# -*- coding: utf8 -*-
import pgdb
con = pgdb.connect(user=farfan, password='00', host='localhost',
database='test')
cur = con.cursor()
cur.execute(INSERT INTO tabla VALUES ('é'))
con.commit()
cur.execute(uINSERT INTO tabla VALUES ('é'))
con.commit()
As you can see, the first insert statement is executed in ascii format and is
succeful,
the second, which is in Unicode, fails
Why do you need the whole statement to be Unicode? It looks like the
database wants utf-8. Probably you should encode the data as utf-8 first.
the problem is thas wxPython will allways send the script in unicode format...
What is coming from wxPython? I guess it is just the data value, not the
SQL statement or the entire script. Try something like
data= u'é' # Unicode data from wxPython
data = data.encode('utf-8')
cur.execute('INSERT INTO tabla VALUES (%s)', [data])
Note I am passing the data as a separate list, not using string
interpolation. Let the database worry about quoting, etc.
Kent
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] how to read from a csv file?
Tim Golden wrote: You really just want to rename __init__ to rawdata and drop the redundant return rawdata function. But remember to include the line: return rawdata at the end of your function or else nothing will be printed when print csvdatareader.rawdata() is called. Also, I'd consider using different names for the function and list variable. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] pgdb and unicode
Ismael Farfán Estrada wrote:
Hi there.
I have a small system in production with wxPython and PostgreSQL running on
a machine with Centos 5.
At first everytihing was running ok but now a weird bug was discovered:
they can't insert characters like á é í ó ú ä ë ñ (non english
characters)
Does anyone knows how can I make pgdb accept that kind of characters?
I wrote a little script...
But first
CREATE DATABASE test;
CREATE TABLE tabla(
cad character varying
) ;
#!/usr/bin/python
# -*- coding: utf8 -*-
import pgdb
con = pgdb.connect(user=farfan, password='00', host='localhost',
database='test')
cur = con.cursor()
cur.execute(INSERT INTO tabla VALUES ('é'))
con.commit()
cur.execute(uINSERT INTO tabla VALUES ('é'))
con.commit()
As you can see, the first insert statement is executed in ascii format and
is succeful,
the second, which is in Unicode, fails
Why do you need the whole statement to be Unicode? It looks like the
database wants utf-8. Probably you should encode the data as utf-8 first.
the problem is thas wxPython will allways send the script in unicode
format...
What is coming from wxPython? I guess it is just the data value, not the
SQL statement or the entire script. Try something like
data= u'é' # Unicode data from wxPython
data = data.encode('utf-8')
cur.execute('INSERT INTO tabla VALUES (%s)', [data])
Tanks, that did the trick:
data = []
data.append(self.marca.GetLineText(0))#.encode('utf-8'))
sql = INSERT INTO Marca (marca) VALUES (%s);
cur.execute(sql, data)
Note I am passing the data as a separate list, not using string
interpolation. Let the database worry about quoting, etc.
Kent
It seems that just by sending the data in a list fixed the problem
though adding the encode doesn't harm either ...
I'll have to make a looot of changes.
by the way, does sending the data as a list prevent SQL injection?
I haven't worried for that yet.
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] pgdb and unicode
Kent Johnson wrote:
Ismael Farfán Estrada wrote:
Hi there.
I have a small system in production with wxPython and PostgreSQL running on
a machine with Centos 5.
At first everytihing was running ok but now a weird bug was discovered:
they can't insert characters like á é í ó ú ä ë ñ (non english
characters)
Does anyone knows how can I make pgdb accept that kind of characters?
I wrote a little script...
But first
CREATE DATABASE test;
CREATE TABLE tabla(
cad character varying
) ;
#!/usr/bin/python
# -*- coding: utf8 -*-
import pgdb
con = pgdb.connect(user=farfan, password='00', host='localhost',
database='test')
cur = con.cursor()
cur.execute(INSERT INTO tabla VALUES ('é'))
con.commit()
cur.execute(uINSERT INTO tabla VALUES ('é'))
con.commit()
As you can see, the first insert statement is executed in ascii format and
is succeful,
the second, which is in Unicode, fails
Why do you need the whole statement to be Unicode? It looks like the
database wants utf-8. Probably you should encode the data as utf-8 first.
the problem is thas wxPython will allways send the script in unicode
format...
What is coming from wxPython? I guess it is just the data value, not the
SQL statement or the entire script. Try something like
data= u'é' # Unicode data from wxPython
data = data.encode('utf-8')
cur.execute('INSERT INTO tabla VALUES (%s)', [data])
Dear Mr. Johnson,
Thank you for doing your part to help eradicate SQL injection attacks. :-)
Sincerely,
The World
(Seriously, though, after the discussion of last week, I always
appreciate seeing good coding practices, even in example and meta code).
Note I am passing the data as a separate list, not using string
interpolation. Let the database worry about quoting, etc.
Kent
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] pgdb and unicode
Ismael Farfán Estrada wrote: by the way, does sending the data as a list prevent SQL injection? Yes. I haven't worried for that yet. If you are accepting user input and putting it into the database, you should worry about it. See http://xkcd.com/327/ for a humorous take on this ;-) Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Negative Signed Binary Conversion
Hi, I'm trying to get this binary converter working, but I can't seem to get the negatives to work properly. If the integer is too low, the 0's that are added for the amount of bits gets out of whack. I've tried to solve the problem by adding another 'count' meter by which I can then tell if there are too many 0's, but it hasn't worked at all. CODE: def conversion(n): b = '' while n 0: r = n%2 n = n/2 r = str(r) b = r+b return b def positive(n,bits,count): append_zeros = bits - count if append_zeros 0: return 0 + (append_zeros-1)*0 + conversion(n) def negative(n,bits,count,new_count): n = abs(n) append_zeros = bits - count while new_count bits and new_count bits-count: append_zeros = append_zeros - 2 continue if append_zeros 0: return 1 + (append_zeros-6)*0 + conversion(n) def signed_mag(): print print print Signed Binary print print n = int(raw_input(Please enter a signed integer: )) bits = int(raw_input(Please enter the number of bits: )) count = conversion(n).count(0) + conversion(n).count(1) new_count = 0 new_count = negative(n,bits,count,new_count).count(0) \ + negative(n,bits,count,new_count).count(1) if bits - 1 count: print Out of range. else: if n 0: print n,is encoded as, negative(n,bits,count,new_count), \ in Signed Binary. elif n 0: print n,is encoded as, positive(n,bits,count), \ in Signed Binary. else: print That is not an valid signed interger. Any help will be greatly appreciated. Thanks in advance. Cheers, Devon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Negative Signed Binary Conversion
Why not find the sign, calculate the binary of the absolute value, then make the result negative (twos complement) if necessary? Just a thought. [EMAIL PROTECTED] wrote: Hi, I'm trying to get this binary converter working, but I can't seem to get the negatives to work properly. If the integer is too low, the 0's that are added for the amount of bits gets out of whack. I've tried to solve the problem by adding another 'count' meter by which I can then tell if there are too many 0's, but it hasn't worked at all. CODE: def conversion(n): b = '' while n 0: r = n%2 n = n/2 r = str(r) b = r+b return b def positive(n,bits,count): append_zeros = bits - count if append_zeros 0: return 0 + (append_zeros-1)*0 + conversion(n) def negative(n,bits,count,new_count): n = abs(n) append_zeros = bits - count while new_count bits and new_count bits-count: append_zeros = append_zeros - 2 continue if append_zeros 0: return 1 + (append_zeros-6)*0 + conversion(n) def signed_mag(): print print print Signed Binary print print n = int(raw_input(Please enter a signed integer: )) bits = int(raw_input(Please enter the number of bits: )) count = conversion(n).count(0) + conversion(n).count(1) new_count = 0 new_count = negative(n,bits,count,new_count).count(0) \ + negative(n,bits,count,new_count).count(1) if bits - 1 count: print Out of range. else: if n 0: print n,is encoded as, negative(n,bits,count,new_count), \ in Signed Binary. elif n 0: print n,is encoded as, positive(n,bits,count), \ in Signed Binary. else: print That is not an valid signed interger. Any help will be greatly appreciated. Thanks in advance. Cheers, Devon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Negative Signed Binary Conversion
So far I've gotten five copies of this. It could be mailman doing something wrong, but if you're resending because you don't see your reply, please be patient, this list is not always instantaneous. I think you're missing the gist of what I'm saying. Calculate the binary of the absolute. I'm not going to debug your code for you, I'm just offering a suggestion to simplify your logic. Here's the way I might do it: def toBinary( num ): bits = [] negative = num 0 n = abs( num ) while not bits or n: n, bit = divmod(n,2) bits.append( str(bit) ) bits.reverse() binary = .join( bits ) if negative: return( twoscomplement( binary ) ) else: return( binary ) For what it's worth... [EMAIL PROTECTED] wrote: For Two's Complement, I would have to re-assign the 1's to 0's, and vice versa, then add one in binary. That's my second step, and I'm pretty sure I can get it to work IF I could get this negative signed binary part to work. On Mon, 22 Oct 2007 12:09:27 -0600 [EMAIL PROTECTED] wrote: Why not find the sign, calculate the binary of the absolute value, then make the result negative (twos complement) if necessary? Just a thought. [EMAIL PROTECTED] wrote: Hi, I'm trying to get this binary converter working, but I can't seem to get the negatives to work properly. If the integer is too low, the 0's that are added for the amount of bits gets out of whack. I've tried to solve the problem by adding another 'count' meter by which I can then tell if there are too many 0's, but it hasn't worked at all. CODE: def conversion(n): b = '' while n 0: r = n%2 n = n/2 r = str(r) b = r+b return b def positive(n,bits,count): append_zeros = bits - count if append_zeros 0: return 0 + (append_zeros-1)*0 + conversion(n) def negative(n,bits,count,new_count): n = abs(n) append_zeros = bits - count while new_count bits and new_count bits-count: append_zeros = append_zeros - 2 continue if append_zeros 0: return 1 + (append_zeros-6)*0 + conversion(n) def signed_mag(): print print print Signed Binary print print n = int(raw_input(Please enter a signed integer: )) bits = int(raw_input(Please enter the number of bits: )) count = conversion(n).count(0) + conversion(n).count(1) new_count = 0 new_count = negative(n,bits,count,new_count).count(0) \ + negative(n,bits,count,new_count).count(1) if bits - 1 count: print Out of range. else: if n 0: print n,is encoded as, negative(n,bits,count,new_count), \ in Signed Binary. elif n 0: print n,is encoded as, positive(n,bits,count), \ in Signed Binary. else: print That is not an valid signed interger. Any help will be greatly appreciated. Thanks in advance. Cheers, Devon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] multithreaded debugger
Hi Everybody, Is there a multi-threaded debugger in Python? I running into some problems and a debugger would be very helpful here. Thanks, Tino ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] multithreaded debugger
Tino Dai wrote: Hi Everybody, Is there a multi-threaded debugger in Python? I running into some problems and a debugger would be very helpful here. Maybe Winpdb would help: http://www.digitalpeers.com/pythondebugger/ Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] standard output: Broken pipe
That's not a half-baked idea. ;) I'm not really sure how I would replace 'yes', though, in this situation. Thoughts? .james On Oct 22, 2007, at 10:33 AM, Eric Brunson wrote: Just another reason why I would look for a solution that would avoid the yes altogether. :-) ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Negative Signed Binary Conversion
No worries. I said it could be mailman, and apparently it was. :-) [EMAIL PROTECTED] wrote: Hi, I also got this email five times, and several rejection emails from the moderator. I'm very sorry for this, but I swear I only sent the email once. If this Apology email is also sent multiple times, I'll use a different email account to post on lists. Again, very sorry for the inconvenience. Devon ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] standard output: Broken pipe
Martin Walsh wrote:
Michael Langford wrote:
This signal is not something you care about. All SIGPIPE means is that
the source of the signal found itself writing to a pipe with no sender.
Your line signal.signal(signal.SIGPIPE, signal.SIG_DFL) means use the
default signal handler for SIGPIPE. While this works (as the default
signal handler is the ignore handler, you actually want to explicitly
use the IGN handler, which will just ignore the signal. To do this use
signal.signal(signal.SIGPIPE, signal.SIG_IGN)
I don't think this is quite right, but please correct me if I'm
misinformed, or just plain wrong. :)
Using signal.signal(signal.SIGPIPE, signal.SIG_IGN) (kernel 2.6.20,
bash 3.2, python2.5)
I just noticed something, Martin. subprocess.call() on my machine is
calling the shell as /bin/sh, not /bin/bash. This changes the behavior
of bash, possibly causing it to print the message. (Anyone else think
that subprocess should honor the SHELL environment variable?)
I can't get any invocation of the commands to generate the error
message, only when it's called from python does the ouput get
generated. Quite interesting, I'd love to know the explanation for that.
Still poking at it, though.
still produces a broken pipe with the following code:
import signal
import subprocess as sp
signal.signal(signal.SIGPIPE, signal.SIG_IGN)
sp.call(yes 'Spam' | head -n 10, shell=True)
My understanding is that python is *already* overriding with a SIG_IGN
for SIGPIPE, and child processes inherit, which explains the difference
in behavior when running the command from a shell terminal (on my system
at least) vs. a python subprocess object. This is referenced in the
signal module docs (http://docs.python.org/lib/module-signal.html), and
appears to be confirmed in the python2.5 source (pythonrun.c).
Also, while it is unclear in the signal module docs (to me at least), my
take on the use of SIG_DFL is to revert (if necessary) to the *system*
default action for a signal, not the python default (which is SIG_IGN).
Again, this is my interpretation based on a very minimal understanding
-- please correct me if I'm wrong.
The reason you don't see the error on the shell is that the bash shell
does not print notifications of SIGPIPE when running interactively. If
you instead copied your snippit of scripting into a shell script then
called that with bash foo.sh, you'd see the exact same broken pipe.
Ok, this isn't true on my system either -- I don't get a broken pipe
from a bash script. So, perhaps this is due to the differences in our
kernel or bash versions. The version of bash on my system (3.2) has a
DONT_REPORT_SIGPIPE define that is honored in both interactive and
non-interactive shells. Presumably, this is how the ubuntu binary was
compiled.
Here is what all the signals available do:
http://www.delorie.com/gnu/docs/glibc/libc_471.html
Excellent link, thanks! IMO, the signal manpage ('man signal') is also a
good resource. On my system, it contains a table of default actions.
Here's what it has to say about SIGPIPE:
Signal Value Action Comment
-
SIGPIPE 13 TermBroken pipe: write to pipe with no readers
and, the 'Term' action is defined as follows:
Term Default action is to terminate the process.
Thanks!
Marty
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] standard output: Broken pipe
James [EMAIL PROTECTED] wrote I'm not really sure how I would replace 'yes', though, in this situation. Thoughts? Just read the output of Popen from stdout and respond with a 'y' to stdin until the process finishes. See the example in the documentation of Popen replacing os.popen... Or look in the OS topic of my tutorial near the end... HTH, -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Negative Signed Binary Conversion
[EMAIL PROTECTED] wrote I'm trying to get this binary converter working, but I can't seem to get the negatives to work properly. I already sent a reply on this, but: def conversion(n): b = '' while n 0: This line means you only ever return an empty string for a negative n... n = int(raw_input(Please enter a signed integer: )) bits = int(raw_input(Please enter the number of bits: )) count = conversion(n).count(0) + conversion(n).count(1) And you call it with anegative n here and use the empty string to calculate the count... = 0. HTH, -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Offtopic Reply, was: Negative Signed Binary Conversion
You know, Alan, I remember you commenting that you had some flakey behavior from this list a few of weeks ago, then over the weekend I received about two dozen emails from threads as far back as August. Something is definitely wonky (technical term ;-) about this list server. Alan Gauld wrote: [EMAIL PROTECTED] wrote I'm trying to get this binary converter working, but I can't seem to get the negatives to work properly. I already sent a reply on this, but: def conversion(n): b = '' while n 0: This line means you only ever return an empty string for a negative n... n = int(raw_input(Please enter a signed integer: )) bits = int(raw_input(Please enter the number of bits: )) count = conversion(n).count(0) + conversion(n).count(1) And you call it with anegative n here and use the empty string to calculate the count... = 0. HTH, ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] URLLIB / GLOB
Hello, I would like to write a program which looks in a web directory for, say *.gif files. Then processes those files in some manner. What I need is something like glob which will return a directory listing of all the files matching the search pattern (or just a simply a certain extension). Is there a way to do this with urllib? Any other suggestions? Thanks! ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] URLLIB / GLOB
John wrote: Hello, I would like to write a program which looks in a web directory for, say *.gif files. Then processes those files in some manner. What I need is something like glob which will return a directory listing of all the files matching the search pattern (or just a simply a certain extension). Is there a way to do this with urllib? Any other suggestions? If the directory is only available as a web page you will have to fetch the web directory listing itself with urllib or urllib2 and parse the HTML returned to get the list of files. You might want to use BeautifulSoup to parse the HTML. http://www.crummy.com/software/BeautifulSoup/ Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] standard output: Broken pipe
Eric Brunson wrote:
Martin Walsh wrote:
Michael Langford wrote:
I don't think this is quite right, but please correct me if I'm
misinformed, or just plain wrong. :)
Using signal.signal(signal.SIGPIPE, signal.SIG_IGN) (kernel 2.6.20,
bash 3.2, python2.5)
I just noticed something, Martin. subprocess.call() on my machine is
calling the shell as /bin/sh, not /bin/bash. This changes the behavior
of bash, possibly causing it to print the message. (Anyone else think
that subprocess should honor the SHELL environment variable?)
Yeah, I thought that was strange too, and I completely agree that the
SHELL env var would seem the obvious choice -- or perhaps, a mechanism
to change the shell command. Now that you mention the behavior of
/bin/bash when called as /bin/sh, I guess it could have something to do
with posix compliance, but I don't really understand the implications.
Maybe a quick modification of the subprocess source will shed some
light; setting it to /bin/bash, instead of /bin/sh (or '/bin/bash --posix'):
def _execute_child( ... ):
snip
if shell:
args = [/bin/bash, -c] + args
snip
Unfortunately, no change in the odd SIGPIPE behavior.
Another factoid -- Ubuntu /bin/sh is a symlink to dash. After your
advice to pay closer attention to the shell sub-process, I thought dash
might be the culprit. But alas, it produced the same behavior. And, of
course, changing the symlink to point to bash didn't make a difference
either.
I can't get any invocation of the commands to generate the error
message, only when it's called from python does the ouput get
generated. Quite interesting, I'd love to know the explanation for that.
I'm seeing the same thing, error message from python and not from shell
or shell scripts. I am still leaning toward signal inheritance as a
likely contributor, which I think would also indicate that the
subprocess module is rolling up an exception and not passing it along.
As I mentioned it's almost all gut-reaction at this point, so far I
haven't found any definitive proof to substantiate. Slow going for me
I'm afraid, to many tangential paths to follow to fill gaps in my
understanding. But it sure is fun.
Again, thanks for you insight Eric!
Marty
Still poking at it, though.
still produces a broken pipe with the following code:
import signal
import subprocess as sp
signal.signal(signal.SIGPIPE, signal.SIG_IGN)
sp.call(yes 'Spam' | head -n 10, shell=True)
My understanding is that python is *already* overriding with a SIG_IGN
for SIGPIPE, and child processes inherit, which explains the difference
in behavior when running the command from a shell terminal (on my system
at least) vs. a python subprocess object. This is referenced in the
signal module docs (http://docs.python.org/lib/module-signal.html), and
appears to be confirmed in the python2.5 source (pythonrun.c).
Also, while it is unclear in the signal module docs (to me at least), my
take on the use of SIG_DFL is to revert (if necessary) to the *system*
default action for a signal, not the python default (which is SIG_IGN).
Again, this is my interpretation based on a very minimal understanding
-- please correct me if I'm wrong.
The reason you don't see the error on the shell is that the bash shell
does not print notifications of SIGPIPE when running interactively. If
you instead copied your snippit of scripting into a shell script then
called that with bash foo.sh, you'd see the exact same broken pipe.
Ok, this isn't true on my system either -- I don't get a broken pipe
from a bash script. So, perhaps this is due to the differences in our
kernel or bash versions. The version of bash on my system (3.2) has a
DONT_REPORT_SIGPIPE define that is honored in both interactive and
non-interactive shells. Presumably, this is how the ubuntu binary was
compiled.
Here is what all the signals available do:
http://www.delorie.com/gnu/docs/glibc/libc_471.html
Excellent link, thanks! IMO, the signal manpage ('man signal') is also a
good resource. On my system, it contains a table of default actions.
Here's what it has to say about SIGPIPE:
Signal Value Action Comment
-
SIGPIPE 13 TermBroken pipe: write to pipe with no readers
and, the 'Term' action is defined as follows:
Term Default action is to terminate the process.
Thanks!
Marty
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
