Why I love python.

[Dave Brueck]

Yes, the majority of development goes on little *glue programs* that
take data from a database, and format is as XML/HTML, or aggregate and
analyze data stored in a database, and stuff like that. But for all
these to be possible a massive amount of *infrastructure* is
required. And this infrastructure cannot be created in Python. So you
don't say that Python isn't a glue language, but that the greatest
percentage of development that currently goes-on *is* glue-stuff
development

Well, at my current company we've implemented web and file servers,
cache log parsers, web applications, Windows desktop applications,
Windows COM objects including web browser plugins, video splicers, and a
host of tools, all in Python. These aren't "little glue programs" - they
are just programs; normal programs we'd have to write in _some_ language
and Python turned out to be the best fit. What's more, a whole heck of a
lot of the functionality implemented in Python would most definitely
fall under the category of infrastructure, not glue.

Put yourself in this position: Its a few years ago (say 1998 or 1999),
and no graphical web-browser exists for Linux. You are planning to
develop the "iso-standard" web-browser for this operating
system. Would you do it in Python? Remember that no HTML parsers
exist, no decent HTML renderers, the GUI toolkit is more or less
primitive, and the low-end desktops runs at about 200-something
MHz. You might argue "this is not the case today", but how can you
preclude that *similar* challenges do not occur today, or will not
occur in the future?

This is so far removed from what I'm trying to say that I don't even
know how to respond. I'm not arguing that at all.

2004 again, and you decide to scrap and replace the age-old X11 window
system; do away with it and start from scratch. Build a moder
windowing system; 3D all over, fully network transparent, with widget
support on the server-side, fully object oriented interface, and so
on. How much of it would you be able to code in Python?

Python is not the right tool for every job. There do exist cases where
more performance is required than can be delivered.

Having said that, the cases where it is too slow make up a small (and
shrinking) portion of the total amount of development going on. As such,
better performance is always welcome, but it won't benefit as many
people and as much as other things can. IOW, anytime you say, "wouldn't
it be great if Python were faster?" you can easily get everybody to
respond, "sure!" - everybody's on board with you there. It's when you
try to fit it into the list of priorities that you'll find that there
are other things higher on the list. Higher because they provide more
benefit overall and/or to the people who are interesting in helping out.

To your specific question, I actually _would_ use Python for most of an
X11 replacement system. Obviously low-level stuff would be handled by
one of the existing 3D libraries out there (no need to reinvent the
wheel there - the goal is to build a better window system, and we'd want
a good hardware abstraction lay). I've seen a few proof-of-concepts with
Pygame that lead me to believe that it's doable - their performance is
already better than X11's performance for the first decade or so of its
existence.

> How much *more* would you rather be able to code in Python?

You can't consider the benefit in isolation. You have to take into
account the costs involved.

-Dave

 

[Terry Reedy]

someone once said python is runable pseudocode.

or 'executable pseudocode' (which I originally misspelled :-( )

http://groups.google.com/[email protected]

Terry J. Reedy

 

[Miklós]

There is an amazing article by paul graham about python, and an even
better discussion about it on slashdot. The reason I point this out,
is the more I read both articles, the more I realised how we would be
mutilating the language with that god forsaken @ decorator.
I don't know about the rest of you, but I learned python and fell in
love with its syntax and simplicity. Python - just works. So please
GVR. Don't complicate it. Leave it as is. Work on making it faster,
not uglier. Work on - in some cases - better algorithms for certain
modules, not for it to even closely resemble C or perl or god knows
whateverotherlanguagethereisoutthere. Am i the only one with a
visceral reaction to this thing???

This was precisely the motive behind my starting the thread "Going the PL1/1
way"
I also worry about Python's healthy simplicity.

Best regards,
Miklós

paul Graham article: http://www.paulgraham.com/pypar.html

Slashdot discussion:

http://developers.slashdot.org/developers/04/08/12/1721239.shtml?tid=156&tid
=218

 

[Nick Patavalis]

Having said that, the cases where it is too slow make up a small
(and shrinking) portion of the total amount of development going
on. As such, better performance is always welcome, but it won't
benefit as many people and as much as other things can. IOW, anytime
you say, "wouldn't it be great if Python were faster?" you can
easily get everybody to respond, "sure!" - everybody's on board with
you there. It's when you try to fit it into the list of priorities
that you'll find that there are other things higher on the
list. Higher because they provide more benefit overall and/or to the
people who are interesting in helping out

I believe there is no point to continue our little "fight", or we risk
becoming repetive and boring. Our arguments have, I think, become
clear, and only time will tell who was right and who was wrong; if
after-all the is a "right" and a "wrong" side in this argument.

So lets drop it here, and wish the best for the language we both enjoy
programming in.

/npat

 

[Daniel Yoo]

:> Python needs drastic performance improvement if it is to scrap-off the
:> "scripting language" stigma. The only way to get these improvements is
:> making it possible for a python implementation to produce *efficient*
:> *compiled* code. At the same time the dynamic-typing nature of the
:> language is one of its most valuable characteristics. And this is one
:> of the hardest problems when trying to write a decent python
:> compiler. If you define a function like:
:>
:> def sum (a, b):
:> return a + b
:>
:> How can the compiler know what code to produce?

: I know of at least one language which has solved this problem, Ocaml


I'm not quite sure if this is true. In contrast to Python, a lot of
the type information in OCaml is attached to the operators. This is
to make the type-inferencing work efficiently. For example, OCaml's
addition operator is hardcoded to work with integers:

(******)
[dyoo@shoebox dyoo]$ ocaml
Objective Caml version 3.07+2

# (+) ;;
- : int -> int -> int = <fun>
(******)



and there's a separate operator for adding floats to floats:

(*** OCaml ***)
# ( +. );;
- : float -> float -> float = <fun>
(******)



Python's dynamic lookup of module-level symbols also make things more
difficult than in Ocaml. In OCaml, names that are bound stay bound:

(*** OCaml ***)
# let x = 42;;
# let say_x () = print_endline (string_of_int x);;
val say_x : unit -> unit = <fun>
# say_x ();;
42
- : unit = ()
# let x = "hello";;
val x : string = "hello"
# say_x ();;
42
- : unit = ()
(******)


Note, again, that the OCaml operators and functions are often
themselves typed to make type-inference work. This may make things
slightly verbose again. I could be wrong, but I couldn't find a
simple, generic, "print" function that could print any value in OCaml.


In this example, the say_x function keeps a record of all the name
bindings from before, which is why it remembers the original binding
for 'x'. This is just fundamentally different from the "late binding"
approach using in Python:

### Python ###.... print x
....hello
###


So I'm not so sure that Python's current design makes type-inference
easy. I'm pretty sure it's a little harder than just yanking out
OCaml's type-inference engine and jury-rigging it into Python. *grin*

 

[Paul Rubin]

If you define a function like:

def sum (a, b):
return a + b

How can the compiler know what code to produce? It could trace all the
applications of sum(), and decide what types of arguments sum() is
actually applied on. But this is not easy, and sometimes it is
straight-out impossible.

Compilers for languages like Lisp and Smaltalk have dealt with this
for decades. They can either generate code that switches on the type
tags, or have dispatch tables in the objects that point to code for
operations like "+", or take advice or declarations from the
programmer about the arg types, among other possibilities. Any of
these approaches generates code that runs much faster than interpreted code.

 

[Nick Patavalis]

Compilers for languages like Lisp and Smaltalk have dealt with this
for decades. They can either generate code that switches on the type
tags, or have dispatch tables in the objects that point to code for
operations like "+", or take advice or declarations from the
programmer about the arg types, among other possibilities. Any of
these approaches generates code that runs much faster than
interpreted code.

Yes, I know. Something like this was what I was thinking about. I
would really love to see this technology brought to Python, or at
least a discussion as to what additions would be required in the
*language* in order for similar technologies to be easily applicable
to future Pythonic environments.

/npat

 

[510046470588-0001]

Yes, I know. Something like this was what I was thinking about. I
would really love to see this technology brought to Python, or at
least a discussion as to what additions would be required in the
*language* in order for similar technologies to be easily applicable
to future Pythonic environments.

those compilers are totally unflexible,
as they can't deal with data types and function code supplied at run time,
and they cache too much information, causing bloat of the ram.

Klaus Schilling