Re: [Tutor] Top posters to tutor list for 2008
Yeah, I agree. Interesting script, Kent. Surprisingly short. I didn't realize I wasn't in the top 5 posters for 2008! I guess I have a new year's resolution to be more helpful. Happy New Year, everyone! On Thu, Jan 1, 2009 at 9:23 AM, jadrifter wrote: > On Thu, 2009-01-01 at 09:34 -0500, Kent Johnson wrote: >> For several years I have been using a simple script to find the top 20 >> posters to the tutor list by web-scraping the archive pages. I thought >> others might be interested so here is the list for 2008 and the script >> that generates it. The lists for previous years (back to 2003) are at >> the end so everyone on the list doesn't hit the archives to find out >> :-) >> >> The script gives a simple example of datetime, urllib2 and >> BeautifulSoup. It consolidates names that vary by case but other >> variations are not detected. > > Kent, > > Thank you for this. I've been thinking about a web scraping script but > didn't have a clue how to go about it. Seeing someone else's practical > implementation is a huge help! > > A little serendipity to start 2009 off with. > > Happy New Year to all. > > John > > ___ > 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] Distinction between tuples and lists
"Kent Johnson" wrote For what it's worth, Guido has explicitly said, "Tuples are for heterogeneous data, list are for homogeneous data. Tuples are *not* read-only lists." That surprises me, he has always seemed more pragmatist than purist. However even Guido saying it doesn't alter the fact that in practice it is not a part of the language, merely a usage pattern. (Of course that could change in future versions like Python3000 but in the current incarnation, we have what we have) Personally, I take this with a grain of salt. I do tend to use tuples for things that are like records or structs, or often just for pairs of data (e.g. the elements of dict.items()), and lists for homogeneous collections, but that is more a matter of fitness for the purpose than dogma. Precisely. That was the point I tried to make earlier that in most usage scenarios lists tend to be used homogenously and tuples heterogenenously. But there is absolutely nothing in Python that mandates it. A good example of a homogenous tuple is a pair of values such as a point's x,y coordinates. And heterogenuous lists are also very useful at times, particularly when the only alternative would be to define a singleton class... Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Distinction between tuples and lists
On Thu, Jan 1, 2009 at 1:59 PM, Alan Gauld wrote: > lists/tuples serve many purposes in Python but one thing they most > definitely > do not do is act as hetero/homogenous containers. The authors of the blogs > may wish otherwise and indeed their debate seems to be geared around > what they would like to see in Python3000 rather than whats there now. For what it's worth, Guido has explicitly said, "Tuples are for heterogeneous data, list are for homogeneous data. Tuples are *not* read-only lists." http://mail.python.org/pipermail/python-dev/2003-March/033964.html This statement kicked off a very long thread on the python-dev list. For a summary of the discussion, and links to more of it, see the section "Ridiculously minor tweaks?" here: http://groups.google.com/group/comp.lang.python.announce/browse_thread/thread/b2a1ea28a26b3dfb/b2d17a69541e886b?lnk=gst Personally, I take this with a grain of salt. I do tend to use tuples for things that are like records or structs, or often just for pairs of data (e.g. the elements of dict.items()), and lists for homogeneous collections, but that is more a matter of fitness for the purpose than dogma. Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Inserting one dictionary into another
On Thu, Jan 1, 2009 at 11:04 AM, Keith Reed wrote:
> I'm having trouble assigning a dictionary as a value within another:
>
>
> Code Snippet Start
>
>for line in fromchild.readlines():
>itemarray = line.strip().split(":")
>parentdictkey = itemarray[0]
>print 'parentdictkey = ' + parentdictkey
>for index in range(len(headerinfo)):
>nesteddict[headerinfo[index]] = itemarray[index]
>#print nesteddict
>parentdict[parentdictkey] = nesteddict
>nesteddict.clear()
>print
>
> '-\n'
>print parentdict
The problem is that you are re-using the same dict rather than
creating a new one each time through the loop. Every value of
parentdict is the same; when you clear nesteddict you are clearing the
one shared dict.
Python assignment copies references, not values. If you don't
understand this, read this:
http://personalpages.tds.net/~kent37/kk/00012.html
The solution is easy; just make a new dict at the start of the loop:
nesteddict = {}
and get rid of the clear().
Kent
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Distinction between tuples and lists
"Christopher Mutel" wrote I stumbled across some discussion of why the fundamental difference between lists and tuples is not mutability, but hetero- versus homogeneous data, e.g. This is not a discussion about Pythons tuples v lists per se but about how some people think they should be used and their definitions/usage within Computing science generally. lists/tuples serve many purposes in Python but one thing they most definitely do not do is act as hetero/homogenous containers. The authors of the blogs may wish otherwise and indeed their debate seems to be geared around what they would like to see in Python3000 rather than whats there now. http://jtauber.com/blog/2006/04/15/python_tuples_are_not_just_constant_lists/ http://pyre.third-bit.com/blog/archives/000450.html However, after reading the cited discussions, my python books, etc., I have to admit I don't really understand this idea. What does it mean that "lists are intended for homogeneous sequences"? What is different about lists that would make them more suited for homogeneous sequences Nothing except the typical usage. Normally we use lists where we want to be able to change their content or iterate over them. The type of the data is often the same because the loop will try to treat each item identically. Tuples are often used as "lightweight records" so they hold fields of different type. Thus when accessing a database we get back a list of tuples (records) with each tuple containing the data firlds from the database. But Python does not enforce that and a list of lists would work just as well. And of course you can loop over a tuple as well as a list. I wouldn't get overly hung up on these kinds of debates. I've never seen any of the Python gurus make a big issue of it and experience tends to teach where each type is more appropriate. from what I understand, the idea of homo/heterogeneity seems orthogonal to mutability, which is the main distinction emphasized by e.g. Learning Python. They are orthogonal concepts, you are quite right. -- 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] Inserting one dictionary into another
I'm having trouble assigning a dictionary as a value within another:
Code Snippet Start
for line in fromchild.readlines():
itemarray = line.strip().split(":")
parentdictkey = itemarray[0]
print 'parentdictkey = ' + parentdictkey
for index in range(len(headerinfo)):
nesteddict[headerinfo[index]] = itemarray[index]
#print nesteddict
parentdict[parentdictkey] = nesteddict
nesteddict.clear()
print
'-\n'
print parentdict
Code Snippet End
Output Start
{'24': {}, '25': {}, '26': {}, '27': {}, '20': {}, '21': {}, '22': {},
'23': {}, '28': {}, '29': {}, '1': {}, '0': {}, '3': {}, '2': {}, '5':
{}, '4': {}, '7': {}, '6': {}, '9': {}, '8': {}, '11': {}, '10': {},
'13': {}, '12': {}, '15': {}, '14': {}, '17': {}, '16': {}, '19': {},
'18': {}, '31': {}, '30': {}}
Output End
The key looks correct below (it's a unique ID), but the dictionary
inserted below is empty.
If I uncomment the print statement above, the nesteddict dictionary
displays all the proper keys and values. So I know it's getting filled
OK, but it doesn't insert into the parent dictionary at all in the line:
parentdict[parentdictkey] = nesteddict
Any thoughts on how to properly insert the nested dictionary so that I
can refer to it?
--
Keith Reed
keith_r...@fastmail.net
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Distinction between tuples and lists
On Thu, Jan 1, 2009 at 9:43 AM, jadrifter wrote: > Being able to use struct notation (employee.age > instead of employee[4]) would be nice but also not that difficult to > implement as a class either. Python 2.6 added collections.namedtuple() which is a factory for classes like this: http://docs.python.org/dev/library/collections.html#collections.namedtuple Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Distinction between tuples and lists
On Thu, Jan 1, 2009 at 3:43 PM, jadrifter wrote: > Both data types are indexed and both can contain homogeneous (same as) > or heterogeneous (different than) data. I get that lists are analogous > to a C linked lists as tuples are to C structs. I get that the > flexibility of one and the stability of the other makes them useful in > different situations. Being able to use struct notation (employee.age > instead of employee[4]) would be nice but also not that difficult to > implement as a class either. The similar construct in Python to this struct notation would be to use a dictionary rather than a tuple (or list); you could then use employee['age'] etcetera. -- André Engels, andreeng...@gmail.com ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Distinction between tuples and lists
On Thu, Jan 1, 2009 at 3:07 PM, Christopher Mutel wrote: > Hello all- > > I stumbled across some discussion of why the fundamental difference > between lists and tuples is not mutability, but hetero- versus > homogeneous data, e.g. > > http://jtauber.com/blog/2006/04/15/python_tuples_are_not_just_constant_lists/ > > http://pyre.third-bit.com/blog/archives/000450.html > > However, after reading the cited discussions, my python books, etc., I > have to admit I don't really understand this idea. What does it mean > that "lists are intended for homogeneous sequences"? What is different > about lists that would make them more suited for homogeneous sequences > than heterogeneous sequences (or vice-versa for tuples)? In the end, > from what I understand, the idea of homo/heterogeneity seems > orthogonal to mutability, which is the main distinction emphasized by > e.g. Learning Python. > > I would greatly appreciate any help provided, Lists do have all kinds of operations that tuples do not have. Many of those will change the order of the elements in the list, for example by adding or removing an element, or exchanging some elements. Because of this, many of those operations are only useful on homogenous sequences - which means that the second element could also be the first or the fourth, and would then still mean the same thing, though in another place. On the other hand, if I have a heterogenous sequence, that is, if what is in the second position could either not appear on the fourth position (because the second is an integer and the fourth a string, for example), or would mean something completely different there (for example if the second and fourth were both floats, but the second was a price in dollars and the fourth a mass in kilograms), then many of those operations make no sense (in fact, the only one I think _would_ make sense for heterogenous sequences is changing the value of the element at a specified position). Thus, if you have a heterogenous sequence, all those nifty operations on lists have no use, and dropping them for getting the niceties of immutability (like usage as the key in a dictionary) is getting something for almost nothing, thus you might as well use a tuple. -- André Engels, andreeng...@gmail.com ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Top posters to tutor list for 2008
On Thu, 2009-01-01 at 09:34 -0500, Kent Johnson wrote: > For several years I have been using a simple script to find the top 20 > posters to the tutor list by web-scraping the archive pages. I thought > others might be interested so here is the list for 2008 and the script > that generates it. The lists for previous years (back to 2003) are at > the end so everyone on the list doesn't hit the archives to find out > :-) > > The script gives a simple example of datetime, urllib2 and > BeautifulSoup. It consolidates names that vary by case but other > variations are not detected. Kent, Thank you for this. I've been thinking about a web scraping script but didn't have a clue how to go about it. Seeing someone else's practical implementation is a huge help! A little serendipity to start 2009 off with. Happy New Year to all. John ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Distinction between tuples and lists
On Thu, 2009-01-01 at 15:07 +0100, Christopher Mutel wrote: > Hello all- > > I stumbled across some discussion of why the fundamental difference > between lists and tuples is not mutability, but hetero- versus > homogeneous data, e.g. > > http://jtauber.com/blog/2006/04/15/python_tuples_are_not_just_constant_lists/ > > http://pyre.third-bit.com/blog/archives/000450.html > > However, after reading the cited discussions, my python books, etc., I > have to admit I don't really understand this idea. What does it mean > that "lists are intended for homogeneous sequences"? What is different > about lists that would make them more suited for homogeneous sequences > than heterogeneous sequences (or vice-versa for tuples)? In the end, > from what I understand, the idea of homo/heterogeneity seems > orthogonal to mutability, which is the main distinction emphasized by > e.g. Learning Python. > > I would greatly appreciate any help provided, > > -Chris Mutel > ___ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor I read it and don't get their emphasis or perhaps level of concern. As explanatory pieces these two blogs aren't very helpful. They provide a few assertions with no apparent (to me) attempt to support or explain them. Both data types are indexed and both can contain homogeneous (same as) or heterogeneous (different than) data. I get that lists are analogous to a C linked lists as tuples are to C structs. I get that the flexibility of one and the stability of the other makes them useful in different situations. Being able to use struct notation (employee.age instead of employee[4]) would be nice but also not that difficult to implement as a class either. On re-re-re-reading it (I hate it when I don't get the point) I think they're arguing for a more structured "You must use this properly" approach to be built into the language. And that makes some sense. Who would want a database call (say to an employee database table) that returned a record as a list? On the other hand who would want a record set (group of records) returned as a tuple? There's no reason to assume the third record will always be that of John Smith but the 3rd field of John Smiths's record better be his phone number and not his social security number or else wackiness will ensue. Still, aint it great to work with a language that lets us bounce back and forth between structures as we please? John Purser ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] Top posters to tutor list for 2008
For several years I have been using a simple script to find the top 20
posters to the tutor list by web-scraping the archive pages. I thought
others might be interested so here is the list for 2008 and the script
that generates it. The lists for previous years (back to 2003) are at
the end so everyone on the list doesn't hit the archives to find out
:-)
The script gives a simple example of datetime, urllib2 and
BeautifulSoup. It consolidates names that vary by case but other
variations are not detected.
Alan, I thought you might have passed me this year but we are both off
a little :-) Somehow I have posted an average of 2.8 times per day for
the last four years...
Happy New Year everyone!
Kent
2008
Kent Johnson 931
Alan Gauld 820
bob gailer 247
Dick Moores 191
W W 142
Wayne Watson 106
John Fouhy 97
Steve Willoughby 91
Lie Ryan 88
bhaaluu 85
Marc Tompkins 83
Michael Langford 71
Tiger12506 70
Andreas Kostyrka 64
Dinesh B Vadhia 64
wesley chun 58
Tim Golden 57
Chris Fuller 54
Ricardo Aráoz 53
spir 53
#
''' Counts all posts to Python-tutor by author'''
# -*- coding: latin-1 -*-
from datetime import date, timedelta
import operator, urllib2
from BeautifulSoup import BeautifulSoup
today = date.today()
for year in [2008]:
startDate = date(year, 1, 1)
endDate = date(year, 12, 31)
thirtyOne = timedelta(days=31)
counts = {}
# Collect all the counts for a year by scraping the monthly author
archive pages
while startDate < endDate and startDate < today:
dateString = startDate.strftime('%Y-%B')
url = 'http://mail.python.org/pipermail/tutor/%s/author.html'
% dateString
data = urllib2.urlopen(url).read()
soup = BeautifulSoup(data)
li = soup.findAll('li')[2:-2]
for l in li:
name = l.i.string.strip()
counts[name] = counts.get(name, 0) + 1
startDate += thirtyOne
# Consolidate names that vary by case under the most popular spelling
nameMap = dict() # Map lower-case name to most popular name
for name, count in sorted(counts.iteritems(),
key=operator.itemgetter(1), reverse=True):
lower = name.lower()
if lower in nameMap:
# Add counts for a name we have seen already
counts[nameMap[lower]] += count
else:
nameMap[lower] = name
print
print year
print ''
for name, count in sorted(counts.iteritems(),
key=operator.itemgetter(1), reverse=True)[:20]:
print name.encode('latin-1', 'xmlcharrefreplace'), count
print
# Results as of 12/31/2008:
'''
2003
Danny Yoo 617
Alan Gauld 421
Jeff Shannon 283
Magnus Lycka 242
Bob Gailer 195
Magnus =?iso-8859-1?Q?Lyck=E5?= 166
alan.ga...@bt.com 161
Kirk Bailey 155
Gregor Lingl 152
Lloyd Kvam 142
Andrei 118
Sean 'Shaleh' Perry 117
Magnus Lyckå 113
Michael Janssen 113
Erik Price 100
Lee Harr 88
Terry Carroll 87
Daniel Ehrenberg 78
Abel Daniel 76
Charlie Clark 74
2004
Alan Gauld 699
Danny Yoo 530
Kent Johnson 451
Lloyd Kvam 146
Dick Moores 145
Liam Clarke 140
Brian van den Broek 122
Karl Pflästerer 109
Jacob S. 101
Andrei 99
Chad Crabtree 93
Bob Gailer 91
Magnus Lycka 91
Terry Carroll 88
Marilyn Davis 84
Gregor Lingl 73
Dave S 73
Bill Mill 71
Isr Gish 71
Lee Harr 67
2005
Kent Johnson 1189
Danny Yoo 767
Alan Gauld 565
Alan G 317
Liam Clarke 298
Max Noel 203
Nathan Pinno 197
Brian van den Broek 190
Jacob S. 154
jfouhy at paradise.net.nz 135
Alberto Troiano 128
Bernard Lebel 119
Joseph Quigley 101
Terry Carroll 93
Andrei 79
D. Hartley 77
John Fouhy 73
bob 73
Hugo González Monteverde 72
Orri Ganel 69
2006
Kent Johnson 913
Alan Gauld 815
Danny Yoo 448
Luke Paireepinart 242
John Fouhy 187
Chris Hengge 166
Bob Gailer 134
Dick Moores 129
Asrarahmed Kadri 119
Terry Carroll 111
Python 94
Mike Hansen 74
Liam Clarke 72
Carroll, Barry 67
Kermit Rose 66
anil maran 66
Hugo González Monteverde 65
wesley chun 63
Christopher Spears 53
Michael Lange 51
2007
Kent Johnson 1052
Alan Gauld 938
Luke Paireepinart 260
Dick Moores 203
Eric Brunson 164
Terry Carroll 128
Tiger12506 112
John Fouhy 105
Bob Gailer 97
Ricardo Aráoz 93
Rikard Bosnjakovic 93
bhaaluu 88
elis aeris 83
Andreas Kostyrka 77
Michael Langford 68
shawn bright 63
Tim Golden 62
Dave Kuhlman 62
wormwood_3 53
wesley chun 53
2008
Kent Johnson 931
Alan Gauld 820
bob gailer 247
Dick Moores 191
W W 142
Wayne Watson 106
John Fouhy 97
Steve Willoughby 91
Lie Ryan 88
bhaaluu 85
Marc Tompkins 83
Michael Langford 71
Tiger12506 70
Andreas Kostyrka 64
Dinesh B Vadhia 64
wesley chun 58
Tim Golden 57
Chris Fuller 54
Ricardo Aráoz 53
spir 53
'''
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
[Tutor] Distinction between tuples and lists
Hello all- I stumbled across some discussion of why the fundamental difference between lists and tuples is not mutability, but hetero- versus homogeneous data, e.g. http://jtauber.com/blog/2006/04/15/python_tuples_are_not_just_constant_lists/ http://pyre.third-bit.com/blog/archives/000450.html However, after reading the cited discussions, my python books, etc., I have to admit I don't really understand this idea. What does it mean that "lists are intended for homogeneous sequences"? What is different about lists that would make them more suited for homogeneous sequences than heterogeneous sequences (or vice-versa for tuples)? In the end, from what I understand, the idea of homo/heterogeneity seems orthogonal to mutability, which is the main distinction emphasized by e.g. Learning Python. I would greatly appreciate any help provided, -Chris Mutel ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Fw: Creating sub-menus?
On Thu, 1 Jan 2009 10:58:44 + (GMT)
ALAN GAULD wrote:
> Forwarding to the list
> Please use ReplyAll when responding.
>
>
>
>
> On Wed, Dec 31, 2008 at 4:10 AM, Alan Gauld wrote:
>
> "nathan virgil" wrote
>
>
>
> Each menu is a function that prints out options, saves a raw_input as the
> variable choice, and returns choice. In the main menu, each option leads to
> a sub-menu. After choice is defined, however, the sub-menu "tags" the value
> of choice.
>
>
> Yes that can all work.
>
>
>
> Then create a loop of while choice !=q, run current_menu, and include a
> bunch of statements along the lines of:
>
> if choice == :
> current_menu =
>
>
> Consider using a dictionary keyed by your combined choice values.
> Then the big if/elif chain shrinks to
>
> returnValue = FuncDict[choice](params)
>
> The only challenge with this route is making all the functions
> take a single input argument. But that argument can be a tuple :-)
>
> Dictionaries? Tuples? I just figured out functions, so I'm very new. I'm
> still working on
> understanding lists. I know what I have probably isn't the best solution for
> what I'm trying to
> do, but I'm trying to work with the little that I know.
>
>
>
>
> This seems like it would work, but for some reason, every time I run the
> code, it freezes after I give input from the main menu. Can anybody help? I
> can show my source code, but indentation doesn't seem to copy/paste very
> well, so it may be a bit hard to read...
>
>
> Try putting it on the pastebin web site and sending us the URL.
> That gives us colour coding of syntax too which helps read it!
>
>
> http://pastebin.com/m252eea7a
Below a copy of the menu control loop of your code, with some corrections.
denis
#In development
choice = "start"# rather use None or "" as
not-yet-setvalue
current_menu = main_menu() # current_menu = main_menu : see below
while choice != "q":
current_menu # current_menu() : it's a call
#Main Menu results
if choice == "1":
current_menu = temp_conv_menu()# idem: rather no '()' for consistency
elif choice == "2":
current_menu = area_menu()
elif choice == "3":
current_menu = perim_menu()
### inside sub-menus, you simply forget to process "back to main menu"
choices
### in all active branches below, you also forget to go back up a menu
level
### after execution of the terminal choice
## so that, once reached, the user is stick in a terminal branch
elif choice == "t1":
temp = input("Celsius temperature: ")
print "Fahrenheit:", celsius_to_fahrenheit(temp)
* current_menu = temp_conv_menu / main_menu
* [possibly with "x = raw_input("ok?")" before]
elif choice == "t2":
temp = input("Fahrenheit temperature: ")
print "Celsius:", fahrenheit_to_celsius(temp)
* elif "t3":
* current_menu = main_menu
elif choice =="a1":
s = input("Width:")
print "Square area:", area_s(s)
elif choice =="a2":
w = input("Width:")
h = input("Height:")
print "Rectangle area:", area_r(w, h)
elif choice =="a3":
none
elif choice =="a4":
r=input("Radius of circle: ")
print "Circle area:", area_c(r)
In the sub-menus, I would also give a distinctive key for "back to main menu"
(eg 'b' or 'm')
rather than a number. [all comments / changes / additions untested]
--
la vida e estranya
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
[Tutor] Fw: Creating sub-menus?
Forwarding to the list Please use ReplyAll when responding. On Wed, Dec 31, 2008 at 4:10 AM, Alan Gauld wrote: "nathan virgil" wrote Each menu is a function that prints out options, saves a raw_input as the variable choice, and returns choice. In the main menu, each option leads to a sub-menu. After choice is defined, however, the sub-menu "tags" the value of choice. Yes that can all work. Then create a loop of while choice !=q, run current_menu, and include a bunch of statements along the lines of: if choice == : current_menu = Consider using a dictionary keyed by your combined choice values. Then the big if/elif chain shrinks to returnValue = FuncDict[choice](params) The only challenge with this route is making all the functions take a single input argument. But that argument can be a tuple :-) Dictionaries? Tuples? I just figured out functions, so I'm very new. I'm still working on understanding lists. I know what I have probably isn't the best solution for what I'm trying to do, but I'm trying to work with the little that I know. This seems like it would work, but for some reason, every time I run the code, it freezes after I give input from the main menu. Can anybody help? I can show my source code, but indentation doesn't seem to copy/paste very well, so it may be a bit hard to read... Try putting it on the pastebin web site and sending us the URL. That gives us colour coding of syntax too which helps read it! http://pastebin.com/m252eea7a It's a simple formula calculator, so the point isn't really the content. I don't have all the formulas coded in yet, but the way I see it, if I can't access the sub-menus that lead to the formulas, then it doesn't do me any good to have the formulas. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
