On Friday, Jan 3, 2003, at 01:33 US/Eastern, Skip Montanaro wrote:

Well, yeah. So don't write list comprehensions that are that complex, or at least not without a little indentation, and not until you see them in your dreams:

This isn't completely about *my* coding style. One of the reasons why I was so attracted to Python back in, what, 1993 or 1994 or so was that it didn't matter *who* wrote the code, the syntax of the language and the design of the libraries was such that it just about anyone's code was comprehensible unless they actively worked to make it incomprehensible. Given that I had just spent 18 months doing very hard core OO perl with a relational backing store [Sybase], Python was like a bolt from the blue. Obfuscation was not a feature, the library code was readable, and I could immediately see that I would have a chance of being able to actually read my code six months after I had written it (and, yes, I succumbed to posting a 'python is superior to perl; i have seen the light' type message somewhere not long thereafter). List comprehensions and the */** notation are very powerful, but they also make the language less approachable to the newcomer to Python. At least, I think they do and most of the people I have run into think they do, as well. I'm not, for a moment, advocating that such features be deprecated or changed -- they are here and here to stay. At my experience level, I am comfortable with said constructs and use them heavily [though, I don't use */** as often as I probably should]. But this isn't just about me. Python is being used as a teaching tool and every experienced Python programmer was once a novice. The language itself is harder to learn now than it was 8 years ago. That is balanced by better documentation. It would be helpful to have a documentation with a syntactic table of contents. I.e. something like the tutorial, but with sections with two line titles -- the first being a title as found in the Tutorial [List Comprehensions] and a subtitle that is an actual example of a List Comprehension (don't know how you would do generators in such a fashion). I would have found this to be an incredibly useful learning tool when returning to python after a couple of year hiatus. b.bum

On Friday, Jan 3, 2003, at 05:19 US/Eastern, Christian Tismer wrote:

Where I absolutely cannot follow you is why you dislike the asterisk notation so much? I see this as one of the most elegant addition to Python of the last years, since it creates a symmetric treatment of argument definition and argument passing.

Elegance does not always mean easy to understand. What is the old adage: Something significantly advanced will seem like pure magic to the layman? I just don't want to see the future directions of Python lose the incredible strength of being such a straightforward, yet still very powerful, language. To the newcomer, map/reduce/filter/apply, list comprehensions, lambda, and */** are all relatively impoderable. An * or ** in the arglist of a function call/definition is extremely easy to gloss over because the newcomer has no idea what they mean. Doing so, leaves the newcomer without a clue as to what is going on in the call/definition. At least with map/reduce/filter/apply, there is a WORD to latch onto and spoken/read (not computer) languages are generally all about words with punctuation taking a somewhat secondary role. Most people do not learn languages by studying the tutorials/documentation at great length-- the first exposure is often under circumstances where too little time is alloted to learning the language. map/filter/reduce may be less powerful and less elegant, but they are a heck of a lot easier to look up in the documentation. More and more commonly, that means going to google and typing in 'python filter documentation'. Try going to google and typing in 'python [] documentation' or 'python * documentation'.... b.bum

On Fri, 3 Jan 2003, holger krekel wrote:

While the '*/**' notation adds syntactic complexity it doesn't feel too bad to me. (although i am currently refactoring a module to not use '*/**' anymore because it gets hard to read).

I agree: */** syntax makes for hard(er) to read code. However, I make a point of only using it in code that _should_ be hard(er) to read, because it is _doing_ somethat hard. Any feature can be naively overused to the point of becoming a mental blinder. This applies equally to lambda, list comprehensions, dictionaries, objects, print, indentation, chaining methods, etc... The key is to be a smart language-feature consumer and not over do the sugary features. My rule is to ration out 'cool tricks' to at most one per 4 lines of code or 2 lines of comments. -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com

...

While the '*/**' notation adds syntactic complexity it doesn't feel too bad to me. (although i am currently refactoring a module to not use '*/**' anymore because it gets hard to read).

I agree: */** syntax makes for hard(er) to read code. However, I make a point of only using it in code that _should_ be hard(er) to read, because it is _doing_ somethat hard.

Any feature can be naively overused to the point of becoming a mental blinder. This applies equally to lambda, list comprehensions, dictionaries, objects, print, indentation, chaining methods, etc... The key is to be a smart language-feature consumer and not over do the sugary features. My rule is to ration out 'cool tricks' to at most one per 4 lines of code or 2 lines of comments.

I recently learned that some people use apply() unnecessary whenever the function is something computed by an expression, e.g. apply(dict[key], (x, y)) rather than dict[key](x, y) More recently I learned that some people use * and ** unnecessarily too: f(x, y, *[a, b], **{}) for f(x, y, a, b) Finally I note that * and ** are slightly more flexibly than apply: you can write f(a, *args) where with apply you'd have to write apply(f, (a,)+args) And, of course, * and ** should be no strangers to anyone who has ever coded a function *declaration* using varargs or variable keyword arguments. --Guido van Rossum (home page: http://www.python.org/~guido/)

Andrew> You may recall that a while ago I mentioned that gnu binutils Andrew> 2.13 has bugs in how it handles dynamic linking that can prevent Andrew> Python from building on Solaris machines, and that 2.13.1 does Andrew> not correct those bugs completely. Can you narrow down the Solaris version for me? I'll update the warning in the README file of the distribution. Skip

Skip> Can you narrow down the Solaris version for me? I'll update the Skip> warning in the README file of the distribution. Andrew> I have encountered the problem on Solaris 2.7 and 2.8. I would Andrew> expect it to be present in 2.9. I don't think it's present in Andrew> 2.6, but I'm not sure and can no longer test it easily. Thanks, that will do. Andrew> If you like, I can send you patches to binutils 2.13 and 2.13.1, Andrew> but I suspect that for almost everyone, upgrading to 2.13.2 will Andrew> be the easiest course. Thanks for the offer, but I wouldn't know what to do with them (thankfully). :-) Skip