IsString

[Tom Anderson]

On Tue, 13 Dec 2005, Steve Holden wrote:

> Tom Anderson wrote:
>> On Tue, 13 Dec 2005, Steven D'Aprano wrote:
>> 
>>> On Mon, 12 Dec 2005 18:51:36 -0600, Larry Bates wrote:
>>> 
>>> [snippidy-doo-dah]
>>> 
>>>> I had the same thought, but reread the post.  He asks "if a given 
>>>> variable is a character or a number".  I figured that even if he is 
>>>> coming from another language he knows the difference between "a given 
>>>> variable" and the "contents of a give variable".  I guess we will see.... 
>>>> ;-).  This list is so good, he gets BOTH questions answered.
>>> 
>>> The problem is, Python doesn't have variables (although it is 
>>> oh-so-tempting to use the word, I sometimes do myself). It has names 
>>> in namespaces, and objects.
>> 
>> In what sense are the names-bound-to-references-to-objects not variables?
>
> In a very important sense, one which you should understand in order to 
> understand the nature of Python.
>
> In C

Stop. How am i going to understand the nature of python by reading about 
C? Python is not C. What C does in the privacy of its own compilation unit 
is of no concern to us.

> if you declare a variable as (for example) a character string of length 
> 24, the compiler will generate code that allocates 24 bytes to this 
> variable on the stack frame local to the function in which it's 
> declared. Similarly if you declare a variable as a double-length 
> floating point number the compiler will emit code that allocates 16 
> bytes on the local stack-frame.

True but irrelevant.

> In Python a name [...] is simply *bound* to a value. The only storage 
> that is required, therefore, is enough to hold a pointer (to the value 
> currently bound to the name). Thus assignment (i.e. binding to a name, 
> as opposed to binding to an element of a data structure) NEVER copes the 
> object, it simply stores a pointer to the bound object in the part of 
> the local namespace allocated to that name.

Absolutely true. I'm not saying your terminology is wrong - i'm pointing 
out that mine is also right.

Basically, we're both saying:

"""In python, the universe consists of things; in order to manipulate 
them, programs use hands, which hold things - the program is expressed as 
actions on hands, which direct actions on things at runtime. Although it 
appears at first glance that there is a direct correspondence between 
hands and things, it is crucial to realise that the relationship is 
mediated by a holding - the hand identifies a particular holding, which in 
turn identifies a particular thing. So, when we make a function call, and 
specify hands as parameters, it is not the hands themselves, *or* the 
things, that get passed to the function - it's the holdings. Similarly, 
when we make an assignment, we are not assigning a thing - no things are 
touched by an assignment - but a holding, so that the hand assigned to 
ends up gripping a different thing.

There is in fact another layer of indirection - the programmer refers to 
hands using strings, but this is just part of the language used to express 
programs textually: the correspondence between these strings and the hands 
they refer to is called a manual. The manual which applies at any point in 
a program is determined lexically - it is the manual corresponding to the 
function enclosing that point, or the global manual, if it is at the top 
level.

"""

Where you can substitute either of:

steves_terminology = {
 	"thing": "value",
 	"hand": "name",
 	"hold": "are bound to",
 	"holding": "binding",
 	"gripping": "being bound to",
 	"manual": "namespace"
}

toms_terminology = {
 	"thing": "object",
 	"hand": "variable",
 	"hold": "point to",
 	"holding": "pointer",
 	"gripping": "pointing to",
 	"manual": "scope"
}

Using:

def substitute(text, substitutions):
 	substituands = substitutions.keys()
 	# to handle substituands which are prefixes of other substituands:
 	substituands.sort(lambda a, b: -cmp(len(a), len(b)))
 	for substituand in substituands:
 		text = text.replace(substituand, substitutions[substituand])
 	return text

I'd then point out that my terminology is the one used in all other 
programming languages, including languages whose model is the same as 
python's, and so we should use it for consistency's sake. I guess the 
argument for your terminology is that it's less confusing to C programmers 
who don't realise that the * in *foo is now implicit.

>>> It be a subtle difference, but an important one.
>> 
>> No, it's just spin, bizarre spin for which i can see no reason. Python 
>> has variables.
>
> You appear very confident of your ignorance ;-)

You appear to be very liberal with your condescension.

Steering rapidly away from further ad hominem attacks ...

>> I'm sure this has been argued over many times here, and we still all have 
>> our different ideas, so please just ignore this post!
>
> Couldn't!
>
> I do apologise, though, for any implication you assertions are based on 
> ignorance because you do demonstrate quite a sophisticated knowledge of 
> what goes on under the hood. As long as you can accept that "Python 
> 'variables' are all references" then the rest is indeed semantics.

Right. I think we just agreed.

> Of course it will be helpful for newcomers if we can adopt a standard 
> terminology ...

That's certainly true. We should therefore adopt my terminology as 
standard.

:)

tom

-- 
The literature, especially in recent years, has come to resemble `The
Blob', growing and consuming everything in its path, and Steve McQueen
isn't going to come to our rescue. -- The Mole