Very, Very Green Python User

[hanumizzle at gmail.com]

bruno at modulix wrote:
> hanumizzle at gmail.com wrote:
> > 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.
>
> Seems that this page is sometimes just plain wrong and somewhat
> outdated. Let's see some of them:

I doubt it not. The C&C wiki is full of blowhards.

> 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.

...that, and ORO is the worst-performing memory management scheme there
is. Look at NewLISP for an implementation.

> 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]()

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'.

> 4/ Speed
> Never been a problem for me so far.

Yeah, as I say, the bottleneck in speed is usually user interaction.

> 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.

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.

> > A couple blemishes I'm concerned about, though:
> >
> > Python closures are apparently very poor,
>
> 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...

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.

> > 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.
>
> You don't even need this to use callbacks. Remember, functions and
> methods are objects, and other objects can be callable too...

Eh?? I need an example.

> > Double-underscore methods are rewritten with the class name? That's an
> > ugly hack,
>
> Ever looked at what a C++ compiler do to symbols ?-)

I'm afraid I don't want to know.

> > but remember I'm coming from Perl.
> 
> Talking about ugky hacks... !-)

Not all hacks are ugly.