PEP 312 - Making lambdas implicit worries me, surely it's just the name 'lambda' that is bad...
Stephen Horne
As the title says, making lambdas implicit worries me - just because a
parser will not find them ambiguous, it doesn't mean I won't!
I'm going to be called a hypocrite by anyone who remembers my
contribution to the integer division thread - but surely the real
problem with 'lambda' is it's name. It really needs something that is
short yet more easily understood. Replacing this name (in stages, over
several Python versions) might be a better solution.
I'd propose 'fn' - a fairly obvious abbreviation for 'function' (at
least mathemeticians seem to think so). While it still may not be
entirely obvious what is going on to some, it seems better than
'lambda' - at least to me. It's also *much* easier to look up a
keyword in the manual than yet another use of the colon.
In an example like...
x = function_name (a = b, c : b + c)
Is it even obvious that the 'b, c : b + c' is a significant construct?
- I don't think so. What I see is 'a = b' as one parameter and 'c : b
+ c' as possibly someone mistyping a ':' for an '='.
In a related issue, I'd quite like to be able to embed short
imperative sequences in an expression sometimes. I added this facility
to a little language I wrote some time ago (no - you won't have seen
it), and it turned out to be one of the most used facilities.
A major use was abbreviation, in contexts where temporary variables
could not otherwise be declared because of the way fragments of code
are assembled (Zope has a similar issue, I believe).
A typical example may be...
{ local a := <some_long_expression>; a * a }
Instead of...
<some_long_expression> * <some_long_expression>
The language already supported '{' and '}' for C-like grouping of
statements, so it seemed natural to allow it's use in an expression
and take the result of the last item as the overall result.
Admittedly, this abbreviation purpose can be solved using lambdas in
Python - e.g.
(lambda a : a * a) (<some_long_expression>)
or even
(lambda a = <some_long_expression>: a * a) ()
but there have been other uses - e.g. people seem to prefer
{ local t := 0; for (local i : list) { t += i; }; t }
to...
reduce (local t, 0, local i, list, i + t)
Personally, I find the former less readable. The trouble is that
people tend not to know the latter, whereas they know the building
blocks of the former.
If you're wondering about the reduce syntax, the language doesn't have
lambdas or - for that matter - user defined functions as it doesn't
need them given its very limited applications. Things like 'reduce'
were added when I decided they were a good idea, though I still get
funny looks. The odd syntax works because the interpreter works
directly on the abstract syntax tree - it doesn't need lambdas because
the parameters to built-in functions are basically the unevaluated
subexpressions.
How is this a related issue? - Well, one thing I dislike about lambdas
is that you can't use imperative code in them. On (admittedly rare)
occasions, I've wanted to do just that. Just because the function is
declared in an expression context, that doesn't mean that the body of
the function has to be a simple expression. Keeping things readable
tends to mean the body should be a simple expression, but not quite
always.
Actually, I've always thought that having separate 'def' and 'lambda'
syntaxes is a bit redundant. In lisp (and a few others) you'd use the
'lambda' form to do both jobs, rather like (in current Python)
writing...
sum = lambda a, b : a + b
This could be modified to allow indentation to structure imperative
statements in the body of the function (ie slightly generalising
current indentation rules to allow the Haskell off-side rule). The
following needs a fixed-pitch font to read, I'm afraid...
total = fn p_list : l_total = 0
for i in p_list :
l_total += i
return l_total
print total ([1, 2, 3])
A switch-like structure might then look something like...
cases := [ fn : do_stuff
do_stuff
do_stuff
, fn : do_stuff
do_stuff
]
cases [x] ()
The off-side rule in Haskell acts much like parentheses, to override
precedence. Thus...
a = b
* c
+ d
* e
Would mean...
a = (b * c) + (d * e)
Whereas...
a = b
* c
+ d
* e
Would mean...
a = b * (c + d) * e
My Haskell is very rusty, though, so there's a very good chance I'm
wrong. Even so, this general pattern would theoretically work - except
for the rather obvious fact that existing Python code doesn't expect
the precedence rules to suddenly change for multiline expressions.
Damn. Still, it could be set up to work only for selected initial
keywords, such as a replacement-for-lambda such as 'fn'.
--
steve at ninereeds dot fsnet dot co dot uk
Sean Ross
sum = do a, b: a + b
or, if you want blocks,
total = do seq:
amt = 0
for i in seq:
amt += i
return amt
This would be similar to ruby blocks, except there would be no end statement
and the block parameters would not be piped ( do |seq|: ... ). I'm not sure
about
how to handle the indentation, i.e., should it be as above, where you indent
once
beyond "do" or
total = do seq:
amt = 0
for i in seq:
amt += i
return amt
where you indent once beyond the current indentation level.
Whatever...
just a passing thought,
Sean
Erik Max Francis
> As the title says, making lambdas implicit worries me - just because a
> parser will not find them ambiguous, it doesn't mean I won't!
Indeed. I don't see what the tangible benefit is, except by making a
certain style of lambdas harder to read. One might object to the use of
lambdas on general grounds, but certainly when you see the keyword
`lambda' you know what you're in for. PEP 312 attempts to blur that
distinction, for no other reason than to save keystrokes and make code
look more impenetrable. I don't see the benefit.
It seems to me that on general grounds, is Guido really did indeed
regret adding lambdas to the language, the chances of this PEP getting
past him are nil. What's worse than a lambda? A lambda that is
cleverly hiding.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Mona Lisa / Come to discover / I am your daughter
\__/ Lamya
Fauxident / http://www.alcyone.com/pyos/fauxident/
A "faux" ident daemon in Python.
Alexander Schmolck
> Actually, I've always thought that having separate 'def' and 'lambda'
> syntaxes is a bit redundant. In lisp (and a few others) you'd use the
> 'lambda' form to do both jobs, rather like (in current Python)
> writing...
>
> sum = lambda a, b : a + b
Not true, I think. Apart from scheme (which's lispness is often disputed in
both lisp and scheme circles).
alex
Alexander Schmolck
> Indeed. I don't see what the tangible benefit is, except by making a
> certain style of lambdas harder to read. One might object to the use of
> lambdas on general grounds, but certainly when you see the keyword
> `lambda' you know what you're in for. PEP 312 attempts to blur that
> distinction, for no other reason than to save keystrokes and make code
> look more impenetrable. I don't see the benefit.
You overlook the fact "that saving keystrokes" (and space) can make a
qualitative change to a language. Certain styles of doing things only become
viable if they don't involve too many keystrokes. For example, thanks to its
lightweight lambda-syntax, smalltalk has a very simple syntax and powerful
methods. If ``[x]`` became ``lambda : x``, it would be completely unusable.
Compare:
Smalltalk: Python:
... someBool ifTrue: [1] ifFalse: [2] apparently needs a ternary operator...
... someContainer at: 3 ifAbsent: [0] try:
... someContainer[3] ...
except IndexError, KeyError:
... 0 ...
# easy
... someDict at: 3 ifAbsent: [0] ... someDict.get(3, 0)
# oops
... someDict at: 3 ifAbsent: [val compute] if someDict.has_key(3):
...
else:
... val.compute() ...
alex
Erik Max Francis
> You overlook the fact "that saving keystrokes" (and space) can make a
> qualitative change to a language. Certain styles of doing things only
> become
> viable if they don't involve too many keystrokes. For example, thanks
> to its
> lightweight lambda-syntax, smalltalk has a very simple syntax and
> powerful
> methods.
Well, Python isn't Smalltalk, so I don't really know where this gets us.
> If ``[x]`` became ``lambda : x``, it would be completely unusable.
It would become longer, how is that unusable?
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ All the people in her neighborhood turn around and get mad and sing
\__/ Public Enemy
CSBuddy / http://www.alcyone.com/pyos/csbuddy/
A Counter-Strike server log file monitor in Python.
Roman Suzi
> How about "do", instead of "fn"?:
As on of the PEP 312 authors, I must explain. PEP 312 is not about adding
new keywords, etc. And I am already allergic (thanks PEP 308) to such
suggestions. The only problem with PEP 312 as I see it is that lambdas are
more useful when they have arguments. And this is hard to help without
"lambda" keyword.
Making lambda implicit is no more fuss than making implicit line-breaks.
Sincerely yours, Roman A.Suzi
--
- Petrozavodsk - Karelia - Russia - mailto:r...@onego.ru -
Stephen Horne
wrote:
Wierd - I've hardly used scheme, but I have looked at it much more
recently than lisp (not used properly in more than a decade). Still, I
appologise for the confusion.
Roman Suzi
If I understand correctly, functional-savvy (or even aware) people are
minority of Python programmers. So all features which advance the FP
paradigma will be countered by those who "do not need the feature".
Will it lead to a FunPython fork in the future? I hope not!
If FP in Python is indeed Guido's mistake, then lets deprecate lambda,
map, filter, etc and ban function objects as function arguments/results.
;-)
Stephen Horne
wrote:
>
>If I understand correctly, functional-savvy (or even aware) people are
>minority of Python programmers. So all features which advance the FP
>paradigma will be countered by those who "do not need the feature".
>
>Will it lead to a FunPython fork in the future? I hope not!
>
>If FP in Python is indeed Guido's mistake, then lets deprecate lambda,
>map, filter, etc and ban function objects as function arguments/results.
>;-)
>
>Sincerely yours, Roman A.Suzi
My argument in starting this thread was not to ban functional
facilities - I *like* functional facilities.
I simply recognise that one significant argument against 'lambda' is
that it is a bad name which in itself raises some peoples hackles -
one of the points raised in the PEP. I think that a differently
spelled keyword would handle this problem better than an implicit
lambda because I feel that hiding the lambda is going to open a whole
new can of worms - programs that use lambdas will quite simply be
unreadable to those who are unfamiliar with lambdas because there
won't even be a 'hint' of what to look up in the manual - just an
obscure use of an already common piece of punctuation.
Believing that functional facilities are a good thing to have is quite
different to demanding that every Python programmer must be familiar
with them or else.
Gary Stephenson
In Clipper 5 and it's derivatives ( Xbase++, Visual DB, VO, Flagship,
Harbour, ... ), lambda style thingies are referred to as "codeblocks", and
have the declaration syntax.:
b = {|x,y| x+y }
and a special function is provided to evaluate them
eval( b, 3, 5 )
or even, in some dialects,
b.eval( 3,5 )
I find this syntax very easy to understand and to teach, and the concept
extremely powerful in practice. Codeblocks can even be made to serve as
closures (via a mechanism which Clipper 5 christened as "detached locals""),
although the implementation is a little inconsistent imho.
Xbase++ is quite similar to Python in many ways (particularly with 2.2 's
slots-based classes), and I am puzzled why codeblocks seem so
extraordinarily useful in Xbase++, and yet lambdas seem almost to languish
in Python. Part of the reason may be that Xbase++ doesn't have first-class
functions, but I can't see that being the whole story.
Is there some fundamental difference between the two that I've failed to
appreciate? Or are codeblocks only so popular in Xbase++ because the rest
of the language is so impoverished in comparison to Python? Or is the
codeblock syntax superior enough to make the construct more accessible to
"lesser minds".
just curious,
gary
"Roman Suzi" <r...@onego.ru> wrote in message
news:mailman.104668074...@python.org...
Stephen Horne
<ga...@ihug.com.au> wrote:
>Xbase++ is quite similar to Python in many ways (particularly with 2.2 's
>slots-based classes), and I am puzzled why codeblocks seem so
>extraordinarily useful in Xbase++, and yet lambdas seem almost to languish
>in Python. Part of the reason may be that Xbase++ doesn't have first-class
>functions, but I can't see that being the whole story.
>
>Is there some fundamental difference between the two that I've failed to
>appreciate? Or are codeblocks only so popular in Xbase++ because the rest
>of the language is so impoverished in comparison to Python? Or is the
>codeblock syntax superior enough to make the construct more accessible to
>"lesser minds".
I've not used Clipper since the days when it was a DBase III+
compatible compiler, and I certainly don't recognise code blocks, but
my main comment on the syntax would be that it looks very different
from anything I remember from Clipper - it would stand out in the
code. It would be easy for people who are aware of the syntax to
identify and read the construct and, while there is no keyword, it is
sufficiently different to other syntax that even a reader who is
unaware of them could probably isolate the unknown syntax and look it
up readily enough.
A major problem with 'lambda' is simply that it is an obscure name.
Obscure punctuation is usually less of a problem as long as it is easy
to isolate each construct, and as long as the language does not
overuse it. A clear pattern of symbols can be almost as explicit as a
keyword - it is only when the same symbols get used for many different
purposes that things get severely confusing. However, give something a
fully explicit name, however, and you risk giving it a name that
people hate.
Church calculus is not in most peoples everyday experience, so
'lambda' is a name that a lot of people hate.
Some people hate functional facilities anyway (and I'm far from clear
on relative numbers) as can be seen in the fact that list
comprehensions also sometimes get bashed. List comprehensions actually
have a close relationship with the idea of embedding short imperative
sequences in an expression (though the notation is tweaked along more
functional lines, that is essentially what they do) and they look
superficially rather like the Clipper codeblocks.
Erik Max Francis
> A major problem with 'lambda' is simply that it is an obscure name.
I don't agree. The term "lambda" is well-recognized throughout the
computer science community as a construct which introduces an anonymous
function.
Is the term "lambda" recognizable to a random guy in the street? I'm
quite sure it isn't. But programming can't be made trivial to
non-programmers simply by giving things trivial names, just as
mathematics can't be made simple simply by using common terms instead of
all those technical terms; I'm reminded here of Mathematics in the
Common Tongue:
http://www.earth360.com/mathtongue.html
Myself, I'm not much interested in what the average non-programmer
things about programming terminology. Even for those involved with
teaching, there's got to be a tradeoff: The learned has to understand
upfront that everything can't be instantly understandable without some
manner of investment. If you're new to programming and you're learning
a language and you bump into a "lambda," one would hope you'd have the
actual energy and willpower to look it up.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I can paint a portrait of myself / I will call me a black Mona Lisa
\__/ Lamya
Bosskey.net: Unreal Tournament 2003 / http://www.bosskey.net/ut2k3/
A personal guide to Unreal Tournament 2003.
Daniel Dittmar
> In Clipper 5 and it's derivatives ( Xbase++, Visual DB, VO, Flagship,
> Harbour, ... ), lambda style thingies are referred to as
> "codeblocks", and have the declaration syntax.:
>
> b = {|x,y| x+y }
> Is there some fundamental difference between the two that I've failed
> to appreciate? Or are codeblocks only so popular in Xbase++ because
> the rest of the language is so impoverished in comparison to Python?
> Or is the codeblock syntax superior enough to make the construct more
> accessible to "lesser minds".
It can't be seen from your example, but if they are anything like Smalltalk
code blocks, then you can have multiple statements in one block. Whereas
lambda allows only a single expression.
Also, that lambdas act as closures is quite new, so there wasn't that much
that you could do with them.
There are also other ways to get a callable object which are probably not
available in Clipper:
- object.method yields a callable object
- def __call__ (self): makes all objects of a class callable.
Daniel
Alexander Schmolck
To clarify, in scheme, there is only one namespace:
> (define a-var 1)
> (define a-function (lambda () 1))
> a-var
1
> (a-function)
1
in (common) lisp, which has a separate namespace for functions:
> (defvar a-var 1)
> (defvar a-function (lambda () 1))
> a-var
1
> (a-function)
Error: the function a-function is undefined
> (funcall a-function)
1
> ;; this doesn't affect the variable value of a-function
> (defun a-function () 'result)
> (a-function)
'result
> ;; still the same variable
> (funcall a-function)
1
alex
AdSR
> Erik Max Francis <m...@alcyone.com> writes:
>
> > Indeed. I don't see what the tangible benefit is, except by making a
> > certain style of lambdas harder to read. One might object to the use of
> > lambdas on general grounds, but certainly when you see the keyword
> > `lambda' you know what you're in for. PEP 312 attempts to blur that
> > distinction, for no other reason than to save keystrokes and make code
> > look more impenetrable. I don't see the benefit.
Neither do I.
> You overlook the fact "that saving keystrokes" (and space) can make a
> qualitative change to a language.
As can making it less readable. As I understand, Python is, among
other things, readability-oriented. Let's keep it like that.
As they say, if it ain't broken, don't fix it.
Cheers,
AdSR
Jack Diederich
> A major problem with 'lambda' is simply that it is an obscure name.
> Obscure punctuation is usually less of a problem as long as it is easy
> to isolate each construct, and as long as the language does not
> overuse it. A clear pattern of symbols can be almost as explicit as a
> keyword - it is only when the same symbols get used for many different
> purposes that things get severely confusing. However, give something a
> fully explicit name, however, and you risk giving it a name that
> people hate.
My major problem with 'lambda' is just the way it jars the eye when reading
code. Even with a colorizing editor the fact that it is a word and a longish
one at that[1] adds to the cost of both writing and reading map(), filter(),
etc. 'lambda' is the only long keyword to always appear in the middle of a
line[2].
I'm a big functional programming fan, but most python user's aren't.
If you took a vote, they'd want the 'lambda' keyword to be renamed
'lambda_go_away_you_lisper'
A quick grep of src/Lib/*.py shows just 122 lambdas. There are more asserts
than that. There are more bitwise operators. In a code base I've written,
I have twice that number of lambdas in one fourth the lines of code.
Unsuprisingly, I have about the same 'over usage' of map() and filter() and
only two dozen [very simple!] list comprehensions.
I know how the folks who want a ternary operator - ANY ternary operator -
feel, I'd take almost any way to make lambdas look nicer. I've even considered
recompiling my local Grammar with 'L' replacing 'lambda'.
-jackdied
[1] Keyword list taken from pthon-mode.el
* shorter keywords: is, in, or, if, not, def, del, and, for, pass, elif,
else, exec, from, break, print, raise, while, yield, class
* same length keywords: assert, import, except, global, return
* longer keyword(!): continue
[2]
Note that all the other 6 & 7 length keywords are the first thing on a line
global my_var
import foo
return 42
assert(2 + 2 == 5)
'lambda' is always in the middle of a line
new_list = filter(lambda x:x > 0, old_list)
Sean Ross
> On Sun, 2 Mar 2003, Sean Ross wrote:
>
> > How about "do", instead of "fn"?:
>
> As on of the PEP 312 authors, I must explain. PEP 312 is not about adding
> new keywords, etc.
>
Yes. I was aware of that when I made my post. PEP312 is about removing
keywords, or,
more precisely, making them
"optional in some cases where it is not grammatically ambiguous"
I was not suggesting otherwise. I was suggesting "do" over "fn". Someone
suggestion "fn". I didn't care for that, so I suggested "do", mostly because
it was not an abbreviation but also because it has been used in Ruby to
delimit blocks.
Nothing more than that - idle speculation, what if's, that sort of
thing...i.e.,
If you were going to change the keyword lambda(and not make it
optionally implicit), then I think "do"
would be a better replacement than "fn".
>And I am already allergic (thanks PEP 308) to such
> suggestions.
I rather enjoyed reading the PEP308 debate. I find the idea of language
design to be very interesting
and I found the discussions and differences of opinions over a single
feature fascinating. Perhaps if I
had to implement this language, I would be more concerned by idle
speculations that include keyword
introductions but, for the moment, I'll just enjoy playing with the syntax
to see if there is a better way.
Or, at least, a way that I'd prefer were I to implement a language. In
general, this is my point of view when
I post syntax alteration ideas. I'm just trying them out. Seeing if one way
is better than another, or more
preferred. If they were more than that, I should write a PEP. (or a
language)
>The only problem with PEP 312 as I see it is that lambdas are
> more useful when they have arguments. And this is hard to help without
> "lambda" keyword.
>
Our opinion differ slightly here. Personally, I have no problem with
"lambda", but I can see where it could be intimidating.
And, given my preference, I would have chosen "do", but we won't go there at
the moment
IMO, the problems with PEP 312 are twofold: (1) it favors implicit over
explicit and (2) it introduces inconsistent syntax -
two possible lambda forms without arguments, and one form with arguments. I
could argue that my objection to (1) is not strictly correct, since, in the
new form ":expression", the colon, in certain unambiguous cases, and once we
have learned the new idiom, explicitly signifies that we are dealing with an
anonymous function. I don't find that it's level of "explicitness" matches
my taste but, either way, (1) does not concern me greatly in this particular
case. (None of them "concern me greatly", but it's a nice turn of phrase...
moving on...)
However, if you prefer consistent syntax, which I do, then I should think
that (2) would be of more concern. Of course, the new syntax is optional, so
if consistency is your bugaboo, you can still use the "lambda" for
argumentless anonymous functions, if you want to, but others may not, and
you'll have to remain aware of each form.
Anyway, all if this is just to say, I saw a post suggesting "fn" and
thought, "Well, 'do' is not 'lambda', it's less intimidating, it's shorter,
it's been used in other languages, it can be used explicitly and
consistently, it's not 'fn', and it's not abbreviated, I think I'll fly that
idea out there, what the hey. It's not like anyone's going to rush out and
add it to the language..."
speculatively-yrs
Sean
Alexander Schmolck
> Well, Python isn't Smalltalk, so I don't really know where this gets us.
Geez, I don't know either how looking at a language Z (different from python)
that has and makes extensive use of feature X could *possibly* be helpful for
understanding how (some variant of X) might be useful in python. I thought I
just mention it anyway.
>
> > If ``[x]`` became ``lambda : x``, it would be completely unusable.
>
> It would become longer, how is that unusable?
Do you think adding a few keystrokes by replacing
>>> a + b * c[2]
with the more explict
>>> a operatorAddOrMaybeConcatenate (b operatorMultiplyOrMaybeRepeat c
... operatorAtIndexOrMaybeKey 1)
would make python unusable? Or maybe just unpopular?
(Hint: in case the point of how mere "differences in keystrokes" can widely
affect design choices in a language and its libraries was lost on you; do you
really think anyone would dream of introducing a ternary operator if you could
just do
def when(cond, a,b):
if cond: return a()
else: return b()
res = when(cond, :b, :c)
instead of
res = when(cond, lambda : b, lambda :c)
?)
alex
Alex Martelli
...
> I'm a big functional programming fan, but most python user's aren't.
> filter() and only two dozen [very simple!] list comprehensions.
So I guess your "functional programming" enthusiasm doesn't come
from Haskell, who some consider amont the best FP languages -- as
Python got list comprehensions from Haskell, with just little
syntax-sugar changes, I'd expect LOTS of list comprehensions in
Python code written by Haskell-savvy FP fans...!-)
Alex
Alexander Schmolck
> Jack Diederich wrote:
> ...
> > I'm a big functional programming fan, but most python user's aren't.
> ...
> > filter() and only two dozen [very simple!] list comprehensions.
>
> So I guess your "functional programming" enthusiasm doesn't come
> from Haskell
I don't think that follows. Python's list comprehensions are different -- they
pollute the namespace.
alex
Andrew Koenig
Alex> can widely affect design choices in a language and its libraries
Alex> was lost on you; do you really think anyone would dream of
Alex> introducing a ternary operator if you could just do
Alex> def when(cond, a,b):
Alex> if cond: return a()
Alex> else: return b()
Alex> res = when(cond, :b, :c)
Alex> instead of
Alex> res = when(cond, lambda : b, lambda :c)
Alex> ?)
Yes, definitely.
What's wrong with when(cond, :b, :c) is that it's too easy to forget
one of the colons, in which case the error goes undiagnosed until the
corresponding branch is actually executed.
For that reason, although I wouldn't mind having a more compact way of
writing lambda-expressions, I don't think that the colon syntax is
the best way to do it.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Dan Schmidt
| My major problem with 'lambda' is just the way it jars the eye when
| reading code. Even with a colorizing editor the fact that it is a
| word and a longish one at that adds to the cost of both writing and
| reading map(), filter(), etc. 'lambda' is the only long keyword to
| always appear in the middle of a line[2].
|
| I know how the folks who want a ternary operator - ANY ternary
| operator - feel, I'd take almost any way to make lambdas look nicer.
| I've even considered recompiling my local Grammar with 'L' replacing
| 'lambda'.
I am a big fan of functional programming and I never use lambdas in my
Python code because they're too ugly looking. (It's different in Lisp,
where all the syntax looks the same, but even there I think lambda is
too verbose - and so does Lisp guru Paul Graham, who's renamed lambda
to fn in his new Lisp dialect Arc.) I'd complain more loudly, but I
think Guido likes the fact that their ugliness dissuades people from
using them...
Luckily, in at least half of the places that I would want to use
anonymous functions I can now use list comprehensions, which are quite
pretty and clear.
Dan
Alex Martelli
True -- though I, personally, don't find it hard to pick a name for
the control variable in a list comprehension that doesn't overwrite
any other variable of interest, I think this counts as a (minor) wart.
But I still can't imagine a Haskell list-comprehension fan eschewing
LC's in Python just because of this wart.
Alex
Dave Brueck
Oh, c'mon. This is a frequently cited yet overstated wart. Yeah,
technically it's a problem, but much more a theoretical than practical one
- in practice the only time it causes problems is when you're doing
something questionable anyway, like reusing a variable without
initializing it to some known value.
It's a nit rather than a real divergence from Haskell's list comps.
-Dave
Alexander Schmolck
> Alex> (Hint: in case the point of how mere "differences in keystrokes"
> Alex> can widely affect design choices in a language and its libraries
> Alex> was lost on you; do you really think anyone would dream of
> Alex> introducing a ternary operator if you could just do
>
> Alex> def when(cond, a,b):
> Alex> if cond: return a()
> Alex> else: return b()
>
> Alex> res = when(cond, :b, :c)
>
> Alex> instead of
>
>
> Alex> res = when(cond, lambda : b, lambda :c)
>
> Alex> ?)
>
> Yes, definitely.
>
> What's wrong with when(cond, :b, :c) is that it's too easy to forget
> one of the colons, in which case the error goes undiagnosed until the
> corresponding branch is actually executed.
[...]
> For that reason, although I wouldn't mind having a more compact way of
> writing lambda-expressions, I don't think that the colon syntax is
> the best way to do it.
Fair enough, my main point simply was that apparently small differences in
verbosity of constructs do sometimes matter *a lot*, to the extent that not
only library interfaces but even language design decisions can be affected by
it.
Whether or not :x is a good way to write lambda: x, my bet would still be that
*if* a similar lighweight lambda idiom had already existed, the chances of a
ternary making it into the language would be nil.
alex
Alexander Schmolck
> I am a big fan of functional programming and I never use lambdas in my
> Python code because they're too ugly looking. (It's different in Lisp,
> where all the syntax looks the same, but even there I think lambda is
> too verbose - and so does Lisp guru Paul Graham, who's renamed lambda
> to fn in his new Lisp dialect Arc.) I'd complain more loudly, but I
> think Guido likes the fact that their ugliness dissuades people from
> using them...
If you fancy yourself a subversive (in which case you obviously already use
emacs rather than e.g. idle) try this:
;;Stefan Monnier's hack to make "lambda" display as λ (a greek lambda symbol)
(unless (featurep 'xemacs)
(defun pretty-lambdas ()
(font-lock-add-keywords
nil `(("\\<lambda\\>"
(0 (progn (compose-region (match-beginning 0) (match-end 0)
,(make-char 'greek-iso8859-7 107))
nil))))))
(add-hook 'emacs-lisp-mode-hook 'pretty-lambdas)
(add-hook 'python-mode-hook 'pretty-lambdas)
(add-hook 'ilisp-mode-hook 'pretty-lambdas))
alex
Erik Max Francis
> Do you think adding a few keystrokes by replacing
>
> >>> a + b * c[2]
>
> with the more explict
>
> >>> a operatorAddOrMaybeConcatenate (b operatorMultiplyOrMaybeRepeat
> c
> ... operatorAtIndexOrMaybeKey 1)
>
> would make python unusable? Or maybe just unpopular?
Just as using fewer keystrokes for its own sake is not a laudable goal,
neither is using more keystrokes for its own sake. Since nobody's
proposed anything like the above, it's a red herring.
> (Hint: in case the point of how mere "differences in keystrokes" can
> widely
> affect design choices in a language and its libraries was lost on you;
> do you
> really think anyone would dream of introducing a ternary operator if
> you could
> just do
>
> def when(cond, a,b):
> if cond: return a()
> else: return b()
>
> res = when(cond, :b, :c)
>
> instead of
>
> res = when(cond, lambda : b, lambda :c)
In a word, yes, because in a conditional operator the lazy evaluation is
implicit. You can forgot the lambdas/colons in the non-short-circuiting
version.
The point here is that terseness in and of itself is not a laudable
goal, especially for Python. Readability is far more important to me
than terseness. Considering that the functionality for this already
exists with the addition of _one_ extra keyword, offering the ability to
remove that lambda in the corner case of a zero-argument thunk does not
seem attractive; it makes it shorter, but it makes it less readable. I
want Python to be more Pythonic, not more like Perl.
That Smalltalk has a particularly compact form for expressing explicit
lazy evaluation is fine for Smalltalk. But that has no bearing on
whether Python should also have a compact form _for the sole purpose of
being compact_. Especially since getting the same effect in Python is
so straightforward.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Strange is our situation here upon earth.
\__/ Albert Einstein
Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
An Esperanto reference for English speakers.
Erik Max Francis
> Oh, c'mon. This is a frequently cited yet overstated wart. Yeah,
> technically it's a problem, but much more a theoretical than practical
> one
> - in practice the only time it causes problems is when you're doing
> something questionable anyway, like reusing a variable without
> initializing it to some known value.
Doesn't seem anymore a wart than for loops pollute the namespace with
the iteration variable. If one considers that a wart as well, then list
comprehensions were only following suit. Consistency with a
long-standing wart would be better than keeping the old wart and
introducing a _new_ one by making a very similar structure behave
differently (one pollutes and one doesn't).
Stephen Horne
wrote:
>Stephen Horne wrote:
>
>> A major problem with 'lambda' is simply that it is an obscure name.
>
>I don't agree. The term "lambda" is well-recognized throughout the
>computer science community as a construct which introduces an anonymous
>function.
I'm not convinced this is true. For anyone who is familiar with
functional languages it would be but, as far as I recall, the word
lambda was hardly mentioned in all my academic study. When I was
specifically studying functional languages, the standard phrase was
"function" - with "first class" specified only when necessary to
clarify a point.
I've worked with enough other programmers to know that my experience
is far from unique.
A lot of programmers only have experience with imperative languages,
and even if the word lambda was mentioned once or twice in a
particular lecture a decade ago, I wouldn't necessarily expect them to
remember it.
Then there's the fact that we use the name of the symbol that Church
used, rather than the name of the abstraction, which IMO is rather
obtuse. The abstraction is a (first class) function - not a Greek
letter. It may be hard to see for those of us who are familiar with
the word, but would we prefer the 'pow' function to be called
'superscript' just because thats how powers are written in
mathematics? The principle is the same. I prefer a spelling to a
metaspelling ;-)
>If you're new to programming and you're learning
>a language and you bump into a "lambda," one would hope you'd have the
>actual energy and willpower to look it up.
In general I agree with this - a hidden lambda, disguised in syntax
that is already commonly used for many other purposes, is far worse
than the existing explicit lambda. But many people do have problems
with the word lambda and having learned a different subset of computer
science to the one you learned (or having forgotten certain parts
through lack of everyday use) does not make their viewpoint invalid.
Stephen Horne
wrote:
>Do you think adding a few keystrokes by replacing
>
> >>> a + b * c[2]
>
>with the more explict
>
> >>> a operatorAddOrMaybeConcatenate (b operatorMultiplyOrMaybeRepeat c
> ... operatorAtIndexOrMaybeKey 1)
>
>would make python unusable? Or maybe just unpopular?
Unpopular, of course. But then it's a bad comparison. The '+' and '*'
symbols are sufficiently familiar to even newbie programmers that they
are as explicit as is needed anyway. In fact your versions are less
explicit as they are less understandable to non-English-speakers.
There'll probably come a day when '*' is seen as a historic absurdity,
of course - a relic of the ASCII character set ;-)
Even more important than the familiarity of the '+' and '*' operators
is the fact that those symbols are only used for a small number of
purposes - essentially one purpose each, in fact, if you consider that
most people think of concatenating sequences as adding them, and
repeating sequences as multiplying them (hence the choice of symbols).
Finally, an excess of symbol-only syntax in any language is a bad
thing because it increases the odds of a person being confused by two
or more constructs in a single chunk of code and perhaps not even
being able to isolate one from the other - ie leaving the person with
a major headache figuring out what's happening. Instead of learning
the language incrementally, newbies have to know everything just to
read one line of code.
An implicit lambda is distinguished from a plain subexpression purely
by the presence of a colon. Colons are used for quite a few other
purposes. A symbols-only spelling of lambda would not necessarily be a
bad thing, but any syntax would have to be clearly distinct from other
syntactic forms. The fact that the PEP already lists cases where the
grammar cannot accomodate implicit lambdas due to ambiguities already
hints at how confusable this notation would be.
I agree that spelling is important, but the spelling in the PEP is
not, IMO, a good one.
Stephen Horne
>too verbose - and so does Lisp guru Paul Graham, who's renamed lambda
>to fn in his new Lisp dialect Arc.) I'd complain more loudly, but I
Wow - I'd claim that "great minds think alike" but I think my
credibility would be stretched too thin.
Dave Brueck
> Dave Brueck wrote:
>
> > Oh, c'mon. This is a frequently cited yet overstated wart. Yeah,
> > technically it's a problem, but much more a theoretical than practical
> > one
> > - in practice the only time it causes problems is when you're doing
> > something questionable anyway, like reusing a variable without
> > initializing it to some known value.
>
> Doesn't seem anymore a wart than for loops pollute the namespace with
> the iteration variable. If one considers that a wart as well, then list
> comprehensions were only following suit. Consistency with a
> long-standing wart would be better than keeping the old wart and
> introducing a _new_ one by making a very similar structure behave
> differently (one pollutes and one doesn't).
My thoughts exactly.
-Dave
Alexander Schmolck
> > I don't think that follows. Python's list comprehensions are different -- they
> > pollute the namespace.
>
> Oh, c'mon. This is a frequently cited yet overstated wart. Yeah,
> technically it's a problem, but much more a theoretical than practical one
It isn't a major problem, but I can remember that it did (infrequently) cause
me bugs, so it's not all theoretical. Another minor cause of annoyance are
things like this:
SOME_GLOBAL_CONST = [(y**2, x**2) for (x,y) in SOME_OTHER_GLOBAL_CONST]
del x, y # I could do without this
> - in practice the only time it causes problems is when you're doing
> something questionable anyway, like reusing a variable without
> initializing it to some known value.
Or accidently overwriting a variable (or modulename).
All this might not amount to much, but I do think they violate the spirit of
functional programming enough to bias some people who like FP towards map and
filter.
alex
Dave Brueck
> Dave Brueck <da...@pythonapocrypha.com> writes:
>
> > > I don't think that follows. Python's list comprehensions are different -- they
> > > pollute the namespace.
> >
> > Oh, c'mon. This is a frequently cited yet overstated wart. Yeah,
> > technically it's a problem, but much more a theoretical than practical one
>
> It isn't a major problem, but I can remember that it did (infrequently) cause
> me bugs, so it's not all theoretical.
Could you post an example? Maybe I'm just being too narrowminded, but the
cases where it causes problems seem to be bad coding style anyway. I keep
thinking of stuff like:
x = 5
y = [int(x) for x in seq]
z = x + 2
Relying on x to still be 5 by the time z uses it, or relying on the value
of x to be some value because of what happened in the list comp both seem
sloppy to me. Am I missing some other common scenario?
> Another minor cause of annoyance are things like this:
>
> SOME_GLOBAL_CONST = [(y**2, x**2) for (x,y) in SOME_OTHER_GLOBAL_CONST]
> del x, y # I could do without this
I _do_ do without it, and it doesn't cause any problems.
> > - in practice the only time it causes problems is when you're doing
> > something questionable anyway, like reusing a variable without
> > initializing it to some known value.
>
> Or accidently overwriting a variable (or modulename).
Perhaps so. I guess I just reacted because I've never seen it happen in
practice. It seems like it'd be pretty rare in most cases, assuming
meaningful variable names. It's not too hard to dream up a counterexample,
but all the counterexamples I dreamt up _seemed_ dreamt up rather than
real ones. :)
> All this might not amount to much, but I do think they violate the spirit of
> functional programming enough to bias some people who like FP towards map and
> filter.
If you say so... do you explicitly delete your for-loop variables too?
for i in range(5):
print i
del i
If namespace pollution is a problem for you with listcomps, how are you
able to avoid it with for-loops? Might not your same problem avoidance
techniques apply to both?
Nice talking to you,
Dave
Erik Max Francis
> It isn't a major problem, but I can remember that it did
> (infrequently) cause
> me bugs, so it's not all theoretical. Another minor cause of annoyance
> are
> things like this:
>
> SOME_GLOBAL_CONST = [(y**2, x**2) for (x,y) in
> SOME_OTHER_GLOBAL_CONST]
> del x, y # I could do without this
But that wouldn't be any different than the explicit for loop form:
SOME_GLOBAL_CONST = []
for x, y in SOME_OTHER_GLOBAL_CONST:
SOME_GLOBAL_CONST.append((y**2, x**2))
del x, y # you could do without this
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I am the king of sorrow
\__/ Sade
REALpolitik / http://www.realpolitik.com/
Get your own customized newsfeed online in realtime ... for free!
Stephen Horne
wrote:
>Alexander Schmolck wrote:
>
>> It isn't a major problem, but I can remember that it did
>> (infrequently) cause
>> me bugs, so it's not all theoretical. Another minor cause of annoyance
>> are
>> things like this:
>>
>> SOME_GLOBAL_CONST = [(y**2, x**2) for (x,y) in
>> SOME_OTHER_GLOBAL_CONST]
>> del x, y # I could do without this
>
>But that wouldn't be any different than the explicit for loop form:
>
> SOME_GLOBAL_CONST = []
> for x, y in SOME_OTHER_GLOBAL_CONST:
> SOME_GLOBAL_CONST.append((y**2, x**2))
> del x, y # you could do without this
To me, the slight difference is that because I see list comprehensions
as functional I don't expect them to have side effects. Of course it
is a trivial issue, but it isn't *quite* as benign as the for loop
(which is 'supposed to' have side effects).
Terry Reedy
"Stephen Horne" <intent...@blank.co.uk> wrote in message
news:pmj86v0ba8n6kgunt...@4ax.com...
> To me, the slight difference is that because I see list
comprehensions
> as functional I don't expect them to have side effects. Of course it
Thanks for the explanation of how a difference of background makes a
difference of gut feeling. To me, they are just a somewhat weird and
redundant but increasingly comfortable new syntax. This is one issue
on which I am more of a newbie with less to unlearn ;-).
TJR
Alexander Schmolck
> But that wouldn't be any different than the explicit for loop form:
>
> SOME_GLOBAL_CONST = []
> for x, y in SOME_OTHER_GLOBAL_CONST:
> SOME_GLOBAL_CONST.append((y**2, x**2))
> del x, y # you could do without this
Of course not, but then nobody claimed that anyone who likes FP and Haskell
also necessarily has to like for loops.
alex
Alexander Schmolck
> On Mon, 3 Mar 2003, Alexander Schmolck wrote:
> > Another minor cause of annoyance are things like this:
> >
> > SOME_GLOBAL_CONST = [(y**2, x**2) for (x,y) in SOME_OTHER_GLOBAL_CONST]
> > del x, y # I could do without this
>
> I _do_ do without it, and it doesn't cause any problems.
Yes it does -- maybe not to you but to the people who import your module
(unless you use __all__, or wrap everything like the above in a function
call), because otherwise your module exports rubbish.
And BTW, unless one's lucky, global variables like x, y and i are quite likely
to cause trouble so I see no point in carelessly introducing this pitfall.
I've more than once had situations where a function due to a typo accidently
refered to a global i/x/y (instead of throwing a NameError), mostly because in
interactive sessions one tends to accumulate rubbish like this in global
scope.
>
> > > - in practice the only time it causes problems is when you're doing
> > > something questionable anyway, like reusing a variable without
> > > initializing it to some known value.
> >
> > Or accidently overwriting a variable (or modulename).
>
> Perhaps so. I guess I just reacted because I've never seen it happen in
> practice. It seems like it'd be pretty rare in most cases, assuming
> meaningful variable names. It's not too hard to dream up a counterexample,
> but all the counterexamples I dreamt up _seemed_ dreamt up rather than
> real ones. :)
Well, you asked for an example -- I vaguely remember that I did something like
this:
... [time + delta for time in computeTimes()] ...
I then (possibly as an later addition) wanted to use the time module at a
later point in this function (which I had globally imported for other
functions). No big deal.
>
> > All this might not amount to much, but I do think they violate the spirit of
> > functional programming enough to bias some people who like FP towards map and
> > filter.
>
> If you say so... do you explicitly delete your for-loop variables too?
>
> for i in range(5):
> print i
> del i
In global scope -- yes. Don't you?
>
> If namespace pollution is a problem for you with listcomps, how are you
> able to avoid it with for-loops? Might not your same problem avoidance
> techniques apply to both?
Ahem, do you still remember how we got here? I claimed that someone with a FP
slant who usually prefers map and filter in python to list comprehesions is
not automatically a Haskell hater.
Do Haskell list comprehensions force you to "use problem avoidance
techniques"? Do map and filter in python force you to "use problem avoidance
techniques"?
alex
Dave Brueck
> Dave Brueck <da...@pythonapocrypha.com> writes:
>
> > On Mon, 3 Mar 2003, Alexander Schmolck wrote:
> > > Another minor cause of annoyance are things like this:
> > >
> > > SOME_GLOBAL_CONST = [(y**2, x**2) for (x,y) in SOME_OTHER_GLOBAL_CONST]
> > > del x, y # I could do without this
> >
> > I _do_ do without it, and it doesn't cause any problems.
>
> Yes it does -- maybe not to you but to the people who import your module
> (unless you use __all__, or wrap everything like the above in a function
> call), because otherwise your module exports rubbish.
No, it is generally a no-no to do "from foo import *" - so much so that it
doesn't even _work_ in some cases (inside a function), so I'm not
especially worried about taking care of people who do it anyway (but if I
did, that's precisely what __all__ is for).
> > Perhaps so. I guess I just reacted because I've never seen it happen in
> > practice. It seems like it'd be pretty rare in most cases, assuming
> > meaningful variable names. It's not too hard to dream up a counterexample,
> > but all the counterexamples I dreamt up _seemed_ dreamt up rather than
> > real ones. :)
>
> Well, you asked for an example -- I vaguely remember that I did something like
> this:
>
> ... [time + delta for time in computeTimes()] ...
>
> I then (possibly as an later addition) wanted to use the time module at a
> later point in this function (which I had globally imported for other
> functions). No big deal.
I guess it's a matter of coding style. To me it seems sloppy to be doing a
a whole lot of module-level computation and/or using names of well-known
modules as variables (e.g. using 'os' as a variable name _anywhere_ except
the os module is bound to bite you eventually, regardless of whether or
not listcomps "leak" into your namespace). If you don't have any qualms
about using 'time' as a variable name, surely you've also been bitten by
it when you used it in a for-loop, no?
> > If you say so... do you explicitly delete your for-loop variables too?
> >
> > for i in range(5):
> > print i
> > del i
>
> In global scope -- yes. Don't you?
Nope, never. And it has _never_ caused me problems in practice.
> > If namespace pollution is a problem for you with listcomps, how are you
> > able to avoid it with for-loops? Might not your same problem avoidance
> > techniques apply to both?
>
> Ahem, do you still remember how we got here? I claimed that someone with a FP
> slant who usually prefers map and filter in python to list comprehesions is
> not automatically a Haskell hater.
>
> Do Haskell list comprehensions force you to "use problem avoidance
> techniques"? Do map and filter in python force you to "use problem avoidance
> techniques"?
No and no. And in practice neither do list comps and for-loops.
To-each-his-own-ly y'rs,
-Dave
Gerrit Holl
> [1] Keyword list taken from pthon-mode.el
> * shorter keywords: is, in, or, if, not, def, del, and, for, pass, elif,
> else, exec, from, break, print, raise, while, yield, class
> * same length keywords: assert, import, except, global, return
> * longer keyword(!): continue
>
> [2]
> Note that all the other 6 & 7 length keywords are the first thing on a line
As are all the 5 lenght keywords.
yours,
Gerrit.
--
Asperger Syndroom - een persoonlijke benadering:
http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
http://www.sp.nl/
Alexander Schmolck
> No, it is generally a no-no to do "from foo import *"
True, but I think there are exceptions (when qualified names or specifying
each import are quite awkward -- the only example that readily comes to mind
are math libraries or a library that is largely meant for interactive
use). Anyway, I just prefer not to litter -- it also makes it easier to get a
quick overview of the module by doing ``dir`` etc.
> >
> > Well, you asked for an example -- I vaguely remember that I did something like
> > this:
> >
> > ... [time + delta for time in computeTimes()] ...
> >
> > I then (possibly as an later addition) wanted to use the time module at a
> > later point in this function (which I had globally imported for other
> > functions). No big deal.
>
> I guess it's a matter of coding style. To me it seems sloppy to be doing a
> a whole lot of module-level computation and/or using names of well-known
No argument that doing a lot of module-level compuation is sloppy, so I mainly
use one-liners on module level (computing a global variable or constant in a
single expression or (possibly looped) attribute asignments and other simple
reflection).
> modules as variables (e.g. using 'os' as a variable name _anywhere_ except
> the os module is bound to bite you eventually, regardless of whether or
> not listcomps "leak" into your namespace). If you don't have any qualms
> about using 'time' as a variable name, surely you've also been bitten by
> it when you used it in a for-loop, no?
I presume the reason I got bitten was my expectancy that list comp.s introduce
a new scope. I wouldn't have any qualms using time in ``map(lambda time,:
...`` or in a function signature since there is no good alternative word or
spelling.
> Nope, never. And it has _never_ caused me problems in practice.
Just out of curiosity, do you do much work in interactive shells? Maybe our
stylistic differences might have to do with our working habbits -- much of the
code I write has to be 'import *' safe, because otherwise it would be
cumbersome for interactive sessions.
Anyway, I guess I'm just being overly pedantic, so I'll stop the nitpicking
now.
alex
Alexander Schmolck
> But that has no bearing on whether Python should also have a compact form
> _for the sole purpose of being compact_.
No one suggests such a thing! I think there are maybe 4 different levels at
which the mere conciseness of a construct FOO (with a hypothetical, more
verbose alternative, FOO_VERBOSE) can affect a language:
1. FOO is used in the same places as FOO_VERBOSE would, but the code becomes
more (or less) readable (e.g. ``Bignum(1).add(3)`` 'vs' ``1l + 3``)
2. FOO is used in places where FOO_VERBOSE wouldn't be used, because it is too
cumbersome (e.g. I'd wager that people more readily use dicts in python
than HashTables in java).
3. FOO's conciseness affects the design of interfaces of other functions (so
that they become in some way better, or more general -- e.g. `ifAbsent` vs
`.get`).
4. FOO's conciseness renders certain hypothetical language extensions
unnecessary (e.g. control construct syntax, and to some extent even macros,
in smalltalk).
Now 3 and 4 are of course quite rare, (but all other things being equal),
rather desirable. I think smalltalk's blocks satisfy all 4 (and smalltalk,
although different, is not completely unlike python).
Of course adding a (amongst other things, highly syntactically constrained and
possibly rather restricted) lightweight anonymous function equivalent to
python at this stage might not be worth while the trouble (and increase in
complexity). Also, as you and others remarked, certain syntactic possiblities
might be errorprone or unreadable.
Nonetheless, I think the ability to easily pass chunks of code around (and no
-- lambda does not qualify; or I'd like to see how you rewrite a smalltalk
program by replacing blocks with something like lambda) that close over the
current environment, even if added to python now, is unlikely to affect the
only point 1 (as you seem to imply).
alex
Dave Brueck
> > Nope, never. And it has _never_ caused me problems in practice.
>
> Just out of curiosity, do you do much work in interactive shells?
> Maybe our stylistic differences might have to do with our working
> habbits -- much of the code I write has to be 'import *' safe, because
> otherwise it would be cumbersome for interactive sessions.
Most of the interactive work I do is during development - testing mostly.
Anytime the user of the program will be doing stuff interactively I use
__all__ to make it 'import *' safe. Maybe I didn't get bitten because I
was overly cautious. ;-)
Have fun,
Dave
Greg Ewing (using news.cis.dfn.de)
> For that reason, although I wouldn't mind having a more compact way of
> writing lambda-expressions, I don't think that the colon syntax is
> the best way to do it.
How about
(a, b) -> expr
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Stephen Horne
>Andrew Koenig wrote:
>> For that reason, although I wouldn't mind having a more compact way of
>> writing lambda-expressions, I don't think that the colon syntax is
>> the best way to do it.
>
>How about
>
> (a, b) -> expr
I see what you're getting at. I'd certainly prefer it to the existing
PEP312 suggestion. I could even imagine putting the name back on the
front as a shorthand for short named functions that don't need
imperative statements - giving a syntax which is almost identical to
the math notation...
f (a, b) -> expr
But there is, IMO, still a clarity issue. Apart from people who use
the math notation every day, I suspect most people won't find the
meaning of this notation obvious. Also, the leading part describing
the formal parameters looks a lot like (in most cases, exactly like) a
tuple until you reach that operator.
In other words, this could be a bit confusing.
In general, I like all but the most obvious constructs to have a
leading keyword - even if it's an abbreviation - because as a last
resort the reader can always look up that keyword to find an
explanation of the syntax and what it means.
Your idea isn't necessarily bad - the '->' operator is at least a
unique symbol rather than a reuse of existing symbols, and the syntax
has a clear basis outside of the limits of Python programming - it's
just that it still makes me slightly nervous.
Of course, I could just be rationalising to cover up my "it's new"
syndrome ;-)
A. Lloyd Flanagan
> Alexander Schmolck wrote:
>
> That Smalltalk has a particularly compact form for expressing explicit
> lazy evaluation is fine for Smalltalk. But that has no bearing on
> whether Python should also have a compact form _for the sole purpose of
> being compact_. Especially since getting the same effect in Python is
> so straightforward.
Part of the problem, I think, is that people coming from other
languages don't understand the power and proper use of the lambda
construct. I also agree that lambda is a horrible keyword for it, as
it doesn't convey anything about its use to a non-Lisp/functional
language programmer. I'll bet 95% of the programmers out there
wouldn't know a lambda form from a racing form.
One solution would be to provide a lot more documentation of lambda
and its use in different situations, preferably as part of the
tutorial. But I also definitely think that if we can find a better
way to do lambdas we should.
Daniel Dittmar
> Part of the problem, I think, is that people coming from other
> languages don't understand the power and proper use of the lambda
> construct.
coming from Smalltalk:
Python lambdas are restricted to one expression, which makes them cumbersome
to use for more complex stuff and difficult to debug as you can't insert a
quick 'print'.
Daniel
Thomas Bellman
> coming from Smalltalk:
> Python lambdas are restricted to one expression, which makes them cumbersome
> to use for more complex stuff and difficult to debug as you can't insert a
> quick 'print'.
They also execute in their own namespace, with their own local
variables. From what I understand, code blocks in Smalltalk
execute in the same namespace/scope as the surrounding code, and
cam thus bind variables in the surrounding code. Even if lambdas
in Python were not restricted to expressions, the following
would still just print "17":
def select(n, *blocks):
blocks[n]()
x = 17
select(1, lambda: x=23, lambda: x=69, lambda: x=4711)
print x
--
Thomas Bellman, Lysator Computer Club, Linköping University, Sweden
"You cannot achieve the impossible without ! bellman @ lysator.liu.se
attempting the absurd." ! Make Love -- Nicht Wahr!
Greg Ewing (using news.cis.dfn.de)
> From what I understand, code blocks in Smalltalk
> execute in the same namespace/scope as the surrounding code, and
> cam thus bind variables in the surrounding code.
As far as I remember, they can have their own local
variables, so it's probably more accurate to say
that they execute in a lexically nested scope.
But there's no problem with rebinding variables in an
outer scope in Smalltalk, since all variables are
declared.
Greg Ewing (using news.cis.dfn.de)
> In general, I like all but the most obvious constructs to have a
> leading keyword - even if it's an abbreviation - because as a last
> resort the reader can always look up that keyword to find an
> explanation of the syntax and what it means.
That's a very good point.
If I were re-designing Python I would probably just
replace "lambda" with "func". ("fn" is a bit too short
for my liking, and besides, how do you pronounce it?)
Jack Diederich
> If I were re-designing Python I would probably just
> replace "lambda" with "func". ("fn" is a bit too short
> for my liking, and besides, how do you pronounce it?)
short is good, non-alpha is good. A problem with the lambda keyword is
that it sticks out like a sore thumb and jars the eye when reading.
A groups.google link to a post where (in the footnotes) I mention that 'lambda'
is both A: a long keyword, and B: one of the few keywords that never starts
a line (hence it jars the eye).
Variables-to-the-left-of-me-arguments-on-my-right-ly,
-labmda, err, jackdied
Stephen Horne
<ja...@performancedrivers.com> wrote:
>A groups.google link to a post where (in the footnotes) I mention that 'lambda'
>is both A: a long keyword, and B: one of the few keywords that never starts
>a line (hence it jars the eye).
I don't really see the relevance of the fact that "'lambda' never
starts a line". Other frequently used words (such as built-in function
names) also never start a line - 'reduce' is as long as 'lambda' for a
start. What is the relevance of the distinction between keywords and
standard identifiers in this issue?
Erik Max Francis
> I don't really see the relevance of the fact that "'lambda' never
> starts a line". Other frequently used words (such as built-in function
> names) also never start a line - 'reduce' is as long as 'lambda' for a
> start. What is the relevance of the distinction between keywords and
> standard identifiers in this issue?
Furthermore, it's perfectly legal for lambda to "start a line," it's
just not particularly useful (i.e., an expression statement with no
effect).
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Life is an effort that deserves a better cause.
\__/ Karl Kraus
The laws list / http://www.alcyone.com/max/physics/laws/
Laws, rules, principles, effects, paradoxes, etc. in physics.
Stephen Horne
wrote:
>Erik Max Francis <m...@alcyone.com> writes:
>
>> But that has no bearing on whether Python should also have a compact form
>> _for the sole purpose of being compact_.
>
>No one suggests such a thing! I think there are maybe 4 different levels at
>which the mere conciseness of a construct FOO (with a hypothetical, more
>verbose alternative, FOO_VERBOSE) can affect a language:
>
>1. FOO is used in the same places as FOO_VERBOSE would, but the code becomes
> more (or less) readable (e.g. ``Bignum(1).add(3)`` 'vs' ``1l + 3``)
'+' is a common operation that everyone understands. 'lambda' is not.
Completely removing the best clue to what's going on (ie a keyword to
look up in the documentation) does not aid readability.
>2. FOO is used in places where FOO_VERBOSE wouldn't be used, because it is too
> cumbersome (e.g. I'd wager that people more readily use dicts in python
> than HashTables in java).
Having had to explain lists and dictionaries to a couple of
programmers who'd only used statically typed languages before, I can
say that some irritation would have been avoided if the respective
syntaxes were...
list {1, 2, 3, 4, ...}
dict {1 : 2, 3 : 4, ...}
It's not so much the "oh that - that's a list" that causes the
problem. It's the explaining that list support is built in, doesn't
require a library class, doesn't specify the implementation, etc etc.
At the end of that, I've lost the thread of whatever I was doing
before. All avoidable if the people involved could look up the keyword
and find out for themselves.
Well - probably 30 mins out of my life in total. Hardly a big issue.
But let's get back to the point...
I don't know how HashTables work in Java, but I do know that there is
a happy medium for conciseness - like lossy compression, smaller
representations are only better to a point. And the decision on where
to stop is inherently a subjective one.
For me, when a construct has no explicit indicator of what it's doing
it usually means the compression has gone a step or two too far.
Explicit does not always mean a keyword ('+' for instance is explicit
enough), but quite often that is what is required.
Every language has a few 'overcompressed' syntaxes. This isn't
necessarily a bad thing. These syntaxes tend to define the style of a
particular language, and they reflect the languages priorities. If
there are too many highly compressed notations, though - and
particular if some are rarely used except by code-obfuscators - it
leads to unreadable code. In particular, if each symbol is put to too
many different uses, the results can rapidly get very confusing.
The C comma operator is probably the definitive example of conciseness
gone mad. The comma is most often used as a separator punctuation, so
the comma as an evaluate-and-discard operator is far from intuitive
when its first seen. It works extremely well when used for in-step
loops, but its wider generality leads to no end of confusion and
errors. For example, what does the following code output...
int x = 0;
switch (x)
{
case 0, 1 : cout << "First case passed" << endl; break;
default : cout << "Default case passed" << endl; break;
}
The correct answer is "Default case passed" - the first case evaluates
the '0' but discards it, and only actually tests for the '1'. But can
you honestly claim that result is intuitive?
The fact is that the C comma should (at least in my opinion) never
have been used as an evaluate-and-discard operator. Either a more
explicit operator should have been used, or else the comma should have
been recognised as a special separator in 'for' and 'while' clauses
specifically designed for setting up in-step loops without the more
general evaluate-and-discard meaning. If it did that, even the
intended purpose would have been enhanced in C++ - you could write...
for (int i = 0, float j = 1.0; i++, j *= 1.1; i < 100)
{
...
}
As things stand, this is illegal - you can't combine the 'int' and
'double' declarations in one statement using the evaluate-and-discard
operator, though if it was just a separator it could have been seen as
separating two independent statements.
By being too general, too concise, and by 'overloading' the comma
symbol, the C evaluate-and-discard operator contributes significantly
to the readability, maintainability and reliability problems in that
language - and gets in the way of even the task it is designed to
support.
Python has a fair share of highly compressed syntaxes, but it also has
a style which favours readability. Adding a new highly compressed
syntax should be considered very carefully, and should really only be
done if the syntax is likely to be put to everyday use by average
programmers - ie if most people who would have a reason to read Python
source code would recognise it immediately.
As much as I like lambdas, they simply aren't used that much by most
programmers - and I seriously doubt that dropping the 'lambda' keyword
would make that much difference.
And besides, the syntax should certainly be distinguished from plain
expressions by more than a colon - a symbol which already has several
uses in Python.
>3. FOO's conciseness affects the design of interfaces of other functions (so
> that they become in some way better, or more general -- e.g. `ifAbsent` vs
> `.get`).
The strength of the 'ifAbsent' notation, however, isn't just about
having a single concise notation - it's tightly coupled to the overall
design of SmallTalk, and I'm not convinced you can draw useful
conclusions about conciseness in general from it.
>4. FOO's conciseness renders certain hypothetical language extensions
> unnecessary (e.g. control construct syntax, and to some extent even macros,
> in smalltalk).
I'm not convinced an abbreviated lambda could achieve this any more
than the existing lambda - e.g. you could only render control constuct
syntax less readable, and macros don't exist anyway in Python.
>Now 3 and 4 are of course quite rare, (but all other things being equal),
>rather desirable. I think smalltalk's blocks satisfy all 4 (and smalltalk,
>although different, is not completely unlike python).
Python has it's own style, and lambdas - while extremely useful for
certain tasks - are not a fundamental part of that style. Smalltalks
codeblocks seem much more fundamental to that languages style. This is
a significant difference.
>Of course adding a (amongst other things, highly syntactically constrained and
>possibly rather restricted) lightweight anonymous function equivalent to
>python at this stage might not be worth while the trouble (and increase in
>complexity). Also, as you and others remarked, certain syntactic possiblities
>might be errorprone or unreadable.
Changing the subject a second, this can be linked to a the idea of
using XML as a source language.
The editor might display a marker in place of the lambda. Select the
marker, and a drop-down editing pane (or separate window or whatever)
could appear, containing the body of the lambda complete with
indentation-based block structures. As the layout of the lambda body
is independent of the layout of the code that it is embedded in,
readability is improved and certain syntax related issues are avoided.
>Nonetheless, I think the ability to easily pass chunks of code around (and no
>-- lambda does not qualify; or I'd like to see how you rewrite a smalltalk
>program by replacing blocks with something like lambda
A naive translation of Python code to Smalltalk would also be pretty
awkward.
>) that close over the
>current environment, even if added to python now, is unlikely to affect the
>only point 1 (as you seem to imply).
Everything you've said has some truth to it, but IMO the specifics of
PEP312 raise serious issues that run counter to each of those points.
The comparison with the C comma operator should give anyone good
reason to fear the PEP312 syntax.
Karl A. Krueger
>> In general, I like all but the most obvious constructs to have a
>> leading keyword - even if it's an abbreviation - because as a last
>> resort the reader can always look up that keyword to find an
>> explanation of the syntax and what it means.
>
> That's a very good point.
>
> If I were re-designing Python I would probably just
> replace "lambda" with "func". ("fn" is a bit too short
> for my liking, and besides, how do you pronounce it?)
Oddly enough, the limitation of Python lambda is reminiscent of the
DEF FN statements in some flavors of BASIC. Like Python lambda, a BASIC
function defined with DEF FN -- in at least some of the flavors of micro
BASIC that damaged my brain in my youth -- could not contain statements.
--
Karl A. Krueger <kkru...@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
Alex Martelli
> On Wed, 12 Mar 2003 17:54:37 -0500, Jack Diederich
> <ja...@performancedrivers.com> wrote:
>
>>A groups.google link to a post where (in the footnotes) I mention that
>>'lambda' is both A: a long keyword, and B: one of the few keywords that
>>never starts a line (hence it jars the eye).
>
> I don't really see the relevance of the fact that "'lambda' never
> starts a line". Other frequently used words (such as built-in function
> names) also never start a line - 'reduce' is as long as 'lambda' for a
Some built-in function names OFTEN "start a line" -- setattr, for
example (you're far more rarely going to use setattr EXCEPT at the
start of a line).
> start. What is the relevance of the distinction between keywords and
> standard identifiers in this issue?
No idea, just wanted to correct the previous strange assertion;-).
Alex
Stephen Horne
wrote:
>Stephen Horne wrote:
>
>> On Wed, 12 Mar 2003 17:54:37 -0500, Jack Diederich
>> <ja...@performancedrivers.com> wrote:
>>
>>>A groups.google link to a post where (in the footnotes) I mention that
>>>'lambda' is both A: a long keyword, and B: one of the few keywords that
>>>never starts a line (hence it jars the eye).
>>
>> I don't really see the relevance of the fact that "'lambda' never
>> starts a line". Other frequently used words (such as built-in function
>> names) also never start a line - 'reduce' is as long as 'lambda' for a
>
>Some built-in function names OFTEN "start a line" -- setattr, for
>example (you're far more rarely going to use setattr EXCEPT at the
>start of a line).
So what? - some keywords not only OFTEN but ALWAYS start a line.
Jack Diederich is obviously OK with long words starting a line, so I
didn't have anything to be confused about in that case.
>> start. What is the relevance of the distinction between keywords and
>> standard identifiers in this issue?
>
>No idea, just wanted to correct the previous strange assertion;-).
Correct what?
For me, the strange assertion is that "'lambda' is ... one of the few
keywords that never starts a line". It's pretty much accurate, but I
don't see the relevance - especially given that other words than
keywords can be just as long and yet equally be unable (or at least
unlikely) to start a line. I simply wanted to question the relevance
of worrying about the length of keywords that never start a line by
pointing out that other long words may equally never start a line but
are apparently OK.
You're assertion that some built-in function names often start a line
seems to have no relevance to either Jacks or my statements. We are
not debating the kinds of words that *can* start a line. It has
nothing to do with the question at hand.
So I ask again - why does Jack think that keywords that never start a
line should never be long when many other words that never start a
line are long? What is the relevance of the keyword/other word
distinction in this issue?
"ice-cream is cold" will not be considered a valid answer.
Alex Martelli
...
>>> I don't really see the relevance of the fact that "'lambda' never
>>> starts a line". Other frequently used words (such as built-in function
>>> names) also never start a line - 'reduce' is as long as 'lambda' for a
>>
>>Some built-in function names OFTEN "start a line" -- setattr, for
>>example (you're far more rarely going to use setattr EXCEPT at the
>>start of a line).
>
> So what? - some keywords not only OFTEN but ALWAYS start a line.
So, the assertion that built-in function names never start a line
is incorrect. The fact that some keywords "always start a line"
has no relevance wrt the fact that built-in function names also can --
rarely for functions that have no side effects (and for lambda),
often for those that do (such as setattr). The only keywords that
can NEVER "start a line" (a logical line -- they could, of course,
be at the start of a physical line that's a continuation line!-)
are: and, in, is, or.
> Jack Diederich is obviously OK with long words starting a line, so I
> didn't have anything to be confused about in that case.
>
>>> start. What is the relevance of the distinction between keywords and
>>> standard identifiers in this issue?
>>
>>No idea, just wanted to correct the previous strange assertion;-).
>
> Correct what?
The strange assertion that built-in function names "never start a
line".
> For me, the strange assertion is that "'lambda' is ... one of the few
> keywords that never starts a line". It's pretty much accurate, but I
If you change "never" into "rarely", it becomes accurate, and you
can then also strengthen the "one of the few keywords" into "the
only keyword" -- four keywords are operators ('in' is also used as
part of 'for' syntax) and NEVER start (logical) lines, 24 begin
statements or clauses thereof and always (for compound statements
and clauses) or often (for simple statements) start a line, lambda
is the only one that CAN do so but is RARELY seen in that role as
such an expression-statement essentially serves no useful purpose.
> don't see the relevance - especially given that other words than
I don't see the relevance of this whole discussion to anything, either.
In particular, if somebody's trying to assert something about keywords,
whether that assertion be well-founded or not, your counter-assertions
about tokens that are NOT keywords has no possible relevance that I
can see. So, I've given up on trying to understand why all of these
non-sequiturs are accumulating on this thread and just making sure that
what _DOES_ get said, whether relevant or not, is at least correct.
> You're assertion that some built-in function names often start a line
> seems to have no relevance to either Jacks or my statements. We are
> not debating the kinds of words that *can* start a line. It has
> nothing to do with the question at hand.
It's not a question of debating, but one of asserting, specifically
of asserting things that are false. It is NOT true that built-in
functions never start a line: they are all ALLOWED to do so (as is
lambda) [and some of them are seen in such positions frequently,
while others are seen in such positions rarely].
Feel free to continue this weird discussion, but don't be surprised
if I correct assertions that are false, quite apart from the issue
of the relevance of anything to anything else.
Alex
Steve Holden
news:jk_ba.71962$zo2.1...@news2.tin.it...
> Stephen Horne wrote:
[...]
> >
> > Correct what?
>
> The strange assertion that built-in function names "never start a
> line".
>
>
> > For me, the strange assertion is that "'lambda' is ... one of the few
> > keywords that never starts a line". It's pretty much accurate, but I
>
> If you change "never" into "rarely", it becomes accurate, and you
> can then also strengthen the "one of the few keywords" into "the
> only keyword" -- four keywords are operators ('in' is also used as
> part of 'for' syntax) and NEVER start (logical) lines, 24 begin
> statements or clauses thereof and always (for compound statements
> and clauses) or often (for simple statements) start a line, lambda
> is the only one that CAN do so but is RARELY seen in that role as
> such an expression-statement essentially serves no useful purpose.
>
> > don't see the relevance - especially given that other words than
>
> I don't see the relevance of this whole discussion to anything, either.
>
> In particular, if somebody's trying to assert something about keywords,
> whether that assertion be well-founded or not, your counter-assertions
> about tokens that are NOT keywords has no possible relevance that I
> can see. So, I've given up on trying to understand why all of these
> non-sequiturs are accumulating on this thread and just making sure that
> what _DOES_ get said, whether relevant or not, is at least correct.
>
> > You're assertion that some built-in function names often start a line
> > seems to have no relevance to either Jacks or my statements. We are
> > not debating the kinds of words that *can* start a line. It has
> > nothing to do with the question at hand.
>
> It's not a question of debating, but one of asserting, specifically
> of asserting things that are false. It is NOT true that built-in
> functions never start a line: they are all ALLOWED to do so (as is
> lambda) [and some of them are seen in such positions frequently,
> while others are seen in such positions rarely].
>
> Feel free to continue this weird discussion, but don't be surprised
> if I correct assertions that are false, quite apart from the issue
> of the relevance of anything to anything else.
>
The moon is made of green cheese :-)
regards
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
Register for PyCon now! http://www.python.org/pycon/reg.html
Stephen Horne
for reasons that were not your fault.
However...
On Thu, 13 Mar 2003 11:54:55 GMT, Alex Martelli <al...@aleax.it>
wrote:
>Stephen Horne wrote:
> ...
>>>> I don't really see the relevance of the fact that "'lambda' never
>>>> starts a line". Other frequently used words (such as built-in function
>>>> names) also never start a line - 'reduce' is as long as 'lambda' for a
>>>
>>>Some built-in function names OFTEN "start a line" -- setattr, for
>>>example (you're far more rarely going to use setattr EXCEPT at the
>>>start of a line).
>>
>> So what? - some keywords not only OFTEN but ALWAYS start a line.
>
>So, the assertion that built-in function names never start a line
>is incorrect.
I never made that assertion, though on further examination I see why
you thought I did.
My words were "Other frequently used words (such as built-in function
names) also never start a line".
I did not say "_all_ built-in function names". Neither did I say
"_some_ built-in function names". That part was not clarified because,
in context, it was unnecessary - _all_ or _some_ makes no difference
to the point I was making - and because the _some_ was, to me, implied
by common sense anyway.
Context pervades all natural language. That is why the (sadly highly
subjective) thing called common sense is so important to natural
language communication, and an important reason why natural language
can never be a perfect medium of communication.
One of the things I like about Steven Pinkers "The Language Instinct"
and "Words and Rules" is the healthy disrespect that he, as a
linguistics expert, has towards language pedantry and particularly
towards "language mavens" as he calls them. "Words and Rules" is, in
my opinion, actually quite a dull book relative to his others - mainly
because I'm already familiar with the formal grammar concepts that he
describes so painfuly slowly - but at a few points he certainly had me
laughing out loud at his descriptions of how the pedants completely
miss the point.
Anyway, the fact that many built-in function names can start a line is
common sense to me as Python has no equivalent to the Pascal
distinction between functions and procedures. Hence I didn't feel any
need to clarify "some" built-in functions. Hence, when you 'corrected'
me, implying that I didn't know this common sense thing, I felt
insulted and - in my already bad mood - I overreacted.
Once again, I am sorry for that.
Now I think about it, most built-in functions probably return a value
(I can't be bothered checking, but most of the ones I can think of off
the top of my head do anyway). While some of those may still be used
(or abused) for their side effects, a person might reasonably consider
that functions that can appear at the start of a line are exceptional.
We then get into the subjective nature of common sense, and how I
really wish I wasn't in such a foul mood this morning.
Stephen Horne
wrote:
>I don't see the relevance of this whole discussion to anything, either.
>
>In particular, if somebody's trying to assert something about keywords,
>whether that assertion be well-founded or not, your counter-assertions
>about tokens that are NOT keywords has no possible relevance that I
>can see.
I missed this when I replied before (mainly because I was too busy
feeling stupid for overreacting) but I would like to explain...
What Jack was asserting was not just that lambda is a long keyword
that is (almost) always in the middle of a line. His intention was to
assert that this property is responsible for making the word 'lambda'
"jar the eyes".
To me, it seems absurd that the ugliness of a word could be a function
of whether it happens to be a keyword or some other kind of word. The
distinction between keywords and identifiers has no relevance to how
jarring something is when you read it.
That was the point of my counter-argument, but it would have no
relevance if there were no other long words which always appear in the
middle of a line.
That is why the counter-assertion about other tokens was relevant - to
establish that long words which always appear in the middle of lines
are not always considered ugly, and thus that the question of whether
or not keywords and other tokens should be distinguished in this
context.
That is why I said, right in my first post, "What is the relevance of
the distinction between keywords and standard identifiers in this
issue?"
BTW - on the 'never'/'rarely' issue - there is a term "relative
absolute" which with a simple play on words expresses the fact that it
is perfectly valid to use 'absolute' words as extreme relatives.
Superlatives are, quite simply, not always *strictly* superlative.
It's all part of the subjectivity of natural language, and one of the
reasons context can be so important - not to mention, where relevant,
redundancy (in the error detection and correction sense).
Knowledge of these kinds of things is only really useful if you want
to out-pedant a language pedant, of course ;-)
Jacks use of a "relative absolute" isn't an issue to me - the meaning
was clear enough and, even if it wasn't, the never/rarely distinction
is about as relevant as (in my mind) the
keyword/built-in-function-name distinction. Clarification would have
been a waste of time.
Stephen Horne
>("fn" is a bit too short
>for my liking, and besides, how do you pronounce it?)
I'd normally pronounce it as 'function' to be honest, unless I needed
to clarify the intended spelling.
Alex Martelli
...
> What Jack was asserting was not just that lambda is a long keyword
> that is (almost) always in the middle of a line. His intention was to
> assert that this property is responsible for making the word 'lambda'
> "jar the eyes".
Ah, thanks for the clarification; I had indeed missed this intention.
> To me, it seems absurd that the ugliness of a word could be a function
> of whether it happens to be a keyword or some other kind of word. The
> distinction between keywords and identifiers has no relevance to how
> jarring something is when you read it.
Probably not; the keyword/identifier distinction is very important
in some contexts but presumably not in that of "jarringhood" (:-).
> BTW - on the 'never'/'rarely' issue - there is a term "relative
> absolute" which with a simple play on words expresses the fact that it
> is perfectly valid to use 'absolute' words as extreme relatives.
I'm not familiar with the specifical oxymoron you quote, but in more
classic terms it does seem a form of hyperbole, or even catachresis.
Like many other rhetorical figures, it can usefully color one's speech,
but particularly in technical discourse it's best used cautiously, as
it can engender misunderstandings.
In this specific case, since there ARE some keywords that can never
start a (logical) line ('and', &c), AND some that can but rarely do
('lambda'), conflating the two with a hyperbolic "never" can in
fact leave some doubt in the reader -- particularly when unsure of
the point of the whole discourse -- as to whether the writer is
aware of the distinction, and whether the distinction being thus
brushed away is or isn't relevant to the issue anyway. I'm not sure
the confusion is worth the slight "coloring" (see, litotes [which is
here shading into aporia] can also offer one's discourse some color,
while being less prone to such misunderstandings as the more popular
hyperbole can often engender...).
> Superlatives are, quite simply, not always *strictly* superlative.
> It's all part of the subjectivity of natural language, and one of the
> reasons context can be so important - not to mention, where relevant,
> redundancy (in the error detection and correction sense).
>
> Knowledge of these kinds of things is only really useful if you want
> to out-pedant a language pedant, of course ;-)
Knowledge of rhetorics has its uses, and providing hi-falutin' terms
that are not widely known is one such use, particularly in pedanter-
than-thou duels...
Alex
Alex Martelli
...
>>>>> starts a line". Other frequently used words (such as built-in function
>>>>> names) also never start a line - 'reduce' is as long as 'lambda' for a
>>So, the assertion that built-in function names never start a line
>>is incorrect.
>
> I never made that assertion, though on further examination I see why
> you thought I did.
Ah, yes -- I do see a parenthesis of "Other <Y>s (such as <X>s)" as
meaning "all <X>s are <Y>s" without needing a redundant "all" after
the word "as" (just as "all <X>s are <Y>s" does not need the pleonasm
of the reinforcing "all" -- it means the same thing without it).
So, I believe you simply mis-spoke, and are now trying to hedge by
claiming some ambiguity (needing to be resolved by context) for a
phrasal form that I believe has no such ambiguity. Feel free to keep
tilting at this particular windmill -- I'll no doubt remain convinced
of my thesis, and you, of yours.
As for the meta-thesis -- if I make an unambiguous assertion, I can get
quite angry when people try to distort it into something else by claiming
that "context" justifies their attempt to make me say something different
than what I _DID_ say. When my assertion is ambiguous the responsibility
for possibly mis-interpreting it is often shared, but not ALL assertions
are inevitably ambiguous -- and when an assertion IS non-ambiguous, it
stands or falls on its own; trying to weasel it into meaning something
quite different by invoking "context" is a game that's no doubt of huge
interest to lawyers and literary critics, but of no interest to me as
an engineer. In particular, when I say something unambiguously wrong (by
badly chosen wording, OR because I did not know the true state of things,
makes no difference) I prefer to admit it and apologize for it, rather
than attacking those who correct me and/or climbing over mirrors of
"context" to avoid admitting I was wrong. Personal tastes, I guess.
> need to clarify "some" built-in functions. Hence, when you 'corrected'
> me, implying that I didn't know this common sense thing, I felt
> insulted and - in my already bad mood - I overreacted.
>
> Once again, I am sorry for that.
No problem, except that the implication you're reading is also quite
unwarranted -- somebody may know something perfectly well but still err
in expressing it. Thus, correcting a wrong expression carries no
necessary implication that the utterer of said expression did not
know the true state of affairs, any more than it carries any necessary
implication that the utterer was deliberately lying -- in the general
case, both are possible, but mis-expression is also quite possible.
> Now I think about it, most built-in functions probably return a value
They all do, but that value can of course be None.
> (I can't be bothered checking, but most of the ones I can think of off
> the top of my head do anyway). While some of those may still be used
> (or abused) for their side effects, a person might reasonably consider
> that functions that can appear at the start of a line are exceptional.
There are 43 built-in names of type builtin_function_or_method (in
Python 2.3 just built from CVS). Of those, I'd say apply, delattr,
execfile, intern, raw_input, reload and setattr are typically or at
least quite frequently called without caring about their return values
(one could quibble both ways, e.g. adding map or removing intern,
but, roughly) -- whether 7 out of 43 qualifies as "exceptional" is
quite dependent on what meaning one attaches to that adjective, of
course, but to me it seems to qualify as a substantial minority,
even without considering the common try/except idioms (e.g., hash(x)
in a try clause to check if x is hashable without caring about its
hash value).
Once again, the _relevance_ of this to anything whatsoever appears to
be totally mysterious to me. If MOST built-in functions very rarely
make sense at the start of a logical line, then the "context" you were
earlier claiming as the justification for (what I do still consider)
your mis-statement is very weak indeed -- and so much more important
was it then for me to correct that mis-statement, according to your
own interpretations as previously presented.
Alex
Alex Martelli
...
>> Feel free to continue this weird discussion, but don't be surprised
>> if I correct assertions that are false, quite apart from the issue
>> of the relevance of anything to anything else.
>>
> The moon is made of green cheese :-)
No: see http://www-curator.jsc.nasa.gov/curator/lunar/lunar.htm
for an introduction to some of the composition of the surface of
the Moon. No cheese of any variety was so far detected in all
of the samples' analyses.
Alex
Erik Max Francis
> Once again, the _relevance_ of this to anything whatsoever appears to
> be totally mysterious to me.
So why do you continue, to the point of nitpicking obviously facetious
comments about the Moon being made of green cheese?
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Isn't the best defense always a good attack?
\__/ Ovid
Computer science / http://www.alcyone.com/max/reference/compsci/
A computer science reference.
Terry Reedy
> Stephen Horne wrote:
> > (I can't be bothered checking, but most of the ones I can think of
off
> > the top of my head do anyway). While some of those may still be
used
> > (or abused) for their side effects, a person might reasonably
consider
> > that functions that can appear at the start of a line are
exceptional.
When using the interpreter interactively, as I do quite often, *every*
function makes sense appearing at the start of a line!
TJR
Alex Martelli
> Alex Martelli wrote:
>
>> Once again, the _relevance_ of this to anything whatsoever appears to
>> be totally mysterious to me.
>
> So why do you continue, to the point of nitpicking obviously facetious
> comments about the Moon being made of green cheese?
I'm on a retainer by several Italian producers of high-quality dairy
products, who fear the market for their (excellent) wares might be
diminished if such cheese-related (but unfounded) rumors were allowed
to spread unchecked.
Alex
Stephen Horne
wrote:
>Stephen Horne wrote:
> ...
>>>>>> starts a line". Other frequently used words (such as built-in function
>>>>>> names) also never start a line - 'reduce' is as long as 'lambda' for a
> ...
>>>So, the assertion that built-in function names never start a line
>>>is incorrect.
>>
>> I never made that assertion, though on further examination I see why
>> you thought I did.
>
>Ah, yes -- I do see a parenthesis of "Other <Y>s (such as <X>s)" as
>meaning "all <X>s are <Y>s" without needing a redundant "all" after
>the word "as" (just as "all <X>s are <Y>s" does not need the pleonasm
>of the reinforcing "all" -- it means the same thing without it).
Hmmm.
I was about to get all angry and start accusing you of weaseling me...
thankfully I didn't.
Put it this way.
I have Aspergers disorder, and as a result I have a strong tendency to
overpedantic use and interpretation of language. Back at school in
particular, I was beaten up repeatedly for this (though not - for this
- in the literal sense).
Having been told that my interpretating that structure that way was
wrong - repeatedly and with menace, and often by English teachers - I
assumed it was actually wrong - that the 'such as' need not imply
'all' even though it frequently does.
I've heard enough people use the structure this way (and used it
myself that way) without confusion that I've never questioned that.
Now I think about it, that is probably another Aspergers trait at work
- over-literalness. Perhaps I was merely missing their intention, but
they weren't sufficiently pedantic in explaining that to me.
So basically, I'm now in some doubt as to what an English grammar book
would say - I will be checking with a reliable third party soon (the
Aspergers trait of obsessiveness, I expect ;-) ) as my Collins Gem
English Usage has just failed me for the first time ever.
Even without this, I believe the 'context' justification holds a fair
amount of water - but I would have accepted a possible need to
clarify.
In normal use, most language forms *are* regularly used in ways that,
according to the textbooks, are inaccurate. Not all possible meanings
of a given syntactic structure, any more than a possible choice of
words, should be taken seriously. Expecting people to obsessively
remove every possible misinterpretation and every possible
justification for a misinterpretation would make language completely
impractical. That is presumably why I've seen so much evidence for my
interpretation of the '(such as ...)' form.
I have a theory that part of the Aspergers language pedanticism
actually arises out of the lack of 'empathy' - if you are unable to
track peoples intentions (or to express your own intentions) through
non-verbal and subtext channels, you have a greater need to send and
recieve clarification. Regular confusion, accusations of stupidity,
and desparate attempts to cope ensue. One of the desparate attempts to
cope can be ever increasing language pedanticism, even in contexts
where it is unnecessary (because we don't know whether its necessary
or not - lack of empathy again) in order to send and gain
clarifications. In simple terms, if you are misinterpreted one course
of action is to use more precise language to clarify. If you cannot
understand someone else, you may request clarification by explaining
the unclear (to you) aspect of what was said. Repeat and reinforce ad
nauseum and something similar to Aspergers language pedanticism is
bound to happen.
Incidentally, my own language pedanticism was also why I became
facinated in the whole issue of whether natural language can have a
formal definition - and how I became a pedantic crusader against
language pedants! (It's not hypocrisy if I use the arguments against
myself, to moderate my own pedanticism, too - I hope!)
After all, while people often think of English grammar references as
definitive, they cannot strictly be that except in the 'relative
absolute' sense (that's getting to be my favorite term for the week).
The English language is an entity defined by the collective
understanding of its speakers - the grammar references were written by
people (experts, true, but certainly not omniscient ones) who were
describing something much older than them and something which
continues to evolve. There is no-one with the authority to define what
the English language is.
There is the term 'the Queens English' - but the Queen doesn't write
English language textbooks, and neither is she the primary source of
information for those who do. It's just an old expression which has
lost its originally literal meaning - and even when it was literally
true that what royalty said was law, I doubt any King or Queen ever
wrote a dictionary or grammar reference ;-)
I believe France has an organisation which *does* have a kind of
authority to define the French language. But as the French public
generally ignores it, even that is a debatable point!
So at this point, I believe I can get away with a small piece of
weaseling by saying that - if that 'such as' structure is so often
used in the 'not necessarily all' sense (whether by accident or
design), without confusion - maybe in everyday English language it
isn't as wrong as the textbooks might say.
One of Pinkers points in "Words and Rules" was that what we regard as
correct now was frequently seen as sloppy and inaccurate use in the
past and - far enough back - as so wrong as to be bizarre. That's how
the language evolves.
>> Now I think about it, most built-in functions probably return a value
>
>They all do, but that value can of course be None.
Was that a deliberate attempt to annoy me!!! ;-)
IMO, the missing word 'useful' was redundant - unnecessary because the
intention was clear in context and the distinction irrelevant to the
issue being discussed.
>Once again, the _relevance_ of this to anything whatsoever appears to
>be totally mysterious to me. If MOST built-in functions very rarely
>make sense at the start of a logical line, then the "context" you were
>earlier claiming as the justification for (what I do still consider)
>your mis-statement is very weak indeed -- and so much more important
>was it then for me to correct that mis-statement, according to your
>own interpretations as previously presented.
Your original statement implied that I wasn't aware of that built-in
function names can start a line. To me, that fact is common sense
therefore I felt insulted - if it is common sense, then your telling
me implies that I don't even know common sense things.
On realising that no insult was intended, I wanted to do more than
just say 'sorry' and go away - a simple retraction leaves open the
possibility that I might want the issue to go away, but still believe
in myself that you wanted to insult me. I don't believe that you
intended an insult, so I wanted to make sure that was understood.
In an (obviously misguided) attempt to show that I can see different
sides to the issue, I explained why I think it's common sense and gave
one reason why others might have a different view of what's common
sense would do that. If your view of whether the issue is common sense
is different, you weren't necessarily calling me stupid.
In short, I was trying to express that maybe, in another persons
mindset...
>the "context" you were
>earlier claiming as the justification for (what I do still consider)
>your mis-statement is very weak indeed
And now I feel a little upset that you picked up on that thought, yet
you completely missed the intention behind it and used it to attack me
rather than in the spirit of reconciliation in which it was offered.
Of course I have no right to complain about that, but I hope you can
understand what I'm saying now - before long, the clarifications are
already reaching an epic scale ;-)
Stephen Horne
wrote:
>Stephen Horne wrote:
>> BTW - on the 'never'/'rarely' issue - there is a term "relative
>> absolute" which with a simple play on words expresses the fact that it
>> is perfectly valid to use 'absolute' words as extreme relatives.
>
>I'm not familiar with the specifical oxymoron you quote, but in more
>classic terms it does seem a form of hyperbole, or even catachresis.
>Like many other rhetorical figures, it can usefully color one's speech,
>but particularly in technical discourse it's best used cautiously, as
>it can engender misunderstandings.
The question is not, IMO, whether we intended to use a specific
syntax. It's whether we can reasonably be expected to filter out every
single potentially confusing syntax. Natural language tends to have
some colour anyway - the more we focus on draining out all the colour,
the less we focus on the issue at hand. Sender and reciever must
co-operate in removing possible confusion - "active listening" being
the phrase that has beaten into my head with a sledgehammer just
recently.
But as I explained before, I'm probably biassed on this issue.
>Knowledge of rhetorics has its uses, and providing hi-falutin' terms
>that are not widely known is one such use, particularly in pedanter-
>than-thou duels...
And I must say that your use of "hyperbole" caught me a little by
surprise, while your use of "catachresis" was a masterstroke -
pressing home your advantage and defeating me utterly ;-)
<limps off in the direction of the nearest dictionary>
Jack Diederich
shift storm, I hereby declare the thread over.
I use this .emacs bit which was posted about a year ago in this thread.
I still type 'lambda' but it is displayed in context as
newlist = map(L x: x.a + x.b, oldlist)
# vs the standard
newlist = map(lambda x: x.a + x.b, oldlist)
The L snuggles up to the opening paren. Plus it isn't a real word so you
can see it without having to 'read' it.
All in all, a much quicker and more low maintenance solution than a custom
Grammar [pun very much intended].
-jackdied
;;Stefan Monnier's hack to make "lambda" display as (a greek lambda symbol)
;; EDIT - I use it to display 'L' instead
(defun pretty-lambdas ()
(font-lock-add-keywords
nil `(("\\<lambda\\>"
(0 (progn (compose-region (match-beginning 0) (match-end 0)
,'"L")
nil))))))
(add-hook 'emacs-lisp-mode-hook 'pretty-lambdas)
(add-hook 'python-mode-hook 'pretty-lambdas)
(add-hook 'ilisp-mode-hook 'pretty-lambdas)
Alex Martelli
...
> I have Aspergers disorder, and as a result I have a strong tendency to
> overpedantic use and interpretation of language. Back at school in
While I've never been diagnosed with any such disorder, I can certainly
identify with many (not all) of the symptoms you mention.
> assumed it was actually wrong - that the 'such as' need not imply
> 'all' even though it frequently does.
In a huge majority of use cases, "such as" is followed by SPECIFIC,
not GENERIC, examples of what precedes it -- so, the question does
not even arise; when you say, e.g., "engineers such as John" you
are definitely stating that John is an engineer.
A second category of use cases does include implicit qualification.
E.g., "Explore EU funding opportunities such as subsidies, grants,
loans" -- I would agree there is no implication whatsoever that
ALL subsidies, grants and loans are given out by the EU... however,
there IS an implication that they're all examples of opportunities,
and even, more specifically, of "funding opportunities". So, here,
the phrase "EU funding opportunities" needs to be split based on
semantics grounds in order to make sense of the sentence. I think
that, with some ingenuity, one might construct along these lines
an understandable sentence where "such as" leads to some implied
qualification. Offhand I can't make an example that rings quite
true, but consider for example "the best-trained policemen (such
as German policemen)" shortened to "(such as German ones)" then
further shortened to "(such as Germans)" -- it doesn't sound quite
natural English, but it's a sentence that a non-native speaker
might easily utter without any intention of implying that all
Germans are policemen, just because of some slight confusion on
nuances of English grammar (quite understandable, e.g., from an
Italian, used to a language where "i tedeschi" might equally well
stand for "the Germans" or "the German ones"). I encourage you
to proceed along the lines of these exploration and I'm confident
that you'll be able to construct some example of this use.
_However_ -- I don't think this is yet analogous to your use of
"such as built-in function names" to mean "such as some, but not
all, built-in function names". In the hypothetical "such as
Germans" standing for "such as German ones", we have a slight and
perhaps-understandable confusion between adjective and pronoun.
I can see no such explanation for simply dropping "some, but not
all" in your case.
> I've heard enough people use the structure this way (and used it
> myself that way) without confusion that I've never questioned that.
So maybe you can offer me many examples that do sound perfectly
natural to a native speaker -- I do suffer under the disadvantage
that English is not my mother tongue, after all. A lot of
Googling has failed to show me *any* such example -- by far most
hits are of the form "such as <specific>", and those where
something more generic follows the "such as" don't appear to
match the pattern you were using.
> In normal use, most language forms *are* regularly used in ways that,
> according to the textbooks, are inaccurate. Not all possible meanings
Sure! I just don't see this as applying to "such as", but, since
that's what we're talking about, you can no doubt enhance my
understanding of English by providing abundant examples of such
"normal use" (examples in the context of accurate technical
discourse would be even more welcome, but I'll accept others almost
as gladly).
> of a given syntactic structure, any more than a possible choice of
> words, should be taken seriously. Expecting people to obsessively
> remove every possible misinterpretation and every possible
> justification for a misinterpretation would make language completely
> impractical. That is presumably why I've seen so much evidence for my
> interpretation of the '(such as ...)' form.
I really look forwards to being presented with that huge amount
of evidence, and will gladly apologize, when you do so, for letting
my inadequate knowledge of English lead me astray. Of course, the
"so much" qualification is important; if in 999 cases out of 1000
the use of "X (such as Y)" does imply Y's are X's, then I think it
was not reasonable of you to expect us poor non-English-mothertongue
readers "catch" the subtle nuance that you were using it in the
"exceptional one case out of one thousand" way, when it would have
cost you so little to help us out by adding a "some" or "most".
Just as you say, expecting people to obsessively ask for clarification
of every expression that's 99.9% unambiguous, just in case the
exceptional "one in a thousand" nuance was being employed, would
make language completely impractical -- most particularly when the
removal of the ambiguity would cost as little as adding one little
monosyllable.
> The English language is an entity defined by the collective
> understanding of its speakers - the grammar references were written by
> people (experts, true, but certainly not omniscient ones) who were
I fully agree with this. When I worked in computational linguistics,
that was one crucial result of our research -- by using statistics to
model the way people actually DO use the language, rather than "rules"
to try and model the way people "should" use it according to some
authority, we obtained much better rates of dictation-recognition, &c.
I also had the good luck to work with Professor Tullio de Mauro, a
major Italian linguist, on exploring these issues, and found that this
stance is essentially universal in contemporary linguistics -- that
linguistics is descriptive, not usefully prescriptive.
Which is why I look forwards to the mass of evidence for your usage
of "such as", not to a pointer to some old and dusty grammar tome.
> So at this point, I believe I can get away with a small piece of
> weaseling by saying that - if that 'such as' structure is so often
> used in the 'not necessarily all' sense (whether by accident or
> design), without confusion - maybe in everyday English language it
> isn't as wrong as the textbooks might say.
Absolutely! Our disagreement, or misunderstanding, at this point,
is on whether the antecedent of this "if" holds. I do not believe
it does, but it's very easy for you to show me I'm mistaken (or, in
the unlikely case you can't find overwhelming masses of evidence
for your usage, then perhaps you _might_ consider apologizing, as,
in that case, it would appear to me that you have [a] attacked me
and [b] induced me to go on a wild-goose chase for usage evidence
that does not, at this time, appear to me to exist, all, apparently,
in a bid to feistily and tenaciously keep defending what would in
this hypothetical case have to be called your original mistake).
>>> Now I think about it, most built-in functions probably return a value
>>
>>They all do, but that value can of course be None.
>
> Was that a deliberate attempt to annoy me!!! ;-)
Just a (deliberate) refuse to stop being pedantic in a thread that
seems to be about nothing but pedantry.
> IMO, the missing word 'useful' was redundant - unnecessary because the
> intention was clear in context and the distinction irrelevant to the
> issue being discussed.
I can see why you'd like to use the "intention clear in context"
defense, and it's surely quite sensible here, but I just cannot see
how you can make the preposterous claim that "the distinction [is]
irrelevant". Whether the value returned by a built-in function is
NECESSARILY useful or not, i.e., "the distinction", is ALL that is
being discussed in this sub-sub-sub-thread, so how can it possibly
be "irrelevant" to it?!
E.g., reload(x) does "return a value" -- the value x, specifically --
but that is hardly ever "useful", since object x has been updated
in-place. This is of course _quite_ relevant to the typical usage
patterns for reload!
>>Once again, the _relevance_ of this to anything whatsoever appears to
>>be totally mysterious to me. If MOST built-in functions very rarely
>>make sense at the start of a logical line, then the "context" you were
>>earlier claiming as the justification for (what I do still consider)
>>your mis-statement is very weak indeed -- and so much more important
>>was it then for me to correct that mis-statement, according to your
>>own interpretations as previously presented.
>
> Your original statement implied that I wasn't aware of that built-in
> function names can start a line. To me, that fact is common sense
I dispute that it implied anything of the kind, as I have already
stated on this thread. If you say "the sky is green" and I correct
this statement by counter-stating "no, the sky is blue", any of
several situations may apply:
a. you might indeed be unaware of the sky's color,
b. you might have mis-expressed your meaning,
c. you might be deliberately asserting a falsehood (commonly known
as "lying"), perhaps e.g. in an attempt to be funny
It's generally not up to me to distinguish which of these cases
may apply -- I care about the sky's color, and it being clearly and
correctly communicated to other readers of this thread, not about
your knowledge, intentions, and expressive abilities.
> therefore I felt insulted - if it is common sense, then your telling
> me implies that I don't even know common sense things.
Ah, but I'm not telling *YOU* -- I'm correcting your mis-statement,
made in a public forum, by an equally public counter-statement; I
am "telling" _everybody_ who chooses to listen, including, quite
possibly, readers whose current grasp of Python may not suffice to
distinguish the truth or falsehood of your original statement.
> On realising that no insult was intended, I wanted to do more than
> just say 'sorry' and go away - a simple retraction leaves open the
> possibility that I might want the issue to go away, but still believe
> in myself that you wanted to insult me. I don't believe that you
> intended an insult, so I wanted to make sure that was understood.
>
> In an (obviously misguided) attempt to show that I can see different
> sides to the issue, I explained why I think it's common sense and gave
> one reason why others might have a different view of what's common
> sense would do that. If your view of whether the issue is common sense
> is different, you weren't necessarily calling me stupid.
>
> In short, I was trying to express that maybe, in another persons
> mindset...
>
>>the "context" you were
>>earlier claiming as the justification for (what I do still consider)
>>your mis-statement is very weak indeed
>
> And now I feel a little upset that you picked up on that thought, yet
> you completely missed the intention behind it and used it to attack me
> rather than in the spirit of reconciliation in which it was offered.
>
> Of course I have no right to complain about that, but I hope you can
> understand what I'm saying now - before long, the clarifications are
> already reaching an epic scale ;-)
I am not sure I entirely understand what you're saying, but it seems
to me that most of it comes from taking technical discourse as personal
attacks. When I discuss what built-in functions could reasonably be
used in one way or another way, I am discussing Python (what this
newsgroup is _alleged_ to be about). If you choose to take this as
discussing Stephen Horne instead, then it's not surprising that things
may end up being very tangled.
Alex
Bengt Richter
>A. Lloyd Flanagan wrote:
>> Part of the problem, I think, is that people coming from other
>> languages don't understand the power and proper use of the lambda
>> construct.
>
>coming from Smalltalk:
>Python lambdas are restricted to one expression, which makes them cumbersome
>to use for more complex stuff and difficult to debug as you can't insert a
>quick 'print'.
>
Whatever the restrictions, you can arrange for "a quick print'," e.g.,
def qp(x): print x; return x
or even
def qp(fmt, x): print fmt % x; return x
I.e., use
qp(expression_term)
in place of
expression_term
to get "a quick 'print'" of an expression term.
Regards,
Bengt Richter
Tim Randolph
> Stephen Horne wrote:
> ...
> > I have Aspergers disorder, and as a result I have a strong tendency to
> > overpedantic use and interpretation of language. Back at school in
>
> While I've never been diagnosed with any such disorder, I can certainly
> identify with many (not all) of the symptoms you mention.
Harper's mag ran (May 2002) a fascinating biography of someone with
Aspergers last year. It has a lot to say about the disorder and the
NYC Subway System.
Can be found on the web here:
http://www.findarticles.com/cf_0/m1111/1824_304/85882845/print.jhtml
--Tim
Chris Gonnerman
How about http://www.asperger.org
I'm one also... although my diagnosis is far from properly
"clinical" I fit the profile pretty snugly.
There's a test (one of several actually) at:
http://www.wired.com/wired/archive/9.12/aqtest.html
I'm a 33.
On that page it says:
The test is not a means for making
a diagnosis, however, and many who
score above 32 and even meet the
diagnostic criteria for mild autism
or Asperger's report no difficulty
functioning in their everyday lives.
Like many, I have learned to recognize social signals and
simulate them cognitively (whereas "normal" people have
instincts for this)... so the last statement rings a bit
false with me.
There are probably a lot of us on this list who suffer from
Asperger's... it pretty much defines nerdiness.
Chris Gonnerman -- chris.g...@newcenturycomputers.net
http://newcenturycomputers.net
Carl Banks
> There are probably a lot of us on this list who suffer from
> Asperger's... it pretty much defines nerdiness.
Blegh.
I think people with Asperger's "syndrome" just violated someone's
arbitrary and very narrow idea of what they think is normal.
Here's my advice: forget all this crap about Asperger's syndrome.
Instead, go read about Myers-Briggs personality typing. _Please
Understand Me_, by David Kiersey, is a good reference. Kiersey would
probably dismiss Asperger's "syndrome" as nothing but a strong
introverted and thinking personality.
Frankly, it sickens me that there are people out there who consider
traits such as introversion, and reliance on thought instead of
feeling, to be "diseases."
--
CARL BANKS
Chris Gonnerman
From: "Carl Banks" <imbosol-1...@aerojockey.com>
> Chris Gonnerman wrote:
> > There are probably a lot of us on this list who suffer from
> > Asperger's... it pretty much defines nerdiness.
>
> Blegh.
>
> I think people with Asperger's "syndrome" just violated someone's
> arbitrary and very narrow idea of what they think is normal.
I never knew how I was different, only that I was; until I was
married to someone with "normal" social instincts for over ten
years (still am, thankfully). My wife has shown me a lot that
I could never see on my own.
> Here's my advice: forget all this crap about Asperger's syndrome.
> Instead, go read about Myers-Briggs personality typing. _Please
> Understand Me_, by David Kiersey, is a good reference. Kiersey would
> probably dismiss Asperger's "syndrome" as nothing but a strong
> introverted and thinking personality.
It is real. The primary reason to understand this is that, if
two people who both have Asperger's Syndrome have children, there
is a statistically higher rate of autism.
The highest rate of new autism diagnosis is in the Silicon Valley,
and if you think you can dismiss this severe disorder as easily
as Asperger's you are a fool.
Note also that Microsoft (the evil empire) has a special program
for their employees with autistic children. (Read that in the
newspaper where I first heard of Asperger's.) They wouldn't waste
the money on it if it weren't a real problem.
> Frankly, it sickens me that there are people out there who consider
> traits such as introversion, and reliance on thought instead of
> feeling, to be "diseases."
Asperger's doesn't make you introverted. Usually quite the
opposite; I am a bull in the china shop of other people's feelings,
and I have never liked it. I am aware of a great many adaptations
I have made cognitively that other people don't have to think about
at all; adaptations that are often incorrect due to my incomplete
understanding.
Don't blow me off, Carl Banks. This is real, and it sucks.
You can't imagine what a relief it was to learn that there is a
reason I don't fit in. "Personality typing" is too wimpy to
cover the gaps in my understanding, gaps I will never be able
to properly fill. I am also slightly hearing impaired, and it
was a similar relief to understand that... are you going to
blow off my hearing problem too?
One of the less well understood symptoms of Asperger's is
delayed emotional response. I have to synthesize a visible
response in many cases, trying to imagine how I will feel
later when the emotional response sets in; otherwise the more
or less normal people I am interacting with think me cold and
unfeeling.
Unfortunately, anger is rarely delayed, and I am pretty well
mad right now.
My apologies to the list for this off-topic rant; I would have
replied by private mail but I didn't want Carl's rudeness to
be unchallenged in public.
A. Lloyd Flanagan
> Chris Gonnerman wrote:
> I think people with Asperger's "syndrome" just violated someone's
> arbitrary and very narrow idea of what they think is normal.
>
There's definitely a much broader range to 'normal' human behavior
than most people realize. I think they've been paying more attention
to movies and TV than what's going on around them.
Lloyd (AQ Test score:25)
Carl Banks
> ----- Original Message -----
> From: "Carl Banks" <imbosol-1...@aerojockey.com>
>
>
>> Chris Gonnerman wrote:
>> > There are probably a lot of us on this list who suffer from
>> > Asperger's... it pretty much defines nerdiness.
>>
>> Blegh.
>>
>> I think people with Asperger's "syndrome" just violated someone's
>> arbitrary and very narrow idea of what they think is normal.
>
> I never knew how I was different, only that I was; until I was
> married to someone with "normal" social instincts for over ten
> years (still am, thankfully). My wife has shown me a lot that
> I could never see on my own.
I'm happy for you. None of that means Asperger's "syndrome" is real.
>> Here's my advice: forget all this crap about Asperger's syndrome.
>> Instead, go read about Myers-Briggs personality typing. _Please
>> Understand Me_, by David Kiersey, is a good reference. Kiersey would
>> probably dismiss Asperger's "syndrome" as nothing but a strong
>> introverted and thinking personality.
>
> It is real. The primary reason to understand this is that, if
> two people who both have Asperger's Syndrome have children, there
> is a statistically higher rate of autism.
If that's the *best* reason you can come up with that Asperger's is a
disease and not a strong personality type, then you are standing on
weak grounds indeed.
I don't doubt what you've said true, but simply having a
predisposition to having autistic children doesn't mean you have a
mental illness. Some people have a predisposition to have children
with Down's Syndrome. Does that mean they have a mental disease? No.
Based on the on-line test, it seemed to me that the "symptoms" of
Asperger's "syndrome" and near-autism were equivalent to the traits of
a strong ISTJ personality.
> The highest rate of new autism diagnosis is in the Silicon Valley,
> and if you think you can dismiss this severe disorder as easily
> as Asperger's you are a fool.
I dismiss Asperger's "syndrome," not autism.
> Note also that Microsoft (the evil empire) has a special program
> for their employees with autistic children. (Read that in the
> newspaper where I first heard of Asperger's.) They wouldn't waste
> the money on it if it weren't a real problem.
One, that's autism.
Two, Microsoft doesn't care about autism; it cares about keeping its
employees happy. If a bunch of employees were to start whining that
they need special care for their kids with Asperger's "syndrome," then
Microsoft would pay for it whether it's a disease or not.
>> Frankly, it sickens me that there are people out there who consider
>> traits such as introversion, and reliance on thought instead of
>> feeling, to be "diseases."
>
> Asperger's doesn't make you introverted.
I think it's the other way around. Being introverted (among other
things) is what "causes" Asperger's "syndrome."
In the on-line test that was posted here, I noticed a handful of
questions that directly tested for introversion (i.e., the introverted
answers scored a point). These questions could have just as easily
appeared on a personality test.
To wit, here are some questions that test directly for introversion
(there were some others that tested for introversion along with some
other qualities):
I prefer to do things with others rather than on my own.
I would rather go to a library than to a party.
I enjoy meeting new people.
> Usually quite the
> opposite; I am a bull in the china shop of other people's feelings,
> and I have never liked it.
You evidently don't understand what introversion is.
> I am aware of a great many adaptations
> I have made cognitively that other people don't have to think about
> at all; adaptations that are often incorrect due to my incomplete
> understanding.
You might think this means you have a disease. Guess what?
*Everyone* has to make adjustments of some sort to fit into society,
be it social or otherwise. Some more than others, obviously, but
simply having to adjust doesn't mean you have a disease. I say you
have a personality type whose strong point is not interaction with
other humans, nothing more.
> Don't blow me off, Carl Banks. This is real, and it sucks.
I agree you have trouble adjusting. I agree it sucks. I don't agree
it's a disease.
> You can't imagine what a relief it was to learn that there is a
> reason I don't fit in. "Personality typing" is too wimpy to
> cover the gaps in my understanding, gaps I will never be able
> to properly fill. I am also slightly hearing impaired, and it
> was a similar relief to understand that... are you going to
> blow off my hearing problem too?
If it makes you feel better to think you have a diesease, then be my
guest.
> One of the less well understood symptoms of Asperger's is
> delayed emotional response. I have to synthesize a visible
> response in many cases, trying to imagine how I will feel
> later when the emotional response sets in; otherwise the more
> or less normal people I am interacting with think me cold and
> unfeeling.
>
> Unfortunately, anger is rarely delayed, and I am pretty well
> mad right now.
Please accept my apologies for suggesting that you're not really
mentally ill.
> My apologies to the list for this off-topic rant; I would have
> replied by private mail but I didn't want Carl's rudeness to
> be unchallenged in public.
I scored 27 on the test. If some shrink were to suggest I have
Asperger's "syndrome," I'd think *he* was rude.
And if I were your health care provider, and you asked for coverage of
Asperger's "syndrome," I would tell you to take a hike.
--
CARL BANKS
Gerrit Holl
Tim Randolph schreef op maandag 17 maart om 01:47:30 +0000:
> Alex Martelli <al...@aleax.it> wrote in message news:<JrEca.87817$zo2.2...@news2.tin.it>...
> > Stephen Horne wrote:
> > > I have Aspergers disorder,
Cool!
> > > and as a result I have a strong tendency to
> > > overpedantic use and interpretation of language. Back at school in
Yes, me too. In English however, this problem is smaller because my
vocabulary is smaller. When I just started being active on the internet,
I made a lot of noise and a lot of argument/dispute, for example, I
though some website should be W3C AAA, while others disagreed, and I
was being unreasonable. At itself, this is not Asperger but rereading it
astonisheh myself about by obstinacy, although that is not Aspergers
either. I find it cool that more Aspergers are using Python, any
others reading this? Let's make an Aspergers Python User Group ;)
I have been active in nl.comp.programmeren, n.politiek and n.c.os.linux
long ago. However, I could not withhold there, because of the atmospehere,
since I am very bad at withholding "critics" (read: people saying a
13-year-old-boy would never get a job because he is busy flaming) (well
I still am). Please don't say that's normal: it is, but that's because
this is an extreme example, and the less extreme examples aren't noticed
by myself ;).
> > While I've never been diagnosed with any such disorder, I can certainly
> > identify with many (not all) of the symptoms you mention.
Many people say so, but they often do not know what Asperger truly means.
It can be very difficult for Aspergers to have contacts, and for
others to have contacts with Aspergers. Aspergers have difficulties
in making social contacts, it could be called some sort of social
blindness. Actually, it is sort of the default-reflex-reaction. Everyone,
from my Physics teacher to my dad to the man who brought me into a
health-program on TV said so. *Please* don't, because it isn't True...!
Being an Asperger is not _bad_, however, at least, for me it isn't.
I often get comments on my website (see .sig), and a lot of people are
in situations far worse that I and probably far worse than Steve's; isolated,
without family, denying their Aspergers, depressive... I have been on
a special school and very lucky in having so.
> Harper's mag ran (May 2002) a fascinating biography of someone with
> Aspergers last year. It has a lot to say about the disorder and the
> NYC Subway System.
>
> Can be found on the web here:
>
> http://www.findarticles.com/cf_0/m1111/1824_304/85882845/print.jhtml
Interesting.
For the Dutch, which are around here a lot, a biography in Dutch by a
Python-user can be found at:
http://people.nl.linux.org/~gerrit/
; )
BTW, a friend of mine knows the periodic system out of his head. I'm
thinking of going to learn this as well, just to train my memory.
Haven't done that for a loooong time, since I left Gymnasium.
yours,
Gerrit.
--
Asperger Syndroom - een persoonlijke benadering:
http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
http://www.sp.nl/
Gerrit Holl
I feel I must objects strongly to the tone in this discussion.
Carl Banks schreef op maandag 17 maart om 08:12:13 +0000:
> > There are probably a lot of us on this list who suffer from
> > Asperger's... it pretty much defines nerdiness.
"A lot" would be relative, maybe three times as much as outside,
which still means one or two.
It is *not* nerdiness!
It is something *different*!
It is a form of *autism*!
It is a *syndrome*!
> I think people with Asperger's "syndrome" just violated someone's
> arbitrary and very narrow idea of what they think is normal.
Please go meet Aspergers. Please visit schools with a lot of
Aspergers, please don't talk about something you don't know
something about.
> Here's my advice: forget all this crap about Asperger's syndrome.
Please don't say this, you may insult people.
> Instead, go read about Myers-Briggs personality typing. _Please
> Understand Me_, by David Kiersey, is a good reference. Kiersey would
> probably dismiss Asperger's "syndrome" as nothing but a strong
> introverted and thinking personality.
Well, he is wrong than.
> Frankly, it sickens me that there are people out there who consider
> traits such as introversion, and reliance on thought instead of
> feeling, to be "diseases."
Well, please don't dismiss Asperger's syndrome as something simple
or as something meaning introvertion.
Please, people, go talk about lambda's but not about subjects you
haven't got any knowledge about! I feel really strongly about this!
Please.
Bjorn Pettersen
> Chris Gonnerman wrote:
> > ----- Original Message -----
> > From: "Carl Banks" <imbosol-1...@aerojockey.com>
> >
> >
> >> Chris Gonnerman wrote:
> >> > Asperger's... it pretty much defines nerdiness.
> >>
> >>
> >> I think people with Asperger's "syndrome" just violated someone's
> >> arbitrary and very narrow idea of what they think is normal.
> >
> > married to someone with "normal" social instincts for over ten
> > years (still am, thankfully). My wife has shown me a lot that
> > I could never see on my own.
>
> I'm happy for you. None of that means Asperger's "syndrome" is real.
Sorry Carl, but you're being an ass. What you go on saying would be like
telling a bipolar person that "I too go through periods of sadness and
happiness", therefore their diagnosis is not only incorrect, but
non-existant. For your sake I hope you never discover the difference,
but at least take some time and study the literature (including case
studies)...
-- bjorn
Carl Banks
> Sorry Carl, but you're being an ass. What you go on saying would be like
> telling a bipolar person that "I too go through periods of sadness and
> happiness", therefore their diagnosis is not only incorrect, but
> non-existant.
http://www.nizkor.org/features/fallacies/straw-man.html
> For your sake I hope you never discover the difference,
> but at least take some time and study the literature (including case
> studies)...
I'm done commenting on this, as it's off topic. I'll change my mind
when I see something suggesting that Asperger's is anything different
(and more abnormal) than an ISTJ personality.
--
CARL BANKS
GerritM
news:mailman.1047930524...@python.org...
> Hi,
>
> I feel I must objects strongly to the tone in this discussion.
>
>
> > Instead, go read about Myers-Briggs personality typing. _Please
> > Understand Me_, by David Kiersey, is a good reference. Kiersey would
> > probably dismiss Asperger's "syndrome" as nothing but a strong
> > introverted and thinking personality.
>
> Well, he is wrong than.
Referring to the useful Myers-Briggs personality classification and
description as the _one and only_ useful viewpoint is rather narrowminded.
It is like the hammer which is used as a tool for everything (see completely
other threads in c.l.p).
A whole spectrum of disorders is known, ranging from ADHD, ODD, GAD, to
autism, PDD-NOS, Asperger, to Gilles de Tourette etcetera. For most
disorders the "cause" is not known. The classification is well defined, but
be aware that a classifciation is only a description of symptoms.
Classification is one of the starting points to understand very complex
issues.
Two threats exist:
+ overdiagnosis, due to attaching these labels way too easily
+ undertreatment, due to ignorance
(treatment can range from special schools as Gerrit Holl mentions, to
therapeutic drugs)
I am not a specialist in this field at all, but I have seen psychiatric
doctors treating people with these disorders. Simply calling it a strong
personality is a dangerous oversimplification.
regards Gerrit Muller
Alexander Schmolck
> > It is real. The primary reason to understand this is that, if
> > two people who both have Asperger's Syndrome have children, there
> > is a statistically higher rate of autism.
>
> If that's the *best* reason you can come up with that Asperger's is a
> disease and not a strong personality type, then you are standing on
> weak grounds indeed.
>
> I don't doubt what you've said true, but simply having a predisposition to
> having autistic children doesn't mean you have a mental illness. Some
> people have a predisposition to have children with Down's Syndrome. Does
> that mean they have a mental disease? No.
Your counter example has an entirely different logical structure.
alex
Tony Clarke
> Hi,
>
> I feel I must objects strongly to the tone in this discussion.
>
>
> yours,
> Gerrit.
Hi
I empathise: see http://isnt.autistics.org/
:-)
Tony
Cliff Wells
> > From: Carl Banks [mailto:imbosol-1...@aerojockey.com]
> >
> > Chris Gonnerman wrote:
> > > ----- Original Message -----
> > > From: "Carl Banks" <imbosol-1...@aerojockey.com>
> > >
> > >
> > >> Chris Gonnerman wrote:
> > >> > There are probably a lot of us on this list who suffer from
> > >> > Asperger's... it pretty much defines nerdiness.
> > >>
> > >> Blegh.
> > >>
> > >> I think people with Asperger's "syndrome" just violated someone's
> > >> arbitrary and very narrow idea of what they think is normal.
> > >
> > > I never knew how I was different, only that I was; until I was
> > > married to someone with "normal" social instincts for over ten
> > > years (still am, thankfully). My wife has shown me a lot that
> > > I could never see on my own.
> >
> > I'm happy for you. None of that means Asperger's "syndrome" is real.
> [..]
>
> telling a bipolar person that "I too go through periods of sadness and
> happiness", therefore their diagnosis is not only incorrect, but
> but at least take some time and study the literature (including case
> studies)...
I have to admit that the "questionaire" posted earlier could easily lead
one to believe that Asperger's is yet another McDisorder (in the US this
is a big problem). The following links are perhaps a bit better:
http://www.aspergers.com/aspcrit.htm
http://www.udel.edu/bkirby/asperger/aswhatisit.html
http://www.autism.org/asperger.html
A big problem with many personality "disorders" is that their symptoms,
taken individually or to a lesser degree, often correspond to normal,
albeit maladjusted behaviors in the general population. It's only when
these symptoms appear in together or to such a degree as to inhibit a
normal life that they can be considered a "disorder". Shyness that
makes one reluctant to talk to strangers at a party is normal, shyness
that prevents one from leaving their house is a disorder.
In the US, healthcare is so screwed up that people often take a reactive
position when they hear of disorders such as these. You can have an
internal staph infection and get turned away by medical facility (my
girlfriend met someone the other day on the bus in this situation - the
woman was in so much pain she screamed whenever the bus hit a bump - and
she was leaving a facility that refused to treat her [OHSU, for the
record]) but have no problem getting expensive medication to treat
"Seasonal Depression". This situation has made people somewhat callous
toward these types of disorders, especially since, at a lesser degree,
their symptoms aren't unlike what many people feel is simply the human
condition.
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308
Michele Simionato
> arbitrary and very narrow idea of what they think is normal.
> Here's my advice: forget all this crap about Asperger's syndrome.
> Instead, go read about Myers-Briggs personality typing. _Please
> Understand Me_, by David Kiersey, is a good reference. Kiersey would
> probably dismiss Asperger's "syndrome" as nothing but a strong
> introverted and thinking personality.
This is a quite rude way of making the point, but still I think there
is some merit in what Carl is saying. I see that this is an unpopular view
in the newsgroup, so let me be clear in what I mean.
I think there is a tiny line dividing the syndrome from the strong personality
type, but still the line exists.
I would put the line here: or you have the control of your life, or the
syndrome has the control of your life.
If (to make a simple example) you don't enjoy social life and you would
rather go to the library than to the party, this does not means that you
have the syndrome: however, if you CANNOT go to the party, then you have the
syndrome.
I agree that there are people that really are on the bad side of the line:
you cannot say to them "oh, be a good boy, make a little effort an go to the
party", because they *cannot*. It would denote complete incomprehension for
them (and besides, rudeness and stupidity) to follow this approach.
However, I don't think Carl is addressing his words to the really
sick persons, that are the minority. I think he is addressing his
words to the persons with "a strong introverted and thinking personality",
as he says, that do not have the syndrome but they think they have.
And they think they have the syndrome because of the strong social pressure
(which is stronger in the USA than in Europe, as I can tell having lived in
both countries, BTW): unfortunately, the society is trying to convince
people that they are sick if they don't follow a very strictly defined
"normal" behavior, where "normal" means conformism with the society
stereotypes.
> Frankly, it sickens me that there are people out there who consider
> traits such as introversion, and reliance on thought instead of
> feeling, to be "diseases."
Well said Carl! The problem is more with "normal" people than with
the "non-normal".
I think Carl does not like weenies and a victimism philosophy: I don't
like it either. More on philosophical terms, I am against the modern
society when is trying to convince people that "life is (always)
wonderful", and that there is something like the "right to happiness".
Historically speaking, these concepts are extremely recent and they
were unthinkable in earlier epoch. According to the Ancient Greek,
the aim to pursue was avoiding the pain, not reaching the "happiness".
Happiness was thought to be a transient state, not a rightful expectation
for a normal life.
If I look at my "normal" friends of my age (I am 33) they are all in
existential crisis: they all had big dreams of a great or at least happy
life whereas they are discovering now that they have just a plain, ordinary
life that sucks (in the best cases) or not a life at all (many of the people
I know, alone, with bad sentimental stories, an horrible job, etc).
They say: look at me, I am still young, still sane, I have some
money, I should be happy, why I am not so? I must be sick!! Which, of
course, it is a completely absurd point of view. The reality, as
Lacan says, is that "life is hard".
Carl is slapping people that have no reason of thinking to be sick,
not the people that really are! It really disturbs me to see people
(not referring to people on the mailing list here, but some people I
know) complaining, wondering about their psychological status, when they
are entirely and absolutely normal, plain and ordinary: it is their life
that it is not okay, not them!
On the other hand, surprisingly maybe, people with "a strong introverted and
thinking personality" (notice: I am not saying people with the syndrome)
are quite advantaged with respect to the "normals". I hadn't big
expectations for my life at the age of seven: actually I was never
thinking about the future, all my effort were concentrated on surviving
in the present. I couldn't be fooled by society propaganda (at least
not so completely fooled as others): I did not want a great life,
I only wanted a life.
I must say that I never heard about Asperger's before this threat: anyway,
I wasn't surprised to have a score of 32. Nevertheless, as the test says
"many who score above 32 and even meet the diagnostic criteria for mild autism
or Asperger's report no difficulty functioning in their everyday lives."
I would go further and says that having "a strong introverted and
thinking personality" is helping me in my life now (of course it was
*not* helping me when I was a child :-(). Let me give a single example.
I am a physicists: I must give seminars and lectures at international
congress. This would be a scary task for most normal people, but for me it
is not very hard: I am trained. For me, it was hard even go the local shop
and buy milk and bread for my mother: if I survived to that, I can easily give
a seminar to an audience of international scientists. I also have
a fiance' and a life that I think is much more interesting of the
lives of my friends who stayed in our original little village in the
countryside. I would say that I am happier than I was and even more happier
than I expected to be.
Final thought: normality strongly depends on the milieu where you
live. I am sure the average score on the test for people on the
mailing list is much higher than 16.4, the "normal" average
(according to http://www.wired.com/wired/archive/9.12/aqtest.html)
As I often say to my fiance' "I have always thought to be a little strange
when I was younger, but now, if I compare myself with my colleagues
physicists, I am one of the most normal!"
Whereas for most people life is easy when they are young and difficult
when they are grown up, for people with "a strong introverted and thinking
personality" it is probably the opposite.
My advice to the youngest people of the mailing list is simply "wait".
I think this is the best advice I can give. Of course, IANAP and I
referring to people in the safe side of the line. When you pass the
line things get harder and harder, and I don't think anybody has a
good advice in those cases.
That's all for today, it was an interesting thread,
--
Michele Simionato - Dept. of Physics and Astronomy
210 Allen Hall Pittsburgh PA 15260 U.S.A.
Phone: 001-412-624-9041 Fax: 001-412-624-9163
Home-page: http://www.phyast.pitt.edu/~micheles/
Carl Banks
> If (to make a simple example) you don't enjoy social life and you would
> rather go to the library than to the party, this does not means that you
> have the syndrome: however, if you CANNOT go to the party, then you have the
> syndrome.
>
> I agree that there are people that really are on the bad side of the line:
> you cannot say to them "oh, be a good boy, make a little effort an go to the
> party", because they *cannot*. It would denote complete incomprehension for
> them (and besides, rudeness and stupidity) to follow this approach.
> However, I don't think Carl is addressing his words to the really
> sick persons, that are the minority. I think he is addressing his
> words to the persons with "a strong introverted and thinking personality",
> as he says, that do not have the syndrome but they think they have.
Just to avoid having my words misconstrued too much, and to nitpick:
if someone can't go to party, then they have agoraphobia, or social
phobia, or avoidant personality disorder, not Asperger's "syndrome."
I don't think Asperger's syndrome exists, period. If they have a
mental problem, it's something else.
Taking a sociable, energetic, empathetic person, and saying they have
a disease because their nature makes them bad with computers and
checkbooks, is no less ludicrous than Asperger's syndrome.
--
CARL BANKS
Erik Max Francis
> I don't think Asperger's syndrome exists, period. If they have a
> mental problem, it's something else.
Strange then, that people who are diagnosed with Asperger's disagree
with you, isn't it?
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Of all the perversions, chastity is the strangest.
\__/ Anatole France
Bosskey.net: Counter-Strike / http://www.bosskey.net/cs/
A personal guide to Counter-Strike.
Michele Simionato
> Just to avoid having my words misconstrued too much, and to nitpick:
> if someone can't go to party, then they have agoraphobia, or social
> phobia, or avoidant personality disorder, not Asperger's "syndrome."
> I don't think Asperger's syndrome exists, period. If they have a
> mental problem, it's something else.
>
Okay, Carl your point is clear. Sorry if I have misconstrued too much
your words. Anyway, I think these kinds of problems do exist, even if
probably in many cases they are exaggerated; if the right name for
them is "Asperger" or some other name, it is a secondary issue to me.
Regards,
Michele
Gerrit Holl
> I don't think Asperger's syndrome exists, period. If they have a
> mental problem, it's something else.
Carl,
I am diagnosed with Aspergers' Syndrome, and I accept this. Since I
have a website, I am often contacted by people, and I hear stories. Some
people are in a *very bad* state, for instance that they can't leave the
house, can't stay with their parents... I have also been in a school for
Aspergers and related syndromes. It is pure nonsense to dismiss Aspergers.
A lot of people who say "I have something similar" do not have
anything similar. They recognize the simptons but do not realize what
Asperger truly is.
I was diagnosed as Asperger 10 years ago by a professional psychologist.
It was a very "new" syndrome then, although a great lot of research had
been put into it. Asperger is not merely a rational approach to life,
neither does it have anything to do with "Geek syndrome". A lot of Aspergers
are not intelligent at all, and not interested at all in geekish subjects.
Aspergers can be extremely difficult to cope with. Non-verbal communication
is lost; you should realize how important those are! Customs are not
understood, which is a big problem. Social weakness in so extreme for
Aspergers that almost all are, or have been, bullied. Aspergers do not
understand emotions: this is *much* more than a simple 'personality
type'!
I wonder if you have ever *met* an Asperger, let alone *talked* to one
a little deeper than this. What do you know at all about Aspergers? Why
do you think you can dismiss the syndrome of a lot of people? Do you
realize it may be very difficult for some Aspergers, who just accepted
their syndrome, if they read this? Do you realize that you may *hurt*
some people badly? Do you realize that you can really do damage to
very vulnarable people? Do you know what you're talking about? Do you
know the consequences? Why are you bothering *at all*?
Please, quit.
Please!
yours truly,
Gerrit Holl.
P.S.
You are dismissing Asperger, but not Autism: do you agree that those
diagnosed with Asperger are Autists?
--
259. If any one steal a water-wheel from the field, he shall pay five
shekels in money to its owner.
-- Hammurabi, Code of Law