Python from Wise Guy's Viewpoint

[Alex Martelli]

Re: Python from Wise Guy's Viewpoint

Joachim Durchholz wrote:
[color=blue]
> Oh, you're trolling for an inter-language flame fest...
> well, anyway:
>[color=green]
>> 3. no multimethods (why? Guido did not know Lisp, so he did not know
>> about them) You now have to suffer from visitor patterns, etc. like
>> lowly Java monkeys.[/color]
>
> Multimethods suck.[/color]

Multimethods are wonderful, and we're using them as part of the
implementation of pypy, the Python runtime coded in Python. Sure,
we had to implement them, but that was a drop in the ocean in
comparison to the amount of other code in pypy as it stands, much
less the amount of code we want to add to it in the future. See
http://codespeak.net/ for more about pypy (including all of its
code -- subversion makes it available for download as well as for
online browsing).

So, you're both wrong:-).


Alex

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Joachim Durchholz wrote:
[color=blue]
> Oh, you're trolling for an inter-language flame fest...
> well, anyway:
>[color=green]
>> 3. no multimethods (why? Guido did not know Lisp, so he did not know
>> about them) You now have to suffer from visitor patterns, etc. like
>> lowly Java monkeys.[/color]
>
>
> Multimethods suck.[/color]

Do they suck more or less than the Visitor pattern?
[color=blue]
> The longer answer: Multimethods have modularity issues (if whatever
> domain they're dispatching on can be extended by independent developers:
> different developers may extend the dispatch domain of a function in
> different directions, and leave undefined combinations; standard
> dispatch strategies as I've seen in some Lisps just cover up the
> undefined behaviour, with a slightly less than 50% chance of being
> correct).[/color]

So how do you implement an equality operator correctly with only single
dynamic dispatch?


Pascal

[Terry Reedy]

Re: Python from Wise Guy's Viewpoint


"Frode Vatvedt Fjeld" <frodef@cs.uit. no> wrote in message
news:2hn0bxm8kf .fsf@vserver.cs .uit.no...
cc'ed in case you are not reading c.l.python, which I am limiting this
to.
[color=blue]
> So to get from the ID to the bytecode, you go through a dictionary?
> And the mapping from name to ID happens perhaps when the caller is
> bytecode-compiled?[/color]

No. In Python, all names are associated with objects in namespaces.
Lookup is done as needed at the appropriate runtime. Function objects
are 1st class and are no different from any others in this respect.
The same goes for slots in collection objects being associated with
member objects.

The free online tutorial as www.python.org explains Python basics like
this.

Terry J. Reedy

[Kenny Tilton]

Re: Python from Wise Guy's Viewpoint



Joachim Durchholz wrote:
[color=blue]
> Oh, you're trolling for an inter-language flame fest...
> well, anyway:
>[color=green]
>> 3. no multimethods (why? Guido did not know Lisp, so he did not know
>> about them) You now have to suffer from visitor patterns, etc. like
>> lowly Java monkeys.[/color]
>
>
> Multimethods suck.
>
> The longer answer: Multimethods have modularity issues[/color]

Lisp consistently errs on the side of more expressive power. The idea of
putting on a strait jacket while coding to protect us from ourselves
just seems batty. Similarly, a recent ex-C++ journal editor recently
wrote that test-driven development now gives him the code QA peace of
mind he once sought from strong static typing. An admitted former static
typing bigot, he finished by wondering aloud, "Will we all be coding in
Python ten years from now?"

kenny

--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Kenny Tilton]

Re: Python from Wise Guy's Viewpoint



Kenny Tilton wrote:
[color=blue]
>
>
> Joachim Durchholz wrote:
>[color=green]
>> Oh, you're trolling for an inter-language flame fest...
>> well, anyway:
>>[color=darkred]
>>> 3. no multimethods (why? Guido did not know Lisp, so he did not know
>>> about them) You now have to suffer from visitor patterns, etc. like
>>> lowly Java monkeys.[/color]
>>
>>
>>
>> Multimethods suck.
>>
>> The longer answer: Multimethods have modularity issues[/color]
>
>
> Lisp consistently errs on the side of more expressive power. The idea of
> putting on a strait jacket while coding to protect us from ourselves
> just seems batty. Similarly, a recent ex-C++ journal editor recently
> wrote that test-driven development now gives him the code QA peace of
> mind he once sought from strong static typing. An admitted former static
> typing bigot, he finished by wondering aloud, "Will we all be coding in
> Python ten years from now?"[/color]

http://www.artima.com/weblogs/viewpost.jsp?thread=4639

--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Tomasz Zielonka]

Re: Python from Wise Guy's Viewpoint

Kenny Tilton wrote:[color=blue]
>
> Lisp consistently errs on the side of more expressive power. The idea of
> putting on a strait jacket while coding to protect us from ourselves
> just seems batty. Similarly, a recent ex-C++ journal editor recently
> wrote that test-driven development now gives him the code QA peace of
> mind he once sought from strong static typing.[/color]

C++ is not the best example of strong static typing. It is a language
full of traps, which can't be detected by its type system.
[color=blue]
> An admitted former static typing bigot, he finished by wondering
> aloud, "Will we all be coding in Python ten years from now?"
>
> kenny[/color]

Best regards,
Tom

--
..signature: Too many levels of symbolic links

[Scott McIntire]

Re: Python from Wise Guy's Viewpoint


"Kenny Tilton" <ktilton@nyc.rr .com> wrote in message
news:_8Ekb.7543 $pT1.318@twiste r.nyc.rr.com...[color=blue]
>
>
> Joachim Durchholz wrote:
>[color=green]
> > Oh, you're trolling for an inter-language flame fest...
> > well, anyway:
> >[color=darkred]
> >> 3. no multimethods (why? Guido did not know Lisp, so he did not know
> >> about them) You now have to suffer from visitor patterns, etc. like
> >> lowly Java monkeys.[/color]
> >
> >
> > Multimethods suck.
> >
> > The longer answer: Multimethods have modularity issues[/color]
>
> Lisp consistently errs on the side of more expressive power. The idea of
> putting on a strait jacket while coding to protect us from ourselves
> just seems batty. Similarly, a recent ex-C++ journal editor recently
> wrote that test-driven development now gives him the code QA peace of
> mind he once sought from strong static typing. An admitted former static
> typing bigot, he finished by wondering aloud, "Will we all be coding in
> Python ten years from now?"
>
> kenny
>[/color]

There was a nice example from one of the ILC 2003 talks about a Europian
Space Agency rocket exploding with a valueable payload. My understanding was
that there was testing, but maybe too much emphasis was placed the static
type checking of the language used to control the rocket. The end result was
a run time arithmetic overflow which the code intepreted as "rocket off
course". The rocket code instructions in this event were to self destruct.
It seems to me that the Agency would have fared better if they just used
Lisp - which has bignums - and relied more on regression suites and less on
the belief that static type checking systems would save the day.

I'd be interested in hearing more about this from someone who knows the
details.

-R. Scott McIntire

[Alex Martelli]

Re: Python from Wise Guy's Viewpoint

Frode Vatvedt Fjeld wrote:
[color=blue]
> John Thingstad <john.thingstad @chello.no> writes:
>[color=green]
>> [..] Functions are internally delt with using dictionaies. The[/color][/color]

Rather, _names_ are dealt that way (for globals; it's faster for
locals -- then, the compiler can turn the name into an index
into the table of locals' values), whether they're names of functions
or names of other values (Python doesn't separate those namespaces).
[color=blue][color=green]
>> bytecode compiler gives it a ID and the look up is done using a
>> dictionary. Removing the function from the dictionary removes the
>> function. (pythonese for hash-table)[/color]
>
> So to get from the ID to the bytecode, you go through a dictionary?[/color]

No; it's up to the implementation, but in CPython the id is the
memory address of the function object, so the bytecode's directly
accessed from there (well, there's a couple of indirectness --
function object to code object to code string -- nothing important).
[color=blue]
> And the mapping from name to ID happens perhaps when the caller is
> bytecode-compiled?[/color]

No, it's a lookup. Dict lookup for globals, fast (index in table)
lookup for locals (making locals much faster to access), but a
lookup anyway. I've already posted about how psyco can optimize
this, being a specializing compiler, when it notices the dynamic
possibilities are not being used in a given case.


Alex

[Terry Reedy]

Re: Python from Wise Guy's Viewpoint


"Scott McIntire" <mcintire_charl estown@comcast. net> wrote in message
news:MoEkb.8215 34$YN5.832338@s ccrnsc01...[color=blue]
> There was a nice example from one of the ILC 2003 talks about a[/color]
Europian[color=blue]
> Space Agency rocket exploding with a valueable payload. My[/color]
understanding was[color=blue]
> that there was testing, but maybe too much emphasis was placed the[/color]
static[color=blue]
> type checking of the language used to control the rocket. The end[/color]
result was[color=blue]
> a run time arithmetic overflow which the code intepreted as "rocket[/color]
off[color=blue]
> course". The rocket code instructions in this event were to self[/color]
destruct.[color=blue]
> It seems to me that the Agency would have fared better if they just[/color]
used[color=blue]
> Lisp - which has bignums - and relied more on regression suites and[/color]
less on[color=blue]
> the belief that static type checking systems would save the day.
>
> I'd be interested in hearing more about this from someone who knows[/color]
the[color=blue]
> details.[/color]

I believe you are referring to the first flight of the Ariane 5
(sp?). The report of the investigating commission is on the web
somewhere and an interesting read. They identified about five
distinct errors. Try google.

Terry

[Dennis Lee Bieber]

Re: Python from Wise Guy's Viewpoint

Scott McIntire fed this fish to the penguins on Sunday 19 October 2003
15:39 pm:
[color=blue]
>
> There was a nice example from one of the ILC 2003 talks about a
> Europian Space Agency rocket exploding with a valueable payload. My
> understanding was that there was testing, but maybe too much emphasis
> was placed the static type checking of the language used to control
> the rocket. The end result was a run time arithmetic overflow which
> the code intepreted as "rocket off course". The rocket code
> instructions in this event were to self destruct. It seems to me that
> the Agency would have fared better if they just used Lisp - which has
> bignums - and relied more on regression suites and less on the belief
> that static type checking systems would save the day.
>
> I'd be interested in hearing more about this from someone who knows
> the
> details.
>[/color]
Just check the archives for comp.lang.ada and Ariane-5.

Short version: The software performed correctly, to specification
(including the failure mode) -- ON THE ARIANE 4 FOR WHICH IT WAS
DESIGNED.

The software was then dropped into the ARIANE 5 with NO REVIEW of
requirements. Two things were different -- the A-5 was capable of more
severe maneuvering, AND apparently the A-5 launch sequence did not need
this code to run for some 40 seconds after ignition (something about
the A-4 launch sequence allowed it to be aborted and restarted in the
40 second span, so the code had to keep up-to-date navigational fixes;
the A-5 OTOH is in space by that point, no post ignition holds).

On the A-4, any values that were that extreme were a sign of critical
malfunction and the software was to shutdown. Which is what it did on
the A-5. Of course, the backup computer then saw the same "malfunctio n"
and shut down too... For the A-4, you wouldn't WANT the computer to try
processing with those values that were so far out of performance specs
that the rocket had to be tumbling out of control anyways.

The bean-counters apparently did not allow the folks with the A-5
requirements to examine the A-4 code for compliance, and the A-4 Coders
obviously never knew about the A-5 performance specs.

LISP wouldn't have helped -- since the A-4 code was supposed to
failure with values that large... And would have done the same thing if
plugged in the A-5. (Or are you proposing that the A-4 code is supposed
to ignore a performance requirement?)



--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <[/color]

[Kenny Tilton]

Re: Python from Wise Guy's Viewpoint



Dennis Lee Bieber wrote:
[color=blue]
> Scott McIntire fed this fish to the penguins on Sunday 19 October 2003
> 15:39 pm:
>
>[color=green]
>>There was a nice example from one of the ILC 2003 talks about a
>>Europian Space Agency rocket exploding with a valueable payload. My
>>understandi ng was that there was testing, but maybe too much emphasis
>>was placed the static type checking of the language used to control
>>the rocket. The end result was a run time arithmetic overflow which
>>the code intepreted as "rocket off course". The rocket code
>>instruction s in this event were to self destruct. It seems to me that
>>the Agency would have fared better if they just used Lisp - which has
>>bignums - and relied more on regression suites and less on the belief
>>that static type checking systems would save the day.
>>
>> I'd be interested in hearing more about this from someone who knows
>> the
>>details.
>>[/color]
>
> Just check the archives for comp.lang.ada and Ariane-5.
>
> Short version: The software performed correctly, to specification
> (including the failure mode) -- ON THE ARIANE 4 FOR WHICH IT WAS
> DESIGNED.[/color]

Nonsense. From: http://www.sp.ph.ic.ac.uk/Cluster/report.html

"The internal SRI software exception was caused during execution of a
data conversion from 64-bit floating point to 16-bit signed integer
value. The floating point number which was converted had a value greater
than what could be represented by a 16-bit signed integer. This resulted
in an Operand Error. The data conversion instructions (in Ada code) were
not protected from causing an Operand Error, although other conversions
of comparable variables in the same place in the code were protected.
The error occurred in a part of the software that only performs
alignment of the strap-down inertial platform. This software module
computes meaningful results only before lift-off. As soon as the
launcher lifts off, this function serves no purpose."

[color=blue]
> LISP wouldn't have helped -- since the A-4 code was supposed to
> failure with values that large... And would have done the same thing if
> plugged in the A-5. (Or are you proposing that the A-4 code is supposed
> to ignore a performance requirement?)[/color]

"supposed to" fail? chya. This was nothing more than an unhandled
exception crashing the sytem and its identical backup. Other conversions
were protected so they could handle things intelligently, this bad boy
went unguarded. Note also that the code functionality was pre-ignition
only, so there is no way they were thinking that a cool way to abort the
flight would be to leave a program exception unhandled.

What happened (aside from an unnecessary chunk of code running
increasing risk to no good end) is that the extra power of the A5 caused
oscillations greater than those seen in the A4. Those greater
oscillations took the 64-bit float beyond what would fit in the 16-bit
int. kablam. Operand Error. This is not a system saying "whoa, out of
range, abort".

As for Lisp not helping:
[color=blue]
> most-positive-fixnum ;; constant provided by implementation[/color]
536870911
[color=blue]
> (1+ most-positive-fixnum) ;; overflow fixnum type and...[/color]
536870912
[color=blue]
> (type-of (1+ most-positive-fixnum)) ;; ...auto bignum type[/color]
BIGNUM
[color=blue]
> (round most-positive-single-float) ;; or floor or ceiling[/color]
340282346638528 859811704183484 516925440
0.0
[color=blue]
> (type-of *)[/color]
BIGNUM

kenny

--

http://tilton-technology.com

What?! You are a newbie and you haven't answered my:

http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey

[Hannu Kankaanp??]

Re: Python from Wise Guy's Viewpoint

mike420@ziplip. com wrote in message news:<LVOAILABA JAFKMCPJ0F1IFP5 N3JTNUL0EPMGKMD S@ziplip.com>.. .[color=blue]
> THE BAD:
>
> 1. f(x,y,z) sucks. f x y z would be much easier to type (see Haskell)
> 90% of the code is function applictions. Why not make it convenient?[/color]

Python has been designed to attract non-programmers as well. Don't
you think f(x,y,z) resembles the mathematical notation of passing
a function some parameters, instead of "f x y z"?
[color=blue]
> 5. Why do you need "def" ? In Haskell, you'd write
> square x = x * x[/color]

The reason is just to make it clearer that we're defining
a function. I wonder why you didn't complain about
the colons at the beginning of each block.. Some syntax is
there just to add readability. I suppose it means nothing
to you that Python is compared to executable pseudocode.
It means to Pythonistas.
[color=blue]
> 6. Requiring "return" is also dumb (see #5)[/color]

You really don't get any of this "explicit is better than implicit"
thing, do you? Requiring people to write "return" instead of
leaving it as optional like in Ruby, is again one reason why
Pythonistas *like* Python instead of Ruby. You come to
a Python group (and cross-post this meaninglessly everywhere
even though it only concerns Pythonistas) claiming that the
features we like are dumb, and you wonder why people think
of you as a troll..

Anyway, as a conclusion, I believe you'd be much happier with
Ruby than with Python. It doesn't do this weird "statement vs
expression" business, it has optional return, it has optional
parens with function calls, and probably more of these things
"fixed" that you consider Python's downsides. You're trying to
make Python into a language that already exists, it seems, but
for some reason Pythonistas are happy with Python and not rapidly
converting to Ruby or Haskell. Instead of trying to tell us
what we like (and failing at that, as you can see), maybe you
should try to think for a while of why we like Python.

By the way, have you already posted a similar message
to comp.std.c++, saying what they should change about C++
to make it more like Haskell or Ruby? I'd love to read it
(it could be hilarious) ;)

[Fergus Henderson]

Re: Python from Wise Guy's Viewpoint

Kenny Tilton <ktilton@nyc.rr .com> writes:
[color=blue]
>Dennis Lee Bieber wrote:
>[color=green]
>> Just check the archives for comp.lang.ada and Ariane-5.
>>
>> Short version: The software performed correctly, to specification
>> (including the failure mode) -- ON THE ARIANE 4 FOR WHICH IT WAS
>> DESIGNED.[/color]
>
>Nonsense.[/color]

No, that is exactly right. Like the man said, read the archives for
comp.lang.ada.
[color=blue]
>From: http://www.sp.ph.ic.ac.uk/Cluster/report.html
>
>"The internal SRI software exception was caused during execution of a
>data conversion from 64-bit floating point to 16-bit signed integer
>value. The floating point number which was converted had a value greater
>than what could be represented by a 16-bit signed integer. This resulted
>in an Operand Error. The data conversion instructions (in Ada code) were
>not protected from causing an Operand Error, although other conversions
>of comparable variables in the same place in the code were protected.
>The error occurred in a part of the software that only performs
>alignment of the strap-down inertial platform. This software module
>computes meaningful results only before lift-off. As soon as the
>launcher lifts off, this function serves no purpose."[/color]

That's all true, but it is only part of the story, and selectively quoting
just that part is misleading in this context.

For a more detailed answer, see
<http://www.google.com. au/groups?as_umsgi d=359BFC60.446B %40lanl.gov>.
[color=blue][color=green]
>> LISP wouldn't have helped -- since the A-4 code was supposed to
>> failure with values that large... And would have done the same thing if
>> plugged in the A-5. (Or are you proposing that the A-4 code is supposed
>> to ignore a performance requirement?)[/color]
>
>"supposed to" fail? chya. This was nothing more than an unhandled
>exception crashing the sytem and its identical backup. Other conversions
>were protected so they could handle things intelligently, this bad boy
>went unguarded.[/color]

The reason that it went unguarded is that the programmers DELIBERATELY
omitted an exception handler for it. The post at the URL quoted above
explains why.

--
Fergus Henderson <fjh@cs.mu.oz.a u> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

[Duncan Booth]

Re: Python from Wise Guy's Viewpoint

mike420@ziplip. com wrote in
news:LVOAILABAJ AFKMCPJ0F1IFP5N 3JTNUL0EPMGKMDS @ziplip.com:
[color=blue]
> 1. f(x,y,z) sucks. f x y z would be much easier to type (see Haskell)
> 90% of the code is function applictions. Why not make it convenient?[/color]

What syntax do you propose to use for f(x(y,z)), or f(x(y(z))), or
f(x,y(z)) or f(x(y),z) or f(x)(y)(z) or numerous other variants which are
not currently ambiguous?

--
Duncan Booth duncan@rcp.co.u k
int month(char *p){return(1248 64/((p[0]+p[1]-p[2]&0x1f)+1)%12 )["\5\x8\3"
"\6\7\xb\1\x9\x a\2\0\4"];} // Who said my code was obscure?

[Alex Martelli]

Re: Python from Wise Guy's Viewpoint

Duncan Booth wrote:
[color=blue]
> mike420@ziplip. com wrote in
> news:LVOAILABAJ AFKMCPJ0F1IFP5N 3JTNUL0EPMGKMDS @ziplip.com:
>[color=green]
>> 1. f(x,y,z) sucks. f x y z would be much easier to type (see Haskell)
>> 90% of the code is function applictions. Why not make it convenient?[/color]
>
> What syntax do you propose to use for f(x(y,z)), or f(x(y(z))), or
> f(x,y(z)) or f(x(y),z) or f(x)(y)(z) or numerous other variants which are
> not currently ambiguous?[/color]

Haskell has it easy -- f x y z is the same as ((f x) y) z -- as an
N-ary function is "conceptualized " as a unary function that returns
an (N-1)-ary function [as Haskell Curry conceptualized it -- which
is why the language is named Haskell, and the concept currying:-)].
So, your 5th case, f(x)(y)(z), would be exactly the same thing.

When you want to apply operators in other than their normal order
of priority, then and only then you must use parentheses, e.g. for
your various cases they would be f (x y z) [1st case], f (x (y z))
[2nd case], f x (y z) [3rd case], f (x y) z [4th case]. You CAN,
if you wish, add redundant parentheses, of course, just like in
Python [where parentheses are overloaded to mean: function call,
class inheritance, function definition, empty tuples, tuples in
list comprehensions, apply operators with specified priority --
I hope I recalled them all;-)].

Of course this will never happen in Python, as it would break all
backwards compatibility. And I doubt it could sensibly happen in
any "simil-Python" without adopting many other Haskell ideas, such
as implicit currying and nonstrictness. What "x = f" should mean
in a language with assignment, everything first-class, and implicit
rather than explicit calling, is quite troublesome too.

Ruby allows some calls without parentheses, but the way it disambiguates
"f x y" between f(x(y)) and f(x, y) is, IMHO, pricey -- it has to KNOW
whether x is a method, and if it is it won't just let you pass it as such
as an argument to f; that's the slippery slope whereby you end up having to
write x.call(y) because not just any object is callable.
"x = f" CALLS f if f is a method, so you can't just treat methods
as first-class citizens like any other... etc, etc...
AND good Ruby texts recommend AVOIDING "f x y" without parentheses,
anyway, because it's ambiguous to a human reader, even when it's
clear to the compiler -- so the benefit you get for that price is
dubious indeed.


Alex