Python went well enough in the classroom last school year that I'll be using it again this year. Last year we had to leave aside graphics programming because of problems with getting a working graphics library on Mac with Python 3 (Pygame, specifically. There are folks working on its problems.) But the students had a lot of fun even with the text programs from Invent Your Own Computer Programs with Python and their own variations on them. So that's enough to make Python worthwhile in class.
We'll be doing the same, and if Pygame works, we'll be adding that as well. Frankly, dealing with version differences between Python 3.x and 2.x in class is something that I don't feel would be productive, so if we don't have a Pygame that works with Python 3 on our Macs in the school's lab, I won't be going to Python 2.x to get it. We'll move on to something else. For middle school, we'll probably continue with more text programs and have fun with formatting and such. For the high school classes, we'll move over to Greenfoot with Java to do a video game project. In the past, my high school students have dealt with the differences between Python to Java without much trouble. The middle school students who have outside experience with programming are similarly capable, but those who haven't or don't do any sort of programming or scripting outside of class struggle with the changes, so it's best just to avoid the change over at that level.
Prior to Python, the students will have had experience with HTML and CSS. Which presents another opportunity for output that's more interesting than simple console text--Python-generated HTML/CSS code. I've found HTML and CSS to be a good introduction to a lot of the concepts of programming, so it's often the first thing we do along those lines.
Finally, I can't say enough about how great a resource Al Sweigart's book is for my classes. It's a great introduction to programming, no matter the language, and Python makes a good starting language in spite of the "formatting as syntax" issues. It makes a great 21st century version of the great beginners' BASIC books of the 70s and 80s.
Here's hoping the Pygame/graphics issues will get resolved. If not, I need to take another look and see if the turtle graphics package is included in Python or will work with minimal effort on my part. If so, then I can prepare some lessons of my own using it to pick up where the text section of the Sweigart book leaves off.
Sunday, September 30, 2012
Wednesday, February 29, 2012
Python 2, Python 3, and Pygame
I've been using Al Sweigart's excellent book as the core of a beginning programming curriculum for middle school students for the past four weeks. So far, it's going great.
But there have been some problems.
First, I was originally intending to use the version of Python already installed on our new Mac Minis. It's a version of Python 2.7, perfectly adequate for new programmers with no interest in which version of a language they're using. That would save me the trouble of doing 14 installs of a different version of Python.
But the book uses Python 3. I had looked at several possible books for the class, and hadn't entirely cottoned on to the fact this one had the exercises in Python 3. So I had a choice of trying to have the students see the differences between 2 and 3 on their own from the very first, before they have any idea what they're up to, rewriting the programs for the installed version of Python, or installing Python 3.
I decided to install Python 3.
Later, the book uses the pygame library to give Python graphics and sound capabilities. Unfortunately, there's no distribution package of pygame for Python 3 on Macintosh, only Windows (and possibly some of the Linux distros.)
So I tried to install pygame for 2.7. At least by the time my students get to chapter 17 in the Invent Your Own Computer Games with Python, I believe I'll be able to discuss the 2 vs. 3 syntax differences with them. Hopefully they'll be able to translate on their own. I expect to be doing Python 2 rewrites of the programs myself for next year's classes (unless a working pygame package appears for Python 3 on OS X Lion in the meanwhile).
It took me quite a few tries and a fair bit of my limited class prep time to find a combination of Python and Pygame that works on our school's lab computers. I discuss the details of that on my other blog. But I found a combo that appears to work today (pygame imports, and the first graphics program from the book runs.) I have installed it on 3 out of 14 computers so far, hopefully I'll have time to get it everywhere before the students reach that chapter.
Ass it is, I had already had to spend significant amounts of time developing alternatives to using the rest of the book after Chapter 16. My plan was to shift to turtle graphics, which appear to be bundled with Python 3.2 regardless of platform.
A Bit of a Rant
Frankly, as much as python has worked well for my students so far, if I had known the time and trouble I'd be running into I would never have even started using Python in class. There is no good Python solution here, everything is no better than a 9/10s solution.
Python, by itself, is pretty darn good. The current features in the standard distribution include graphics without requiring any external package installs on all 3 platforms I've run it on: Mac OS X, both 10.6 and 10.7, Win7, and Ubuntu 9.04 and 9.10. It's turtle graphics, but for the needs of my new programmers that fits the bill. I'd like to see standard sound support across platforms. Really, anything that supposes itself to be a general purpose language on this side of AmigaBASIC should be expected to support graphics and sound as standard features. Preferably without a ton of boilerplate. Here's hoping future Python versions can manage this.
The change in the print statement between Python 2 and 3 is maddening. The rationalizations aren't especially convincing to me, at least with respect to breaking backward compatibility and requiring silliness like "end=''" to suppress newlines. What great new ability has been gained for this cost? Nothing that's convinced me of the value yet. I expect this was discussed in PEPs somewhere. Parens, OK, I can possibly see adding those if it does something for added functionality (orthagonality with functions is not a convincing argument, to me.) But failing to provide a simple means of suppressing a newline like the earlier trailing comma, while going to a parametric assignment...that certainly appears well out of line with Python's apparent philosophy.
Now, pygame. No 3.X distributable for OS X? On what's touted as so wonderfully multi-platform? And it's not as if we're talking about a new version of Python that we need to just wait a week or two to get a binary for platform X ready. But Windows gets first class treatment. Mac OS? Not so much. Great multi-platform commitment, there.
I'm not at home to suggestions of compiling my own, I'm afraid. I could, for myself. But the world has a lot of machines that aren't just my own development system. The OS and hardware in our school's lab differs to what I run on my own systems. I haven't the time or desire to set up one of the school's systems as a dev box for porting software, then porting what claims to be a highly popular multi-platform package to the school's computers. Especially when they are a very popular hardware/OS mix already. I shouldn't be expected to put a large commitment of time and energy into getting this working at a point when I don't even know if it has any value to me yet.
And that still doesn't get me a package for Python 3, just for 32/64-bit, unless I move files by hand or make my own installer. While I'm a newcomer to python, for the most part, myself.
Good, but Not Quite Ready for Prime Time
That all said, I think I and my students will get plenty of value out of Python, pygame, and Al's book. But the price of entry for the package deal was too high. And we've still got this Python 2/3 version switch problem sitting in front of us, which I hope isn't going to turn into another big problem, but stay a little problem--though one that still needlessly eats up our limited class time with explanations of syntax differences rather than real new material.
Frankly, I couldn't possibly recommend doing this to others teaching at this level, as things stand at present. Things that would change this:
Edit: I've read PEP 3105 now. I still don't agree with breaking backward compatibility, as opposed to adding the function and deprecating the statement syntax. I also think there's reason for a simpler newline suppression syntax than the end parameter. Not every Python programmer is going to share the viewpoint of a python-dev wonk. ;) Some of them just want something simple that does the basics (print a string, suppress linefeed as needed--that's all.) In this case, the extended usage has broken the basic usage.
Addt'l edit: Reading "Python Regrets" now. The example syntax there of write() and writeln() would do the trick, from my teacher's standpoint. While I'm aware that redundancy is not a Python value, I think adding write() and writeln() to 3.x while keeping but deprecating the print statement for the term of one major version would have been a better approach (drop print when 4 comes.) Possibly limit print by rolling it back to a more limited version that doesn't allow redirection during 3, if the clock could be rolled back. Obviously at this point it's somewhat too late for that.
But there have been some problems.
First, I was originally intending to use the version of Python already installed on our new Mac Minis. It's a version of Python 2.7, perfectly adequate for new programmers with no interest in which version of a language they're using. That would save me the trouble of doing 14 installs of a different version of Python.
But the book uses Python 3. I had looked at several possible books for the class, and hadn't entirely cottoned on to the fact this one had the exercises in Python 3. So I had a choice of trying to have the students see the differences between 2 and 3 on their own from the very first, before they have any idea what they're up to, rewriting the programs for the installed version of Python, or installing Python 3.
I decided to install Python 3.
Later, the book uses the pygame library to give Python graphics and sound capabilities. Unfortunately, there's no distribution package of pygame for Python 3 on Macintosh, only Windows (and possibly some of the Linux distros.)
So I tried to install pygame for 2.7. At least by the time my students get to chapter 17 in the Invent Your Own Computer Games with Python, I believe I'll be able to discuss the 2 vs. 3 syntax differences with them. Hopefully they'll be able to translate on their own. I expect to be doing Python 2 rewrites of the programs myself for next year's classes (unless a working pygame package appears for Python 3 on OS X Lion in the meanwhile).
It took me quite a few tries and a fair bit of my limited class prep time to find a combination of Python and Pygame that works on our school's lab computers. I discuss the details of that on my other blog. But I found a combo that appears to work today (pygame imports, and the first graphics program from the book runs.) I have installed it on 3 out of 14 computers so far, hopefully I'll have time to get it everywhere before the students reach that chapter.
Ass it is, I had already had to spend significant amounts of time developing alternatives to using the rest of the book after Chapter 16. My plan was to shift to turtle graphics, which appear to be bundled with Python 3.2 regardless of platform.
A Bit of a Rant
Frankly, as much as python has worked well for my students so far, if I had known the time and trouble I'd be running into I would never have even started using Python in class. There is no good Python solution here, everything is no better than a 9/10s solution.
Python, by itself, is pretty darn good. The current features in the standard distribution include graphics without requiring any external package installs on all 3 platforms I've run it on: Mac OS X, both 10.6 and 10.7, Win7, and Ubuntu 9.04 and 9.10. It's turtle graphics, but for the needs of my new programmers that fits the bill. I'd like to see standard sound support across platforms. Really, anything that supposes itself to be a general purpose language on this side of AmigaBASIC should be expected to support graphics and sound as standard features. Preferably without a ton of boilerplate. Here's hoping future Python versions can manage this.
The change in the print statement between Python 2 and 3 is maddening. The rationalizations aren't especially convincing to me, at least with respect to breaking backward compatibility and requiring silliness like "end=''" to suppress newlines. What great new ability has been gained for this cost? Nothing that's convinced me of the value yet. I expect this was discussed in PEPs somewhere. Parens, OK, I can possibly see adding those if it does something for added functionality (orthagonality with functions is not a convincing argument, to me.) But failing to provide a simple means of suppressing a newline like the earlier trailing comma, while going to a parametric assignment...that certainly appears well out of line with Python's apparent philosophy.
Now, pygame. No 3.X distributable for OS X? On what's touted as so wonderfully multi-platform? And it's not as if we're talking about a new version of Python that we need to just wait a week or two to get a binary for platform X ready. But Windows gets first class treatment. Mac OS? Not so much. Great multi-platform commitment, there.
I'm not at home to suggestions of compiling my own, I'm afraid. I could, for myself. But the world has a lot of machines that aren't just my own development system. The OS and hardware in our school's lab differs to what I run on my own systems. I haven't the time or desire to set up one of the school's systems as a dev box for porting software, then porting what claims to be a highly popular multi-platform package to the school's computers. Especially when they are a very popular hardware/OS mix already. I shouldn't be expected to put a large commitment of time and energy into getting this working at a point when I don't even know if it has any value to me yet.
And that still doesn't get me a package for Python 3, just for 32/64-bit, unless I move files by hand or make my own installer. While I'm a newcomer to python, for the most part, myself.
Good, but Not Quite Ready for Prime Time
That all said, I think I and my students will get plenty of value out of Python, pygame, and Al's book. But the price of entry for the package deal was too high. And we've still got this Python 2/3 version switch problem sitting in front of us, which I hope isn't going to turn into another big problem, but stay a little problem--though one that still needlessly eats up our limited class time with explanations of syntax differences rather than real new material.
Frankly, I couldn't possibly recommend doing this to others teaching at this level, as things stand at present. Things that would change this:
- A book of the character and caliber of Al's that relies on no external package installs, just a current version of Python. Or,
- An unambiguous install of Python and a matching compatible version of pygame, plus a book with matching code for that version in the exercises. Preferably as a single bundle installed all at once.
Edit: I've read PEP 3105 now. I still don't agree with breaking backward compatibility, as opposed to adding the function and deprecating the statement syntax. I also think there's reason for a simpler newline suppression syntax than the end parameter. Not every Python programmer is going to share the viewpoint of a python-dev wonk. ;) Some of them just want something simple that does the basics (print a string, suppress linefeed as needed--that's all.) In this case, the extended usage has broken the basic usage.
Addt'l edit: Reading "Python Regrets" now. The example syntax there of write() and writeln() would do the trick, from my teacher's standpoint. While I'm aware that redundancy is not a Python value, I think adding write() and writeln() to 3.x while keeping but deprecating the print statement for the term of one major version would have been a better approach (drop print when 4 comes.) Possibly limit print by rolling it back to a more limited version that doesn't allow redirection during 3, if the clock could be rolled back. Obviously at this point it's somewhat too late for that.
Wednesday, February 8, 2012
type() and input()
Playing around with type(), a handy function that shows the type of data stored, and input():
The interpreter teaches the concept that data types will be recognised at input. When using the input() function, however, all data is treated as a string. This is documented, but it's not apparently consistent to new users.
The fix is simple, but this also assumes the input data can be converted.
I'm new to this, there may be some other function that accepts and validates only numeric input data.
The interpreter teaches the concept that data types will be recognised at input. When using the input() function, however, all data is treated as a string. This is documented, but it's not apparently consistent to new users.
The fix is simple, but this also assumes the input data can be converted.
I'm new to this, there may be some other function that accepts and validates only numeric input data.
Thursday, January 26, 2012
Beginner's Resources
I've turned up some nice beginner's resources on Python:
Dive into Python is an online book teaching Python step by step, the way I like to approach things in my classes.
Python Tutorials for Kids 8+ also looks like it'll be very useful.
Invent You Own Computer Games with Python is a course using games as the draw. I've ordered a hardcopy of the book, and the book is available online for free. This makes it easy to afford using it in my classes (and students can't claim to have forgotten their textbook when it's online!) I'll be trying it out with my middle school classes this semester.
There are many other python resources out there. Add your favorites in the comments, please!
Dive into Python is an online book teaching Python step by step, the way I like to approach things in my classes.
Python Tutorials for Kids 8+ also looks like it'll be very useful.
Invent You Own Computer Games with Python is a course using games as the draw. I've ordered a hardcopy of the book, and the book is available online for free. This makes it easy to afford using it in my classes (and students can't claim to have forgotten their textbook when it's online!) I'll be trying it out with my middle school classes this semester.
There are many other python resources out there. Add your favorites in the comments, please!
Tuesday, January 24, 2012
Python 2, Python 3
Python 3 kinda gets different right away, for the beginner. It's not huge, just different.
The simple, free, and easy print 'Hello there!' becomes print ('Hello There!'). Doesn't look like too big a difference. Unless you're a beginner, where every single bit of unfamiliar punctuation becomes a step into darkness.
I'm planning on using Python in the classes I teach. I've already used it as one of the "broadening" languages I use. These are languages that aren't central to the class, but I give the students a bit of time with them as a way of letting them have a look at other languages, so that the language we are using doesn't become the only one they've ever seen.
So far, the core of my teaching has been around Java. We don't start right off in Java. We do some command line stuff, we get through some of the introductory concepts there and in BASIC. Then we do a lot with HTML and CSS, which is a great lead-in for more formal programming.
Python, Ruby, C, LISP and LOGO all have a place in my classroom. LOGO becomes one of the languages I use a lot with the middle school classes (6th-8th.) All my classes at least get a look at all these languages, to the Hello, World! level and maybe a bit more if time allows.
I'm strongly considering using Python as the main language for either middle school or high school or both next year. This immediately raises the version 2 or version 3 question.
One of my constraints, my time, immediately suggests an answer to this question. Python 2 is already installed on all the systems in the school lab. If I want 3, I need to go through and spend my own time installing it and checking it out on all the systems. Whereas 2 is there (2.7 right now, as I recall.) All I have to do is have the students open a command line and type 'python'.
All my systems at home are also on Python 2, except for my Windows 7 machine. It had no Python on it, I just installed the latest of the Windows easy installer versions on it last night (3.2-something, I believe.) I played with it for a bit, I'd already seen some information on the differences between 2 and 3 and was able to work my way through without any problems on the basis of those fuzzy memories. I'm not exactly a Python power user, so I only have to cover limited ground.
The same goes for my classes. The concepts we learn about controlling the computer and organizing tasks for it are more important that what language we use, or which version of a language we use. So I don't see going with 2 as a problem. I expect to have a Python 3 familiarity exercise, at least, as part of the class once we're well along and comfortable with Python in general. Just as I have familiarity exercises with different languages including those mentioned above and others that change from year to year.
Online interpreters/compilers help us do that without me having to install new software on the school computers. But those aren't adequate for our regular class work, just for "try it and see" type exercises.
So Python 2 it is. For now.
I'm planning to start doing some curriculum development with my middle schoolers in this Spring semester. They're enthusiastic about being guinea pigs for me. That'll make it easier for me to decide before year end how far to go with Python in my classes, and to have a start on the new materials for next year before summer, the time when I do most of my curriculum development.
Spring semester this year will still have me using Java with Greenfoot for my high school students. They're enthusiastic about that, too. It's been very successful for me for the past several years. It takes time and work to change directions in a class like this, the relative merits of the different languages are only one factor in the choice of language. Personally, I like both languages a lot. Each has advantages that I wish both shared.
Ruby is in the mix, too. Either for an expanded role in the class (such as replacing the time we used to spend on Windows command line), or as the main language in one or the other level of class. I try not to confuse things by introducing too many different languages, so I've got to be careful that I structure things so that one thing builds on another, rather than each new thing being something that adds confusion.
The simple, free, and easy print 'Hello there!' becomes print ('Hello There!'). Doesn't look like too big a difference. Unless you're a beginner, where every single bit of unfamiliar punctuation becomes a step into darkness.
I'm planning on using Python in the classes I teach. I've already used it as one of the "broadening" languages I use. These are languages that aren't central to the class, but I give the students a bit of time with them as a way of letting them have a look at other languages, so that the language we are using doesn't become the only one they've ever seen.
So far, the core of my teaching has been around Java. We don't start right off in Java. We do some command line stuff, we get through some of the introductory concepts there and in BASIC. Then we do a lot with HTML and CSS, which is a great lead-in for more formal programming.
Python, Ruby, C, LISP and LOGO all have a place in my classroom. LOGO becomes one of the languages I use a lot with the middle school classes (6th-8th.) All my classes at least get a look at all these languages, to the Hello, World! level and maybe a bit more if time allows.
I'm strongly considering using Python as the main language for either middle school or high school or both next year. This immediately raises the version 2 or version 3 question.
One of my constraints, my time, immediately suggests an answer to this question. Python 2 is already installed on all the systems in the school lab. If I want 3, I need to go through and spend my own time installing it and checking it out on all the systems. Whereas 2 is there (2.7 right now, as I recall.) All I have to do is have the students open a command line and type 'python'.
All my systems at home are also on Python 2, except for my Windows 7 machine. It had no Python on it, I just installed the latest of the Windows easy installer versions on it last night (3.2-something, I believe.) I played with it for a bit, I'd already seen some information on the differences between 2 and 3 and was able to work my way through without any problems on the basis of those fuzzy memories. I'm not exactly a Python power user, so I only have to cover limited ground.
The same goes for my classes. The concepts we learn about controlling the computer and organizing tasks for it are more important that what language we use, or which version of a language we use. So I don't see going with 2 as a problem. I expect to have a Python 3 familiarity exercise, at least, as part of the class once we're well along and comfortable with Python in general. Just as I have familiarity exercises with different languages including those mentioned above and others that change from year to year.
Online interpreters/compilers help us do that without me having to install new software on the school computers. But those aren't adequate for our regular class work, just for "try it and see" type exercises.
So Python 2 it is. For now.
I'm planning to start doing some curriculum development with my middle schoolers in this Spring semester. They're enthusiastic about being guinea pigs for me. That'll make it easier for me to decide before year end how far to go with Python in my classes, and to have a start on the new materials for next year before summer, the time when I do most of my curriculum development.
Spring semester this year will still have me using Java with Greenfoot for my high school students. They're enthusiastic about that, too. It's been very successful for me for the past several years. It takes time and work to change directions in a class like this, the relative merits of the different languages are only one factor in the choice of language. Personally, I like both languages a lot. Each has advantages that I wish both shared.
Ruby is in the mix, too. Either for an expanded role in the class (such as replacing the time we used to spend on Windows command line), or as the main language in one or the other level of class. I try not to confuse things by introducing too many different languages, so I've got to be careful that I structure things so that one thing builds on another, rather than each new thing being something that adds confusion.
Sunday, January 22, 2012
IDLE Windows and Saves
Let's have a look at 'idle', the GUI-fied command line for python...
OK, looks pretty standard. It's got "Save" in the menu. Let's give it a try...
Let's see what got saved:
mag@rincewind:~/programming/python$ cat python-shell.txt
Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15)
[GCC 4.4.1] on linux2
Type "copyright", "credits" or "license()" for more information.
****************************************************************
Personal firewall software may warn about the connection IDLE
makes to its subprocess using this computer's internal loopback
interface. This connection is not visible on any external
interface and no data is sent to or received from the Internet.
****************************************************************
IDLE 2.6.4
>>> print 'I\'m a lumberjack and I\'m OK!"
SyntaxError: EOL while scanning string literal
>>> print 'I\'m a lumberjack and I\'m OK!'
I'm a lumberjack and I'm OK!
>>>
Yuck. Everything got saved. How do we save a program? Lessee...
Aha, a "New Window" item on the menu. Maybe that'll give me an uncluttered window. But what about the prompt? Ah, let's just click it and find out.
Ah, a clear window appears. Let's type something in and save it as 'larch.py'.
Let's have a look at the file:
mag@rincewind:~/programming/python$ cat larch.py
print "I'm a lumberjack and I'm OK!"
That's more like it. Let's try running it from the command line...
mag@rincewind:~/programming/python$ python larch.py
I'm a lumberjack and I'm OK!
OK, so idle works as an editor. Now, how about running it in idle? Hmmm...'Open' in the interactive window?
Nope. That just opens the other window.
I can copy and paste, and that works, but it's not very clean. Gotta be a better way.
D'oh! There's a menu item right there that says "Run". Let's see..."Python Shell"?
Nope, that just takes me back to the other window. How about "Run Module F5"?
>>> ================================ RESTART ================================
>>>
I'm a lumberjack and I'm OK!
>>>
Aha! That's the ticket.
Time for a soda.
OK, looks pretty standard. It's got "Save" in the menu. Let's give it a try...
Let's see what got saved:
mag@rincewind:~/programming/python$ cat python-shell.txt
Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15)
[GCC 4.4.1] on linux2
Type "copyright", "credits" or "license()" for more information.
****************************************************************
Personal firewall software may warn about the connection IDLE
makes to its subprocess using this computer's internal loopback
interface. This connection is not visible on any external
interface and no data is sent to or received from the Internet.
****************************************************************
IDLE 2.6.4
>>> print 'I\'m a lumberjack and I\'m OK!"
SyntaxError: EOL while scanning string literal
>>> print 'I\'m a lumberjack and I\'m OK!'
I'm a lumberjack and I'm OK!
>>>
Yuck. Everything got saved. How do we save a program? Lessee...
Aha, a "New Window" item on the menu. Maybe that'll give me an uncluttered window. But what about the prompt? Ah, let's just click it and find out.
Ah, a clear window appears. Let's type something in and save it as 'larch.py'.
Let's have a look at the file:
mag@rincewind:~/programming/python$ cat larch.py
print "I'm a lumberjack and I'm OK!"
That's more like it. Let's try running it from the command line...
mag@rincewind:~/programming/python$ python larch.py
I'm a lumberjack and I'm OK!
OK, so idle works as an editor. Now, how about running it in idle? Hmmm...'Open' in the interactive window?
Nope. That just opens the other window.
I can copy and paste, and that works, but it's not very clean. Gotta be a better way.
D'oh! There's a menu item right there that says "Run". Let's see..."Python Shell"?
Nope, that just takes me back to the other window. How about "Run Module F5"?
>>> ================================ RESTART ================================
>>>
I'm a lumberjack and I'm OK!
>>>
Aha! That's the ticket.
Time for a soda.
Saturday, January 21, 2012
Playing with Print
print prints things. Well, duh. Let's see how....
>>>print 'hello'
hello
OK, single quotes work.
>>>print "Hello"
Hello
And double quotes. What about printing quotes? I bet I can nest one type of quote inside the others...
>>>print "Python's Print Puts Pennies in Paragraphs"
Python's Print Puts Pennies in Paragraphs
>>>print 'The Python Quoth "Bring out your dead!"'
The Python Quoth "Bring out your dead!"
What about printing both sorts together?
Hmmm...
Maybe I could concatenate...
>>>print 'The Python Quoth "' + "You're no fun anymore!" + '"'
The Python Quoth "You're no fun anymore!"
That worked. But Python's tricky. Maybe there's an easier way. Multiple quotes?
>>> print ""The Python Quoth "I'm a lumberjack and I'm OK!"""
File "", line 1
print ""The Python Quoth "I'm a lumberjack and I'm OK!"""
^
SyntaxError: invalid syntax
>>> print ''The Python Quoth "I'm a lumberjack and I'm OK!"''
File "", line 1
print ''The Python Quoth "I'm a lumberjack and I'm OK!"''
^
SyntaxError: invalid syntax
>>> print '''The Python Quoth "I'm a lumberjack and I'm OK!"''''
File "", line 1
print '''The Python Quoth "I'm a lumberjack and I'm OK!"''''
^
SyntaxError: EOL while scanning string literal
>>> print """'The Python Quoth "I'm a lumberjack and I'm OK!""""
File "", line 1
print """'The Python Quoth "I'm a lumberjack and I'm OK!""""
^
SyntaxError: EOL while scanning string literal
>>> print """'The Python Quoth "I'm a lumberjack and I'm OK!"""
'The Python Quoth "I'm a lumberjack and I'm OK!
Dang, lost the final double quotes. Lessee...
>>> print """'The Python Quoth "I'm a lumberjack and I'm OK!\""""
'The Python Quoth "I'm a lumberjack and I'm OK!"
Aha! Escaping quotes works!
>>>print 'I\'m a lumberjack and I\'m OK!'
I'm a lumberjack and I'm OK!
Let's try mixing some numbers in.
>>> print 'There are ' + 3 + 'Pythons upon the desk.'
Traceback (most recent call last):
File "", line 1, in
TypeError: cannot concatenate 'str' and 'int' objects
>>> print 'There are ', 3, ' Pythons upon the desk.'
There are 3 Pythons upon the desk.
Commas work, but too many spaces are in there.
>>> print 'There are',3,'Pythons upon the',3,'rd desk.'
There are 3 Pythons upon the 3 rd desk.
OK, the first number is spaced right, how do we get the other one without spaces?
>>> print 'There are',3,'Pythons upon the '+ str(3) +'rd desk.'
There are 3 Pythons upon the 3rd desk.
OK, so we can concatenate with '+', but only if it's a string.
We can use numerals if we put it together with a comma, but then we get an added space.
We can make a numeral into a string with str() and then we can concatenate with + so that we don't get added spaces.
I think I get it.
I'm sure there are a dozen other ways to do this, and at least ten of them may be better. But that'll do for now.
>>>print 'hello'
hello
OK, single quotes work.
>>>print "Hello"
Hello
And double quotes. What about printing quotes? I bet I can nest one type of quote inside the others...
>>>print "Python's Print Puts Pennies in Paragraphs"
Python's Print Puts Pennies in Paragraphs
>>>print 'The Python Quoth "Bring out your dead!"'
The Python Quoth "Bring out your dead!"
What about printing both sorts together?
Hmmm...
Maybe I could concatenate...
>>>print 'The Python Quoth "' + "You're no fun anymore!" + '"'
The Python Quoth "You're no fun anymore!"
That worked. But Python's tricky. Maybe there's an easier way. Multiple quotes?
>>> print ""The Python Quoth "I'm a lumberjack and I'm OK!"""
File "
print ""The Python Quoth "I'm a lumberjack and I'm OK!"""
^
SyntaxError: invalid syntax
>>> print ''The Python Quoth "I'm a lumberjack and I'm OK!"''
File "
print ''The Python Quoth "I'm a lumberjack and I'm OK!"''
^
SyntaxError: invalid syntax
>>> print '''The Python Quoth "I'm a lumberjack and I'm OK!"''''
File "
print '''The Python Quoth "I'm a lumberjack and I'm OK!"''''
^
SyntaxError: EOL while scanning string literal
>>> print """'The Python Quoth "I'm a lumberjack and I'm OK!""""
File "
print """'The Python Quoth "I'm a lumberjack and I'm OK!""""
^
SyntaxError: EOL while scanning string literal
>>> print """'The Python Quoth "I'm a lumberjack and I'm OK!"""
'The Python Quoth "I'm a lumberjack and I'm OK!
Dang, lost the final double quotes. Lessee...
>>> print """'The Python Quoth "I'm a lumberjack and I'm OK!\""""
'The Python Quoth "I'm a lumberjack and I'm OK!"
Aha! Escaping quotes works!
>>>print 'I\'m a lumberjack and I\'m OK!'
I'm a lumberjack and I'm OK!
Let's try mixing some numbers in.
>>> print 'There are ' + 3 + 'Pythons upon the desk.'
Traceback (most recent call last):
File "
TypeError: cannot concatenate 'str' and 'int' objects
>>> print 'There are ', 3, ' Pythons upon the desk.'
There are 3 Pythons upon the desk.
Commas work, but too many spaces are in there.
>>> print 'There are',3,'Pythons upon the',3,'rd desk.'
There are 3 Pythons upon the 3 rd desk.
OK, the first number is spaced right, how do we get the other one without spaces?
>>> print 'There are',3,'Pythons upon the '+ str(3) +'rd desk.'
There are 3 Pythons upon the 3rd desk.
OK, so we can concatenate with '+', but only if it's a string.
We can use numerals if we put it together with a comma, but then we get an added space.
We can make a numeral into a string with str() and then we can concatenate with + so that we don't get added spaces.
I think I get it.
I'm sure there are a dozen other ways to do this, and at least ten of them may be better. But that'll do for now.
Subscribe to:
Posts (Atom)