Re: Script codes

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Thu Jan 05 2006 - 22:04:37 CST

-----Original Message-----
>From: David Jefferson <>
>Sent: Jan 5, 2006 10:26 PM
>To: charlie strauss <>, Open Voting Consortium discussion list <>
>Subject: Re: [OVC-discuss] Script codes
>I am not facile with Python. But my reading of these lines is that
>they require strong typing,

People argue what that means in python. Some argue it's strongly typed since every object has a fixed type. But from a usage perspectives python is not strongly typed: function arguments and return values have no type enforcement. Reference to object have no fixed type. Moreover an instance can introspectively mutate it's own type or that of another instance or class of objects. So an object's type is dynamic both at and during run time. New types can be created during runtime.

These are not features that can be deliberatley avoided like in C. (e.g. in C Malloc exists but you don't have to call it to create an array. But to create any object or an array in Python you need to instantiate it dynamically at run time.

>including bounds checked arrays and
>strings, and disciplined object references (e.g. Java).

Like java, Python uses refences not memory pointers. But the variable holding references can change the types they refer to, so they are not strongly typed.

>Also, my
>personal interpretation is that whatever the main body of code is
>writen in, there cannot be a second level of interpretation, i.e.
>Python and Java would be OK by me as primary languages even though
>they are interpreted, as long as there were not another level of
>interpretation of some other language.

I think this would have to mean that one could only run a .pyc file and not a .py file. .pyc is vaguely analogous to compiled java. .py would be the first level of a two level interpretation. And pythons ability to interpet and execute a string of python commands adds a third layer. Perhaps like perl string execution in python can be deliberately crippled at the opcode level?

>And if it were up to me these lines would seem to preclude C, because
>of the confusion between integers and pointers in that language does
>not allow any strong way of controlling pointer references; but I
>doubt the ITAs interpret it that way, or enforce it.

Hmm good point. were rapidly running out of languages here. Maybe C++.

I'm not arguing here that I think python is a bad choice. I'm trying to figure out how to read interpet this requirement for the ITA. So far I have not detected the line that divides Accubasic from python. Nor is it clear to me where postscript, fonts, SQL, and .dll would fit in this spectrum.

OVC-discuss mailing list
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Mon Jan 8 20:24:35 2007

This archive was generated by hypermail 2.1.8 : Mon Jan 08 2007 - 20:24:39 CST