Python's biggest compromises

[John Roth]

What are these quirks? By far the most common I've seen is mixing tabs and
spaces, but this should be relatively easily solved by requiring one or the
other (minus continuation lines, which are still a problem). Using spaces
has some disadvantages too, since not everyone will use the same number of
spaces, and editors don't behave as nicely. I like when you hit the arrow
key at a tab, and it jumps the full tab, rather than having to press an
arrow key 4 times.

I'm used to a certain minimum standard from my editors, and smart
tabs are one of those things that's part of the price of admission these
days, just like syntax highlighting. A programming editor's job is to help
where it's useful, and get out of the way when it's not. When you want
to indent, you hit the tab button. It's the editor's job to know I want,
for example, four spaces, and deliver them. In Python, it's the editor's
job to know that when I hit return at the end of a line, there are only one
or two legitimate places to put the cursor on the next line, and to put
it in the most likely of them.

As to the different number of spaces between developers, that's
another thing I'd expect from my editors. It's easy enough in Python
to figure out what's an indent and infer the number of spaces. I'd
expect a decent editor to be able to load a program and tell me
what the indentation policy was! I'd also expect to be able to tell
it to change it, and have it automatically reindent the program for
me.

John Roth

 

[John Roth]

Because there is no 'official' meanings, despite claims to the
contrary, some software like Outlook Express ignores them on receipt.

<flameshield on> tjr

You can always blame that on Micro$haft. However, it does
make e-mailing a program indented with tabs something of an
adventure.

John Roth

 

[Ben Finney]

OK, then unless I'm missing something, tabs vs. spaces shouldn't
matter for you. The editor should be able to handle tabs in a
satisfactory manner as well.

Not if spaces *and* tabs are used for indentation within the one file.
Without editor-specific hacks (the "vim:" comment line, the Emacs mode
line, etc.) there's no way to know what size the previous person's
editor had tab stops set to. The standard size of a tab stop is 8, but
many programmers change this in their editors, resulting in indentation
that gets completely messed up when the tabs are shown at 8 columns
against other lines in the same file that use spaces for indentation.

 

[Andrew Dalke]

Andy C:

OK, then unless I'm missing something, tabs vs. spaces shouldn't matter for
you. The editor should be able to handle tabs in a satisfactory manner as
well.

python-mode for Emacs is an example of how to support different
styles of tab/space uses.

But code goes through other tools. Suppose you only use tabs
and you have your editor set for 2 character tabs. Now print
your code. It'll look different because your printer is likely set
for 8 character tabs.

Some people like writing code like this

if ((this_is_a_value > that_long_variable) or
(this_is_a_value == something_else):
....

that is, align terms of an expression vertically to emphasize
similarities between the lines. Were the second line done in
tabs then differing tab styles would change the alignment,
which ruins the intent. And different tools do have different
tab styles.

Just Use Spaces.

Andrew
(e-mail address removed)

 

[Andrew Dalke]

Terry Reedy:

Because there is no 'official' meanings, despite claims to the
contrary, some software like Outlook Express ignores them on receipt.

I sent email to a friend of mine. It contained a copy&paste from
the interactive prompt. Something like

Something on his side (either Exchange or OE, dropped
the "... pass" part of what I sent.

Andrew
(e-mail address removed)

 

[Dennis Lee Bieber]

Andrew Dalke fed this fish to the penguins on Friday 01 August 2003
01:22 am:

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.

I'd swear that the BASIC I learned on -- via a timeshare
Honeywell-Bull using a dial-up from an ASR-33 -- back in 1972 was
interpreted... At the least, we had no seperate compile/link/run
phase... We'd invoke BASIC, enter the source, and type RUN.

My college mainframe (Xerox Sigma 6) also had an interpreted BASIC,
and I can't believe that was created for the machine way down in the
late 70s -- when the hardware dates to the late 60s...

I'll concede that those may have been "compile on <ret>", wherein each
statement was compiled, but statement labels (and branching thereby)
was interpreted (look up in a table to get a pointer to the actual
code).

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?

Python's compatibility doesn't /feel/ like a different language;
through all the changes in Python, a Python 1.3 program /looks/ like a
Python 2.2+ program.

But between early 70s BASIC and what passes for BASIC today looks like
totally different languages. Not even FORTRAN underwent that great a
/visual/ change between (say) FORTRAN IV (aka FORTRAN 66) and FORTRAN
77 (essentially adding block IF constructs) and then Fortran 90 -- yes,
the packaging of modules, dynamic allocation, and new line continuation
do make it a different language... but it /still/ LOOKS like FORTRAN on
quick glance... Let a non-programmer look at source files from K&K
type BASIC, Visual BASIC, F-IV, F77, and F90... and he likely will be
able to identify the three Fortrans as being related -- but would not
consider K&K to be a relation of VB.


Then again, I consider Java (and now .NET) to be nothing more than a
reinvention of the UCSD P-Code Pascal system...

Andrew
(e-mail address removed)

--

 

[Dennis Lee Bieber]

Daniel Dittmar fed this fish to the penguins on Friday 01 August 2003
06:09 am:

see also: DOS sucks, let's use an operating system instead.

WHICH "DOS"... I have source code listings for something called
"K2FDOS"... Along with the source code volumes for LS-DOS. <G>

Now, if you mean MS-DOS... YES. LS-DOS (later licensed as TRSDOS 6)
had features that barely made it into MS-DOS v2. I distinctly recall
laughing in surprised shock when Dr. Dobbs boasted about MS-DOS having
"user installable device drivers" (and what later came to be called
TSRs); LS-DOS 5! had those features at least a year earlier, on an
8-bit OS. It also had a "compiled" JCL, ability to not only redirect
I/O but link I/O -- letting one use a serial port as in/out while still
using the keyboard/display for the /same/ channels, ability for a Job
Log -- tracking commands and errors messages, and a 7-level password
protection scheme (originally every file had two passwords, user and
owner, and the user password was linked to a privilege level --even
knowing the user password might only give you execute-only access to a
file. When updated to handle dates outside 1980-1987, the user password
was dropped -- effectively given all files a "blank" user password. The
owner password was needed to assign a user privilege level to the file)
[no fear of the secretary deleting the word processor executable if it
were set to execute-only].

--

 

[Andrew Dalke]

Dennis Lee Bieber:

I'd swear that the BASIC I learned on -- via a timeshare
Honeywell-Bull using a dial-up from an ASR-33 -- back in 1972 was
interpreted...

Well, my background is all microcomputer basics in the 80s, including
some (very little) HP BASIC for lab equipment, so I'm not a good
judge. Were I to implement a compiled BASIC I would have done
the "compile on <ret>" you suggested. One of the links described the
Dartmouth BASIC commands and they would be easy to implement
that way.

Python's compatibility doesn't /feel/ like a different language;
through all the changes in Python, a Python 1.3 program /looks/ like a
Python 2.2+ program.

In playing around with some of the new Python 2.3 features, I noticed
myself using a more functional style, like

d = {"A": 1, "B": 9", ...} # all uppercase keys
d.update(dict([(k.lower(), v) for k, v in d.items()]))

instead of the more readable and faster

for k, v in d.items():
d[k.lower] = v

It's easier in Python 2.2+ to make Python code which doesn't
look like Python 1.3. Which I think is the version I started with.

When I got QuickBasic in 1988 or so, it would run just about
all of my old GW-BASIC programs, which was distributed some
5 years previous. But it's true, the GW-BASIC program wouldn't
look like a QB program.

Thinking some more ... the 1.3 code would have string
exceptions, so that's one age indicator. It would use the
"while 1 / readline / if not line / break" idiom instead of the
more modern 'for line in file'. It didn't have module support,
IIRC, and only the regex module for regular expressions.
Ahh, and no string methods. That's very noticible when I
look at pre-2.0 code.

Okay, so the two main things that would make a 1.3-style
code stick out is using string.* and raising string exceptions.
In other words, I mostly agree with you, but couldn't let
you get a complete bye

But between early 70s BASIC and what passes for BASIC today looks like
totally different languages.

I stopped about 10 years ago. I do recall reading an article by
a VB book author saying VB_(N+1) was too different from VB(N)
and the differences were driven by marketing and not for good
programming reasons.

There's also the TrueBASIC folks. I believe they started in the
mid-80s and argue their BASIC is essentially the same.

quick glance... Let a non-programmer look at source files from K&K
type BASIC, Visual BASIC, F-IV, F77, and F90... and he likely will be
able to identify the three Fortrans as being related -- but would not
consider K&K to be a relation of VB.

Interesting test. Nasty idea: get that same person to judge if
Lisp and Scheme are closely related then post the results on c.l.lisp.

Andrew
(e-mail address removed)

 

[Lulu of the Lotus-Eaters]

|But a lot of Python code depends on reference counting or more exactly it
|depends on the timely call of the destructor. So even if a much better GC is
|added to Python, reference counting would perhaps be kept for backwards
|compatibility (see Python's biggest compromises)

Did this thread get caught in a time warp, and posts from two years ago
get posted again. Exactly this all happened years ago.

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------

 

[Lulu of the Lotus-Eaters]

|But a lot of Python code depends on reference counting or more exactly it
|depends on the timely call of the destructor. So even if a much better GC is
|added to Python, reference counting would perhaps be kept for backwards
|compatibility (see Python's biggest compromises)

Did this thread get caught in a time warp, and posts from two years ago
get posted again. Exactly this all happened years ago.

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------

 

[Dennis Lee Bieber]

Andrew Dalke fed this fish to the penguins on Saturday 02 August 2003
11:09 pm:

There's also the TrueBASIC folks. I believe they started in the
mid-80s and argue their BASIC is essentially the same.

Unless I'm mistaken, the folks behind TrueBASIC /were/ Kemeny and

Interesting test. Nasty idea: get that same person to judge if
Lisp and Scheme are closely related then post the results on c.l.lisp.

Heh... Toss in MPI (the only expansion I've seen for that is "my
personal insanity" -- it's similar except for using {, :, and ,! Been
way too long since I've done any MUCKing but... it was easier to learn
than MUF, which I never could get into even though I used to program HP
calculators).

--

 

[Andrew Dalke]

Dennis Lee Bieber:

Unless I'm mistaken, the folks behind TrueBASIC /were/ Kemeny and
Kurtz (spellings)... IE, the creators of the original BASIC. <G>

Yup. From truebasic.com
] John G. Kemeny and Thomas E. Kurtz invented BASIC in 1964
] for use at Dartmouth College. They made it freely available to
] everyone who wanted to learn how to program computers. It
] soon became a world standard.
]
] In 1983 they created True BASIC to incorporate and showcase
] all the advanced developments they had added to their language,
] and offered it as a commercial product.

But that doesn't implement the original BASIC language. OTOH,
it does say it can convert older BASIC to TrueBASIC, so there
is still backwards compatibility. That's gotta warm someone's heart
knowing code written back in the 1960s on a teletype machine
will still run today.. and even on a handheld.

Andrew
(e-mail address removed)

 

[Alex Martelli]

OK, then unless I'm missing something, tabs vs. spaces shouldn't matter
for
you. The editor should be able to handle tabs in a satisfactory manner as
well.

There seems to be an unspoken assumption here that an editor is the only
program that will need to deal with Python code I receive. It isn't --
mail and news readers, for example, are often involved -- and those often
can't deal satisfactorily with tabs. Thus, it should be the job of the
editor of the person who PRODUCES code (if said code is to be sent outside
at all) to store spaces, not tabs.


Alex

 

[Michael Hudson]

You apparently have such a loose definition for garbage
collection, that even C programs have "a form of garbage
collection" on modern OSes: All garbage is reclaimed by
the OS when the program exits. It's just a very lazy collector.

I don't consider something a garbage collector unless it
collects all garbage (ref.counting doesn't) and is a bit more
agile than the one provided by OS.

Well, OK, but people do tend to allow a bit of 'conservativeness' in
their collectors, don't they? Boehm's GC-for-C is usually considered
a 'real GC' and that doesn't necessarily collect everything (AIUI, I'm
not an expert in this field).

CPython's 'ref counting + gimmicks' certainly *would* seem to qualify
as a GC, by your definitions.

You, I and everyone knows what I was talking about, so it could
hardly be regarded as "meaningless".

Well, OK, but: even if we don't allow refcounting as 'GC' I would
(really!) like to know which form of garbage collection you would use
instead.

It's not "the one currently employed". It's the *two* currently
employed and that causes grief as I described in my previous post.

You mean two, as in the ones used by Jython and CPython? If have to
admit, I

And AFAIK, Ruby does use GC (mark-and-sweep, if you wish) and
seems to be working.

With finalizers? Just curious.

However, this is rather iffy knowledge. I'm actually longing for
real GC because I've seen it work well in Java and C#, and I know
that it's being used successfully in many other languages.


A trick question?

Not at all!

I think it would be practically very difficult to move to a radically
different memory management methodology without breaking the vast
majority of C extensions out there, but I would like to see some
more concrete speculation about alternatives.

Cheers,
mwh

 

[Michael Hudson]

|But a lot of Python code depends on reference counting or more exactly it
|depends on the timely call of the destructor. So even if a much better GC is
|added to Python, reference counting would perhaps be kept for backwards
|compatibility (see Python's biggest compromises)

Did this thread get caught in a time warp, and posts from two years ago
get posted again. Exactly this all happened years ago.

Welcome to USENET!

Cheers,
mwh

 

[Andrew Dalke]

Mel Wilson:

(Idea for obfuscated Python: a program that mixes spaces
and tabs in the indenting so as to perform two or more
distinct useful functions depending on the space-to-tab
rate. Bonus points for a program that undoes itself at
different settings.)

That's just not possible because Python only has one setting
for a tag - 8 spaces. At most there would appear to be a
difference if your editor was configured to display tabs as,
say, 4 spaces. But Python's understanding of it would not
change.

Andrew
(e-mail address removed)

 

[Dang Griffith]

Anthony_Barker wrote:
...

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

...
Strings are also immutable in Java. Maybe Guido likes Java? ;-)
--dang

 

[Aahz]

Strings are also immutable in Java. Maybe Guido likes Java? ;-)

Python predates Java.

 

[enoch]

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?

Its non existant SMP scalability.
If you try to sell clients somewhat bigger server apps, they don't
want to hear that having these run on a SMP system might (and will)
actually _hurt_ performance without special administrative
interference (processor binding), which isn't even possible on some
older operating systems.
We seem to be more or less at the end concerning ramping up single
processor speeds, and SMP like hardware becomes more and more
ubiquitous, e.g. Intel's Hyperthreading, IBM's SMP-on-a-chip, Sun's
"Throughput Computing".
As far as I know, there seems to be no interest to get rid of the GIL.
To do this might be a big technical problem, but I fear if it stays
the way it is, the actual trend in the hardware industry might work
against python (in server apps) big time.

 

[Aahz]

Its non existant SMP scalability.

Would you care to back up your claim with some actual evidence?

(Yes, there are issues with Python on SMP machines, but to call Python's
built-in threading "non-existent SMP scalability" is either a lie or
revelatory of near-complete ignorance. That doesn't even count the
various IPC mechanisms.)