FORTRAN (was Re: indentation)

[William B. Clodius]

Christian Tismer wrote:
> <snip>
> I'm 43, and I learned FORTRAN IV right after Algol 64 in the late 70s.
> Can't remember if it was this, or an earlier Fortran version which
> had no dynamic variables but just statics?
> <snip>
Tim Peters may correct me on this, but I believe that all Fortran's up
to Fortran 90 could be implemented with static allocation. It had no
recursion and, in most respects, no dynamic allocation. The one tricky
point in static allocation involves some usages of CHARACTER variables
which result in expressions whose size can vary at runtime. However, I
believe that the language defined a standard upper bound on the size of
these expressions to allow static allocation in these cases. (No I can't
cite a reference at this time.) While Fortran could be statically
allocated it did not require this, and some code would rely on such
tricks as statically defining arrays significantly larger than needed
knowing that the processor would allocate the memory for the arrays on
demand, i.e., the system would implement reallocation up to the defined
size of the arrays or the system capability, whichever was smaller.

As a side point, dynamic languages can also be implemented statically
with defined limits on depth of recursion or sizes of dynamic entities,
it is just wasteful of computer memory and implementor's time to make
that an implementation goal on current user systems (there have been
user systems in the past that only allowed static allocation and of
course micro-controllers usually require static allocation).

From: Preston Landers <prestonlanders at my-deja.com>
Newsgroups: comp.lang.python
Subject: Re: some random reflections of a "Python newbie": (2) language issues
Date: Thu, 09 Dec 1999 23:32:59 GMT
Organization: Deja.com - Before you buy.
Lines: 85
Message-ID: <82pe7b$q76$1 at nnrp1.deja.com>
References: <82o0to$6eq$1 at serv1.iunet.it> <82od57$i7n$1 at serv1.iunet.it>
NNTP-Posting-Host: 205.238.143.132
To: alex at magenta.com
X-Article-Creation-Date: Thu Dec 09 23:32:59 1999 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)
X-Http-Proxy: 1.1 x30.deja.com:80 (Squid/1.1.22) for client 205.238.143.132
X-MyDeja-Info: XMYDJUIDprestonlanders
Path: news!uunet!ffx.uu.net!newsfeed.mathworks.com!howland.erols.net!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail
Xref: news comp.lang.python:78033
Sender: python-list-admin at python.org
Errors-To: python-list-admin at python.org
X-BeenThere: python-list at python.org
X-Mailman-Version: 1.2 (experimental)
Precedence: bulk
List-Id: General discussion list for the Python programming language <python-list.python.org>

In article <82od57$i7n$1 at serv1.iunet.it>,
  "Alex Martelli" <alex at magenta.com> wrote:

> 3. "dictionary locking" in lieu of declarations

> Given Python's powers of "introspection", I
> bet some prototype for this could already be
> hacked up, by subclassing the dictionary and
> playing with __getattr__, __setattr__, and
> __delattr__ -- but, as a newbie, I'm somewhat
> reluctant to start along this path myself, in
> particular since these dictionaries seem to be
> somewhat "magical" (a much beloved term in
> Perl, of course, not in Python...:-).  But that is

You're on the right track with this.  There's nothing "magical" about
the __getitem__ and __setitem__ methods of dictionary-like or sequence-
like objects.  (That's what you want in this case, not the attr
methods.) You could easily implement what you describe in a Python
class.  If you really need the speed of built in Python dictionaries,
you could implement it as a C/C++ module.

I will leave it to you as a learning exercise rather than writing out
all the code for you.  It's probably a lot easier than you're
imagining.

I will refer you to:

http://www.python.org/doc/current/ref/sequence-types.html

and nearby chapters for a reference.  The safest thing to do is
implement all of those 'special' methods unless you know you won't need
one.

Unfortunately for you, Python dicts are a built-in type (for speed
reasons) and thus you cannot subclass it, then then implement your
locking mechanism.  This is one of the few obvious inconsistencies in
Python's implementation.  If you could subclass builtins, then what you
want to do would be completely trivial.

If you are still stuck, write me and I will walk you through what you
need to do.

> 4. why can't I overload "in" to have the
>     expected semantics and maybe be fast...?

You don't need to 'overload' the 'in' keyword.  Just define the
__getitem__ method in your class.

This works for me:

class foo:
    def __init__(self):
        self.data = [1, 2, 3, 4, 5]

    def __getitem__(self, index):
        return self.data[index]

myfoo = foo()

# will print all elements in order
for index in myfoo:
    print index

# will print yes
if 1 in myfoo:
    print "yes it is"

# will print nope
if 7 in myfoo:
    print "7 is present"
else:
    print "nope, 7 is not there"


cheers,

---Preston

--
|| Preston Landers <prestonlanders at my-deja.com> ||


Sent via Deja.com http://www.deja.com/
Before you buy.