Re: [Tutor] a logic problem in an if statement
On Sun, Sep 26, 2010 at 5:12 PM, Steven D'Aprano wrote: > On Mon, 27 Sep 2010 06:01:35 am Bill Allen wrote: > > Now your decision logic becomes simple, and obvious. It documents > itself: > > if click_in_bottom_half1 and click_in_bottom_half2: >print "Both clicks in bottom half of screen" > elif click_in_bottom_half1: >print "The first click was in the bottom half." >print "The second click was in the top half." > elif click_in_bottom_half2: >print "The first click was in the top half." >print "The second click was in the bottom half." > else: >print "Both clicks in top half of screen" > > > > -- > Steven D'Aprano > Steven, Those are great suggestions and certainly do simplify matters quite a bit. I had not realized the I was including such redundancies into my code. I have some other code I need to now go back through and see what simplifications I can there also make. Thanks! --Bill ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] super.__init__() arguments
On Mon, Sep 27, 2010 at 1:45 AM, Jojo Mwebaze wrote: > Hey Tutor, > Seems a small issue but this has been playing for a while now, what am i > doing wrong here? > Take an Example > Class Point: > def __init__(self, x=0, y=0): > self.x = x > self.y = y > Class Circle(Point): > def __init__(self, radius=0, x=0, y=0): > super().__init__(x, y) > self.radius = radius > > c = Circle(radius =3, x=4, y= 6) > Traceback (most recent call last): > File "", line 1, in > File "Point.py", line 13, in __init__ > super().__init__(x, y) > TypeError: super() takes at least 1 argument (0 given) > Did you read the error you were given? super() takes an argument, and you're not giving it any. Go read the documentation for super. http://docs.python.org/library/functions.html#super Hugo ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] super.__init__() arguments
Hey Tutor, Seems a small issue but this has been playing for a while now, what am i doing wrong here? Take an Example Class Point: def __init__(self, x=0, y=0): self.x = x self.y = y Class Circle(Point): def __init__(self, radius=0, x=0, y=0): super().__init__(x, y) self.radius = radius c = Circle(radius =3, x=4, y= 6) Traceback (most recent call last): File "", line 1, in File "Point.py", line 13, in __init__ super().__init__(x, y) TypeError: super() takes at least 1 argument (0 given) ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On 2:59 PM, Bill DeBroglie wrote: No, I meant that you should edit your .py file and add #!/usr/bin/env python as the first line, THEN try to run it. BINGO! Right now what's happening is that you're handing a line of Python script to the shell and asking it to run it; the shell is telling you (oh-so-politely) "what the hell is this?" You need to give it a clue. Thank you for the translation. So I need to do this with every .py file? My friend who was helping me (he's only been at this a few months) doesn't need to do this. Is that possible or is he just misleading me? Two times you wouldn't need such a line: 1) in Windows, where file extension determines what the shell will do with the file 2) when you explicitly run the script by naming the python executable, such as: python chapter_2.py ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On Mon, 27 Sep 2010 08:37:08 am Bill DeBroglie wrote: > > No, I meant that you should edit your .py file and add > > #!/usr/bin/env python > > as the first line, THEN try to run it. > > BINGO! > > > Right now what's happening is that you're handing a line of Python > > script to the shell and asking it to run it; the shell is telling > > you (oh-so-politely) "what the hell is this?" You need to give it > > a clue. > > Thank you for the translation. So I need to do this with every .py > file? Only if you want to run them without specifying Python on the command line. You can always call python first: python name-of-my-script.py instead of just name-of-my-script.py -- Steven D'Aprano ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On Sep 26, 2010, at 6:29 PM, Marc Tompkins wrote:
On Sun, Sep 26, 2010 at 3:24 PM, Bill DeBroglie > wrote:
Is this what you mean?
matthew-parrillas-macbook:Dawson_Book matthewparrilla$ #!/usr/bin/
env python
matthew-parrillas-macbook:Dawson_Book matthewparrilla$ ./chapter_2.py
./chapter_2.py: line 1: syntax error near unexpected token `"Hello
World"'
./chapter_2.py: line 1: `print("Hello World")'
If so, obviously still no dice.
No, I meant that you should edit your .py file and add
#!/usr/bin/env python
as the first line, THEN try to run it.
BINGO!
Right now what's happening is that you're handing a line of Python
script to the shell and asking it to run it; the shell is telling
you (oh-so-politely) "what the hell is this?" You need to give it a
clue.
Thank you for the translation. So I need to do this with every .py
file? My friend who was helping me (he's only been at this a few
months) doesn't need to do this. Is that possible or is he just
misleading me?
--
www.fsrtechnologies.com
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] generating formatted output
On Sun, Sep 26, 2010 at 4:21 PM, Hugo Arts wrote:
> On Sun, Sep 26, 2010 at 10:16 PM, Rance Hall wrote:
> > My app will be printing a series of documents that are the same each
> > time the doc is printed with the exception of the variables. Sort of
> > a MailMerge if you will.
> >
> >
>
> I would suggest you take a look at string.Template or the str.format
> method. It may be somewhat simpler than doing a whole lot of replaces,
> perhaps faster as well.
>
> http://docs.python.org/library/string.html#template-strings
> http://docs.python.org/library/stdtypes.html#str.format
>
> Hugo
>
> I agree. I had a great deal of success with using docstrings along with
str.format in a program I wrote at work.
Example, two ways:
"""
Dear Mr. {0},
Thanks for your recent inquiry.
Your current invoice #{1} is overdue by {2} days.
Please make remittance by {3} in order to avoid
overdue fees.
Sincerely,
{4}
Billing Dept.
""".format(client_name, inv_num, num_days, due_date, sender)
or
over_due_notice = """
Dear Mr. {0},
Thanks for your recent inquiry.
Your current invoice #{1} is overdue by {2} days.
Please make remittance by {3} in order to avoid
overdue fees.
Sincerely,
{4}
Billing Dept.
"""
over_due_notice.format(client_name, inv_num, num_days, due_date, sender)
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On Sun, Sep 26, 2010 at 3:24 PM, Bill DeBroglie wrote:
>
> Is this what you mean?
>
> matthew-parrillas-macbook:Dawson_Book matthewparrilla$ #!/usr/bin/env
> python
> matthew-parrillas-macbook:Dawson_Book matthewparrilla$ ./chapter_2.py
> ./chapter_2.py: line 1: syntax error near unexpected token `"Hello World"'
> ./chapter_2.py: line 1: `print("Hello World")'
>
> If so, obviously still no dice.
>
> No, I meant that you should edit your .py file and add
> #!/usr/bin/env python
>
as the first line, THEN try to run it.
Right now what's happening is that you're handing a line of Python script to
the shell and asking it to run it; the shell is telling you (oh-so-politely)
"what the hell is this?" You need to give it a clue.
--
www.fsrtechnologies.com
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On Sep 26, 2010, at 6:18 PM, Marc Tompkins wrote: On Sun, Sep 26, 2010 at 3:04 PM, David Hutto wrote: > Pretty sure it's the parentheses, but I'm not an expert. In python 3 you use > print(), in 2.6 you either use import from __futur__ or print "string here". I mean __future__ . The parentheses are optional in 2.6, mandatory in 3. In 2.6, print and print() are alternate ways to invoke the print statement; in 3 the print statement has been replaced by the print() function. If you want to use the function instead of the statement, you must do this: from __future__ import print_function but I'm pretty sure that's not the OP's issue. Yes, not a parenthesis issue (happens whether I use them or not, I've tried both ways). -- www.fsrtechnologies.com By the way guys, thank you so much for the help. I'm sort of learning this on my own and don't know where to go when I hit a wall like this... ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On Sep 26, 2010, at 6:06 PM, Marc Tompkins wrote:
On Sun, Sep 26, 2010 at 2:55 PM, Bill DeBroglie > wrote:
Which is great, but when I try and run the same code in the Terminal
by calling a program I've written (print("hello world") again) I get
the following:
matthews-macbook:Dawson_Book matthewparrilla$ ./chapter_2.py
./chapter_2.py: line 4: syntax error near unexpected token
`"Hello World"'
./chapter_2.py: line 4: `print("Hello World")'
I'm using a Mac OS X 10.5.8. I had previously downloaded Python
2.6.5 AND 3.1 and had them both on this computer simultaneously but
was having trouble with 3.1 crashing. I have since put both in the
trash but obviously still have 2.6.5 on my system, I assume that was
the version pre-installed on this Mac.
I think that's a shell issue, not specifically a Python issue. You
need to include a line at the top of the script to tell the OS how
to find the Python interpreter. Try adding this line at the
beginning:
#!/usr/bin/env python
Is this what you mean?
matthew-parrillas-macbook:Dawson_Book matthewparrilla$ #!/usr/bin/env
python
matthew-parrillas-macbook:Dawson_Book matthewparrilla$ ./chapter_2.py
./chapter_2.py: line 1: syntax error near unexpected token `"Hello
World"'
./chapter_2.py: line 1: `print("Hello World")'
If so, obviously still no dice.
Your default Python install probably is NOT installed at /usr/bin/
python, but there should be a symbolic link there that points to the
actual location. If not, you'll need to adjust things a bit.
--
www.fsrtechnologies.com
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On Mon, 27 Sep 2010 07:55:40 am Bill DeBroglie wrote:
[...]
> Which is great, but when I try and run the same code in the Terminal
> by calling a program I've written (print("hello world") again) I get
> the following:
How do you call the program?
At the shell prompt, if you call:
python name_of_my_program.py
does it work?
Looking at the error you get, it looks like OS-X is treating the program
as a shell script, not a Python script:
> matthews-macbook:Dawson_Book matthewparrilla$ ./chapter_2.py
> ./chapter_2.py: line 4: syntax error near unexpected token `"Hello
> World"'
> ./chapter_2.py: line 4: `print("Hello World")'
That's not a Python error message, so it's probably a shell error. You
need to teach the shell how to treat it, either by explicitly calling
python, as above, or by inserting a "hash-bang" line at the very top of
the script:
#!/usr/bin/env python
should do it.
--
Steven D'Aprano
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On Sun, Sep 26, 2010 at 3:04 PM, David Hutto wrote: > > Pretty sure it's the parentheses, but I'm not an expert. In python 3 you > use > > print(), in 2.6 you either use import from __futur__ or print "string > here". > > I mean __future__ . > The parentheses are optional in 2.6, mandatory in 3. In 2.6, print and print() are alternate ways to invoke the print statement; in 3 the print statement has been replaced by the print() function. If you want to use the function instead of the statement, you must do this: from __future__ import print_function but I'm pretty sure that's not the OP's issue. -- www.fsrtechnologies.com ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] a logic problem in an if statement
On Mon, 27 Sep 2010 06:01:35 am Bill Allen wrote: > #This captures the coordinates the two mouse clicks, successfully. > mouse_pos is in the form (x,y), such as (204,102). > if mouse_pressed == (1,0,0) and first_click == False: > first_click = True > mouse_pos1 = mouse_pos > elif mouse_pressed == (1,0,0) and first_click == True: > mouse_pos2 = mouse_pos You don't actually tell us what mouse_pressed is, I presume (1, 0, 0) has some significance. But you check its value twice: if mouse_pressed = (1, 0, 0) and something-else: ... elif mouse_pressed = (1, 0, 0) and the opposite of something-else: ... That is best written as a single test of mouse_pressed, followed by an if-else: if mouse_pressed = (1, 0, 0): if something-else: ... else: ... What should "something-else" be? Your tests are written as: first_click == False first_click == True But both of them return True or False themselves, so you might as well write: (first_click == True) == True ((first_click == True) == True) == True (((first_click == True) == True) == True) == True # Help, help, when do I stop??? Of course nobody would bother with the extra tests, because they're redundant. But even doing *one* test is likewise redundant -- the place to stop is before you even start! Since first_click is already either True or False, all you need is to look at it directly: if mouse_pressed == (1,0,0): if first_click: mouse_pos2 = mouse_pos else: first_click = True mouse_pos2 = mouse_pos I'm not entirely sure about the logic with first_click. It seems to me that once it becomes True, it will always stay True, and if it becomes False, it will immediately be set to True. But perhaps you have some other code elsewhere that handles setting it to False. > #This is the decisional logic based on the mouse click coordinates, > previously captured. > #This first case fails although the print statement give me feedback > on the coordinates, > #that suggest it should have worked. It always falls through to the > final else. > if mouse_pos[1] < height/2 and mouse_pos2[1] > height/2: [...] I'm going to suggest another approach here. Since you only care whether the clicks are in the top or bottom half of the screen, let's make that explicit: click_in_bottom_half1 = mouse_pos[1] < height/2 click_in_bottom_half2 = mouse_pos2[1] < height/2 Now your decision logic becomes simple, and obvious. It documents itself: if click_in_bottom_half1 and click_in_bottom_half2: print "Both clicks in bottom half of screen" elif click_in_bottom_half1: print "The first click was in the bottom half." print "The second click was in the top half." elif click_in_bottom_half2: print "The first click was in the top half." print "The second click was in the bottom half." else: print "Both clicks in top half of screen" -- Steven D'Aprano ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On Sun, Sep 26, 2010 at 2:55 PM, Bill DeBroglie wrote:
> Which is great, but when I try and run the same code in the Terminal by
> calling a program I've written (print("hello world") again) I get the
> following:
>
>matthews-macbook:Dawson_Book matthewparrilla$ ./chapter_2.py
>./chapter_2.py: line 4: syntax error near unexpected token `"Hello
> World"'
>./chapter_2.py: line 4: `print("Hello World")'
>
> I'm using a Mac OS X 10.5.8. I had previously downloaded Python 2.6.5 AND
> 3.1 and had them both on this computer simultaneously but was having trouble
> with 3.1 crashing. I have since put both in the trash but obviously still
> have 2.6.5 on my system, I assume that was the version pre-installed on this
> Mac.
>
I think that's a shell issue, not specifically a Python issue. You need to
include a line at the top of the script to tell the OS how to find the
Python interpreter. Try adding this line at the beginning:
> #!/usr/bin/env python
>
> Your default Python install probably is NOT installed at /usr/bin/python,
but there should be a symbolic link there that points to the actual
location. If not, you'll need to adjust things a bit.
--
www.fsrtechnologies.com
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On Sun, Sep 26, 2010 at 6:03 PM, David Hutto wrote:
> On Sun, Sep 26, 2010 at 5:55 PM, Bill DeBroglie
> wrote:
>> Hello all,
>>
>> Totally new to this stuff and community so I very much appreciate the help
>> and apologize in advance for asking what might be a stupid question... Oh,
>> and I'm new to the lingo too!!
>>
>> I'm having issues running Python in Terminal. When I run code through the
>> interpreter I get:
>>
>> Python 2.6.5 (r236:73959, Mar 24 2010, 01:32:55)
>> [GCC 4.0.1 (Apple Inc. build 5943)] on darwin
>> Type "help", "copyright", "credits" or "license" for more
>> information.
>> >>> print("Hello World")
>> Hello World
>>
>> Which is great, but when I try and run the same code in the Terminal by
>> calling a program I've written (print("hello world") again) I get the
>> following:
>>
>> matthews-macbook:Dawson_Book matthewparrilla$ ./chapter_2.py
>> ./chapter_2.py: line 4: syntax error near unexpected token `"Hello
>> World"'
>> ./chapter_2.py: line 4: `print("Hello World")'
>
> Pretty sure it's the parentheses, but I'm not an expert. In python 3 you use
> print(), in 2.6 you either use import from __futur__ or print "string here".
I mean __future__ .
>
>>
>> I'm using a Mac OS X 10.5.8. I had previously downloaded Python 2.6.5 AND
>> 3.1 and had them both on this computer simultaneously but was having trouble
>> with 3.1 crashing. I have since put both in the trash but obviously still
>> have 2.6.5 on my system, I assume that was the version pre-installed on this
>> Mac.
>>
>> Any guidance at all would be much appreciated-- I'm totally lost and have
>> spent hours trying to figure this out.
>>
>> bdb
>> ___
>> Tutor maillist - tu...@python.org
>> To unsubscribe or change subscription options:
>> http://mail.python.org/mailman/listinfo/tutor
>>
>
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Issues In Terminal
On Sun, Sep 26, 2010 at 5:55 PM, Bill DeBroglie
wrote:
> Hello all,
>
> Totally new to this stuff and community so I very much appreciate the help
> and apologize in advance for asking what might be a stupid question... Oh,
> and I'm new to the lingo too!!
>
> I'm having issues running Python in Terminal. When I run code through the
> interpreter I get:
>
> Python 2.6.5 (r236:73959, Mar 24 2010, 01:32:55)
> [GCC 4.0.1 (Apple Inc. build 5943)] on darwin
> Type "help", "copyright", "credits" or "license" for more
> information.
> >>> print("Hello World")
> Hello World
>
> Which is great, but when I try and run the same code in the Terminal by
> calling a program I've written (print("hello world") again) I get the
> following:
>
> matthews-macbook:Dawson_Book matthewparrilla$ ./chapter_2.py
> ./chapter_2.py: line 4: syntax error near unexpected token `"Hello
> World"'
> ./chapter_2.py: line 4: `print("Hello World")'
Pretty sure it's the parentheses, but I'm not an expert. In python 3 you use
print(), in 2.6 you either use import from __futur__ or print "string here".
>
> I'm using a Mac OS X 10.5.8. I had previously downloaded Python 2.6.5 AND
> 3.1 and had them both on this computer simultaneously but was having trouble
> with 3.1 crashing. I have since put both in the trash but obviously still
> have 2.6.5 on my system, I assume that was the version pre-installed on this
> Mac.
>
> Any guidance at all would be much appreciated-- I'm totally lost and have
> spent hours trying to figure this out.
>
> bdb
> ___
> Tutor maillist - tu...@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
[Tutor] Issues In Terminal
Hello all,
Totally new to this stuff and community so I very much appreciate the
help and apologize in advance for asking what might be a stupid
question... Oh, and I'm new to the lingo too!!
I'm having issues running Python in Terminal. When I run code through
the interpreter I get:
Python 2.6.5 (r236:73959, Mar 24 2010, 01:32:55)
[GCC 4.0.1 (Apple Inc. build 5943)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> print("Hello World")
Hello World
Which is great, but when I try and run the same code in the Terminal
by calling a program I've written (print("hello world") again) I get
the following:
matthews-macbook:Dawson_Book matthewparrilla$ ./chapter_2.py
./chapter_2.py: line 4: syntax error near unexpected token `"Hello
World"'
./chapter_2.py: line 4: `print("Hello World")'
I'm using a Mac OS X 10.5.8. I had previously downloaded Python 2.6.5
AND 3.1 and had them both on this computer simultaneously but was
having trouble with 3.1 crashing. I have since put both in the trash
but obviously still have 2.6.5 on my system, I assume that was the
version pre-installed on this Mac.
Any guidance at all would be much appreciated-- I'm totally lost and
have spent hours trying to figure this out.
bdb
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] generating formatted output
On Sun, Sep 26, 2010 at 10:16 PM, Rance Hall wrote: > My app will be printing a series of documents that are the same each > time the doc is printed with the exception of the variables. Sort of > a MailMerge if you will. > > It seems to me that the easiest approach is to create a series of text > files with the layout and placeholders I need (again much like > MailMerge) > > And then do something like this: > > file = open(fileName, "r") #Opens the file in read-mode > text = file.read() #Reads the file and assigns the value to a variable > file.close() #Closes the file (read session) > text = text.replace(sourceText, replaceText) #there will be a > series of these. > file = open(fileName2, "w") #Opens a new file in write-mode. > file.write(text) > file.close() #Closes the file (write session) > > Then you can print the file or email it or whatever you need to do. > > There wont be too many of these replacements (think invoice template > with substitutes for customer information and a billing detail > section.) > > So my question is about the approach. Is this reasonable? Is there a > better way to do this? > I would suggest you take a look at string.Template or the str.format method. It may be somewhat simpler than doing a whole lot of replaces, perhaps faster as well. http://docs.python.org/library/string.html#template-strings http://docs.python.org/library/stdtypes.html#str.format Hugo ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Python And reading the Web - Javascript
On Sat, Sep 25, 2010 at 4:29 AM, Sayth Renshaw wrote: > I want to read some data from the web it will be text and numeric i > was planning to export it to a database. I was thinking while I am > learning maybe something simple like Sqlite or MySQL. > > I then want to read back data to perform sorting and some calculations on. > > This might be a good starting place for you. http://diveintopython.org/html_processing/extracting_data.html --Bill ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] a logic problem in an if statement
On Sun, Sep 26, 2010 at 1:36 PM, Bill Allen wrote: > I hate it when I do something like that!A combination of poor choice of > names for the variables and programming tunnel vision > Been there, done that! -- www.fsrtechnologies.com ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] a logic problem in an if statement
On Sun, Sep 26, 2010 at 3:12 PM, Marc Tompkins wrote: > On Sun, Sep 26, 2010 at 1:01 PM, Bill Allen wrote: > >> >> Any thoughts how I am going wrong here? >> >> Looks like you've got two different names for the first mouse click... > > mouse_pos1 = mouse_pos >> > > but > > if mouse_pos[1] < height/2 and mouse_pos2[1] > height/2: >> > > > Bingo! Yes, that's the problem. Should have been if mouse_pos1[1] < height/2 and mouse_pos2[1] > height/2: rather than if mouse_pos[1] < height/2 and mouse_pos2[1] > height/2: That was basically a typo to which I had become completely blind. I did it in the second case as well, but it did not affect the result in that case, making it even harder for me to spot. I hate it when I do something like that!A combination of poor choice of names for the variables and programming tunnel vision Many thanks, Bill ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] generating formatted output
My app will be printing a series of documents that are the same each time the doc is printed with the exception of the variables. Sort of a MailMerge if you will. It seems to me that the easiest approach is to create a series of text files with the layout and placeholders I need (again much like MailMerge) And then do something like this: file = open(fileName, "r") #Opens the file in read-mode text = file.read() #Reads the file and assigns the value to a variable file.close() #Closes the file (read session) text = text.replace(sourceText, replaceText) #there will be a series of these. file = open(fileName2, "w") #Opens a new file in write-mode. file.write(text) file.close() #Closes the file (write session) Then you can print the file or email it or whatever you need to do. There wont be too many of these replacements (think invoice template with substitutes for customer information and a billing detail section.) So my question is about the approach. Is this reasonable? Is there a better way to do this? ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] a logic problem in an if statement
On Sun, Sep 26, 2010 at 1:01 PM, Bill Allen wrote: > > Any thoughts how I am going wrong here? > > Looks like you've got two different names for the first mouse click... mouse_pos1 = mouse_pos > but > if mouse_pos[1] < height/2 and mouse_pos2[1] > height/2: > -- www.fsrtechnologies.com ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] a logic problem in an if statement
Ok, I am have a problem with some logic in a piece of code I am working
on. I have tinkered with it for hours and am stumped. Pretty sure I have
lost sight of the forest for the trees...
The purpose of this code is to take the coordinates on screen of the mouse
at the time of two mouse clicks, store that information and then make some
decisions based on that. No matter what I do, I am finding that the second
if statement block falls through to the last option. In the if I am try to
say "if the mouse click cursor position with the first click was in the
upper half of the screen (i.e. < height/2) and the second mouse click was in
the lower half of the screen (i.e. > height/2)". elif "both clicks happened
in the upper half of the screen" else "assume the clicks occurred in the
lower half of the screen". The second case and last case always seem to
work out ok. The first case falls through to the final case even though the
coordinates were appropriate for the first case logic.
Any thoughts how I am going wrong here?
--Bill
#This captures the coordinates the two mouse clicks, successfully.
mouse_pos is in the form (x,y), such as (204,102).
if mouse_pressed == (1,0,0) and first_click == False:
first_click = True
mouse_pos1 = mouse_pos
elif mouse_pressed == (1,0,0) and first_click == True:
mouse_pos2 = mouse_pos
#This is the decisional logic based on the mouse click coordinates,
previously captured.
#This first case fails although the print statement give me feedback on the
coordinates,
#that suggest it should have worked. It always falls through to the final
else.
if mouse_pos[1] < height/2 and mouse_pos2[1] > height/2:
print("use 0 for new yadjust")
print(height/2,"did first one", mouse_pos1[1], mouse_pos2[1])
#This case always works.
elif mouse_pos[1] < height/2 and mouse_pos2[1] < height/2:
print("use {0} for new
yadjust".format(1.05+(1-((height/2)-mouse_pos1[1])/(height/2
print(height/2,"did 2nd one", mouse_pos1[1], mouse_pos2[1])
#this case always works.
else:
print("use {0} for new
yadjust".format(-1.07+(1+((height/2)-mouse_pos2[1])/(height/2
print(height/2,"did last one", mouse_pos1[1], mouse_pos2[1])
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] class method problem
On Sun, Sep 26, 2010 at 3:14 AM, Steven D'Aprano wrote: > On Sun, 26 Sep 2010 02:26:25 pm David Hutto wrote: >> On Sat, Sep 25, 2010 at 9:16 PM, Steven D'Aprano > wrote: >> > On Sun, 26 Sep 2010 08:13:23 am David Hutto wrote: >> >> Since I had nothing else to do, but practice, this looks much >> >> better: >> >> >> >> def find(word, search): >> >> if search in word: >> >> print True >> >> else: >> >> print False > [...] >> OP wanted to find if a in b. Does my function do that?...Yep > > I didn't say that the function did the wrong thing, I said the name was > misleading for what it actually did. > > Why didn't you call the function len(), or deleteItemsFromPage()? > Because those names would be misleading, deceptive and silly. And so is > calling a function find() when it does something completely different > from the commonly understood meaning of the word "find". > > When you find something, you know where it is afterwards. Find to me, in the since of the OP's question means a hit. It was found in the furtherence into where, is up to the OP and their next question on the list that says now that I know it's there, where is it? In the context > of text searches, that means returning an offset to where the target is > found, or something similar. That's what str.find() does, and regular > expressions, and list.index(). Your "find" function is a membership > test, which is what the `in` operator is for. And I'm sure that with google, and my trust Building Skills in Python Manual at my side, I would have found those string/list functions, and overtime so will the OP, just as did at one point Mr. Miyagi. > > > > >> > Yes, we found your terms on the Internet, but we won't tell you >> > where. If you would like to find something else, we won't tell >> > you where that is either. >> >> It's not supposed to be a four line version of Google. > > I didn't say it was. I tried to inject a little humour into the email, > but it clearly didn't work. It did work, so I injected a little sarcasm back. > > > [...] >> > Even this is slightly misleading, because "text" doesn't need to be >> > an actual string. It could be any sequence, such as a list. I know this from a brief exercise I was working on before, but when learning, you can just give everything at once and expect it to be absorbed, you have to practive with the different types you can manipulate, but knowing what they are is helpful. But >> > this gives the *intention* of the function, which is to do text >> > searches. So this is (in my opinion) an acceptable compromise >> > between intention and generality. >> >> Semantics, are only important to those who didn't write it. > > "Semantics" means "meaning". If you are trying to tell me that the > meaning of programs -- their *purpose* -- is unimportant, that it > doesn't matter what a function does, I'm afraid you'll have your work > cut out to convince me. I meant if it's a small function that you might use once in a blue moon, and you know what it does for you, and since you wrote this small function, you're able to tell exactly what it does, and then it does this task as expected for you, then ok. If I was working with someone else on it, then I'm sure, they would suggest, that we use overlapping terminology we could agree on for the code at hand. (it would probably require a meeting or something.) > > The most important reader of your functions is... you. The function > might be fresh in your mind *today*, but tomorrow? Next week? Six > months from now when you discover a bug in your program and are trying > to remember how it works so you can fix it? It's five lines long. > > Trust me, any non-trivial program that you don't just use once and throw > away needs to be written with a careful eye to naming functions and > arguments. The ideal is that you should never need to write > documentation, because the functions and arguments document themselves. > (This is an ideal that never quite works in practice, but we can at > least *try*.) and I do. > > An excellent piece of advice I've been given is to write your program's > API -- the names of functions, the calling signatures, and so forth -- > as if the next person to maintain that code will be a psychopath with a > hair-trigger temper and a gun and who knows where you live. Since the > next person to maintain it will likely be you, you will save *much* > more time in the future by careful and consistent naming than it costs > to think of those names right now. Your comments are in the suggestion box, and you'll be happy to know, I even take advice from my critics...when it suits me. > > > > -- > Steven D'Aprano > ___ > Tutor maillist - tu...@python.org > To unsubscribe or change subscription options: > http://mail.python.org/mailman/listinfo/tutor > David Hutto ___ Tutor maillist - Tutor@python.org
Re: [Tutor] class method problem
On Sun, 26 Sep 2010 02:26:25 pm David Hutto wrote: > On Sat, Sep 25, 2010 at 9:16 PM, Steven D'Aprano wrote: > > On Sun, 26 Sep 2010 08:13:23 am David Hutto wrote: > >> Since I had nothing else to do, but practice, this looks much > >> better: > >> > >> def find(word, search): > >> if search in word: > >> print True > >> else: > >> print False [...] > OP wanted to find if a in b. Does my function do that?...Yep I didn't say that the function did the wrong thing, I said the name was misleading for what it actually did. Why didn't you call the function len(), or deleteItemsFromPage()? Because those names would be misleading, deceptive and silly. And so is calling a function find() when it does something completely different from the commonly understood meaning of the word "find". When you find something, you know where it is afterwards. In the context of text searches, that means returning an offset to where the target is found, or something similar. That's what str.find() does, and regular expressions, and list.index(). Your "find" function is a membership test, which is what the `in` operator is for. > > Yes, we found your terms on the Internet, but we won't tell you > > where. If you would like to find something else, we won't tell > > you where that is either. > > It's not supposed to be a four line version of Google. I didn't say it was. I tried to inject a little humour into the email, but it clearly didn't work. [...] > > Even this is slightly misleading, because "text" doesn't need to be > > an actual string. It could be any sequence, such as a list. But > > this gives the *intention* of the function, which is to do text > > searches. So this is (in my opinion) an acceptable compromise > > between intention and generality. > > Semantics, are only important to those who didn't write it. "Semantics" means "meaning". If you are trying to tell me that the meaning of programs -- their *purpose* -- is unimportant, that it doesn't matter what a function does, I'm afraid you'll have your work cut out to convince me. The most important reader of your functions is... you. The function might be fresh in your mind *today*, but tomorrow? Next week? Six months from now when you discover a bug in your program and are trying to remember how it works so you can fix it? Trust me, any non-trivial program that you don't just use once and throw away needs to be written with a careful eye to naming functions and arguments. The ideal is that you should never need to write documentation, because the functions and arguments document themselves. (This is an ideal that never quite works in practice, but we can at least *try*.) An excellent piece of advice I've been given is to write your program's API -- the names of functions, the calling signatures, and so forth -- as if the next person to maintain that code will be a psychopath with a hair-trigger temper and a gun and who knows where you live. Since the next person to maintain it will likely be you, you will save *much* more time in the future by careful and consistent naming than it costs to think of those names right now. -- Steven D'Aprano ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
