Python's biggest compromises

[Marc]

Re: Python's biggest compromises

In general, I suspect BASIC is more defined by compromises than
Python.

To me there is a compromise in Python's dependence on C. It seems that
at some point I will hit a performance or feature issue that will
require me to write a C extension. It seems to me VB6 has a similarly
awkward relationship with C++. Clearly the creators of Python were
expert C programmers; that should not be a requirement to become an
expert Python programmer.

- Marc

[John Roth]

Re: Python's biggest compromises


"Marc" <marcstober@yah oo.com> wrote in message
news:ac7dc9b9.0 308011211.7edb0 e76@posting.goo gle.com...[color=blue]
> In general, I suspect BASIC is more defined by compromises than
> Python.
>
> To me there is a compromise in Python's dependence on C. It seems that
> at some point I will hit a performance or feature issue that will
> require me to write a C extension. It seems to me VB6 has a similarly
> awkward relationship with C++. Clearly the creators of Python were
> expert C programmers; that should not be a requirement to become an
> expert Python programmer.[/color]

As a number of people have said: if PyPy ever gets working...

John Roth[color=blue]
>
> - Marc[/color]

[Andrew Dalke]

Re: Python's biggest compromises

Paul Rubin:[color=blue]
> I'd say the opposite, the Lisp implementations I've worked on are
> considerably easier to write C extensions for, partly BECAUSE you
> don't have to worry about constantly tweaking ref counts.[/color]

I've mentioned in c.l.py before a library I used which can be called
from both C and FORTRAN. The latter doesn't support pointers,
so instead the library has a global instance table, indexed by integers.
The C/FORTRAN code just passes integers around.

In addition, there are dependencies between the objects, which
means that user code object deallocation can only occur in a
certain order.

With CPython it's possible to put a high-level OO interface to
that library, and provide hooks for the ref-counted gc to call
the proper deallocators in the correct order. This is done by
telling the finalizer how to do it and paying careful attention to
order.

The library also has Java bindings. As far as I can tell, it's
impossible to hook into Java's automatic gc. A C-level
gc like Boehm can't ever tell that data is no longer needed,
because the global table keeps a reference to every created
object, and Java's native gc doesn't make the proper
guarantees on finalization order.

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python's biggest compromises

Gerald Klix:[color=blue]
> IHMO it is the lambda expression.
> These "functions" are not real functions. You can not use
> statements in them.[/color]

True. That's why they are "lambda expressions" and not
"lambda functions"

(Okay, that was a cheap shot ... but still true ;)

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python's biggest compromises

Marc:[color=blue]
> To me there is a compromise in Python's dependence on C.[/color]

Then explain Jython, which is an implementation of Python-the-language
on top of Java.
[color=blue]
> It seems that
> at some point I will hit a performance or feature issue that will
> require me to write a C extension.[/color]

change "will" to "may"

And if you write in C, at some point you may hit a performance
or feature issue that will require you to write assembly code.
[color=blue]
> Clearly the creators of Python were
> expert C programmers; that should not be a requirement to become an
> expert Python programmer.[/color]

Lack of knowledge of C does not strongly preclude becoming an
expert Python programmer.

To be an expert Python programmer, you should know how other
programming langauges work too, but that can be done by
learning other languages: Eiffel, Java, APL, Haskel, Caml, Ada,
Prolog, Java, ...

Andrew
dalke@dalkescie ntific.com

[Courageous]

Re: Python's biggest compromises

[color=blue][color=green]
>> The three that come to my mind are significant whitespace, ...[/color][/color]

"Significan t whitespace" isn't a "compromise ," it's a design choice.
The Python interpreter actually inserts explicit scope tokens into
the symbol stream at the lexer; the parser deals with the symbols as
does any parser. It's really not all that hard, actually. One just
has to understand the bit that making the *parser* deal with the white
space is not the right thing.

C//

[Gerald Klix]

Re: Python's biggest compromises

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is not a function. This just the same as blocks in Algol 68,
because both do not defer execution until the fuction is called.

Of course you can define the semantics of such a block in terms
of a function defintion and an immedirate call to the fuction.
This is done in the Scheme languges let syntax.

HTH,
Gerald

OKB (not okblacke) wrote:
| Gerald Klix wrote:
|
|
|>What Python realy needs here is some means to make an expression
|>from a list of statements (called suite in the syntax defintion).
|
|
| I believe this is called a "function".
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE/K4adEDg9cqFA1jQ RAnLkAJ0WXxqAwd zyqrKfOy2O1ycod 1aCmQCfeKRH
doeQdEuwBJ8LS+g y6IOYzZQ=
=KB0f
-----END PGP SIGNATURE-----

[Andy C]

Re: Python's biggest compromises

> > it isn't to a compiler). OTOH, *Python's* scheme is inferior to a[color=blue][color=green]
> > pure-space-character indentation scheme because off the tab-vs.-space
> > issue :-([/color]
>
> Well, that's been recognized as a problem for a long time. I believe
> that the intention is to mandate spaces only in Python 3.0. On the
> other hand, I'm not holding my breath waiting for Guido to decide[/color]

What's bad about tabs? I'm new to Python. Tabs are good because then you
can view the source however you want. I can't write in 4 space tabs and
someone else can change it to 2 if they prefer. But I can see the problem
with continuation lines. Also it must be ALL tabs or ALL spaces. This
shouldn't be too hard -- most editors have the "tabify" option.

Andy

[Andy C]

Re: Python's biggest compromises

> Many tools don't allow you to configure tabs, and of those that do,[color=blue]
> each uses its own incompatible syntax and has its own quirks. In other
> words, tabs may seem like a good thing if you use just one or two tools
> that do what you want, but as soon as your program moves out into
> the wild world, things change.[/color]

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.

[Terry Reedy]

Re: Python's biggest compromises


"Andy C" <ayc8NOSPAM@cor nell.edu> wrote in message
news:y3VWa.261$ _p6.23775419@ne wssvr21.news.pr odigy.com...[color=blue]
> What's bad about tabs?[/color]

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

<flameshield on> tjr

[John Roth]

Re: Python's biggest compromises


"Andy C" <ayc8NOSPAM@cor nell.edu> wrote in message
news:mEVWa.279$ jw6.24163477@ne wssvr21.news.pr odigy.com...[color=blue][color=green]
> > Many tools don't allow you to configure tabs, and of those that do,
> > each uses its own incompatible syntax and has its own quirks. In other
> > words, tabs may seem like a good thing if you use just one or two tools
> > that do what you want, but as soon as your program moves out into
> > the wild world, things change.[/color]
>
> What are these quirks? By far the most common I've seen is mixing tabs[/color]
and[color=blue]
> spaces, but this should be relatively easily solved by requiring one or[/color]
the[color=blue]
> 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.[/color]

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]

Re: Python's biggest compromises


"Terry Reedy" <tjreedy@udel.e du> wrote in message
news:8Z-cnS25-8ywsLGiXTWJiQ@c omcast.com...[color=blue]
>
> "Andy C" <ayc8NOSPAM@cor nell.edu> wrote in message
> news:y3VWa.261$ _p6.23775419@ne wssvr21.news.pr odigy.com...[color=green]
> > What's bad about tabs?[/color]
>
> Because there is no 'official' meanings, despite claims to the
> contrary, some software like Outlook Express ignores them on receipt.
>
> <flameshield on> tjr[/color]

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[color=blue]
>
>
>[/color]

[Ben Finney]

Re: Python's biggest compromises

On Sat, 02 Aug 2003 23:31:44 GMT, Andy C wrote:[color=blue]
> 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.[/color]

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.

--
\ "The best is the enemy of the good." -- Voltaire |
`\ |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Andrew Dalke]

Re: Python's biggest compromises

Andy C:[color=blue]
> OK, then unless I'm missing something, tabs vs. spaces shouldn't matter[/color]
for[color=blue]
> you. The editor should be able to handle tabs in a satisfactory manner as
> well.[/color]

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_val ue > that_long_varia ble) or
(this_is_a_valu e == 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
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: Python's biggest compromises

Terry Reedy:[color=blue]
> Because there is no 'official' meanings, despite claims to the
> contrary, some software like Outlook Express ignores them on receipt.[/color]

I sent email to a friend of mine. It contained a copy&paste from
the interactive prompt. Something like
[color=blue][color=green][color=darkred]
>>> class Spam:[/color][/color][/color]
.... pass[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

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

Andrew
dalke@dalkescie ntific.com