Strong/weak typing

Discussion in 'Python' started by MartinRinehart@gmail.com, Aug 1, 2008.

  1. Guest

    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?
    , Aug 1, 2008
    #1
    1. Advertising

  2. eliben Guest

    On Aug 1, 5:31 pm, 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/25/a-taxonomy-of-typing-systems/
    eliben, Aug 1, 2008
    #2
    1. Advertising

  3. 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 <>
    -
    Remove .xyz from my email in order to contact me.
    -
    GPG Key Fingerprint:
    5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
    Alan Franzoni, Aug 1, 2008
    #3
  4. Le Friday 01 August 2008 17:31:25 , 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
    Maric Michaud, Aug 1, 2008
    #4
  5. paul Guest

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

    cheers
    Paul
    paul, Aug 1, 2008
    #5
  6. Carl Banks Guest

    On Aug 1, 11:31 am, 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
    Carl Banks, Aug 1, 2008
    #6
  7. Russ P. Guest

    On Aug 1, 8:31 am, 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.
    Russ P., Aug 1, 2008
    #7
  8. Terry Reedy Guest

    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
    Terry Reedy, Aug 1, 2008
    #8
  9. Mel Guest

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

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

    Mel.
    Mel, Aug 2, 2008
    #9
  10. On Fri, 01 Aug 2008 22:47:04 -0400
    Mel <> 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 <> | 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.
    D'Arcy J.M. Cain, Aug 2, 2008
    #10
  11. 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_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
    Diez B. Roggisch, Aug 2, 2008
    #11
  12. Derek Martin Guest

    Terminology (Re: Strong/weak typing)

    On Fri, Aug 01, 2008 at 03:57:10PM +0000, Alan Franzoni wrote:
    > 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)

    iD8DBQFIlGlddjdlQoHP510RAoVyAKCUDmlZt7Zj0k8MJxhE46i+/Wcr9ACcDJpx
    IEVzJkH9LpBZnlUZpSopzQw=
    =jRre
    -----END PGP SIGNATURE-----
    Derek Martin, Aug 2, 2008
    #12
  13. Jorgen Grahn Guest

    On Fri, 01 Aug 2008 22:47:04 -0400, Mel <> wrote:
    > 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.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

    --
    // Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
    Jorgen Grahn, Aug 3, 2008
    #13
  14. Mel Guest

    Jorgen Grahn wrote:

    > 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.
    Mel, Aug 4, 2008
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kuan Zhou
    Replies:
    1
    Views:
    4,976
    Paul Uiterlinden
    Jan 24, 2005
  2. Josef Garvi
    Replies:
    1
    Views:
    608
    Josef Garvi
    May 27, 2004
  3. Gabriel Zachmann

    strong/weak typing and pointers

    Gabriel Zachmann, Oct 28, 2004, in forum: Python
    Replies:
    102
    Views:
    1,779
    Carl Banks
    Nov 13, 2004
  4. namekuseijin

    Re: "Strong typing vs. strong testing"

    namekuseijin, Sep 27, 2010, in forum: C Programming
    Replies:
    214
    Views:
    3,325
    Nick Keighley
    Oct 17, 2010
  5. namekuseijin

    Re: "Strong typing vs. strong testing"

    namekuseijin, Sep 27, 2010, in forum: Python
    Replies:
    229
    Views:
    3,428
    Gregory Ewing
    Oct 29, 2010
Loading...

Share This Page