Very, Very Green Python User

[hanumizzle@gmail.com]

Re: Very, Very Green Python User


bruno at modulix wrote:[color=blue]
> hanumizzle@gmai l.com wrote:[color=green]
> > I have used Perl for a long time, but I am something of an experimental
> > person and mean to try something new. Most of my 'work' with Vector
> > Linux entails the use of Perl (a bit of a misnomer as it is not now a
> > paid position -- I am not yet even out of K-12), and there a lot of
> > things I love about it. I can look past a number of misfeatures in
> > Perl, but I am surprised to see that Python has very few (that I know
> > of). Most of them are documented here, it would seem:
> > http://www.c2.com/cgi/wiki?PythonProblems.[/color]
>
> Seems that this page is sometimes just plain wrong and somewhat
> outdated. Let's see some of them:[/color]

I doubt it not. The C&C wiki is full of blowhards.
[color=blue]
> 1/Memory Management The reference implementation uses reference
> counting, the worst-performing memory management scheme there is
>
> Actually, Python uses *both* reference-counting and a garbage collector.[/color]

....that, and ORO is the worst-performing memory management scheme there
is. Look at NewLISP for an implementation.
[color=blue]
> 2/ No Ternary If
> Well... actually true, but not such a major annoyance.
> NB : the "tuple_dispatch " option works well if you know how-to python.
> IOW, you can avoid useless evaluation with a simple lambda :
>
> result = (lambda: action_if_true, lambda : action_if_false )[test]()[/color]

Ternary if, in itself, is a lame substitute for the free combination of
expressions available in Lisp, where all flow-control statements are,
in fact, functions (or special forms for the pedantic; the semantics
I'm talking about are the same regardless).

You can regress with that argument to the logical conclusion that
everyone should be a 'SmugLispWeenie '.
[color=blue]
> 4/ Speed
> Never been a problem for me so far.[/color]

Yeah, as I say, the bottleneck in speed is usually user interaction.
[color=blue]
> 5/ Ugly mechanism for privates
> This is *not* a mechanism for "privates". This is a mechanism to protect
> some crucial implementation attributes from being *accidentally*
> overriden in a child class.[/color]

I get it now. It would be kind of nice if these 'isolated' methods had
their own 'namespace', but I can't complain too much.

Perl can use closures as private methods, which is pretty nifty. I
never used them like this though, because I don't really believe in the
concept of private methods. (Although what you described above is
reasonable enough.) After I stopped programming C, I quickly adopted
this maxim: validation occurs only on user (or cracker, as the case may
be) input.

If the programmer is being a dick, that's his/her problem.
[color=blue][color=green]
> > A couple blemishes I'm concerned about, though:
> >
> > Python closures are apparently very poor,[/color]
>
> In Python, encapsuling state is better done with objects. Once you'll
> get a better understanding of Python's object model, you'll find out
> that there's not such a need for more powerfull closures (well, that's
> MHO at least). Amongst other things, functions and methods are objects,
> and any other class can be made callable if you implement a method for
> the call operator...[/color]

I used to kind of / sort of program Lisp and Scheme, so I just like
first-class everything. I also disagree with the sentiment against deep
binding in lambdas (lambdae?) that seems to prevail in the Python
community. I used deep binding like this once in my .emacs (my .emacs
is SICK); I had to (require 'cl) just to use lexical-let. It was in
fact quite useful and no mutation of values in the lexical environment
was necessary.
[color=blue][color=green]
> > but from what I can surmise
> > of the PyGTK2 page, instances of objects are dynamic enough to add new
> > methods, so you get your callbacks, at least.[/color]
>
> You don't even need this to use callbacks. Remember, functions and
> methods are objects, and other objects can be callable too...[/color]

Eh?? I need an example.
[color=blue][color=green]
> > Double-underscore methods are rewritten with the class name? That's an
> > ugly hack,[/color]
>
> Ever looked at what a C++ compiler do to symbols ?-)[/color]

I'm afraid I don't want to know.
[color=blue][color=green]
> > but remember I'm coming from Perl.[/color]
>
> Talking about ugky hacks... !-)[/color]

Not all hacks are ugly.

[Bruno Desthuilliers]

Re: Very, Very Green Python User

hanumizzle@gmai l.com a écrit :[color=blue]
> bruno at modulix wrote:
>[/color]
(snip)[color=blue][color=green]
>>You don't even need this to use callbacks. Remember, functions and
>>methods are objects, and other objects can be callable too...[/color]
>
> Eh?? I need an example.[/color]

Of callables ?

class FuncInDisguise( object):
def __init__(self, name):
self.name = name

def __call__(self, who):
return "Hello, %s, my name is %s" % (who, self.name)

hello_from_brun o = FuncInDisguise( "bruno")
print hello_from_brun o("hanumizzle ")

It's somewhat equivalent to a more functional :

def curry(fun, *args):
def _curried(*morea rgs):
return fun(*(args + moreargs))
_curried.func_n ame = "curried(%s ) of %r" % (", ".join(args ), fun)
return _curried

def greeting(name, who):
return "Hello, %s, my name is %s" % (who, name)

hello_from_brun o2 = curry(greeting, "bruno")
print hello_from_brun o2("hanumizzle" )


Now when it comes to callbacks, just pass around any callable with a
compatible signature, and this should Just Work(tm):

def test(callback):
result = callback('baaz' )
print "in test, got: '%s'" % result
return result

class Foo(object):
def __init__(self, name):
self.name = name

def doit(self, arg):
return "%s %s" % (self.name, arg)

f = Foo('bar')

print test(f.doit)
print test(hello_from _bruno)
print test(hello_from _bruno2)
print test(FuncInDisg uise)
print test(lambda n: "what should I do with %s ?" % n)
print test(lambda n: ("what should I do with %s ?" % n).split)

And why we're at it, why not have some fun calling the result of a
callback ?-)

print test(FuncInDisg uise)('madman')
print test(lambda n: ("what should I do with %s ?" % n).split)()

HTH

[hanumizzle@gmail.com]

Re: Very, Very Green Python User

Dhanyavaad (thank you)