Strong/weak typing

[MartinRinehart]

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

Is this good software engineering practice, or am I missing something
Pythonic?

 

[eliben]

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

Is this good software engineering practice, or am I missing something
Pythonic?

I'm not sure you've got the terminology 100% right. Strong typing is
not about re-using names.

Take a look at: http://eli.thegreenplace.net/2006/11/25/a-taxonomy-of-typing-systems/

 

[Alan Franzoni]

(e-mail address removed) was kind enough to say:

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

Is this good software engineering practice, or am I missing something
Pythonic?

Python *is* strongly typed.

You're talking about dynamic typing, but that's not about "name reuse".

--
Alan Franzoni <[email protected]>
-
Remove .xyz from my email in order to contact me.
-
GPG Key Fingerprint:
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E

 

[Maric Michaud]

Le Friday 01 August 2008 17:31:25 (e-mail address removed), vous avez écrit :

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

Is this good software engineering practice, or am I missing something
Pythonic?

As already stated by others, Python is strongly typed, the fact is that the
type of an object is embeded with the object itself, not by the name you give
him at different place in a program.

But in fact you effectively re-use names in your programs, it's the basic of
the language.

Think of the following lines :

a, b = 0, 1
a += b
a, b = b, a

s = "foo"
s = s.upper()

 

[paul]

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

If it buys you anything? Maybe for shedskin or some future
"to-native-code" compiler?

Is this good software engineering practice, or am I missing something
Pythonic?

I'd say so. In a function/method body I do reuse generic names like
data,counter,etc. but I never change say an instance variable to another
type (except from None). Principle of least surprise applies here.

cheers
Paul

 

[Carl Banks]

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

Is this good software engineering practice, or am I missing something
Pythonic?

I don't think you should go about gratuitously rebinding names to
objects of different types just for the sake of being more Pythonic,
no.

The strength of dynamic typing (Pythonistas prefer the terms dynamic
vs static for what you describe, and use weak vs stong for something
else) lies mostly in the freedom it gives you.


It means you can write a function like this and call it on any object
that has an output method:

def function(x):
x.output()

It means you can have big list of objects of different types and
iterate through the items like this, as long they all have that
output method:

for x in some_bug_list:
x.output()

You can arrange for this kind of thing to happen in statically-typed
languages as well, but it's a lot more effort (defining interfaces or
subclasses).

IMO, organizing code to take advantage of this can result in much
simpler logic with much less code duplication. But even if you do
that, most of the variables in a program are going to spend their
whole time being bound to a single time.


Carl Banks

 

[Russ P.]

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

Is this good software engineering practice, or am I missing something
Pythonic?

Reusing names for no reason can make debugging harder in some cases.

 

[Terry Reedy]

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

Names are bound to objects with types.

Is this good software engineering practice,

If you expand 'type' to 'category', then yes.

or am I missing something Pythonic?

Most Python code is or could be generic.

def sum(iterable,start):
for item in iter(iterable):
start += item
return start

Iterable can be any collection that is homogeneous with respect to the
class of start and the operation of addition. And throughout my code, I
never use 'iterable' for anything other that a
homegeneous-for-the-purpose collection. I would never, for instance,
bind it to a number.

tjr

 

[Mel]

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

Is this good software engineering practice, or am I missing something
Pythonic?

Nothing wrong with what you're doing. I've never come up with a really
convincing reason to recycle names. Possibly something that follows the
evolution of the data:

middle_name = raw_input ('Name?')
middle_name = middle_name.split()
middle_name = middle_name[1]

It works, but I don't like it enough to actually use it.

Mel.

 

[D'Arcy J.M. Cain]

middle_name = raw_input ('Name?')
middle_name = middle_name.split()
middle_name = middle_name[1]

It works, but I don't like it enough to actually use it.

Especially since this works better anyway:

middle_name = raw_input ('Name?').split()[1]

 

[Diez B. Roggisch]

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

Is this good software engineering practice, or am I missing something
Pythonic?

Others pointed out the wrong wording.

As often, this is not a question to be answered with a simple yes or no.

Duck-typing is very ptyhonic, and as such it is very common to write e.g.

if content_as_string:
inf = StringIO.String(content_as_string)
else:
inf = open(filename)

inf has two totally different types now, depending on the path taken.

And I personally tend to actually do things like this:

if isinstance(foo, str):
foo = unicode(str)

Or such.

But that is more a matter of taste - I personally don't like to many
names lying around, but YMMV.


Diez

 

[Derek Martin]

(e-mail address removed) was kind enough to say:

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

[...]
Python *is* strongly typed.

That's debatable. It depends on what definition of "strongly typed"
you are using, and Martin's usage was not incorrect. There are,
unfortunately, lots of them:

http://en.wikipedia.org/wiki/Strong_typing

The strength of dynamic typing (Pythonistas prefer the terms dynamic
vs static for what you describe, and use weak vs stong for something
else) lies mostly in the freedom it gives you.

Pythonistas can be extremely irritating. Some attributes I've
observed of (some of) them:

- stubborn insistence on their own narrow definitions of terms, and
complete refusal to accept that other definitions of those terms
exist and are in common usage

- stubborn refusal to accept that other terms exist which describe
some facet of programming they prefer to call by their own Elite
Pythonista name.

- A fundamental lack of understanding that not everyone who posts
here was born speaking Python

- extreme impatience with anyone who does not immediately understand
what they are saying

- superior/condescending tone leveled at anyone who profers an
opinion which differs with the Pythonista hive mind.

Is precision in terminology important? Sure, especially when the
topic tends to be somewhat complex and/or abstract. But words are
just words -- they have meaning that we impart to them, and there is
rarely only one to describe a particular concept. There also is
rarely only one meaning for each word. Computer Science has evolved
increasingly rapidly over the last 40 years or so, and along with it
so has its terminology. Each computer language brings with it a
unique perspective on programming, and almost out of necessity its own
terminology to describe the philosophy behind its design. THIS DOES
NOT RENDER WRONG OTHER TERMS OR USAGES. It merely augments the
already rich natural language we have to describe what we do.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIlGlddjdlQoHP510RAoVyAKCUDmlZt7Zj0k8MJxhE46i+/Wcr9ACcDJpx
IEVzJkH9LpBZnlUZpSopzQw=
=jRre
-----END PGP SIGNATURE-----

 

[Jorgen Grahn]

I'm writing Python as if it were strongly typed, never recycling a
name to hold a type other than the original type.

Is this good software engineering practice, or am I missing something
Pythonic?

Nothing wrong with what you're doing. I've never come up with a really
convincing reason to recycle names. Possibly something that follows the
evolution of the data:

middle_name = raw_input ('Name?')
middle_name = middle_name.split()
middle_name = middle_name[1]

It works, but I don't like it enough to actually use it.

I don't like that there are two lines where 'middle_name' isn't
actually a middle name. It confuses me, even though I know that
everything is ok after the third line.

I reuse names though, mostly because I don't want to invent additional
names which would feel "overburdened". I like this example better:

months = range(1, 13)
# do something with the months-as-numbers list,
# and then:
months = [ monthname(x) for x in months ]
# do something where we only need the names

Your comment "something that follows the evolution of the data"
applies here. It's the same data, but refined to a more usable form.

It also kills off an object which I have decided I will not need
further down, so it kind of documents that decision.

I only do this very locally, like in a simple function.

/Jorgen

 

[Mel]

I reuse names though, mostly because I don't want to invent additional
names which would feel "overburdened". I like this example better:

months = range(1, 13)
# do something with the months-as-numbers list,
# and then:
months = [ monthname(x) for x in months ]
# do something where we only need the names

Your comment "something that follows the evolution of the data"
applies here. It's the same data, but refined to a more usable form. [ ... ]
I only do this very locally, like in a simple function.

Yes. That example looks particularly good.

Somebody emailed me privately with a poster-child for this technique, which,
now that I've been reminded, I *do* use ("locally" applies strongly here):

def f(a):
a = int (a)
# ...

or, in a slightly different context:

class ThisClass (object):
# ...
def __add__ (self, other):
if not isinstance (other, ThisClass):
other = ThisClass (other)


Mel.