bruno at modulix wrote: > [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list