On Thu, Jun 13, 2013 at 9:07 AM, Mark Janssen <dreamingforw...@gmail.com> wrote: >>> You're right. I was being sloppy. > Okay, now I'm a bit confused. "print" is both a <keyword> and a > member of the builtins. What happens then?
Ah! I see where we are getting confused. When you said keyword, did you mean keyword, a person who has lost his parents... oops, that's Pirates of Penzance. Ahem. In Python 2.x, 'print' is actually a keyword. It has its own special syntax (eg printing to something other than stdout), and absolutely cannot be overridden: Python 2.7.4 (default, Apr 6 2013, 19:54:46) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> print=1 File "<stdin>", line 1 print=1 ^ SyntaxError: invalid syntax But in Python 3, it's a builtin function: Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (In tel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> foo=print >>> print=1 >>> foo("Hello, world!") Hello, world! > And abs(), max(), hex() and such seemed like keywords to my > scientific self (due to never having to "include"/import them), but > clearly their not. The builtins don't need to be imported, but they're identifiers like anything else. They're a namespace that gets searched after module-globals. int = 1 def foo(): int = 2 print(int) This has double shadowing :) It'll print 2, because locals get searched first, but if you remove that assignment then it'll print 1, and if you remove _that_ one, then it'll print "<class 'int'>". There's nothing magical about the name int, but before raising NameError, the interpreter will look for it in builtins. You can even add more "builtins", though I would *strongly* advise against this unless you have a really REALLY good reason: >>> __builtins__.helloworld=123 >>> helloworld 123 >>> helloworld=234 >>> helloworld 234 >>> del helloworld >>> helloworld 123 > And int, list, tuple, dict and such always seemed > like keywords to my CS self because they were included in Python's > type system (like "int" would be in C). Yep, but in Python, types/classes are themselves objects, so you can pass them around like anything else. This also downgrades them from "language keyword" to "always-available name", which in effect upgrades your _own_ classes to the same level. > They are all one-step removed from keywords. And yet, since they are > not in a separate namespace, they should not be used as variable > names. Perhaps since they are very different from one another, they > should be put in separate namespaces off of a global, root > namespace... (math, string, etc.) There's no point forcing them to be looked up in a two-step process. If you want that, you can simply reference them as __builtins__.whatever, but you can instead just reference them as the unadorned name whatever. They contribute heavily to the simplicity and readability of Python code - imagine if every call to len() had to be qualified. ChrisA -- http://mail.python.org/mailman/listinfo/python-list