Very, Very Green Python User

[bruno at modulix]

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:

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.

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

3/ Dynamic Typing
Err... Actually, this is not a problem, Sir, it's a feature.

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

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.

6/ SelfDotSyndrome
As for 3, this is definitively a feature. I've always used the implicit
'this' in Java and C++ anyway.


> Is the Python debugger
> fairly stable? 

can't tell, almost never had a use for it.

> More than
> anything else, I would like to have a powerful OO environment where I
> do not have to worry about the debugger sucking ass.

What makes you think you have such a need for a debugger ?

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

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

> Double-underscore methods are rewritten with the class name? That's an
> ugly hack,

Ever looked at what a C++ compiler do to symbols ?-)

> but remember I'm coming from Perl. 

Talking about ugky hacks... !-)


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"