One Python 2.1 idea

[Alex Martelli]

<rturpin at my-deja.com> wrote in message news:927se2$q7n$1 at nnrp1.deja.com...
    [snip]
> > C++ offers lots of very-low-level constructs AS WELL
> > AS pretty high-level ones, and, as I said, the low-level
> > parts keep coming up then and again even when one is
> > trying to work more abstractly ..
>
> To me, this is a BIG reason for preferring Python to
> C++. Yes, you can implement any abstraction in C++.

Nolo contendere: I *do* prefer Python for most tasks.
Squeezing the last little bit of performance out of some
key hotspot, and interfacing to existing libraries and
frameworks that I haven't nicely dressed up yet, being
the occasional exceptions.

> When you write Python, you keep present in your mind the
> memory management strategy for sequences, the lookup,

I do keep in mind a few well-known traps that could
lead to huge performance problems (building a string
by sequentially catenating lots and lots of pieces being
the foremost example).  Apart from that, I feel no real
such need when I _write_ code -- simplicity and clarity
being by far more important issues than a few % worth
of performance.  (Occasionally, when I _tune_ code, I
may do a few experiments based on Python's internals
being a NON-black box -- I don't just thrash around at
random seeing what might make it faster, I do let my
knowledge lead me to see what may be worth trying).


> point release? If so, I think C++ might be a better
> language for you!

It may be better *when the ultimate quest for top-notch
performance is on*.  That is, AT MOST, in 10% of the
code I write.


> > .. IF I have a semantic constraint about there being
> > no deletes on this object, it's a CRUCIAL part of my
> > abstraction for it -- I want to state it clearly and
> > readably, and let compiler and human readers make of
> > my statement what they wish.
>
> But this is NOT what we are talking about. IF it is
> important functionally to some list object that there are
> no deletes from it, if deleting from it is an application
> error, then you SHOULD create a new type, and build in
> this constraint, EVEN IF it imposes a performance penalty
> to ensure this constraint. But that is NOT the issue. The

Oh yes it is.  I want *DECLARATIVE* ways to assert my
known semantic constraints: easier for me to write,
easier for the human readers to follow, easier for the
compiler to insert checking code for OR base inferences
for optimization on.  A win-win-win-win situation.

Hiding declarative knowledge in executable code is a
serious design mistake.  Are you SERIOUSLY saying
that if what I know is "for every item x of X there exists
one item y of Y such that foo(x,y)" then I should code
at each step:
    for x in X:
        for y in Y:
            if foo(x,y): break
        else:
            raise AssertionError, "no foo(x,y) for "+str(x)
...?  I want (in my dreams) the COMPILER to generate
this code for me based on a DECLARATIVE ASSERTION
using quantifiers -- when I throw some switch on it
telling to pedantically check out everything it possibly
can; and I want my declarative assertion to stand as
an interesting tidbit of information to readers AND,
who knows, possibly help some future super-duper
compiler get some extra optimization too.


> issue is the much more common case where it just so
> happens that there are no deletes from a list, in the
> code as it appears now, and this can be used for
> performance optimization. It is NOT part of the
> application's semantics, but just a happenstance of
> current code.

With Python's fluidity and non-encapsulation, 'current
code' will have to comprise every last single user
typed string whose exec might possibly change this
'happenstance'.  Talk about whole-program optimizers...
_at the very least_, a declarative assertion about
lack of access to 'this list here' "from the outside" is
going to be needed for any practical purposes --
"nobody but us chickens is going to mess with X --
feel free to infer everything about X based on this
*finite* set of code and/or to hide it from outside".


Alex