I wrote -
Any opinions as to whether the following is an insight, or the kind of pseudo-incite I tend to realize I have had when I sober up in the morning?
That the "readability" of Python is built-in to the structure of the language in a largely non-obvious way, and has little to do with white space significance, surface level syntax, etc.
Python is a "naming" language. The interpreter is working with assigned names of objects more directly and more significantly than in other languages (of which I am aware). As a programmer, one is conversing with the interpreter by way of these names, as names and objects are closely bound. And it therefore seems intuitively sensible to make names significant, because in fact they are significant at a low and technical level.
As opposed to C, for example. Which sort of laughs of you for going to the trouble for adding extra keystrokes to placeholders.
Or something along these lines.
I'll sink to commenting on my own post. Not the first time. Sobering up - I still think the observation has real substance. Though it is only an insight to the extent that it is non-obvious. I guess that depends on who you are and where you are coming from. It took me a while to get here. Art
I'll sink to commenting on my own post. Not the first time.
Sobering up - I still think the observation has real substance.
Though it is only an insight to the extent that it is non-obvious. I guess that depends on who you are and where you are coming from.
It took me a while to get here.
Art
Guido once scolded me by suggesting I set up a blog rather than "bothering" people on public forums. I have concluded that Guido is never *completely* wrong,,,;) It seems to me that the reason that decorators are/were so controversial - why so many people find them unPythonic - is that they violate the principle I am trying to get my hands on here. As it happens, given that decorators were to be, I supported Guido's choice of syntax - feeling it effectively communicated that we were dealing with the exception to the rule. I don't know the extent to which Guido's decision there was intuitive, or if consciously anywhere along the lines that I am suggesting. Art
Hi Art -- I've been thinking about your observation, but haven't come up with a really coherent way to extend your thinking, in such a way that a prove I know what you mean. Per Wittgenstein (a philosopher I like, and his philo the focus another eGroup I post in), if you go 1, 12, 42 and I go 92, 162, that sort of proves I have an idea about the rule you're using (or maybe not?). In Pythonic terms, you've written a generator, and I've reverse engineered it, so now we're able to compare iterable.next() outputs, to see if we get the same answers. What I'm thinking sort of in parallel, divergently or convergently I don't know yet, is that Python gets us away from any strict notion of "primitives." In other languages, lip service may be paid to "everything is an object" but when you get right down to it, you need syntactical tricks to make that a reality. In C# you can "box" an integer, to treat it like a class object, and in Java I guess you grab an instance of Integer or something. But in neither language can you do what you can in Python: enter dir(2) in the shell and get a dump of everything 1 "knows how to do" (something I show the first day in my Python classes; I call it "making 2 spill its guts" (OK, these are high schoolers, still somewhat in to grossology)). As for decorators, at the moment I'm having no problems with the new syntax. You may have seen that post on the calculus. I was gratified to discover that @ may be used to hand off the function that follows to a class (to some __init__ method), so long as what's returned is likewise a function. Wait, is that what I did? No, not exactly. I fed the function to class and thereby get back an *object*, but this object was *callable*, and that's enough to make its behavior *like* a function's. So everything worked. Cool. Here's the code again, which automatically lists 3rd degree polynomial outputs *and* its 2nd degree derivative: #==== class Function: def __init__(self, f): self.f = lambda x: f(x) def __add__(self, other): return Function(lambda x: self.f(x) + other.f(x)) def __sub__(self,other): return Function(lambda x: self.f(x) - other.f(x)) def __mul__(self,other): return Function(lambda x: self.f(x) * other.f(x)) def __div__(self,other): return Function(lambda x: self.f(x) / other.f(x)) def __call__(self,x): """call wrapped function with argument x, return result""" return self.f(x) class Pair: def __init__(self, u, du): self.u = u self.du = du def __add__(self, other): return Pair(self.u + other.u, self.du + other.du) def __sub__(self, other): return Pair(self.u - other.u, self.du - other.du) def __mul__(self, other): return Pair(self.u * other.u, \ self.du * other.u + self.u * other.du) def __div__(self, other): return Pair(self.u/other.u, \ (self.du * other.u - self.u * other.du)/other.u**2) @Function def ident(x): return x @Function def one(x): return 1 p1 = Pair(ident, one) newp = p1 * p1 * p1 print [newp.u(i) for i in range(-5,6)] print [newp.du(i) for i in range(-5,6)] #==== Kirby
Kirby Urner wrote:
As for decorators, at the moment I'm having no problems with the new syntax. You may have seen that post on the calculus. I was gratified to discover that @ may be used to hand off the function that follows to a class (to some __init__ method), so long as what's returned is likewise a function. Wait, is that what I did? No, not exactly. I fed the function to class and thereby get back an *object*, but this object was *callable*, and that's enough to make its behavior *like* a function's. So everything worked. Cool.
Although everybody already knows this, I'm sure, a function actually is a class, so technically it is a function if you have all the things you get if you dir() a function. The only weird part here is that there's an endless number of functions (actually methods, which are treated exactly the same as functions for our purposes) inside these classes, like __repr__, so you can do:
def afunction(): return 0
afunction() 0 dir(afunction) ['__call__', '__class__', '__delattr__', '__dict__', '__doc__', '__get__', '__getattribute__', '__hash__', '__init__', '__module__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'func_closure', 'func_code', 'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_name'] dir(afunction.__repr__) ['__call__', '__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__'] dir(afunction.__repr__.__repr__) ['__call__', '__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__'] dir(afunction.__repr__.__repr__.__repr__) ['__call__', '__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__'] dir(afunction.__repr__.__repr__.__repr__.__repr__) ['__call__', '__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__'] afunction.__repr__.__repr__.__repr__.__repr__() '<method-wrapper object at 0x41152c0c>'
I wonder how Python deals with this endless chain of __repr__'s. Maybe a function's attributes are generated on use, in which case they /aren't/ really an object at all, just a data type that looks like an object and acts like an object. I've never looked at any code having to do with Python in C or C++, so I wouldn't know. One thing that would be very useful in the next version of Python (regarding decorators) would be the ability to use @return or maybe @print (although I can't think of a use for @print); the ability to put statements (I think that's what they are called) as decorators. Tim -- Visit my website: (and please be a supporter of ... free software, ... free dom, ... by giving others the url) http://kmg.is-a-geek.org Garunteed to be down at least 5% of the time. stff rmed4ur bndwdth "Do you want to reconsider your answer?" "No, I'll remain disconnected."
[ The Bauman Family <baumanpdx@comcast.net> ] ----------------------------------------------- | Although everybody already knows this, I'm sure, a function actually is | a class, Hi Tim, I beg to differ with your statement above. A function is not a class. To prove this point follows:
def m(x): pass class M(object): pass type(m) <type 'function'> type(M) <type 'type'>
Altough they have similarities. To illustrate the most obvious one:
callable(m) True callable(M) True
| so technically it is a function if you have all the things you | get if you dir() a function. Perhaps this is a duck typing style of defining what an object *is*. But a function is (OO framework sense) definetely an object:
isinstance(m,object) True
Therefore, a function supports the object protocol:
x = object() dir(x) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__']
| >>> afunction.__repr__.__repr__.__repr__.__repr__() | '<method-wrapper object at 0x41152c0c>' | | I wonder how Python deals with this endless chain of __repr__'s.
m <function m at 0x402c2a04>
This is the function object.
m.__repr__() '<function m at 0x402c2a04>'
This is the execution of method __repr__() bound to the function object m
m.__repr__ <method-wrapper object at 0x402c870c>
m.__repr__ is an object (a method-wrapper) representing the method called above.
m.__repr__.__repr__ <method-wrapper object at 0x402c878c>
Every object supports __repr__, even method-wrapper objects. HTH, best regards, Rod Senra -- ,_ | ) Rodrigo Senra <rsenra |at| acm.org> |(______ ----------------------------------------------- _( (|__|] GPr Sistemas http://www.gpr.com.br _ | (|___|] IC - Unicamp http://www.ic.unicamp.br/~921234 ___ (|__|] L___(|_|] -----------------------------------------------
Rodrigo Dias Arruda Senra wrote:
[ The Bauman Family <baumanpdx@comcast.net> ] ----------------------------------------------- | Although everybody already knows this, I'm sure, a function actually is | a class,
Hi Tim, I beg to differ with your statement above. A function is not a class.
Maybe I meant to say object... It is, at least, an object that looks like an object but is not an object. Tim -- Visit my website: (and please be a supporter of ... free software, ... free dom, ... by giving others the url) http://kmg.is-a-geek.org Garunteed to be down at least 5% of the time. stff rmed4ur bndwdth "Do you want to reconsider your answer?" "No, I'll remain disconnected."
Kirby Urner wrote: [ lots of fun and good stuff ]
class Function: def __init__(self, f): self.f = lambda x: f(x) ...
Here you missed a simplicity bet (one of my two big pet peeves): class Function: def __init__(self, f): self.f = f ... For the curious, the other peeve is: def function(... if expression: return True else: return False instead of: def function(... return expression --Scott David Daniels Scott.Daniels@Acm.Org
Hi Scott:
Here you missed a simplicity bet (one of my two big pet peeves):
class Function: def __init__(self, f): self.f = f ...
Yes, good one.
For the curious, the other peeve is:
def function(... if expression: return True else: return False
instead of:
def function(... return expression
Also good. Thanks for sharing your peeves. If you get any more pets, please share them too. Kirby
Kirby Urner said unto the world upon 2005-02-01 23:57: <SNIP>
Thanks for sharing your peeves. If you get any more pets, please share them too.
Kirby
Hi, I'd just like to mention the page <http://www.python.org/moin/DubiousPython> and encourage peeved people to help the wiki grow. Best to all, Brian vdB
Greetings earthlings -- For those of you with too much time on your hands, I thought I'd alert you to a recent thread on Synergeo, a Yahoo eGroup: http://groups.yahoo.com/group/synergeo/ In this thread, one John Brawley, probably older than you think, tries to wrap his head around VPython cylinders. He's self-taught in Python, and is in no way a CS major. He cares about a pet theory, which involves geometry and visualization: so VPython to the rescue. Except the cylinder stuff seems to make no sense. A guy named Anton, and myself, trying to explain the meaning of "axis" in cylinder(pos=(x0,y0,z0), axis=(x1,y1,z1), radius=0.1) -- it's *not* the same thing as "destination point." I think John is confused in part because of working with POV-Ray, which also has a cylinder command, but simply asks for start and end points. Way simple. Zooming back, the bigger picture here is: we've got a bunch of people, finding each other through the Internet, talking about geometry and other stuff, and using Python as a tool, perhaps without formal training or any CS background. It's a means to an end, and easy enough to master to get some real work done, even if you're an old guy living with a bunch of cats in some run down trailer (that's a caricature, not a true-to-life portrait of Mr. Brawley). In other words: computer programming for everyman (a more literary, and gender-biased, rendition of the CP4E meaning). Kirby PS: speaking of Yahoo eGroups, and Wittgenstein (a few days back), I'm also pretty active here, in case anyone wants to jump in and join the chatter: http://groups.yahoo.com/group/wittgenstein-dialognet/
participants (6)
-
Arthur -
Brian van den Broek -
Kirby Urner -
Rodrigo Dias Arruda Senra -
Scott David Daniels -
The Bauman Family