Python vs. Lisp -- please explain

[63q2o4i02]

Hi, I've been thinking about Python vs. Lisp. I've been learning
Python the past few months and like it very much. A few years ago I
had an AI class where we had to use Lisp, and I absolutely hated it,
having learned C++ a few years prior. They didn't teach Lisp at all
and instead expected us to learn on our own. I wasn't aware I had to
uproot my thought process to "get" it and wound up feeling like a
moron.

In learning Python I've read more about Lisp than when I was actually
trying to learn it, and it seems that the two languages have lots of
similarities:

http://www.norvig.com/python-lisp.html

I'm wondering if someone can explain to me please what it is about
Python that is so different from Lisp that it can't be compiled into
something as fast as compiled Lisp? From this above website and
others, I've learned that compiled Lisp can be nearly as fast as C/C++,
so I don't understand why Python can't also eventually be as efficient?
Is there some *specific* basic reason it's tough? Or is it that this
type of problem in general is tough, and Lisp has 40+ years vs Python's
~15 years?
Thanks
Michael

[DH]

63*******@sneakemail.com wrote:

A few years ago I
had an AI class where we had to use Lisp, and I absolutely hated it,
having learned C++ a few years prior. They didn't teach Lisp at all
and instead expected us to learn on our own.
CS classes haven't changed, I see.
In learning Python I've read more about Lisp than when I was actually
trying to learn it, and it seems that the two languages have lots of
similarities:

http://www.norvig.com/python-lisp.html

I'm wondering if someone can explain to me please what it is about
Python that is so different from Lisp that it can't be compiled into
something as fast as compiled Lisp? From this above website and
others, I've learned that compiled Lisp can be nearly as fast as C/C++,
so I don't understand why Python can't also eventually be as efficient?
Is there some *specific* basic reason it's tough? Or is it that this
type of problem in general is tough, and Lisp has 40+ years vs Python's
~15 years?

It is by design. Python is dynamically typed. It is essentially an
interpreted scripting language like javascript or ruby or perl, although
python fans will be quick to tell you python is compiled to byte code.
They'll also be quick to tell you:
-python has true closures (although nothing like ruby's blocks)
-is beginner friendly (despite being case sensitive and 3/4==0, for example)
-is not, in fact, slow at all (despite benchmarks as you noted showing
otherwise).
Judge for yourself.

There are projects that combine static typing + the python syntax, which
result in dramatically faster code, but perhaps only 80% of python's
functionality and less flexibility you get from dynamic typing.
Projects like shedskin. But some python fans don't think 80% cuts it,
even if you do get a 100 fold speed increase.

[Terry Reedy]

<63*******@sneakemail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

In learning Python I've read more about Lisp than when I was actually
trying to learn it, and it seems that the two languages have lots of
similarities:

http://www.norvig.com/python-lisp.html

I'm wondering if someone can explain to me please what it is about
Python that is so different from Lisp that it can't be compiled into
something as fast as compiled Lisp? From this above website and
others, I've learned that compiled Lisp can be nearly as fast as C/C++,
In order to be that fast, some of the dynamism of intepreted Lisp must be
given up. In particular object code is not list data. Python with
type-dynamism eliminated can also be translated to decent C/C++ and then
compiled. See PyRex and Weave. There is also Psyco, which I believe
translates directly to machine code.
so I don't understand why Python can't also eventually be as efficient?
Is there some *specific* basic reason it's tough? Or is it that this
type of problem in general is tough, and Lisp has 40+ years vs Python's
~15 years?

Yes, *much* more work has gone into Lisp than Python. (At least 10x, I am
sure. and maybe up to 100x) During the 1980s, there was a Lisp/AI
boom/bust something like the dot.com boom/bust of the last 1990s with
perhaps a billion invested in Lisp/AI companies. I presume some of that
went into Lisp itself (as opposed to AI applications thereof).

Terry Jan Reedy

[gene tani]

63*******@sneakemail.com wrote:

I'm wondering if someone can explain to me please what it is about
Python that is so different from Lisp that it can't be compiled into
something as fast as compiled Lisp? From this above website and
others, I've learned that compiled Lisp can be nearly as fast as C/C++,
so I don't understand why Python can't also eventually be as efficient?
Is there some *specific* basic reason it's tough? Or is it that this
type of problem in general is tough, and Lisp has 40+ years vs Python's
~15 years?

i'm not sure it'll answer question, but Brett cannon's thesis is good
background

http://www.ocf.berkeley.edu/~bac/thesis.pdf

[Steven D'Aprano]

On Sat, 18 Feb 2006 23:35:27 -0600, DH wrote:

I'm wondering if someone can explain to me please what it is about
Python that is so different from Lisp that it can't be compiled into
something as fast as compiled Lisp? From this above website and
others, I've learned that compiled Lisp can be nearly as fast as
C/C++, so I don't understand why Python can't also eventually be as
efficient? Is there some *specific* basic reason it's tough? Or is it
that this type of problem in general is tough, and Lisp has 40+ years
vs Python's ~15 years?
It is by design.

You make it sound like Guido sat down to design a language and
deliberately put "Slow" first on his list of desired attributes. Why such
a negative tone to your post?

Python is not slow by design. Python is dynamically typed by design, and
relative slowness is the trade-off that has to be made to give dynamic
types.

The Python developers have also done marvels at speeding up Python since
the early days, with the ultimate aim of the PyPy project to make Python
as fast as C, if not faster. In the meantime, the question people should
be asking isn't "Is Python fast?" but "Is Python fast enough?".
Python is dynamically typed. It is essentially an
interpreted scripting language like javascript or ruby or perl, although
python fans will be quick to tell you python is compiled to byte code.
You make it sound like Python fans are bending the truth. That Python
compiles to byte-code is an objective fact which can be learnt by anyone,
not just "Python fans". In that regard, Python is closer to Java than Perl
or Javascript. Only without the slow startup time of the JRE.

They'll also be quick to tell you:
-python has true closures (although nothing like ruby's blocks)
They're also nothing like Pascal's with statements either. Why make the
comparison with Ruby's blocks when the original poster is comparing Python
to Lisp?

-is beginner friendly (despite being case sensitive and 3/4==0, for
example)
Case sensitivity isn't beginner unfriendly. It is sloppy thinker
unfriendly. Whether you have been programming for thirty days or thirty
years, if you don't know the difference between foo and FOO you have a
serious problem. As they say, case is the difference between "I helped my
Uncle Jack off a horse" and "I helped my uncle jack off a horse."

As for the difference between integer division and true division, yes,
that was an unfortunate design decision. Fortunately it is being rectified
in the least painful way possible.

-is not, in fact, slow at all (despite benchmarks as you noted showing
otherwise).

I've asked this question before, but obviously there is a particular
mindset that just doesn't get it. Slow compared to what? Slow to do what?

For those who don't understand the difference between "faster" and "fast
enough", perhaps a simple analogy will bring enlightenment. For most
people, under most circumstances, an ordinary car (top speed around 75
mph or so) is fast enough, more convenient, and much better value for
money than the significantly faster F-15 fighter plane (top speed around
1850 mph).

On modern hardware, for the vast majority of applications, the execution
speed of the language is not the limiting factor. I/O or the algorithm is
usually the limiting factor. "Change your algorithm" is often better
advice than "change your language".

That's not to say that Python isn't objectively SLOWER (note the
relative term, not absolute) than some languages. But execution speed is
rarely the most important factor in choice of a language.

For those tasks that language speed is a limiting factor (say, writing
devise drivers, operating systems, and similar), Python may not be fast
enough. But they are the exception rather than the rule, and there are no
shortage of ways around that: Psycho, C extensions, or even "choose
another language".

--
Steven.

[Robert J. Hansen]

> what [is it] about Python that is so different from Lisp that it

can't be compiled into something as fast as compiled Lisp?

IMO, it's the lack of competing implementations.

LISP has a very well-defined ANSI specification. Lots of different
people have written LISPs, from Franz to Steel Bank to GNU to... etc.
Each of these competes with the others on different grounds; some are
purely interpreted (ala CLISP), some are compiled (CMUCL), some are...
etc. They all implement substantially the same language, but the
plethora of different implementations has been a tremendous boon for
the development of efficient compilers, interpreters and garbage
collectors.

By comparison, Python lacks anywhere near as many competing
implementations.

In some respects the lack of competing implementations is a Good Thing.
In some respects it's a Bad Thing. On balance it's just a thing.

[bearophileHUGS]

The question about the speed is interesting. Generally the more dynamic
and flexible your language is, the slower are the programs it produces.
Lisp is almost unique in such matters (and in this regard it's maybe
better than CPython) because it allows the programmer to mix and blend
different levels of how much dynamism and how much optimized a part of
the program has to be. When you want to speed up a part of a Lisp
program (often developed starting from a slow but flexible code) you
start to use more specific functions, unboxed variables, simple arrays
of unboxed data, statically typed variables, etc. It's not easy, but if
you have some experience, often than one year, in that way you can
write programs only 20% or 50% slower than ones written in C, so for
most purposes they become fast enough. On the other hand you can
develop the program using an interactive shell and a dynamically typed
language, that speeds you a lot the prototyping, etc. You can have the
best of both things.
Python allows to mix various blends too (Psyco, Pyrex, ShedSkin, Weave,
SWIG, glues for Fortran and C/C++, etc), but in Lisp such blending
seems much more natural, finer grained, integrated in the language.
I think this isn't a limit of the language itself, because with enough
work two tools like Psyco and ShedSkin can become integrated in the
language itself (I think Psyco and SS are enough for 98% or purposes)
producing something not far from the "optimization flexibility" of
Lisp. Psyco compiles just in time some code, ShedSkin is more
aggressive, but if it becomes developed enough it can produce programs
fast as C/C++ ones with the same syntax of Python (some things aren't
supported). So then you can develop a program like in Lisp, where some
parts aren't optimized, some parts are compiled just in time, and other
critical parts are type inferenced and statically compiled for the max
speed (this requires to join ShedSkin with something like Swig, to
allow a natural, fully automatic and pythonic joining of .PYDs produced
by SS and CPython programs). PyPy can probably solve such problems in
similar ways or better, we'll see.

Bye,
bearophile

[Roy Smith]

DH <[e-mail]> wrote:

-python has true closures (although nothing like ruby's blocks)

What is a "true closure"? Or, maybe what I'm asking is what kind of
closure wouldn't be a true closure? Is there some kind of ersatz closure
other language try to pass off, in violation of truth in closure laws?

[Roy Smith]

"Robert J. Hansen" <ci********@gmail.com> wrote:

LISP has a very well-defined ANSI specification. Lots of different
people have written LISPs, from Franz to Steel Bank to GNU to... etc.
Each of these competes with the others on different grounds; some are
purely interpreted (ala CLISP), some are compiled (CMUCL), some are...
etc. They all implement substantially the same language, but the
plethora of different implementations has been a tremendous boon for
the development of efficient compilers, interpreters and garbage
collectors.

It's been a while since I've dabbled in lisp, but my recollection is that
the plethora of different implementations has also meant that portability
is a fantasy.

I dread the day that competing Python implementations spring up.

[Torsten Bronger]

Hallöchen!

Roy Smith <ro*@panix.com> writes:

[...]

It's been a while since I've dabbled in lisp, but my recollection
is that the plethora of different implementations has also meant
that portability is a fantasy.

I dread the day that competing Python implementations spring up.

Even worse: In one of them Microsoft is involved.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Fredrik Lundh]

Roy Smith wrote:

I dread the day that competing Python implementations spring up.

where were you in 1997?

http://www.python.org/workshops/1997...s/hugunin.html

</F>

[Luis M. González]

>IMO, it's the lack of competing implementations.

I beg to differ in this point.
There are other implementations, but they are not called "python" and
they are not a 100% python in syntax and features.
For example, Boo is 95% python syntax wise, but statically typed.
This fundamental difference makes it as fast as C# or any other .NET
(or mono) language.
Being statically typed doesn't mean that you have to declare types
everywhere, like in C. It uses type inference, so you can declare a
variable x= 5 and the compiler will know that x is an integer of value
5.
Pyrex is statically typed too, but it's used mainly as an extension
language for Cpython.

Now talking specifically about python, there are projects aimed at
speeding it up substantially:

Pypy is a project that relies heavily in type inference (for
translation to lower level code) and dynamic optimization. It's based
mainly on psyco, which has already probed that it can massively speed
up python code.

Shed-Skin: it's a pyton-to-c++ compiler. It won't support the most
dynamic features of python, and requires the programmer to restric a
little bit his coding style in order to allow static compilation, but
so far it looks great (only one developer though..).

[bearophileHUGS]

Luis M. González>[Shed-Skin] ... but so far it looks great (only one
developer though..).<

Two developers, I am there too :-)

I think people aren't much interested so far because there aren't good
ways to link/join/use SSPython compied code from CPython code. A good
solution is probably to:
- Develop code in CPython
- find if there are slow spots that Psyco can't improve enough
- in this situation move the parts in a module and do some tweaks to
adapt the code (if necessary)
- compile the .py module (to a .pyd, etc) with SS (a single click can
be enough on some operating systems), and then import it as before.

To do this it SS requires to know the types of the input data of the
functions/classes in the module. There are solutions to this, the
simpler one to me seems to infer such types from the code below the if
__name__ == "__main__":
That part can contain tests of all the functions/classes, so such parts
can be used to infer types of the whole module.
To do this automatically SS has to use something like SWIG.

Other developers can probably help with such things, otherwise SS will
probably be dead in a year from now... this is not good for me.

Bye,
bearophile

[Alexander Schmolck]

"Terry Reedy" <tj*****@udel.edu> writes:

<63*******@sneakemail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

In learning Python I've read more about Lisp than when I was actually
trying to learn it, and it seems that the two languages have lots of
similarities:

http://www.norvig.com/python-lisp.html

I'm wondering if someone can explain to me please what it is about
Python that is so different from Lisp that it can't be compiled into
something as fast as compiled Lisp? From this above website and
others, I've learned that compiled Lisp can be nearly as fast as C/C++,

In order to be that fast, some of the dynamism of intepreted Lisp must be
given up. In particular object code is not list data.

I'm not entirely sure what you are talking about, but you're almost certainly
very confused about something. Not all common lisp implementations even have
an interpreter (which doesn't tend to be visible to the user).

'as

[Cameron Laird]

In article <ro***********************@reader2.panix.com>,
Roy Smith <ro*@panix.com> wrote:

DH <[e-mail]> wrote:

-python has true closures (although nothing like ruby's blocks)

What is a "true closure"? Or, maybe what I'm asking is what kind of
closure wouldn't be a true closure? Is there some kind of ersatz closure
other language try to pass off, in violation of truth in closure laws?

It's an apt question.

What's a "true closure"? That's the easiest part, in some ways:
Wikipedia, for example, tells that it's "a function that refers
to free variables in its lexical context" <URL:
http://en.wikipedia.org/wiki/Closure...ter_science%29 >,
that is the context of the domain of the function's definition.

Some languages--Lisp, but also many others--definitely have it.
Basic definitely didn't. Tcl ... well, after weeks of discussion
<URL: http://wiki.tcl.tk/closures >, the conclusion was that Tcl
almost has as much as it can, given that "lexical context" just
doesn't have much standing in Tclonia. So, yes, George Mikan and
Allen Iverson both definitely played basketball, and well, but,
at the same time, it's useful to distinguish the things they do
with a ball.

[Kay Schluehr]

Roy Smith wrote:

DH <[e-mail]> wrote:

-python has true closures (although nothing like ruby's blocks)

What is a "true closure"? Or, maybe what I'm asking is what kind of
closure wouldn't be a true closure? Is there some kind of ersatz closure
other language try to pass off, in violation of truth in closure laws?

A "true closure" is what Python doesn't have ;)

If you enclose variables in a certain functional context in which they
are not defined they are turned into something immutable in Python.
Assigning a value to the same name creates a new object instead of
rebinding the old name. This "readonly" semantics confuses many
programmers coming from other languages at least all Lispers/Schemers
I've talked to. Python does not provide a rebinding operator for free
variables by BDFL decision.

Kay

[Terry Hancock]

On Sun, 19 Feb 2006 00:54:22 -0500
"Terry Reedy" <tj*****@udel.edu> wrote:

In order to be that fast, some of the dynamism of
intepreted Lisp must be given up. In particular object
code is not list data. Python with type-dynamism
eliminated can also be translated to decent C/C++ and then
compiled. See PyRex and Weave. There is also Psyco,
which I believe translates directly to machine code.

I thought it was just "Pyrex" as in "Still as clear as
glass, but can really take the heat.". ;-)

Now it's a small snake / dog chimera. Eeeww. You've ruined
it for me.

so I don't understand why Python can't also eventually
be as efficient? Is there some *specific* basic reason
it's tough? Or is it that this type of problem in
general is tough, and Lisp has 40+ years vs Python's ~15
years?

Otherwise, I think this has been well-answered -- if you
give up the same features, you can get the same speed. But
who cares?

Those things only matter in a very limited domain, and real
programs can use Python for logic and Python extension
modules for things that truly need optimization. If you use
Pyrex, you can even still pretend you're programming in
Python when you write those extensions. I'm sure that's why
some 3D libraries have opted to write the fast code in Pyrex
instead of C (even though either is possible).

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[Bruno Desthuilliers]

DH a écrit :
(snip)

It is by design. Python is dynamically typed. It is essentially an
interpreted scripting language like javascript or ruby or perl,
It's not a "scripting" language, and it's not interpreted.
although
python fans will be quick to tell you python is compiled to byte code.

CQFD.

[Alexander Schmolck]

63*******@sneakemail.com writes:

Hi, I've been thinking about Python vs. Lisp. I've been learning
Python the past few months and like it very much. A few years ago I
had an AI class where we had to use Lisp, and I absolutely hated it,
having learned C++ a few years prior. They didn't teach Lisp at all
and instead expected us to learn on our own. I wasn't aware I had to
uproot my thought process to "get" it and wound up feeling like a
moron.

In learning Python I've read more about Lisp than when I was actually
trying to learn it, and it seems that the two languages have lots of
similarities:

http://www.norvig.com/python-lisp.html

I'm wondering if someone can explain to me please what it is about
Python that is so different from Lisp that it can't be compiled into
something as fast as compiled Lisp?
Nothing. Given a sufficiently smart implementation any language can be as fast
as any other -- it might just be a billion times harder to write that
implementation for language A than for language B.
From this above website and others, I've learned that compiled Lisp can be
nearly as fast as C/C++, so I don't understand why Python can't also
eventually be as efficient? Is there some *specific* basic reason it's
tough? Or is it that this type of problem in general is tough, and Lisp has
40+ years vs Python's ~15 years?

I think if you're looking for one single reason, it is presumably that (IIRC)
python was designed on the erronous assumption that dynamically typed
languages have to be slow (and are unsuitable for real applications anyway)
wheras common lisp wasn't. Furthermore the people involved in common lisp were
much more knowledgeable and experienced in things like compiler design and had
a long history of similar languages and various implementations to build upon.

As common lisp and scheme demonstrate you can have high level of dynamism (and
in a number of things both are more dynamic than python) and still get very
good performance (in some cases close to or better than C). But both these
languages have been designed with compiler writers and the generation of fast
code in mind, so they made design decisions to ease writing fast lisp
compilers and programs.

For example:

- python classes (and to some extent modules) are essentially dictionaries
that you can modify and customize more or less at will at run-time and that
behave interchangeably in many respects. I'm sure that presents several
optimization headaches.

By contrast if the common lisp compiler sees the symbol CL:LIST (usually
written just LIST, because the CL package is imported by default) it can
safely assume that it refers to the builtin LIST function, because you're
not allowed to rebind the function value of functions in the CL package.
Python can assume no such thing if it comes across ``list`` -- for all it
knows it might as well be the number 42. Also the package and class system
are completely separate and although common lisp's OO system is rather more
powerful than python's it has been designed to be implementable efficiently.

- in python almost everything has to happen at run-time, whereas in common
lisp you can do things at compile time, load time or run-time e.g:

- common lisp has a mechanism for making compiler declarations (so you can
tell the compiler to inline a function, or the type of a variable, or to
optimize something for speed and not for space etc.)

- common lisp has macros (proper ones, not C style) which allow you to build
efficient abstractions

- common lisp has compiler macros. This sort of means that you can write your
own compiler optimizations for your functions (i.e. if you know that your
expensive FOO function is indempotent you could arrange for all calls of the
form (FOO (FOO A)) to be replaced with simply A, in a similar way as an
optimizing compiler might replace (a+b+c+d)*0 with 0).

What's far more interesting to me, however, is that I think there a good
reasons to suspect python's slowness is more of a feature than a flaw: I'd not
be suprised if on the whole it greatly increases programmer productivity and
results in clearer and more uniform code.

If you know the language to be dog slow any way, you're much less likely to
waste your time (and that of future maintainers) on the pointless
microoptimizations that geeks so love. Also, since only builtins have
reasonable performance there's added motiviation to become very familiar with
the available builtins (and standard libarary) and far less temptation to roll
one's own version of say dict.setdefault (even if it it sucks). The fact that
non-standard library code is inherently somewhat inferior (because it will
either be written in python and slow or written in C and a pain to install)
adds further incentive to attempt community wide standardization.

I think it's not unreasonable to speculate that all this decreases production,
maintenance and reuse costs of python code considerably, so much in fact that
python's very slowness represents part of its competetive edge over languages
that are in some ways better engineered and more capable.

So ironically, some share of python's success might actually be due to
ignorance on Guido's part (of course python in most respects is a marvellously
well designed language that to my mind places Guido at least on par with the
designers of any contemporary language; I'm just intrigued by the possiblity
that had he known as much about performance issues in very dynamic languages
as say some of the lisp and self people, python might have turned out to be a
faster albeit less popular and productive language).

'as

[Alexander Schmolck]

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:

DH a écrit :
(snip)

It is by design. Python is dynamically typed. It is essentially an
interpreted scripting language like javascript or ruby or perl,

It's not a "scripting" language, and it's not interpreted.

Of course it is. What do you think happens to the bytecode? And if python
isn't a scripting language, then what on earth is?

You might want to argue about whether scriping language is a meaningful and
useful concept, but it's really hard to see how you could talk about "scripting
languages" without including python.

'as

[63q2o4i02]

Cool, thank you. That's the answer I was looking for :)

[Fredrik Lundh]

Alexander Schmolck wrote:

What's far more interesting to me, however, is that I think there a good
reasons to suspect python's slowness is more of a feature than a flaw: I'd not
be suprised if on the whole it greatly increases programmer productivity and
results in clearer and more uniform code. So ironically, some share of python's success might actually be due to
ignorance on Guido's part

it didn't, for even a millisecond, strike you that maybe, just maybe, the
"make it as dynamic as we possibly can" choice was made on purpose ?

</F>

[63q2o4i02]

Great, thanks for a very complete answer.
michael

[Fredrik Lundh]

Alexander Schmolck wrote:

You might want to argue about whether scriping language is a meaningful and
useful concept, but it's really hard to see how you could talk about "scripting
languages" without including python.

define "scripting language".

the only even remotely formal definition I've ever seen is "language with
designed to script an existing application, with limited support for handling
its own state". Early Tcl and JavaScript are scripting languages, Python
is not.

</F>

[Bruno Desthuilliers]

Alexander Schmolck a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:

DH a écrit :
(snip)

It is by design. Python is dynamically typed. It is essentially an
interpreted scripting language like javascript or ruby or perl,

It's not a "scripting" language, and it's not interpreted.

Of course it is. What do you think happens to the bytecode?

Ok, then what do you think happens to 'machine' code ?

"interpreted" usually means "no compilation, all parsing etc redone at
each execution", which is not the case with a bytecode/vm based
implementation.
And if python
isn't a scripting language, then what on earth is?
bash is a scripting language for *n*x systems. javascript is a scripting
language for web browsers. VBScript is a scripting language for MS
applications.
You might want to argue about whether scriping language is a meaningful and
useful concept,
A scripting languagee is a language whose main purpose is to be embbeded
in an application to provide the user a way of programmaticaly automate
some tedious tasks.

Now you could of course argue about what is an application...
but it's really hard to see how you could talk about "scripting
languages" without including python.

Ho, really ? How many applications using Python as scripting language ?
And how many applications written in Python ?

Python *can* be used as a scripting language (and is not too bad at it),
but it *is* not a scripting language.

[Ed Jensen]

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:

It's not a "scripting" language, and it's not interpreted.

http://www.python.org/doc/faq/genera...what-is-python

"Python is an interpreted, interactive, object-oriented programming
language."

[63q2o4i02]

Great, thank you and everyone for this nice discussion.

Michael

[Torsten Bronger]

Hallöchen!

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:

Alexander Schmolck a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:

[...]

It's not a "scripting" language, and it's not interpreted.

Of course it is. What do you think happens to the bytecode?

Ok, then what do you think happens to 'machine' code ?

"interpreted" usually means "no compilation, all parsing etc
redone at each execution", which is not the case with a
bytecode/vm based implementation.

That sounds like an implementation feature rather than a language
feature. Besides, it's not a very sensible distinction in my
opinion. Much better is to think about the structure of the
interpreting machine. I'm not a CS person (only a physicist) but if
you *need* a bytecode interpreter on top of the CPU interpretation,
it's an interpreted language to me.

I've had such a discussion about TeX already, and my personal
conclusion was that you can defend almost any opinion in that area.
However, one should ensure that the definitions make a pragmatic and
useful distinction.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Paul Boddie]

Torsten Bronger wrote:

Hallöchen!

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:

Ok, then what do you think happens to 'machine' code ?

"interpreted" usually means "no compilation, all parsing etc
redone at each execution", which is not the case with a
bytecode/vm based implementation.

Such criteria sound more like those which would distinguish interactive
languages from others.
That sounds like an implementation feature rather than a language
feature. Besides, it's not a very sensible distinction in my
opinion. Much better is to think about the structure of the
interpreting machine.
And it's even better to think about the nature of the machine...
I'm not a CS person (only a physicist) but if
you *need* a bytecode interpreter on top of the CPU interpretation,
it's an interpreted language to me.
Yet one could potentially have that bytecode interpreter in hardware.
What typically prevents this is the potential difficulty of realising
complicated software designs in reasonably priced hardware, thus
introducing the nature of the machine: how complicated the instructions
are, what additional support would be required for implementing those
instructions, and so on. Low-level or systems programming languages are
compilable to instructions which are convenient to implement in
hardware and require little additional support: concepts such as stacks
(for various purposes) are supported by machine instructions and
registers, for example, whereas more advanced memory management is left
to software running on top of the virtual machine (although I imagine
that various Lisp machines did some interesting things in this domain).
I've had such a discussion about TeX already, and my personal
conclusion was that you can defend almost any opinion in that area.
However, one should ensure that the definitions make a pragmatic and
useful distinction.

Agreed. The CPython virtual machine consists of "complicated"
instructions: that is, some of those instructions may involve
non-trivial amounts of work and may be integrated with other subsystems
that can realistically only be implemented in software. Even virtual
machines like that of the Java platform have moderately high-level
instructions, resulting in various "Java optimised" hardware
implementations not attempting to provide a complete coverage of all
the available instructions (as far as I am aware).

I'm not sure why people get all defensive about Python's
interpreted/scripting designation or about the details of the CPython
implementation, especially considering that the virtual machine
technology in use has been around for a decade and a half, and that
various projects have been experimenting with alternatives.

Paul

[Steven D'Aprano]

On Sun, 19 Feb 2006 19:26:20 +0000, Alexander Schmolck wrote:

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:

DH a écrit :
(snip)

> It is by design. Python is dynamically typed. It is essentially an
> interpreted scripting language like javascript or ruby or perl,

It's not a "scripting" language, and it's not interpreted.

Of course it is. What do you think happens to the bytecode?

By that logic, all languages are interpreted. What do you think happens to
the machinecode?
--
Steven.

[Alexander Schmolck]

"Fredrik Lundh" <fr*****@pythonware.com> writes:

Alexander Schmolck wrote:

What's far more interesting to me, however, is that I think there a good
reasons to suspect python's slowness is more of a feature than a flaw: I'd not
be suprised if on the whole it greatly increases programmer productivity and
results in clearer and more uniform code.

So ironically, some share of python's success might actually be due to
ignorance on Guido's part

it didn't, for even a millisecond, strike you that maybe, just maybe, the
"make it as dynamic as we possibly can" choice was made on purpose ?

Python is far less dynamic than smalltalk, and presumably also self (last time
I checked there was no implementation for x86, so I have no practical
experience with self). Even common lisp could reasonably be called more
dynamic than python. And all these language communities did in fact still
manage to come up with efficient implementations.

Thus the "make it as dynamic as it possibly can" choice is hardly the cause
for python's slowness, so what's your point?

My point was that Guido probably (and fortunately!) was unaware of the extent
to which you can have both dynamism and speed and the extent to which very
dynamic languages are suitable for writing robust software. I'm pretty sure I
remember reading stuff by Guido himself in which he indicated that he
originally thought that a language with a similar level of dynamism as python
had to be slow anyway and I'm also pretty sure that I read some other stuff by
him which indicates that he thought a language like python would be only
suitable for relatively small scale development. If you don't doubt he wrote
that I'm not sure what we're disagreeing about (because clearly both
statements are wrong), if you do maybe I or someone else can find the right
reference, or maybe I really misremembered.

Anyayw, I'm pretty sure that Guido wouldn't have bothered to add things like
compiler macros to python, whatever his level of his technical expertise
concerning efficient implementations of highly dynamic languages might have
been.

However I don't find it at all implausible to assume that had Guido known all
the stuff that say, David Ungar and Guy Steele were aware of at the same time,
python would have come out not necessarily less dynamic but considerably
faster -- to its own detriment.

'as

[Steven D'Aprano]

On Sun, 19 Feb 2006 13:02:16 -0800, Paul Boddie wrote:

Torsten Bronger wrote:

Hallöchen!

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:

>
> Ok, then what do you think happens to 'machine' code ?
>
> "interpreted" usually means "no compilation, all parsing etc
> redone at each execution", which is not the case with a
> bytecode/vm based implementation.
Such criteria sound more like those which would distinguish interactive
languages from others.
How can that be? Python is interactive, and yet it has a bytecode/vm
implementation.

And I'm just waiting for somebody to mention Forth, which completely
breaks down the barriers between compilation and interpretation. In a
world of virtual machines, bytecode compilers, CPUs which emulate other
CPUs using embedded software, and Forth, I would have thought that it was
as obvious as the Sun in the sky that compiled versus interpreted is a
false dichotomy.
That sounds like an implementation feature rather than a language
feature. Besides, it's not a very sensible distinction in my opinion.
Much better is to think about the structure of the interpreting
machine.

And it's even better to think about the nature of the machine...

Is it? Why? Do you particularly know what happens when your machine code
hits the CPU?

I'm not a CS person (only a physicist) but if you *need* a bytecode
interpreter on top of the CPU interpretation, it's an interpreted
language to me.

Yet one could potentially have that bytecode interpreter in hardware.

Not potentially, in actuality. I know of only one example, and it
wasn't commercially success, but in 1993 IBM developed a version of
the PowerPC RISC chip that had support for the Intel x86 instruction set.

What has been done once can be done again.

[snip]
I'm not sure why people get all defensive about Python's
interpreted/scripting designation or about the details of the CPython
implementation, especially considering that the virtual machine
technology in use has been around for a decade and a half, and that
various projects have been experimenting with alternatives.

I can't speak for others, but for me it is because generally the people
who are the quickest to insist that Python is interpreted appear to mean
it as a put-down. I never hear "Python has the rapid development and
flexibility that only an interpreted language can give", it is always "Of
course Python is slow, it is interpreted, what do you expect?".

Even if they themselves are perfectly aware of the subtle shades of
modern language design, and that interpretation does not mean that every
line of code is parsed repeatedly as it is run, it seems to me that very
often they don't mind one bit if others, less informed than them, come
away with that impression.

Let's be frank: "interpreted language" has negative connotations which may
have been valid in the 1960s and perhaps even the 1970s, but are no longer
automatically valid. Nevertheless, those connotations stick around,
generally amongst the less knowledgeable. That hurts Python's commercial
success, and Python's commercial success is vital for anyone who wishes to
get paid to program in Python.
--
Steven.

[Valentino Volonghi aka Dialtone]

Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

By that logic, all languages are interpreted. What do you think happens to
the machinecode?

Interpreted to transistors state by an internal mapping in the CPU
opcode ==> input configuration.

--
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
New Pet: http://www.stiq.it

[Alexander Schmolck]

"Fredrik Lundh" <fr*****@pythonware.com> writes:

Alexander Schmolck wrote:

You might want to argue about whether scriping language is a meaningful and
useful concept, but it's really hard to see how you could talk about "scripting
languages" without including python.
define "scripting language".

Pretty much any definition that isn't practically useless would do. I'd
personally opt for something like:

A language that doesn't make all common simple tasks difficult and painful.

If that sounds too wishy-washy, note that I specifically question whether
scripting language is a useful and meaningful concept to start with -- I just
find it silly to take issue with calling python a scripting language but not
with the term scripting language itself (especially given that even the python
tutorial talks about python scripts and that almost anyone who uses the term
would include python).
the only even remotely formal definition I've ever seen is "language with
designed to script an existing application, with limited support for handling
its own state". Early Tcl and JavaScript are scripting languages, Python is not.

Right. Which shows that by this definition scripting language is not a
meaningful and useful concept. No one will understand you correctly when you
refer to "scripting language" and mean only something like the above -- and
unless you spend a lot of your time talking about early tcl and early
javascript I doubt you'd need a word for it, either.

'as

[Terry Reedy]

>> Of course it is. What do you think happens to the bytecode?

Ok, then what do you think happens to 'machine' code ?

I believe that on modern CISC processors the human level 'machine code' is
interpreted by subroutines written in the actual machine code usually
called 'microcode'.

tjr

[Paul Boddie]

Steven D'Aprano wrote:

On Sun, 19 Feb 2006 13:02:16 -0800, Paul Boddie wrote:

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:
>
> Ok, then what do you think happens to 'machine' code ?
>
> "interpreted" usually means "no compilation, all parsing etc
> redone at each execution", which is not the case with a
> bytecode/vm based implementation.
Such criteria sound more like those which would distinguish interactive
languages from others.

How can that be? Python is interactive, and yet it has a bytecode/vm
implementation.

The criteria were "no compilation, all parsing etc redone at each
execution": things which would possibly describe features of a language
where much use is made of an interactive mode, and where there wouldn't
be many advantages in generating instructions in another form for later
execution. Not that this applies to Python, since it does compile
source code to bytecode instructions as we all know, and the only
re-parsing occurs in well-defined circumstances, but there have been
other "dare I say scripting?" languages whose execution models have
apparently involved ASTs instead of virtual machine instruction sets.

[...]

And it's even better to think about the nature of the machine...

Is it? Why? Do you particularly know what happens when your machine code
hits the CPU?

In general, yes: it's interpreted by a virtual machine implementation
in hardware. But this is where the nature of the machine is important,
as I originally wrote, since you don't want highly complicated
instructions implemented in hardware for a variety of well-understood
reasons.

[...]
Let's be frank: "interpreted language" has negative connotations which may
have been valid in the 1960s and perhaps even the 1970s, but are no longer
automatically valid. Nevertheless, those connotations stick around,
generally amongst the less knowledgeable. That hurts Python's commercial
success, and Python's commercial success is vital for anyone who wishes to
get paid to program in Python.

I think we're mostly in agreement here. My point was, as usual,
tangential: there is a certain class of instructions conveniently or
economically implementable in hardware; CPython's runtime also has
instructions more complicated than those. Consequently, when people
used to speculate about Python CPUs and other magical devices that
would make Python run much faster (see [1] for more recent material
which doesn't specifically do so, although I believe the speaker made
references to such devices; see [2] for an old mailing list thread),
one has to accept that there are certain constraints that have a severe
effect on whether such devices are viable or not. If some people want
to classify runtime environments on this basis then I don't have a
problem with that, provided that they are honest about it and put
things like the Java VM in the same category as CPython.

Paul

[1]
http://www.python-in-business.org/ep...2116&track=692
[2]
http://mail.python.org/pipermail/pyt...read.html#4543

[Alex Martelli]

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:

DH a écrit :
(snip)

It is by design. Python is dynamically typed. It is essentially an
interpreted scripting language like javascript or ruby or perl,

It's not a "scripting" language, and it's not interpreted.

OK, but then we should change <http://python.org/doc/Summary.html>,
which starts with "Python is an interpreted, interactive,
object-oriented programming language." -- if "it's not interpreted",
then why is this crucial page on Python's main site lying outright?
Alex

[Alex Martelli]

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:
...

Ho, really ? How many applications using Python as scripting language ?

http://wiki.python.org/moin/AppsWithPythonScripting lists many, but it's
obviously woefully incomplete -- e.g., it's missing Civilization IV, a
very popular, major new game whose use of Python has been in the news a
lot. Besides, with ActiveScripting on Windows and Apple Events on the
Mac, all normal applications on both widespread platforms are "using
Python as scripting language", at least potentially -- that makes it
essentially a desperate task to try to count them all...:-(
Alex

[Fredrik Lundh]

Alexander Schmolck wrote:

My point was that Guido probably (and fortunately!) was unaware of the extent
to which you can have both dynamism and speed

any my point was that chosing to ignore something doesn't mean
that you're ignorant.

(but since you keep repeating this nonsense, it's clear that you're
pretty ignorant wrt. software design. too much CS exposure?).

</F>

[Donn Cave]

Quoth Alexander Schmolck <a.********@gmail.com>:
| "Fredrik Lundh" <fr*****@pythonware.com> writes:
....
|> the only even remotely formal definition I've ever seen is "language with
|> designed to script an existing application, with limited support for handling
|> its own state".
|
|> Early Tcl and JavaScript are scripting languages, Python is not.
|
| Right. Which shows that by this definition scripting language is not a
| meaningful and useful concept. No one will understand you correctly when you
| refer to "scripting language" and mean only something like the above -- and
| unless you spend a lot of your time talking about early tcl and early
| javascript I doubt you'd need a word for it, either.

Oddly enough, that's what I understand it to mean, too, so you can't
strictly say "no one".

On the other hand, I think it's obvious that a language like Python could
be used for scripting, without having been specifically designed for it as
described above. There's an ambiguity in the phrase, out of context -
I can say "Python can serve as a scripting language for some applications",
but not "Python is a scripting language!", since its place in the taxonomy
of languages would be somewhere else.

Donn Cave, do**@drizzle.com

[Harald Armin Massa]

>>OK, but then we should change <http://python.org/doc/Summary.html>,

which starts with "Python is an interpreted, interactive,
object-oriented programming language."

I second this motion. Even tried to persuade the site maintainer
before. We should really, really change it. The perceived speed of
Python will at least triple on dropping that "interpreted" - and I am
NOT joking.

Harald

[Michele Simionato]

Alexander Schmolck wrote:

As common lisp and scheme demonstrate you can have high level of dynamism (and
in a number of things both are more dynamic than python) and still get very
good performance (in some cases close to or better than C).
Just for personal enlightment, where do you think Lisp is more dynamic
of Python?
Can you new name a few features?
What's far more interesting to me, however, is that I think there a good
reasons to suspect python's slowness is more of a feature than a flaw: I'd not
be suprised if on the whole it greatly increases programmer productivity and
results in clearer and more uniform code.

If you know the language to be dog slow any way, you're much less likely to
waste your time (and that of future maintainers) on the pointless
microoptimizations that geeks so love. Also, since only builtins have
reasonable performance there's added motiviation to become very familiar with
the available builtins (and standard libarary) and far less temptation to roll
one's own version of say dict.setdefault (even if it it sucks). The fact that
non-standard library code is inherently somewhat inferior (because it will
either be written in python and slow or written in C and a pain to install)
adds further incentive to attempt community wide standardization.

I think it's not unreasonable to speculate that all this decreases production,
maintenance and reuse costs of python code considerably, so much in fact that
python's very slowness represents part of its competetive edge over languages
that are in some ways better engineered and more capable.

I think you have a very good point here. +1000!

Michele Simionato

[bruno at modulix]

Torsten Bronger wrote:

Hallöchen!

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:

Alexander Schmolck a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:
[...]

It's not a "scripting" language, and it's not interpreted.

Of course it is. What do you think happens to the bytecode?
Ok, then what do you think happens to 'machine' code ?

"interpreted" usually means "no compilation, all parsing etc
redone at each execution", which is not the case with a
bytecode/vm based implementation.

That sounds like an implementation feature rather than a language
feature.

It is, of course. When we say that 'this language is
[interpreted|bytecompiled|compiled|runs on clay tablets|whatnot], we're
of course talking about the standard or reference implementation(s).
Besides, it's not a very sensible distinction in my
opinion. Much better is to think about the structure of the
interpreting machine. I'm not a CS person (only a physicist) but if
you *need* a bytecode interpreter on top of the CPU interpretation,
it's an interpreted language to me.
So there are only interpreted languages nowadays.
I've had such a discussion about TeX already, and my personal
conclusion was that you can defend almost any opinion in that area.
However, one should ensure that the definitions make a pragmatic and
useful distinction.

The only pragmatic and useful distinction I can see here is between
languages that have to re-parse the whole source for each and every
executions ('interpreted') and languages that don't.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[bruno at modulix]

Paul Boddie wrote:
(snip)

I'm not sure why people get all defensive about Python's
interpreted/scripting designation

Because it carries a negative connotation of "slow toy language not
suitable for 'serious' tasks". Dynamicity apart, CPython's
implementation is much closer to Java than to bash scripts - but still,
as soon as you say "interpreted, scripting", peoples think "not serious".

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[bruno at modulix]

Harald Armin Massa wrote:

OK, but then we should change <http://python.org/doc/Summary.html>,
which starts with "Python is an interpreted, interactive,
object-oriented programming language."

I second this motion. Even tried to persuade the site maintainer
before. We should really, really change it. The perceived speed of
Python will at least triple on dropping that "interpreted" - and I am
NOT joking.

+1 on this.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Torsten Bronger]

Hallöchen!

bruno at modulix <on***@xiludom.gro> writes:

Torsten Bronger wrote:

[...]

I've had such a discussion about TeX already, and my personal
conclusion was that you can defend almost any opinion in that
area. However, one should ensure that the definitions make a
pragmatic and useful distinction.

The only pragmatic and useful distinction I can see here is
between languages that have to re-parse the whole source for each
and every executions ('interpreted') and languages that don't.

Well, I think that it's fair to say that there are by principle deep
run time differences between CPython and, say, a typical
C++-compiled program. Your definition would not reproduce that. I
think it's also fair to say that these differences should be known
if somebody tries to find the best tool for a job. After all, they
include advantages, too.

My definiton would be that an interpreted language has in its
typical implementation an interpreting layer necessary for typical
hardware. Of couse, now we could discuss what is "typical",
however, in practice one would know it, I think. In case of Python:
CPython and all important modern processors.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Paul Boddie]

bruno at modulix wrote:

Paul Boddie wrote:
(snip)

I'm not sure why people get all defensive about Python's
interpreted/scripting designation

Because it carries a negative connotation of "slow toy language not
suitable for 'serious' tasks". Dynamicity apart, CPython's
implementation is much closer to Java than to bash scripts - but still,
as soon as you say "interpreted, scripting", peoples think "not serious".

Perhaps we should blame the main man for this confusing label, then
[1]:

"From one perspective you can say Python is a very high-level scripting
language."

Interestingly, with regard to my remark about various criteria being
more appropriate when distinguishing between interactive and
non-interactive languages, we also learn the following:

"From another perspective you can say it's a high-level programming
language that happens to be implemented in a way that emphasizes
interactivity. Python shares some characteristics with scripting
languages, but also shares some characteristics with more traditional
programming languages."

Of course, we've all had this debate before, or rather everyone else
has had this debate before and I've mostly ignored whether people call
Python a scripting language, an interactive language, an agile
language, a dynamic language, an applications programming language, or
whatever. Personally, I rather think that whichever labels one chooses
to attach to a language or platform generally come about from the
success stories one can show people in relation to that language or
platform.

But there are always going to be people who contrast something like
CPython's runtime with the Java virtual machine and ask whether CPython
has, for example as one distinguishing factor, just-in-time compilation
as a generally supported feature, and such people will be genuinely
interested in why such things typically lie outside the principal
runtime development process. People like to find distinctions between
things - sometimes arbitrary ones - and make classifications that allow
them to arrange such things conveniently in their mind. What I find
quite worrying is that while in previous years people have responded to
such discussions with a critical analysis of where Python (or rather
CPython) can be improved, it's now the fashion to just trot out some
response or other which excuses rather than explains the way things
are.

Paul

[1] http://www.artima.com/intv/python.html

[Paul Boddie]

Fredrik Lundh wrote:

Alexander Schmolck wrote:

My point was that Guido probably (and fortunately!) was unaware of the extent
to which you can have both dynamism and speed
any my point was that chosing to ignore something doesn't mean
that you're ignorant.

I think it's more charitable (or rather, it possibly expresses the
intent behind the quoted text more accurately or objectively) to
rephrase "ignorance on Guido's part" and "Guido... was unaware of" with
"Guido's deliberate design decisions upon considering previous work on
dynamic language runtime implementation" and "Guido chose to disregard
strategies illustrating" respectively. Not that I actually profess to
know what Guido's knowledge of the field was in the late 1980s or what
he actually knows right now beyond what he has said in various articles
and interviews.
(but since you keep repeating this nonsense, it's clear that you're
pretty ignorant wrt. software design. too much CS exposure?).

Unfortunate choices of words notwithstanding, I think the contributor
in question raises interesting issues at a level way above this kind of
response. Not that I actually profess to know what his level of "CS
exposure" is beyond a brief perusal of his Google Groups profile, but I
don't see how that really comes into play here, apart from as a
convenient put-down label.

Paul

[Carl Friedrich Bolz]

Torsten Bronger wrote:

Well, I think that it's fair to say that there are by principle deep
run time differences between CPython and, say, a typical
C++-compiled program. Your definition would not reproduce that. I
think it's also fair to say that these differences should be known
if somebody tries to find the best tool for a job. After all, they
include advantages, too.

My definiton would be that an interpreted language has in its
typical implementation an interpreting layer necessary for typical
hardware. Of couse, now we could discuss what is "typical",
however, in practice one would know it, I think. In case of Python:
CPython and all important modern processors.

Well, if we take any modern Intel/AMD chip (which could be described as
"typical), a C++ program would fit the "interpreted" definition, since
the processor does not execute the machine code directly but rather
breaks it down into smaller microcode instruction -- a process that
could be described as intepretation.

Another problem with the definition: what would you call a C++ program
that is running on top of an emulator? Does a language become
interpreted just by running the program on top of an emulator? Why is
the python interpreter different from an emulator in this respect? I
think that the disctinction between "interpreted" and "compiled"
(whatever both means) is really just not sensible at all.

Cheers,

Carl Friedrich

[Kay Schluehr]

> What's far more interesting to me, however, is that I think there a good

reasons to suspect python's slowness is more of a feature than a flaw: I'd not
be suprised if on the whole it greatly increases programmer productivity and
results in clearer and more uniform code.

Yes, it's Guidos master-plan to lock programmers into a slow language
in order to dominate them for decades. Do you also believe that Al
Quaida is a phantom organization of the CIA founded by neocons in the
early '90s who planned to invade Iraq?

Kay