What I like about namespaces is the idea is intuitively obvious to anyone spending any time in academia, because every professor is one. It takes time to learn just what each means by this or that key term, although supposedly in math it's easier, because all the definitions are agreed upon in advance, axioms too, plus rules of deduction, so the theorems also. My idea of a good first move, after booting some Python GUI shell for the first time, is to go dir(). IDLE 1.2b2
dir() ['__builtins__', '__doc__', '__name__']
Already the filling is: we're not alone. And what are those weird __xxx__ things. They look strange. Thinking like a computer scientist, you mentally pair tics and decide we have three quoted words, like a list of some time. See? Python fits your brain. You're already thinking like a pro. Instead of words we say strings, and a space is just one more character (ASCII 32). But here comes the *big* revelation:
dir(__builtins__) ['ArithmeticError', 'AssertionError', 'AttributeError', 'BaseException', 'DeprecationWarning', 'EOFError', 'Ellipsis', 'EnvironmentError', 'Exception', 'False', 'FloatingPointError', 'FutureWarning', 'GeneratorExit', 'IOError', 'ImportError', 'ImportWarning', 'IndentationError', 'IndexError', 'KeyError', 'KeyboardInterrupt', 'LookupError', 'MemoryError', 'NameError', 'None', 'NotImplemented', 'NotImplementedError', 'OSError', 'OverflowError', 'PendingDeprecationWarning', 'ReferenceError', 'RuntimeError', 'RuntimeWarning', 'StandardError', 'StopIteration', 'SyntaxError', 'SyntaxWarning', 'SystemError', 'SystemExit', 'TabError', 'True', 'TypeError', 'UnboundLocalError', 'UnicodeDecodeError', 'UnicodeEncodeError', 'UnicodeError', 'UnicodeTranslateError', 'UserWarning', 'ValueError', 'Warning', 'WindowsError', 'ZeroDivisionError', '_', '__debug__', '__doc__', '__import__', '__name__', 'abs', 'all', 'any', 'apply', 'basestring', 'bool', 'buffer', 'callable', 'chr', 'classmethod', 'cmp', 'coerce', 'compile', 'complex', 'copyright', 'credits', 'delattr', 'dict', 'dir', 'divmod', 'enumerate', 'eval', 'execfile', 'exit', 'file', 'filter', 'float', 'frozenset', 'getattr', 'globals', 'hasattr', 'hash', 'help', 'hex', 'id', 'input', 'int', 'intern', 'isinstance', 'issubclass', 'iter', 'len', 'license', 'list', 'locals', 'long', 'map', 'max', 'min', 'object', 'oct', 'open', 'ord', 'pow', 'property', 'quit', 'range', 'raw_input', 'reduce', 'reload', 'repr', 'reversed', 'round', 'set', 'setattr', 'slice', 'sorted', 'staticmethod', 'str', 'sum', 'super', 'tuple', 'type', 'unichr', 'unicode', 'vars', 'xrange', 'zip']
Ohmygod omygod, what *is* going on now? Obviously errors are a big part of the Python experience (why else would that be the major topic in like the whole first half of the list?), and then you have a bunch of underunder guys (ribs?), and then some short words, including one especially ugly one with an internal underbar. Now, as the teacher, I've probably just been projecting so far, encouraging students to all focus on the big screen up front, and the bouncing laser pointer dot, which drifts over this stuff as I vocalize about content. So I'm the one that shows 'em they can now select from the above list and go (for example):
help(iter) Help on built-in function iter in module __builtin__:
iter(...) iter(collection) -> iterator iter(callable, sentinel) -> iterator Get an iterator from an object. In the first form, the argument must supply its own iterator, or be a sequence. In the second form, the callable is called until it returns the sentinel. Aha. Lots of jargon. iterator, callable, argument, sequence... Let's try another.
help(max) Help on built-in function max in module __builtin__:
max(...) max(iterable[, key=func]) -> value max(a, b, c, ...[, key=func]) -> value With a single iterable argument, return its largest item. With two or more arguments, return the largest argument. Hmmmmm, overlapping jargon. There's that iterable notion again. Gotta learn that square brackets mean *optional* stuff, i.e. you don't need it. Is a bare list an iterable?
max([1,2,3,4]) 4
Looks like. Let's explore some more....
max([1,2,3,4]) 4 a = [1,2,3,4] b = iter(a) id(a) 23472728 id(b) 23397744 type(a) <type 'list'> type(b) <type 'listiterator'> max(b) 4
and so on... This might be more for adults with some programming experience already, but not much with Python. But you see how I'm bringing the namespace idea in right away. Immediately upon being in the shell, we're already in one. Best to look around. dir() and help() are your friends. Later, we'll import. But already, we're in a huge fish tank, lots to see and do. Could take an hour at least, to get through this aquarium -- very interactive, so now I'll turn off the projector (actually, I'll leave what you see). Go crazy, play, explore. We'll start up with the formal talk in about 15 minutes, and answer any questions. Bathroom is down the hall to your right. Kirby
kirby urner wrote:
What I like about namespaces is the idea is intuitively obvious to anyone spending any time in academia, because every professor is one. It takes time to learn just what each means by this or that key term, although supposedly in math it's easier, because all the definitions are agreed upon in advance, axioms too, plus rules of deduction, so the theorems also.
My idea of a good first move, after booting some Python GUI shell for the first time, is to go dir().
IDLE 1.2b2
dir()
['__builtins__', '__doc__', '__name__']
Already the filling is: we're not alone. And what are those weird __xxx__ things. They look strange. Thinking like a computer scientist, you mentally pair tics and decide we have three quoted words, like a list of some time. See? Python fits your brain. You're already thinking like a pro. Instead of words we say strings, and a space is just one more character (ASCII 32).
Damn it if I don't agree. Exactly where I would start as well. Art
Go crazy, play, explore. We'll start up with the formal talk in about 15 minutes, and answer any questions. Bathroom is down the hall to your right.
Kirby
Now, reviewing what we did just before break:
a = [1,2,3,4] b = iter(a) id(a) 23472728 id(b) 23397744 type(a) <type 'list'> type(b) <type 'listiterator'>
I'm showing that feeding a list to the builtin iter, gets you back a new type of object, and hence a *different* object. I know they're different because their ids are different. But what if I feed b, already a listiterator, to iter *again*?
c=iter(b) c <listiterator object at 0x01650570> id(c) 23397744 hex(23397744) '0x1650570' b <listiterator object at 0x01650570> b is c True
You see there's some logic here. Whereas iter ate 'a' to return a different 'b', when it eats 'b' it just returns the same object. Yes, I've referenced said object with the letter 'c', using the assignment operator (=), but "under the hood", b and c have the same id, expressed in decimal, but from the hex conversion you see there's a match. Just to confirm, I use the "is" keyword. What do I mean by keyword? A keyword is different from a builtin. By default, IDLE will colorize the latter purple, the former orange. Let's look at keywords for a minute, and in doing so, we'll discover this powerful keyword used to augment our namespace with additional namespaces: import...
help('keyword') Help on module keyword:
NAME keyword - Keywords (from "graminit.c") FILE d:\python25\lib\keyword.py DESCRIPTION This file is automatically generated; please don't muck it up! To update the symbols in this file, 'cd' to the top directory of the python source tree after building the interpreter and run: python Lib/keyword.py FUNCTIONS iskeyword = __contains__(...) x.__contains__(y) <==> y in x. DATA __all__ = ['iskeyword', 'kwlist'] kwlist = ['and', 'as', 'assert', 'break', 'class', 'continue', 'def', ...
import keyword
keyword.iskeyword('is') True
keyword.kwlist ['and', 'as', 'assert', 'break', 'class', 'continue', 'def', 'del', 'elif', 'else', 'except', 'exec', 'finally', 'for', 'from', 'global', 'if', 'import', 'in', 'is', 'lambda', 'not', 'or', 'pass', 'print', 'raise', 'return', 'try', 'while', 'with', 'yield']
Now that's pretty short for a language's list of key words. Many languages have more. How many is this?
len(keyword.kwlist) 31
Just 31, compared to how many builtins (pause to let people try the len builtin -- drop a few hints as they flounder):
len(dir(__builtins__)) 134
Yeah, woah, big difference. Lots more builtins. Let's check our current namespace again:
dir() ['__builtins__', '__doc__', '__name__', 'a', 'b', 'c', 'keyword']
Aha -- those letter references we created, are still here with us. And keyword, a module, has joined __builtins__. We can start purging the namespace if we feel it's too crowded. Restart IDLE, or selectively use del:
del a del b
Note: even though be is gone, c still references the object in memory. That object won't be garbage collected until no name references it any more.
c <listiterator object at 0x01650570> del c
What if we try deleting __builtins__?
del __builtins__ dir() ['__builtins__', '__doc__', '__name__', 'keyword']
Didn't work. Nothing happens. But the keyword namespace is easy to get rid of:
del keyword dir() ['__builtins__', '__doc__', '__name__']
Interesting. Now here's some interesting stuff:
dir(__doc__) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__']
type(__doc__) <type 'NoneType'>
type(None) <type 'NoneType'>
dir(None) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__']
__doc__ references nothing at this point and so its type (the type of object it references) is None. There's just this one None in memory:
id(None) 505251592 id(__doc__) 505251592
OK, we've reached the end of our first session. Next time we meet, we'll import visual and start making stuff happen on top of OpenGL, using the VPython package. You'll start to appreciate what Python will really do for you. If you don't remember Vectors from high school, don't worry. They're pretty easy, especially with VPython at your elbow. But first, here's a puzzle:
134 < 31 False
The '<' operator behaves as you'd expect, but that operator nowhere appeared in the list of builtins or as a keyword. Why is it operational, if it's not in the namespace. Here's a hint. Go dir(134) or dir(31). More next time. Kirby
It took about 150 emails but all of this raw_input() discussion has finally brought us to a revalatory new place! raw_input() and print() are comfy places to begin because that's where my high school Pascal text began. And that's where my college C text began. And that's where "How to think like a computer scientist" begins... Two texts that have inspired my thinking this year are "Learn to Program" from the Pragmatic Bookshelf and "Why's (poignant) guide to Ruby", the single best piece of CS writing I've seen in at least two years. Anyone who loved newsprint BASIC manuals full of nerdy jokes and little ballpoint pen comics will love it : http://poignantguide.net/ruby/ Kevin PS. The Ruby v. Python debate is moot. On 9/13/06, Arthur <ajsiegel@optonline.net> wrote:
kirby urner wrote:
What I like about namespaces is the idea is intuitively obvious to anyone spending any time in academia, because every professor is one. It takes time to learn just what each means by this or that key term, although supposedly in math it's easier, because all the definitions are agreed upon in advance, axioms too, plus rules of deduction, so the theorems also.
My idea of a good first move, after booting some Python GUI shell for the first time, is to go dir().
IDLE 1.2b2
dir()
['__builtins__', '__doc__', '__name__']
Already the filling is: we're not alone. And what are those weird __xxx__ things. They look strange. Thinking like a computer scientist, you mentally pair tics and decide we have three quoted words, like a list of some time. See? Python fits your brain. You're already thinking like a pro. Instead of words we say strings, and a space is just one more character (ASCII 32).
Damn it if I don't agree.
Exactly where I would start as well.
Art
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
del __builtins__ dir() ['__builtins__', '__doc__', '__name__', 'keyword']
Didn't work. Nothing happens. But the keyword namespace is easy to get rid of:
<wizard type="smartypants"> <comment> Wrongo, buddy boy! Something *does* happen when you delete __builtins__. It sticks around *as a dictionary* named __builtins__, but you've purged it from the namespace *as a module* -- which is what allowed dir to treat it as such, and return just a list. Look below:
============= RESTART ============== __builtins__ <module '__builtin__' (built-in)>
type(__builtins__) <type 'module'>
del __builtins__ type(__builtins__) <type 'dict'>
del __builtins__ type(__builtins__) <type 'dict'>
Now if you go dir(__builtins__), it'll just give you the namespace of a regular dictionary, and if you put __builtins__ on the command line and press enter, you'll get a dump of that dictionary's contents (an invocation of its __repr__ method). </comment> </wizard> Thanks a lot Smartypants. I'm sure we'll be seeing *you* here again. Kirby
My idea of a good first move, after booting some Python GUI shell for the first time, is to go dir().
IDLE 1.2b2
dir()
['__builtins__', '__doc__', '__name__']
Already the filling is: we're not alone. And what are those weird __xxx__ things. They look strange.
Easy. Snake ribs ;) Art
participants (3)
-
Arthur -
Kevin Driscoll -
kirby urner