Re: python mode indentation problem
Xah Lee wrote: does anyone know why the Python mode in emacs uses spaces for first level indentation but one tab for second level? i'm using emacs 21.3.50.1. You probably have tab-width set to 8 spaces, but indentation in python set to 4 spaces. -- MJF -- http://mail.python.org/mailman/listinfo/python-list
Re: how to write a tutorial
Xah Lee wrote: i've started to read python tutorial recently. http://python.org/doc/2.3.4/tut/tut.html What does this have to do with Perl, Lisp, Scheme, or C? -- MJF -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Alex Martelli wrote:
> Joe Marshall <[EMAIL PROTECTED]> wrote:
>...
>> If you language allows unnamed integers, unnamed strings, unnamed
>> characters, unnamed arrays or aggregates, unnamed floats, unnamed
>> expressions, unnamed statements, unnamed argument lists, etc. why
>> *require* a name for trivial functions?
>
> I think it's reasonable to make a name a part of functions, classes and
> modules because they may often be involved in tracebacks (in case of
> uncaught errors): to me, it makes sense to let an error-diagnosing
> tracebacks display packages, modules, classes and functions/methods
> involved in the chain of calls leading to the point of error _by name_.
>
> I think it's reasonable to make a name a part of types for a different
> reason: new types are rarely meant to be used "just once"; but also, if
> during debugging any object is displayed, it's nice to be able to show,
> as part of the display, "this object is of type X and ...", with X shown
> as a name rather than as a complete (thus lengthy) description. (any
> decent interactive shell/debugger will let you drill down into the
> details as and when you need to, of course, but a well-chosen name can
> be often sufficient during such interactive exploration/debugging
> sessions, and therefore save time and effort).
Any time you want an anonymous function (or class, or type, or number)
it would be because that thing is sufficiently small and simple that the
best name for it is the code itself. In one game I worked on, there was
a function named canPerformAction_and_isNotActionInQueue. It was a
simple, one line function:
bool canPerformAction_and_isNotActionInQueue( Action action ) {
return canPerformAction( action ) && !isActionInQueue( action );
}
There was no better, more abstract name, as the design required this
logic for a completely arbitrary reason -- so arbitrary it changed
multiple times in development. For a little while it was used in two
places. Then one of those places changed to have only the
isActionInQueue part. There was no useful abstraction to be made, and
it is in cases like these (which come up a lot when using functions as
parameters) where anonymous functions are a win.
-- MJF
--
http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Alex Martelli wrote: > Stefan Nobis <[EMAIL PROTECTED]> wrote: > >> [EMAIL PROTECTED] (Alex Martelli) writes: >> >>> if anonymous functions are available, they're used in even more >>> cases where naming would help >> Yes, you're right. But don't stop here. What about expressions? Many >> people write very complex expression, that are hard to understand. A >> good language should forbid these abuse and don't allow expressions >> with more than 2 or maybe 3 operators! > > That would _complicate_ the language (by adding a rule). I repeat what > I've already stated repeatedly: a good criterion for deciding which good > practices a language should enforce and which ones it should just > facilitate is _language simplicity_. If the enforcement is done by > adding rules or constructs it's probably not worth it; if the > "enforcements" is done by NOT adding extra constructs it's a double win > (keep the language simpler AND push good practices). Your reasoning, taken to the extreme, implies that an assembly language, by virtue of having the fewest constructs, is the best designed language ever. But we know that not to be the case -- rarely do even embedded developers program in assembly language any more. Why? Because assembly language is so simple that it's very tedious to write. There's no function call primitive -- you have to manually generate a function call pattern yourself. There's no looping primitive -- you have to manually generate a looping pattern yourself. I feel sorry for the person who's debugging an assembly program using manually generated code that implements a vtable-based dynamic dispatch. Any feature that allows me to write less code to do the same thing has a huge positive -- the reduction of human generated, and therefore error prone, code. I think the advantages of anonymous functions: a) explicitly documenting that the function is used in only one place b) enabling generic iteration and looping routines c) not having to maintain a unique name for the function d) making the language more elegant e) making the language simpler to implement greatly outweigh the small disadvantage of adding one additional construct to the language. -- MJF -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Alex Martelli wrote:
> M Jared Finder <[EMAIL PROTECTED]> wrote:
>...
>> Your reasoning, taken to the extreme, implies that an assembly language,
>> by virtue of having the fewest constructs, is the best designed language
>
> Except that the major premise is faulty! Try e.g.
> <http://docs.sun.com/app/docs/doc/817-5477/6mkuavhrf#hic> and count the
> number of distinct instructions -- general purpose, floating point,
> SIMD, MMX, SSE, SSE2, OS support... there's *hundreds*, each with its
> own rules as to what operand(s) are allowed plus variants such as (e.g.)
> cmovbe{w,l,q} for "conditional move if below or equal" for word, long,
> quadword (no byte variant) -- but e.g cmpxchg{b,w,l,q} DOES have a byte
> variant too, while setbe for "set if below or equal" ONLY has a byte
> variant, etc, etc -- endless memorization;-).
>
> When you set up your strawman arguments, try to have at least ONE of the
> premises appear sensible, will you?-)
>
> I never argued against keeping languages at a high level, of course
> (that's why your so utterly unfounded argument would be a "strawman"
> even if it WAS better founded;-).
>
>> prone, code. I think the advantages of anonymous functions:
>...
>> e) making the language simpler to implement
>
> Adding one construct (e.g., in Python, having both def and lambda with
> vast semantic overlap, rather than just one) cannot "make the language
> simpler to implement" -- no doubt this kind of "reasoning" (?) is what
> ended up making the instruction-set architecture of the dominant
> families of CPUs so bizarre, intricate, and abstruse!-)
It sure can. First, let's cover the cost. I'll be measuring everything
in terms of lines of code, with the assumption that the code has been
kept readable.
Here's an implementation of lambda (anonymous functions) in Lisp based
on flet (lexically scoped functions):
(defmacro lambda (args &rest body)
(let ((name (gensym)))
`(flet ((,name ,args ,@body)) (function ,name
That's three lines of code to implement. An almost trivial amount.
Now by using anonymous functions, you can implement many other language
level features simpler. Looping can be made into a regular function
call. Branching can be made into a regular function call. Defining
virtual functions can be made into a regular function call. Anything
that deals with code blocks can be made into a regular function call.
By removing the special syntax and semantics from these language level
features and making them just pain old function calls, you can reuse the
same evaluator, optimizer, code parser, introspector, and other code
analyzing parts of your language for these (no longer) special
constructs. That's a HUGE savings, well over 100 lines of code.
Net simplification, at least 97 lines of code. For a concrete example
of this in action, see Smalltalk.
-- MJF
--
http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Chris Uppal wrote: > E.g. can you add three-way comparisons (less-than, same-as, greater-than to, > say, Python with corresponding three-way conditional control structures to > supplement "if" etc ? Are they on a semantic and syntactic par with the > existing ones ? In Smalltalk that is trivial (too trivial to be particularly > interesting, even), and I presume the same must be true of Lisp (though I > suspect you might be forced to use macros). As an illustration, here's the definition and usage of such a numeric-if in Lisp. Using raw lambdas, it's ugly, but doable: (defun fnumeric-if (value lt-body eq-body gt-body) (cond ((< value 0) (funcall lt-body)) ((= value 0) (funcall eq-body)) ((> value 0) (funcall gt-body (fnumeric-if (- a b) (lambda () (print "a < b")) (lambda () (print "a = b")) (lambda () (print "a > b"))) A macro helps clean that up and make it look prettier: (defmacro numeric-if (value lt-body eq-body gt-body) `(fnumeric-if ,value (lambda () ,lt-body) (lambda () ,eq-body) (lambda () ,gt-body))) (numeric-if (- a b) (print "a < b") (print "a = b") (print "a > b")) -- MJF -- http://mail.python.org/mailman/listinfo/python-list
Re: Software Needs Philosophers
SamFeltus wrote: > Religious Fanaticism is a very strong in the Computer community. But, > is it really a surprise that when a bunch of hairless apes created a > new mental world, they created it with a complicated Quilt of religions > and nationalities, and many became fanatical? > > I am confidant the responces Xah will recieve will validate his > observation on religious fanaticism. It is funny, Xah always questions > people's Sacred Cow's, I have often noted that the reponces often read > like the writings of religious fanatics. As a Georgian (US), the > responces often remind me of the Dark Side (there is a Light) of the > Southern Baptist Church, translated into Computer Speak. > > Software needs philosophers is an interesting point, perhaps the most > important function of Philosophers is exposing Sacred Cows as just > Cattle. Finally, someone else who sees that Xah's posts consistently expose valid problems! (Though his solutions are usually not well thought out.) -- MJF -- http://mail.python.org/mailman/listinfo/python-list
