Strong/weak typing

[MartinRinehart@gmail.com]

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]

Re: Strong/weak typing

On Aug 1, 5:31 pm, MartinRineh...@ gmail.com wrote:

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...yping-systems/

[Maric Michaud]

Re: Strong/weak typing

Le Friday 01 August 2008 17:31:25 MartinRinehart@ gmail.com, 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()

--
_____________

Maric Michaud

[paul]

Re: Strong/weak typing

MartinRinehart@ gmail.com schrieb:

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,et c. but I never change say an instance variable to another
type (except from None). Principle of least surprise applies here.

cheers
Paul

[Carl Banks]

Re: Strong/weak typing

On Aug 1, 11:31 am, MartinRineh...@ gmail.com wrote:

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.]

Re: Strong/weak typing

On Aug 1, 8:31 am, MartinRineh...@ gmail.com wrote:

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]

Re: Strong/weak typing



MartinRinehart@ gmail.com wrote:

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,st art):
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]

Re: Strong/weak typing

MartinRinehart@ gmail.com wrote:

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.spl it()
middle_name = middle_name[1]

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

Mel.

[D'Arcy J.M. Cain]

Re: Strong/weak typing

On Fri, 01 Aug 2008 22:47:04 -0400
Mel <mwilson@the-wire.comwrote:

middle_name = raw_input ('Name?')
middle_name = middle_name.spl it()
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]

--
D'Arcy J.M. Cain <darcy@druid.ne t | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

[Diez B. Roggisch]

Re: Strong/weak typing

MartinRinehart@ gmail.com schrieb:

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_stri ng:
inf = StringIO.String (content_as_str ing)
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]

Terminology (Re: Strong/weak typing)

On Fri, Aug 01, 2008 at 03:57:10PM +0000, Alan Franzoni wrote:

MartinRinehart@ gmail.com 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

On Fri, Aug 01, 2008 at 11:23:31AM -0700, Carl Banks wrote:

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)

iD8DBQFIlGlddjd lQoHP510RAoVyAK CUDmlZt7Zj0k8MJ xhE46i+/Wcr9ACcDJpx
IEVzJkH9LpBZnlU ZpSopzQw=
=jRre
-----END PGP SIGNATURE-----

[Jorgen Grahn]

Re: Strong/weak typing

On Fri, 01 Aug 2008 22:47:04 -0400, Mel <mwilson@the-wire.comwrote:

MartinRinehart@ gmail.com wrote:
>

>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.spl it()
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 "overburden ed". 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

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se R'lyeh wgah'nagl fhtagn!

[Mel]

Re: Strong/weak typing

Jorgen Grahn wrote:

I reuse names though, mostly because I don't want to invent additional
names which would feel "overburden ed". 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.