Python's biggest compromises

**Christopher Koppler** · Jul 18 '05, 01:10 AM

Re: Python's biggest compromises

On 31 Jul 2003 06:55:52 -0700, anthony_barker@ hotmail.com
(Anthony_Barker ) wrote:
[color=blue]
>I have been reading a book about the evolution of the Basic
>programming language. The author states that Basic - particularly
>Microsoft's version is full of compromises which crept in along the
>language's 30+ year evolution.
>
>What to you think python largest compromises are?
>[/color]
[snip whitespace, dynamic typing, interpreted]

I don't see those as compromises, but mostly as assets.

Significant whitespace (you probably mean significant indentation -
whitespace isn't more or less significant in Python than in other
modern languages) I have only experienced as a boost in readability,
clarity and, most of all, consistence; and there's no possibility of
'brace style wars'.

Dynamic typing vs. static typing has already long ago reached the
status of holy war, so I'll decline to comment.

That python is not (yet) compiled, is mostly a non-issue (and if PyPy
is a success, it won't even be that). If it was just about
performance, then coding the really performance-intensive parts in C
should suffice, apart from kernel hacking and similar . In my
experience, the decision to convert a (successfully functioning)
project from 'a scripting language' to C/C++/Java has always been a
political one, and not really based on technical considerations.

That said, the only large compromise in Python language design I can
detect, is the decision to be quite strictly backwards-compatible
between versions, which is definitely not a bad thing, as long as the
language doesn't go baroque because of it. And Python 3.0 will
hopefully throw out any accumulated cruft.

--Christopher

**Edward K. Ream** · Jul 18 '05, 01:10 AM

Re: Python's biggest compromises

> What to you think python largest compromises are?

There aren't any.

You want to base significant projects on the highest level, most dynamic
tools available (Python), then use Python as a wrapper to hide static
inflexibilities and inferiorities when descending to lower levels for
whatever (usually spurious) reasons. For example, there is a huge
difference between using wxWindows and wxPython, but the performance
difference between wxWindows and wxPython is insignificant.

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo@chart er.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

**Bruno Desthuilliers** · Jul 18 '05, 01:10 AM

Re: Python's biggest compromises

Anthony_Barker wrote:
(snip)
[color=blue]
>
> What to you think python largest compromises are?
>
> The three that come to my mind are significant whitespace, dynamic
> typing, and that it is interpreted - not compiled.[/color]

IMHO these are not compromises, but features.

Bruno

**Robin Becker** · Jul 18 '05, 01:10 AM

Re: Python's biggest compromises

In article <viibo7t45unv83 @news.supernews .com>, John Roth
<newsgroups@jhr othjr.com> writes[color=blue]
>[/color]
......[color=blue]
>High performance isn't Python's target. If PyPy ever gets their act
>off the ground, then we will have a shot at a good quality JIT
>interpreter. Then watch it fly.
>[/color]
..... doesn't psyco already attempt to do JIT? It certainly doesn't
speed things up that much. If all the variables are known to be of a
specific type then you could expect C like speeds from a good JIT, but
without global analysis it's hard to see how we infer/guarantee python
types.[color=blue]
>
>John Roth
>
>[color=green]
>>
>> Anthony
>> http://xminc.com/anthony[/color]
>
>[/color]

--
Robin Becker

**John J. Lee** · Jul 18 '05, 01:10 AM

Re: Python's biggest compromises

"John Roth" <newsgroups@jhr othjr.com> writes:
[...][color=blue]
> That said, I've come to the conclusion that the editor should take
> care of these things for you. If you prefer a brace free notation,
> you should be able to tell your editor to present the program to you
> that way. If you prefer braces, then it should be able do that for
> you as well. That kind of stylistic thing doesn't belong in the
> language.[/color]

100% agreed: once-and-only-once dictates this. Manually maintaining
both braces and indentation (as in C, with some editors) is Just Plain
Bad for this reason.

[color=blue]
> In fact, if I didn't have to deal with the braces, I think I'd come
> around to the view that the text should have them. Explicit is
> better than implicit,[/color]

At least in the absence of proper research results, I think this part
of it *is* religious. To some people, it's obvious that whitespace is
better on the eyes. To others, it's obvious that whitespace + braces
is better on the eyes. One group may well be wrong <0.5 wink>.

This argument (that braces are another visual cue which make code
easier to read -- provided that they're automatically maintained in
sync with the indentation), is the only argument against
pure-whitespace that has ever made any sense to me. Irrespective of
whether you pick whitespace or braces as the thing the compiler takes
notice of, though, the optimal solution probably still involves an
editor that supports showing/hiding braces, so the syntax is
(theoretically! ) a non-issue. In practice, editors don't seem to
currently support showing and hiding braces automatically. At least
editors do get you out of most mistakes caused by brace-y languages.

Of course, whitespace *is* still superior because the storage format
doesn't duplicate state -- so people with poor editors can't produce
ambiguous code :-) (remember code can be ambiguous to *people* even if
it isn't to a compiler). OTOH, *Python's* scheme is inferior to a
pure-space-character indentation scheme because off the tab-vs.-space
issue :-(

[color=blue]
> and there are a few things that the
> automatic indentation makes rather difficult in the design area.[/color]
[...]

What are those things??

John

**Mark VandeWettering** · Jul 18 '05, 01:10 AM

Re: Python's biggest compromises

In article <899f842.030731 0555.56134f71@p osting.google.c om>,
Anthony_Barker wrote:
[color=blue]
> I have been reading a book about the evolution of the Basic
> programming language. The author states that Basic - particularly
> Microsoft's version is full of compromises which crept in along the
> language's 30+ year evolution.
>
> What to you think python largest compromises are?
>
> The three that come to my mind are significant whitespace, dynamic
> typing, and that it is interpreted - not compiled. These three put
> python under fire and cause some large projects to move off python or
> relegate it to prototyping.[/color]

I don't view any of these as "compromise s". That word suggests that
something was conceded, or that an intermediate position between two
extremes was chosen to appease. I don't think that either sense really
applies to these features.

The three items that you listed are merely design choices. While arguments
over them are continuous, two of the design choices (interpreter, dynamic
typing) are consistent with Python's intended use as a language which
excels at rapid prototyping. The third (white space) is merely a stylistic
choice which is designed to encourage readable programs.

"Compromise s" in language design occur usually when a committee tries to
standardize a language, and each has differing views about how the language
should be used. While this occurs somewhat in Python, other languages
have suffered more mightily from this particular disorder.

Mark
[color=blue]
> Anthony
> http://xminc.com/anthony[/color]

**Aaron Leung** · Jul 18 '05, 01:10 AM

Re: Python's biggest compromises

It seems to me that a big compromise/feature is that all kinds of
namespaces are usually represented by dictionaries, and that Python
exposes this fact to the programmer. This would seem to limit the
possible optimizations that can easily be performed by a compiler.

BTW, I have only read about Python out of interest, and haven't
actually used it for anything, so I hope my remark isn't ignorant.

Best regards,
Aaron

**Terry Reedy** · Jul 18 '05, 01:10 AM

Re: Python's biggest compromises

"Anthony_Barker " <anthony_barker @hotmail.com> wrote in message
news:899f842.03 07310555.56134f 71@posting.goog le.com...[color=blue]
> What to you think python largest compromises are?[/color]

A compromise is an in-between position or decision. Example: wife
wants to go to a horse show, husband to an auto race, so they
compromise and go to a horse race.
[color=blue]
> The three that come to my mind are significant whitespace, dynamic
> typing, and that it is interpreted - not compiled.[/color]

The first two are end-point positions, not in-between compromises.
The third is a matter of definition and implementation. CPython
compiles to version-dependent but otherwise portable PyCode. PyRex,
Weave, and Psyco all compile to C or machine code.
[color=blue]
> These three put python under fire[/color]

Anything can bo put under fire by anyone who wants to shoot.
[color=blue]
> and cause some large projects to move off python or[/color]

This sort of statement remains an opinion or impression until backed
by evidence.
[color=blue]
> relegate it to prototyping.[/color]

This is one of its intended uses.
[color=blue]
> Whitespace is an esthetic preference that make Andrew Hunt and David
> Thomas (of Pragmatic Programmer fame) prefer Ruby.[/color]

Evidence? And I mean evidence that whitespace is *the* reason and not
just a convenient summary of an overall esthetic preference.

In any case, so what? Different strokes for different folks. Do they
also use indentation for human readers? If so, they have assigned
themselves the task of keeping brackets and indents in sync so that
human and machine 'see' the same structure.

I see two good uses for brackets:
1. machine-generated code never intended for human eyes
2. redundancy for transmission error detection by a processor that
compares brackets and indents and raises a flag on mismatches.

A compromise in the area of structure indication would be accepting
either brackets or indents or both.
[color=blue]
> Yahoo groups moved from python to C due to dynamic typing.[/color]

Evidence? Evidence as to what exactly happened (it is not common
knowledge that I know of) and that any such change was a reasoned
technical decision and not politics.

If memory serves me right, Guido has tried a couple of compromises to
slightly limit dynamicity that he could not see much use for and has
backed off at least partly when current users presented use cases that
the change would break.
[color=blue]
> Non-compiled - obviously there are times when performance matters[/color]
more[color=blue]
> than other things. Google I believe uses python to prototype (or[/color]
used)[color=blue]
> and then turns to c++ for heavy lifting.[/color]

This is a simple matter of economic tradeoff. A week of programmer
time costs roughly the same as, say, a year of pc time. A roaring
success like Google has hundreds (thousands?) of servers around the
world running the same relatively stable code. Faster code means
machines not bought, installed, and maintained. But I imagine that
their main production code is pretty far out on the frequency-of-use
curve.

Terry J. Reedy

**Skip Montanaro** · Jul 18 '05, 01:10 AM

Re: Python's biggest compromises

Anthony> What to you think python largest compromises are?

Anthony> The three that come to my mind are significant whitespace,
Anthony> dynamic typing, and that it is interpreted - not compiled.
Anthony> These three put python under fire and cause some large projects
Anthony> to move off python or relegate it to prototyping.

Your message is sure to get the pot boiling. I don't think of any of the
above as compromises. They were all design decisions. Considering the
whitespace issue, calling it a compromise suggests that Guido had to cave in
to some outside forces. He couldn't decide between BEGIN/END or {/} as
block delimiters, so he chose significant whitespace. It doesn't make
sense.

Anthony> What about immutable strings? I'm not sure I understand Guido's
Anthony> preference for them.

Performance is one reason. The Python interpreter creates a huge number of
strings at runtime. Knowing exactly how long the string is going to be and
that it will not grow means that a single malloc can be used to allocate the
object header and the storage for the data. If strings were mutable, the
structure of the string object storage would probably be much different and
you'd need at minimum two mallocs per string, one for the object header and
one for the data itself.

Skip

**Ian Bicking** · Jul 18 '05, 01:10 AM

Re: Python's biggest compromises

On Thu, 2003-07-31 at 08:55, Anthony_Barker wrote:[color=blue]
> The three that come to my mind are significant whitespace, dynamic
> typing, and that it is interpreted - not compiled. These three put
> python under fire and cause some large projects to move off python or
> relegate it to prototyping.[/color]

I think these are valid as "compromise s", not to be confused with
flaws. These are all explicit choices, and ones for which the original
justifications remain valid. A lot of stuff in Basic is simply flaws,
or based on justifications that no longer apply to today's programming
world.

Anyway, I might add mine: the nature of modules as executed code is a
compromise. That is, a module isn't a declaration, it's a program to be
executed in its own namespace. When you import a module, you are
executing the module then looking at the namespace.

There are some advantages to this, particularly in the transparency of
the implementation -- things don't always work the way you might want
(e.g., circular imports), but it's usually not that hard to understand
why (and often the way you want things to work has nasty gotchas that
you wouldn't have thought of). It also opens up a lot of possibilities
for dynamicism in class and function declaration, like doing this in the
top level:

if something:
def func(x): ...
else:
def func(x): ...

But it's a compromise, because it makes things more difficult as well.
It's a *big* problem in any long-running process, where you may want to
modify code underlying the system without rebuilding the entire state.
Classes aren't declared, they are simply constructed, so by reloading a
module all the persistent instances still exist and refer to the defunct
class. You can modify classes at runtime, but this is different from
simply rerunning the class definition. (A clever metaclass *could* make
those equivalent, though... hmmm...)

A related problem is that Python objects generally can accept any
instance variable names, and names are not declared anywhere. Again,
this makes it difficult to deal with long-lived objects. If you change
the class so that all instances get a new attribute, old objects won't
be updated. I'm thinking about both of these things in terms of
Smalltalk, where they make tools possible that really add to the ease of
developing in its environment.

Not that I don't like the fun tricks Python lets you do. Prototype-like
programming (as in Self) is very accessible in Python, and classes are
only a suggestion not a dominant concept. So, it's a compromise.

There are lots and lots of compromises in Python -- every aspect has
pluses and minuses to it. Personally I like whitespace sensitivity well
enough, but in the larger sense I think it probably was the wrong choice
-- but that's based on how I weigh various benefits and problems, and
other people will validly weigh them differently.

Ian

**John Roth** · Jul 18 '05, 01:11 AM

Re: Python's biggest compromises

"Robin Becker" <robin@jessikat .fsnet.co.uk> wrote in message
news:TBO13LAmBV K$Ewml@jessikat .fsnet.co.uk...[color=blue]
> In article <viibo7t45unv83 @news.supernews .com>, John Roth
> <newsgroups@jhr othjr.com> writes[color=green]
> >[/color]
> .....[color=green]
> >High performance isn't Python's target. If PyPy ever gets their act
> >off the ground, then we will have a shot at a good quality JIT
> >interpreter. Then watch it fly.
> >[/color]
> .... doesn't psyco already attempt to do JIT? It certainly doesn't
> speed things up that much. If all the variables are known to be of a
> specific type then you could expect C like speeds from a good JIT, but
> without global analysis it's hard to see how we infer/guarantee python
> types.[/color]

Well, that's certainly a problem, but Bicycle Repair Man seems to
do a pretty good job of type inference, at least for refactoring.

One of the things to consider here is that a decent JIT interpreter
would automatically change the playing field for what is good
practice and what isn't, at least if you expect performance.

John Roth[color=blue]
> --
> Robin Becker[/color]

**Ian Bicking** · Jul 18 '05, 01:11 AM

Re: Python's biggest compromises

On Thu, 2003-07-31 at 16:27, John Roth wrote:[color=blue]
> "Robin Becker" <robin@jessikat .fsnet.co.uk> wrote in message
> news:TBO13LAmBV K$Ewml@jessikat .fsnet.co.uk...[color=green]
> > In article <viibo7t45unv83 @news.supernews .com>, John Roth
> > <newsgroups@jhr othjr.com> writes[color=darkred]
> > >[/color]
> > .....[color=darkred]
> > >High performance isn't Python's target. If PyPy ever gets their act
> > >off the ground, then we will have a shot at a good quality JIT
> > >interpreter. Then watch it fly.
> > >[/color]
> > .... doesn't psyco already attempt to do JIT? It certainly doesn't
> > speed things up that much. If all the variables are known to be of a
> > specific type then you could expect C like speeds from a good JIT, but
> > without global analysis it's hard to see how we infer/guarantee python
> > types.[/color]
>
> Well, that's certainly a problem, but Bicycle Repair Man seems to
> do a pretty good job of type inference, at least for refactoring.[/color]

And Java's JIT is based on (at least originally) work done on Self,
which had to do type inference. And actually in many circumstances Java
requires type inference, because you can substitute in an instance of a
subclass.

Anyway, JIT is all about runtime analysis -- if you could infer types
completely before running the program, you would just put in the
optimizations statically (i.e., compiling optimizations). JIT does
those optimizations at runtime by definition.

And Bicycle Repair Man is inspired by the Refactoring Browser, an IDE
tool based on another dynamic language (Smalltalk), not on a tool from a
static language (like Java).

Ian

**Hannu Kankaanpää** · Jul 18 '05, 01:11 AM

Re: Python's biggest compromises

anthony_barker@ hotmail.com (Anthony_Barker ) wrote in message news:<899f842.0 307310555.56134 f71@posting.goo gle.com>...[color=blue]
> What to you think python largest compromises are?[/color]

I think reference counting is. Added to this the fact that
garbage collection is also possible (as in Jython). So we get
the worst of both worlds.

1. Idioms like this won't work portably:

def foo():
f = file('x')
return f.read()

Even though f.__del__ closes the file, in garbage
collected environment the f object might not get deleted
in a good while, and would cause problems.

2. And then, we still need to use weakref to ensure
that our crossreferenced stuff works both with and without GC.

Worst of both indeed. Maybe the decision to choose reference
counting was driven by speed considerations. That might've
been reasonable back in early 90's, but GC techniques have
evolved from those days and so GC would be a superior
technique now.

Well, since no one else pointed this out yet, maybe there's
some flaw in my reasoning.

**Andrew Dalke** · Jul 18 '05, 01:11 AM

Re: Python's biggest compromises

Dennis Lee Bieber:[color=blue]
> Whereas BASIC started life as an interpreted language wherein[/color]
every[color=blue]
> statement had a line number, conditionals (IF) did jumps to line
> numbers, and all variables were global (even across subroutine calls).[/color]

Not interpreted.
See http://wombat.doc.ic.ac.uk/foldoc/fo...artmouth+BASIC
] Dartmouth BASIC
] <language> The original BASIC language [...] Unlike most later
] BASIC dialects, Dartmouth BASIC was compiled

or a more detailed description at http://www.kbasic.org/1/history.php3
which says the first interpreted BASIC was the Micro-Soft one for
the Altair.

In more seriousness, compiled v. interpreted is an implementation
detail which has very little impact on the language. The other examples
you gave are more relevant.

One thing to consider is - what's the *compromise* in the different
versions of BASIC? That is, how was the support for backwards-
compatible operations in BASIC (which you list as a compromise)
any different than Python's backwards compatibility support?

Andrew
dalke@dalkescie ntific.com

Python's biggest compromises

Python's biggest compromises

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment