Python types

[Salvatore]

Hello,

I've read several articles where it's said that Python is weakly typed.
I'm a little surprised. All objects seem to have a perfectly defined
type

Am i wrong?

Regards

[Steve M]

Re: Python types

I think it means that names, not objects, are weakly typed. So you can
have:
a = 4
a = 'hello'

and there is no problem. The name 'a' doesn't have any type associated
with it. This contrasts with strongly typed language like C where you
declare the type of the name (variable) and the compiler objects at
compile time if you attempt to assign a value of a different type.

[Diez B. Roggisch]

Re: Python types

Steve M schrieb:[color=blue]
> I think it means that names, not objects, are weakly typed. So you can
> have:
> a = 4
> a = 'hello'
>
> and there is no problem. The name 'a' doesn't have any type associated
> with it. This contrasts with strongly typed language like C where you
> declare the type of the name (variable) and the compiler objects at
> compile time if you attempt to assign a value of a different type.[/color]



void foo() {
int *c = "hello weakly typed C!";
}


192:/tmp deets$ gcc -c test.c
test.c: In function `foo':
test.c:5: warning: initialization from incompatible pointer type

So I wouldn't call C strongly typed....

The distinction is usually made on two axis: strong-weak and
static-dynamic. Python is a strong-typed, dynamic language. JAVA is
strong-typed static. And PHP is weakly-typed dynamic.



Regards,

Diez

[Ben Finney]

Re: Python types

"Salvatore" <salvatore.didi o@wanadoo.fr> writes:
[color=blue]
> I've read several articles where it's said that Python is weakly
> typed. I'm a little surprised. All objects seem to have a perfectly
> defined type
>
> Am i wrong?[/color]

You're right. All Python values are strongly typed; they don't, in
general, change their type; and operations between values of
mismatched types are not allowed.

A more recent distinction than "strong" vs "weak" typing, is "dynamic"
vs "static" typing.

"Typing: Strong vs. Weak, Static vs. Dynamic"
<URL:http://www.artima.com/weblogs/viewpost.jsp?th read=7590>

--
\ "I would rather be exposed to the inconveniences attending too |
`\ much liberty than those attending too small a degree of it." |
_o__) -- Thomas Jefferson |
Ben Finney

[Steven Bethard]

Re: Python types

Salvatore wrote:[color=blue]
> I've read several articles where it's said that Python is weakly typed.
> I'm a little surprised. All objects seem to have a perfectly defined
> type[/color]

Hoping to head off another debate:

http://wiki.python.org/moin/StrongVsWeakTyping

STeVe

[sjdevnull@yahoo.com]

Re: Python types


Salvatore wrote:[color=blue]
> Hello,
>
> I've read several articles where it's said that Python is weakly typed.
> I'm a little surprised. All objects seem to have a perfectly defined
> type
>
> Am i wrong?[/color]


No, you're right. It seems like a lot of people conflate weak vs.
strong typing and static vs. dynamic typing. Back when I was in CS
classes in the early 1990s, the distinction was pretty universal, but
in recent years it seems like more people are wrongly assuming that
strong typing and static typing go hand in hand.

C, C++: Weakly, statically typed
Java, ML: Strongly, statically typed.
VB, tcl (kind of): Weakly, dynamically typed
Smalltalk, Python: Strongly, dynamically typed

Note that both axes are continuums. C++ is mostly statically typed,
but it's got rtti and other runtime typing facilities. Java is pretty
strongly typed, but not to the degree that ML is.

[Bruno Desthuilliers]

Re: Python types

Salvatore a écrit :[color=blue]
> Hello,
>
> I've read several articles where it's said that Python is weakly typed.
> I'm a little surprised. All objects seem to have a perfectly defined
> type[/color]
[color=blue]
> Am i wrong?[/color]

Depends on your definition of 'type'.

[BWill]

Re: Python types

Salvatore wrote:[color=blue]
> Hello,
>
> I've read several articles where it's said that Python is weakly typed.
> I'm a little surprised. All objects seem to have a perfectly defined
> type
>
> Am i wrong?
>
> Regards
>[/color]
Aye, the other posters are right about you being right. This is just one
of the great mass confusions in programming (sadly, there are a lot of
them these days).

[Salvatore]

Re: Python types

Thank's everybody :-)


Here is a type définition I've found on the net which I agree with :

Attribute of a variable which determines the set of the values this
variabe can take and the
operations we can apply on it.

[Alex Martelli]

Re: Python types

Salvatore <salvatore.didi o@wanadoo.fr> wrote:
[color=blue]
> Thank's everybody :-)
>
>
> Here is a type définition I've found on the net which I agree with :
>
> Attribute of a variable which determines the set of the values this
> variabe can take and the
> operations we can apply on it.[/color]

Hmmm -- that doesn't work very well for languages in which "a variable"
is just "a name", because we cannot apply any operations at all on THE
NAME -- we apply operations on the OBJECT to which the name refer. This
issue arises with both languages where names "can take" any object, like
Python, and ones where the compiler infers the subset (type) of objects
that each name "can take", like Boo.

Moreover, asserting that 'type' is an attribute of a variable means, for
example, that a function's return-value, not being a variable, has no
type -- that really makes no sense. And similarly for other
expressions; e.g., consider, in Java, something like...:

( (Fooable) zip() ).getFoo() + ( (Barable) zop() ).getBar()

no variables in sight, yet a lot of types in Java's normal sense -- the
types of whatever objects zip() and zop() return, the (Fooable and
Barable, respectively) types after the cast, the type of whatever getFoo
and getBar return, and the type of their sum...

Saying that an _object_ has a type thus makes more sense (even in Java
and similar languages) than considering type to be an "attribute of a
variable" -- *in addition* to objects, which have types, other language
constructs, depending on the language, may or may not be imbued with
type-constraints, be that declaratively (as, say, in Java), by compiler
inference (as, say, in Boo), or by other means yet such as stropping
(e.g., in Perl, you can tell from just looking at the name whether a
variable refers to a scalar, $something, an array, @something, or a
hash, %something -- in Python, Java or Boo you can't tell from just the
name, but rather must find a declaration [Java], assignment [Python] or
use [Boo] to let you read or infer the "scalar vs array" type issue).


Alex

[Salvatore]

Re: Python types

Grazie ALex, for your comment.

[Bruno Desthuilliers]

Re: Python types

Salvatore a écrit :[color=blue]
> Thank's everybody :-)
>
>
> Here is a type définition I've found on the net which I agree with :
>
> Attribute of a variable which determines the set of the values this
> variabe can take and the
> operations we can apply on it.[/color]

Then - as already pointed by Alex - there is no type in Python, since
there is no variable (even if this term is often improperly used for
bindings) !-)

Ok, let's s/variable/object/g and define some objects and operations:

def myop(obj):
return obj.foo * 2

class Bar(object):
pass

b = Bar()

Can we apply the myop() operation on the object name 'b' is bound to ?

myop(b)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in myop
AttributeError: 'Bar' object has no attribute 'foo'


Well... but wait a minute:
b.foo = []
myop(b)
-> []

Err... Wait another minute:

b2 = Bar()
type(b) is type(b2)
-> True
myop(b2)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in myop
AttributeError: 'Bar' object has no attribute 'foo'

Ok, so even if Python itself declares b and b2 (read: objects that names
b and b2 are bound to) to be of the same type, you cannot apply the
myop() operation on b2...

Also:

del b.foo
myop(b)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in myop
AttributeError: 'Bar' object has no attribute 'foo'


So *sometimes* you can apply myop() to b, and sometimes you can't.

Now if we come back to your original post:
"""
All objects seem to have a perfectly defined
type
"""

"Perfectly defined" ? Really ? Not for your current definition of 'type'
at least !-)

I still mostly agree with the given definition of type. But the fact is
that in Python, the type*s* of an object are not so perfectly defined -
they're mostly implicits, and can vary during the object's lifetime.

Note that it does'nt make Python weakly typed - you cannot perform any
arbitrary operation on a given object, only the operations this object
can support at a given moment. FWIW, if you want a weakly typed
language, take a look at C.

[Salvatore]

Re: Python types

Thank's Bruno.

[bruno at modulix]

Re: Python types

Dennis Lee Bieber wrote:[color=blue]
> On Mon, 27 Mar 2006 01:34:14 +0200, Bruno Desthuilliers
> <bdesth.quelque chose@free.quel quepart.fr> declaimed the following in
> comp.lang.pytho n:
>
>[color=green]
>>Ok, so even if Python itself declares b and b2 (read: objects that names
>>b and b2 are bound to) to be of the same type, you cannot apply the
>>myop() operation on b2...[/color]
>
>
>
> Try looking at class-based objects as a form of CONTAINER...[/color]

ouch, my ears :(
[color=blue]
> Two
> containers can be of the same type, but the contents may be different.
>[/color]
(snip)

This is mostly how OO is implemented in Python (in javascript too FWIW)
- but this is not the semantic of classes/objects in OO. The OO
translation of a type - at least according to the definition proposed by
the OP, and this is a pretty common definition - is a set of attributes
and methods. In most OO languages, this set is fixed for *all* the
instances of a class (subclassing not withstanding - and subclassing is
already a not so trivial problem in type theory).

What I wanted to point out is that, while class-based, Python in, in
this respect, closer to a prototype-based language.

In fact, since the set of attributes and methods of a given object may
change during the object's lifetime, it's type(s) may change too. So
saying that objects in Python "have a perfectly defined type" is perhaps
not really accurate, or at least requires further precisions (well, IMHO)

And I didn't even mention the possibility of changing the value of
anobject.__clas s__ at runtime !-)


--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"