Strong/weak typing
MartinR...@gmail.com
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 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
Python *is* strongly typed.
You're talking about dynamic typing, but that's not about "name reuse".
--
Alan Franzoni <alan.fra...@gmail.com>
-
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
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
> I'm writing Python as if it were strongly typed, never recycling a
> name to hold a type other than the original type.
"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 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.
Reusing names for no reason can make debugging harder in some cases.
Terry Reedy
MartinR...@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,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
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
Mel <mwi...@the-wire.com> wrote:
> 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]
--
D'Arcy J.M. Cain <da...@druid.net> | 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
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
> MartinR...@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
Jorgen Grahn
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
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
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.