Optional Static Typing

Discussion in 'Python' started by bearophileHUGS@lycos.com, Dec 23, 2004.

  1. Guest

    Adding Optional Static Typing to Python looks like a quite complex
    thing, but useful too:
    http://www.artima.com/weblogs/viewpost.jsp?thread=85551

    I have just a couple of notes:

    Boo (http://boo.codehaus.org/) is a different language, but I like its
    "as" instead of ":" and "->", to have:
    def min(a as iterable(T)) as T:
    Instead of:
    def min(a: iterable(T)) -> T:


    Sometimes it can be useful to mix parts with static typing and parts
    without it in the same module (because dynamic typing is very useful
    sometimes), but some other times you want to be sure to have a full
    typed and checked module. So maybe a kind of compiler directive (like
    the # used to define encoding) can be used to define a module fully
    typed and fully checked by a pychecker-like. (A module with static
    typing can be very useful for a "true" python compiler too.)
    Bear hugs,
    bearophile
     
    , Dec 23, 2004
    #1
    1. Advertising

  2. Doug Holton Guest

    wrote:
    > Adding Optional Static Typing to Python looks like a quite complex
    > thing, but useful too:
    > http://www.artima.com/weblogs/viewpost.jsp?thread=85551


    Thanks for pointing out that article by Guido van Rossum. Looks like it
    just came out today. It is something that may be added to Python 3.0:
    http://www.python.org/moin/Python3.0

    > Sometimes it can be useful to mix parts with static typing and parts
    > without it in the same module (because dynamic typing is very useful
    > sometimes), but some other times you want to be sure to have a full
    > typed and checked module.


    The closest option right now in CPython is to use Pyrex.
    http://nz.cosc.canterbury.ac.nz/~greg/python/Pyrex/


    > Boo (http://boo.codehaus.org/) is a different language, but I like its
    > "as" instead of ":" and "->", to have:
    > def min(a as iterable(T)) as T:
    > Instead of:
    > def min(a: iterable(T)) -> T:


    Right, you're first example is how Boo does it, and the 2nd is how Guido
    proposed to do it in Python 3.0.

    Boo flips the problem around. Instead of optional static typing,
    everything is statically typed by default (but with type inference so
    you do not always need to explicitly declare the type), and it has
    optional runtime typing that works like python's ("duck typing").
    http://svn.boo.codehaus.org/trunk/tests/testcases/integration/duck-2.boo?view=auto
    http://svn.boo.codehaus.org/trunk/examples/duck-typing/XmlObject.boo?view=auto
    http://svn.boo.codehaus.org/trunk/tests/testcases/integration/duck-5.boo?view=auto
    http://boo.codehaus.org/Duck Typing

    And there are some disadvantages to doing it this way. It means Python
    is more flexible to use than Boo, as I stated a couple months back:
    http://groups-beta.google.com/group...ader=1&q=boo python-like#doc_7a51cdc9ffecbc72
     
    Doug Holton, Dec 23, 2004
    #2
    1. Advertising

  3. John Roth Guest

    <> wrote in message
    news:...
    > Adding Optional Static Typing to Python looks like a quite complex
    > thing, but useful too:
    > http://www.artima.com/weblogs/viewpost.jsp?thread=85551


    One of the comments on Artima asks a rather profound
    question: static typing is an answer. What's the question?
    (That's a paraphrase.)

    The answer that everyone seems to give is that it
    prevents errors and clarifies the program.

    I'm not convinced that it's all that effective at either objective.
    My viewpoint on this is
    that of someone who generally uses test first programming
    (as in Test Driven Development or Extreme Programming).
    Many of the supposed advantages simply aren't there
    when you go to the discipline of writing a test and then
    writing exactly the code needed to make the test pass, and
    not one keystroke more.

    Most of the kinds of error that static typing is supposed
    to catch simply don't persist for more than a minute when
    you do test driven development.

    This isn't to say TDD is the be-all and end-all of
    correctness. Formal methods and formal inspections
    both have very good reputations. In fact, the technique
    with the best reputation is embodied in a sign that was
    on the wall of every office of the old IBM: Think!

    So let's look a bit deeper. As far as I remember, static
    typing came out of the formal methods work in the '70s
    by people like Djikstra, Hoar and Wirth (to name only
    a few.) The thing is, if you properly use the formal program
    derivation methods they advocated, then you don't need
    it: your program will be as correct as it's possible to get
    short of your being promoted to godhood.

    So the conclusion here is that static typing is an attempt
    to make programming safe for people that shouldn't be
    programming in the first place. This may sound a bit
    cynical, but most real uber-programmers have either
    Lisp or Smalltalk in their backgrounds, and
    frequently both one. Neither of those languages
    have static typing, and they simply don't need it.

    So if the problem is reducing errors, then maybe
    we should be working on the places where errors
    show up.

    Another point that's sometimes raised is that it's
    useful to provide type information via reflection.
    I used to think that was a valid concern until I
    started work on PyFit. I had to put a rather
    simplistic metadata facility into the program to
    substitute for not having type information, and
    I found that it was incredibly useful for other
    things that you can't get from reflection on
    type data.

    John Roth

    > Bear hugs,
    > bearophile
    >
     
    John Roth, Dec 23, 2004
    #3
  4. John Roth wrote:
    >
    > One of the comments on Artima asks a rather profound
    > question: static typing is an answer. What's the question?
    > (That's a paraphrase.)
    >
    > The answer that everyone seems to give is that it
    > prevents errors and clarifies the program.


    <shrug> It might just be me, but I thought it was to simplify code
    analysis and compilation. (That is, for the use of static typing in
    general, not for Python in particular.)

    Looking at C, it's doubtful error prevention and program clarification
    was a serious objective in the static typing system. It's more
    reasonable to conclude that C is statically typed because it allows the
    compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular
    variable, and to make sure the proper addition opcodes get put down.

    Now whether this would be useful for Python is an open question.

    > Many of the supposed advantages simply aren't there
    > when you go to the discipline of writing a test and then
    > writing exactly the code needed to make the test pass, and
    > not one keystroke more.

    ....
    > This isn't to say TDD is the be-all and end-all of
    > correctness.


    Right. And unit tests don't do anything for people who don't use them.
    The question is, should Guido state "TDD is the one true way to program
    in Python.", or should concessions be made in the language design for
    those who don't "drink the TDD Kool-aide".

    > So the conclusion here is that static typing is an attempt
    > to make programming safe for people that shouldn't be
    > programming in the first place.


    I rebut it thusly: "elitist bastard." <wink and a half>

    One of the draws of Python is that it's welcoming to newcomers and
    programmers of all talents. You don't have to be an "uber-programmer" to
    use it and use it well. Should we hobble it to suit poor programmers?
    No. But that's no reason why it can't be made to be easier and safer to
    use for the hobbyist when it doesn't compromise usefulness for the
    power-programmer. (My opinion) Python shouldn't have a sign on the door
    saying: "You must be this 'leet to enter."

    Will static typing be a boon for Python? Is it necessary? Or is it the
    trailhead on the road to Hades? <shrug> Only time will tell.
     
    Rocco Moretti, Dec 23, 2004
    #4
  5. Guest

    Doug Holton:

    >And there are some disadvantages to doing it this way.
    >It means Python is more flexible to use than Boo,

    I've just suggested the *syntax* that I like more.

    Bye,
    Bearophile
     
    , Dec 23, 2004
    #5
  6. John Roth Guest

    "Rocco Moretti" <> wrote in message
    news:cqf06r$g39$...
    > John Roth wrote:
    >> One of the comments on Artima asks a rather profound
    >> question: static typing is an answer. What's the question?
    >> (That's a paraphrase.)
    >>
    >> The answer that everyone seems to give is that it
    >> prevents errors and clarifies the program.

    >
    > <shrug> It might just be me, but I thought it was to simplify code
    > analysis and compilation. (That is, for the use of static typing in
    > general, not for Python in particular.)
    >
    > Looking at C, it's doubtful error prevention and program clarification was
    > a serious objective in the static typing system. It's more reasonable to
    > conclude that C is statically typed because it allows the compiler to more
    > easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make
    > sure the proper addition opcodes get put down.


    The C language does not have strong typing in the sense
    that most people use the term today.

    >
    > Now whether this would be useful for Python is an open question.
    >
    >> Many of the supposed advantages simply aren't there
    >> when you go to the discipline of writing a test and then
    >> writing exactly the code needed to make the test pass, and
    >> not one keystroke more.

    > ...
    >> This isn't to say TDD is the be-all and end-all of
    >> correctness.

    >
    > Right. And unit tests don't do anything for people who don't use them.


    Absolutely correct.

    > The question is, should Guido state "TDD is the one true way to program in
    > Python.", or should concessions be made in the language design for those
    > who don't "drink the TDD Kool-aide".


    Neither one. I hope you didn't mean that people
    who advocate TDD are suicidal fanatics, because
    that's exactly what "drink the kool-aid" means.

    >> So the conclusion here is that static typing is an attempt
    >> to make programming safe for people that shouldn't be
    >> programming in the first place.

    >
    > I rebut it thusly: "elitist bastard." <wink and a half>


    Bullshit. Where did you get your certificate in mind reading?

    Remember that all of the people who started this were
    computer science professors, and most of their experiance was
    with computer science students. They were also European
    computer science professors with a strong mathematical
    tendency; we have since learned that mathematicians and
    software developers think differently (see some comments
    by Don Knuth to that effect - don't have the reference handy.)

    They're the ones who were elitist: they strongly believed
    that you had to be a mathematician to be able to properly
    program, and that they were doing something good for
    the people who weren't fortunate enough to have a
    rigorous mathematical background by forcing them into
    the strait-jacket of static typing.

    Competent professional programmers are a different group,
    and need different facilities.

    > One of the draws of Python is that it's welcoming to newcomers and
    > programmers of all talents. You don't have to be an "uber-programmer" to
    > use it and use it well. Should we hobble it to suit poor programmers? No.
    > But that's no reason why it can't be made to be easier and safer to use
    > for the hobbyist when it doesn't compromise usefulness for the
    > power-programmer. (My opinion) Python shouldn't have a sign on the door
    > saying: "You must be this 'leet to enter."


    And it won't. Python has always had the "consenting adults"
    philosophy.

    > Will static typing be a boon for Python? Is it necessary? Or is it the
    > trailhead on the road to Hades? <shrug> Only time will tell.


    Since it won't happen, I'm not particularly worried about it.
    If it does, I'll find another language.

    John Roth
     
    John Roth, Dec 23, 2004
    #6
  7. John Roth wrote:

    > "Rocco Moretti" <> wrote
    >
    >> Looking at C, it's doubtful error prevention and program clarification
    >> was a serious objective in the static typing system. It's more
    >> reasonable to conclude that C is statically typed because it allows
    >> the compiler to more easily allocate 1 vs 2 vs 8 bytes for a
    >> particular variable, and to make sure the proper addition opcodes get
    >> put down.

    >
    > The C language does not have strong typing in the sense
    > that most people use the term today.


    Strong != Static

    As I understand it, strong typing means an object (variable) is what it
    is, and can't be changed to a different type without explicit conversion
    - weak typing being that an object can be any type, depending on which
    functions you use to look at it.

    Static typing is that a variable has a specific type, and can't hold a
    variable of a different type. This is opposed to dynamic typing, where
    the type of an (object in a) variable is flexible and determined at run
    time.

    Python - Strong, Dynamic
    C - Weak, Static
    Perl - Weak, Dynamic

    This is how I understand it. Could be wrong - wouldn't be surprised if I
    was, as it's a rather confusing issue at times.

    >> The question is, should Guido state "TDD is the one true way to
    >> program in Python.", or should concessions be made in the language
    >> design for those who don't "drink the TDD Kool-aide".

    >
    > Neither one. I hope you didn't mean that people
    > who advocate TDD are suicidal fanatics, because
    > that's exactly what "drink the kool-aid" means.


    The irony didn't travel well. All I meant is that in all the advocacy,
    it may get ignored that reasonable people might disagree about the value
    of TDD, that TDD is not a "be-all, end-all" for all people.

    "Concessions" also probably wasn't the right choice of word, as it
    implies the TDD people are giving something up. My point was, if Python
    is not going to be solely targeted at TDD, facilities that make other
    ways of doing things easier are likely (should) be included, as long as
    they don't negatively affect how the majority of the people who use
    Python do things.

    >>> So the conclusion here is that static typing is an attempt
    >>> to make programming safe for people that shouldn't be
    >>> programming in the first place.

    >>
    >> I rebut it thusly: "elitist bastard." <wink and a half>

    >
    > Bullshit. Where did you get your certificate in mind reading?


    Sorry. I didn't mean to imply that *you* were an elitist bastard. I
    merely meant that someone who would dismiss something as for "people
    that shouldn't be doing X in the first place" is likely biased by
    snobbery. You were merely restating someone else's opinion, and if I
    accidentally accused you of also holding it, I'm sorry.

    From the rest of your post, it seems we pretty much agree on the key
    point - different people have different ways of doing things, none of
    which are necessarily "wrong" in and of themselves. Python tries to be
    open and inclusive towards all who want to program, without sacrificing
    power for it's core users.

    Is there a group of people for whom static typing truly helps? I don't
    know. What I do know is that saying that you don't need static typing if
    you use TDD doesn't say anything about the helpfulness of static typing
    for those who don't use TDD. Whether the latter group is worth Python
    worrying about is a philosophical question on the future direction of
    Python best left to Guido.
     
    Rocco Moretti, Dec 23, 2004
    #7
  8. Peter Hansen Guest

    Koolaid (was Re: Optional Static Typing)

    John Roth wrote:
    > "Rocco Moretti" <> wrote:
    >> The question is, should Guido state "TDD is the one true way to
    >> program in Python.", or should concessions be made in the language
    >> design for those who don't "drink the TDD Kool-aide".

    >
    > Neither one. I hope you didn't mean that people
    > who advocate TDD are suicidal fanatics, because
    > that's exactly what "drink the kool-aid" means.


    I always thought the connotation was more that those who
    "drank the Kool-Aid" were unthinking drones, following what
    others told them to do.

    Reading Wikipedia's account of Jonestown, it seems
    that the truth is a mix of both the blind loyalty thing
    and the suicidal fanatic thing.

    I've heard this applied most often in recent years
    to XML, and while I can imagine some people who apply
    the phrase to those overusing XML might think they
    are effectively committing suicide, I'm pretty sure
    most times it is just used to mean "you are blindly
    doing what everybody else does without thinking about
    whether it's the right thing to do".

    -Peter

    P.S.: The ironic thing about all this is that it was
    actually something called "Flavor Aid", made by a
    company called Jel Sert (http://www.jelsert.com),
    and not Kool-Aid at all. What would be even funnier
    is if the expression doesn't derive from the Jonestown
    suicides and I've always just assumed it did...
     
    Peter Hansen, Dec 23, 2004
    #8
  9. <> wrote:

    > Adding Optional Static Typing to Python looks like a quite complex
    > thing, but useful too:
    > http://www.artima.com/weblogs/viewpost.jsp?thread=85551
    >
    > I have just a couple of notes:


    Guido doesn't read this group; if you want him to read your notes, post
    them as comments to Artima.

    _My_ personal note is that I'm now even gladder I got myself Van Roy's
    and Haridi's excellent "Concepts, Techniques and Models of Computer
    Programming" book as a Christmas self-gift, and my motivation for
    studying it in depth is renewed and refreshed...


    Alex
     
    Alex Martelli, Dec 24, 2004
    #9
  10. John Roth <> wrote:
    ...
    > question: static typing is an answer. What's the question?
    > (That's a paraphrase.)
    >
    > The answer that everyone seems to give is that it
    > prevents errors and clarifies the program.

    ...
    > Most of the kinds of error that static typing is supposed
    > to catch simply don't persist for more than a minute when
    > you do test driven development.


    ....which is exactly the point of the famous post by Robert ("Uncle Bob")
    Martin on another artima blog,
    http://www.artima.com/weblogs/viewpost.jsp?thread=4639 .


    Alex
     
    Alex Martelli, Dec 24, 2004
    #10
  11. Mike Meyer Guest

    "John Roth" <> writes:

    > <> wrote in message
    > This may sound a bit
    > cynical, but most real uber-programmers have either
    > Lisp or Smalltalk in their backgrounds, and
    > frequently both one. Neither of those languages
    > have static typing, and they simply don't need it.


    LISP has type declarations. Everybody I know doing production work in
    LISP uses them. It's the only way to get reasonable performance out of
    LISP compiled code.

    Which raises what, to me, is the central question. If we have optional
    static typing, can I get a performance enhancement out of it? If not,
    why bother?

    <mike
    --
    Mike Meyer <> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
     
    Mike Meyer, Dec 24, 2004
    #11
  12. Re: Optional Static Typing - Haskell?

    I've just started learning about Haskell. I suggest looking at this for an
    example.

    A good intro: http://www.haskell.org/tutorial
     
    Neal D. Becker, Dec 24, 2004
    #12
  13. Rahul Guest

    Hi.
    Well i am a newbie to python and maybe not qualified enough to make a
    comment on proposals to changes in python. My previous programming
    experience has been in Java and C. So maybe you will forgive me if i
    make any outlandish comments.

    But anyway here goes:

    I think instead what should be done is:

    1.def gcd(a,b) expects (int,int)

    Here the function is not enforcing type checking. The compiler should
    only generate warning when someone passes something which is not an int
    and should not generate an error.Maybe the person calling the function
    knows what he is doing and wants to pass the unexpected type.

    2.Another possibility is to let the function decide if the type is not
    what it is expecting. Maybe the function recvs some kind of flag which
    tells it that the type passed is not what it was expecting. So it can
    throw an error if it is really critical.

    3.In my post i am not stressing on adding 'expects' as keyword or
    something. Only that type should not be enforced and 'expects' makes
    this clear.

    Rahul Garg
     
    Rahul, Dec 24, 2004
    #13
  14. Re: Optional Static Typing - Haskell?

    Neal D. Becker <> wrote:

    > I've just started learning about Haskell. I suggest looking at this for an
    > example.
    >
    > A good intro: http://www.haskell.org/tutorial


    Haskell's a great language, but beware: its static typing is NOT
    optional -- it's rigorous. It can INFER types for you (just like, say,
    boo), that's a different issue. It also allows bounded genericity at
    compile time (like, say, C++'s templates without the hassles), and
    that's yet another (typeclasses are a great mechanism, btw).

    Languages with really optional static typing can be found; I think the
    premier example is still Dylan -- a kind of commonlisp without infix
    notation, unfortunately very out of fashion nowadays but still available
    (some good books, too).

    I love the explanations of Van Roy and Haridi, p. 104-106 of their book,
    though I may or may not agree with their conclusions (which are
    basically that the intrinsic difference is tiny -- they point to Oz and
    Alice as interoperable languages without and with static typing,
    respectively), all the points they make are good. Most importantly, I
    believe, the way dynamic typing allows real modularity (harder with
    static typing, since type discipline must be enforced across module
    boundaries), and "exploratory computing in a computation model that
    integrates several programming paradigms".

    "Dynamic typing is recommended", they conclude, "when programs must be
    as flexible as possible". I recommend reading the Agile Manifesto to
    understand why maximal flexibility is crucial in most real-world
    application programming -- and therefore why, in said real world rather
    than in the more academic circles Dr. Van Roy and Dr. Hadidi move in,
    dynamic typing is generally preferable, and not such a tiny issue as
    they make the difference to be. Still, they at least show more
    awareness of the issues, in devoting 3 excellent pages of discussion
    about it, pros and cons, than almost any other book I've seen -- most
    books have clearly delineated and preformed precedence one way or the
    other, so the discussion is rarely as balanced as that;).


    Alex
     
    Alex Martelli, Dec 24, 2004
    #14
  15. Nick Coghlan Guest

    Mike Meyer wrote:
    > Which raises what, to me, is the central question. If we have optional
    > static typing, can I get a performance enhancement out of it? If not,
    > why bother?


    I had some thoughts along the same lines, so I dug up PEP 246 and looked at how
    it could be enhanced to potentially support compile time code optimisation
    through static type declarations.

    The write up is here:
    http://boredomandlaziness.skystorm.net/2004/12/type-checking-in-python.html

    Cheers,
    Nick.

    --
    Nick Coghlan | | Brisbane, Australia
    ---------------------------------------------------------------
    http://boredomandlaziness.skystorm.net
     
    Nick Coghlan, Dec 24, 2004
    #15
  16. Tim Jarman Guest

    Re: Koolaid (was Re: Optional Static Typing)

    In article <>,
    Peter Hansen <> wrote:

    >
    > P.S.: The ironic thing about all this is that it was
    > actually something called "Flavor Aid", made by a
    > company called Jel Sert (http://www.jelsert.com),
    > and not Kool-Aid at all. What would be even funnier
    > is if the expression doesn't derive from the Jonestown
    > suicides and I've always just assumed it did...


    I always thought it was a reference to the Illuminatus! trilogy
    (http://tinyurl.com/5uhrz) by Robert Shea & Robert Anton Wilson. At
    least, I'm pretty sure that's where I came across it. Maybe they were
    referencing Jamestown?

    Now if only I could think of a connection between this and Python...

    --
    Remove luncheon meat to reply.
     
    Tim Jarman, Dec 24, 2004
    #16
  17. Donn Cave Guest

    Re: Optional Static Typing - Haskell?

    Quoth (Alex Martelli):
    ....
    | Haskell's a great language, but beware: its static typing is NOT
    | optional -- it's rigorous. It can INFER types for you (just like, say,
    | boo), that's a different issue. It also allows bounded genericity at
    | compile time (like, say, C++'s templates without the hassles), and
    | that's yet another (typeclasses are a great mechanism, btw).

    He didn't dwell much on it, but there was some mention of type
    inference, kind of as though that could be taken for granted.
    I guess this would necessarily be much more limited in scope
    than what Haskell et al. do.

    Donn Cave,


    -----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
    http://www.newsfeed.com The #1 Newsgroup Service in the World!
    -----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
     
    Donn Cave, Dec 24, 2004
    #17
  18. Re: Optional Static Typing - Haskell?

    Donn Cave <> wrote:

    > Quoth (Alex Martelli):
    > ...
    > | Haskell's a great language, but beware: its static typing is NOT
    > | optional -- it's rigorous. It can INFER types for you (just like, say,
    > | boo), that's a different issue. It also allows bounded genericity at
    > | compile time (like, say, C++'s templates without the hassles), and
    > | that's yet another (typeclasses are a great mechanism, btw).
    >
    > He didn't dwell much on it, but there was some mention of type
    > inference, kind of as though that could be taken for granted.
    > I guess this would necessarily be much more limited in scope
    > than what Haskell et al. do.


    Assuming that by "he" you mean GvR, I think I saw that too, yes. And
    yes, a language and particularly a typesystem never designed to
    facilitate inferencing are hard-to-impossible to retrofit with it in as
    thorough a way as one that's designed around the idea. (Conversely,
    making a really modular system work with static typing and inferencing
    is probably impossible; in practice, the type inferencer must examine
    all code, or a rather copious summary of it... it can't really work
    module by module in a nice, fully encapsulated way...).


    Alex
     
    Alex Martelli, Dec 24, 2004
    #18
  19. Rahul wrote:
    > 1.def gcd(a,b) expects (int,int)


    I presume by this syntax you mean something like:
    def gcd(a, b) expects (int, int):
    if b > a:
    a, b = b, a
    while a > b > 0:
    a, b = b, a % b
    return a

    > Here the function is not enforcing type checking. The compiler should
    > only generate warning when someone passes something which is not an int
    > and should not generate an error.Maybe the person calling the function
    > knows what he is doing and wants to pass the unexpected type.


    But if this is the case, why is it different from?:
    def gcd(a, b): # expects (int, int)
    return a * b

    > 2.Another possibility is to let the function decide if the type is not
    > what it is expecting. Maybe the function recvs some kind of flag which
    > tells it that the type passed is not what it was expecting. So it can
    > throw an error if it is really critical.


    Again, why make the test at all if you don't want to act on it?
    assert <boolexp> aborts if it is checked at all, but with __debug__
    defined as 1, it passes. Perhaps you are proposing that expects be
    used in that context.

    > 3.In my post i am not stressing on adding 'expects' as keyword or
    > something. Only that type should not be enforced and 'expects' makes
    > this clear.

    You need to explain why anyone would want to write expects at all.
    If you are expecting the code generation to change, you'd better
    enforce, rather than advise, unless you are defining points at which
    to do code specialization on types.

    --Scott David Daniels
     
    Scott David Daniels, Dec 24, 2004
    #19
  20. Rocco Moretti wrote:
    ....
    > Is there a group of people for whom static typing truly helps?


    Yes. Python doesn't at present compile down to a binary executable. (Py2exe
    don't really count since that's "just" tacking on a VM on the side (he says
    dimissively regarding something he thinks is cool :) )

    The closest I can get to this at present is pyrex - which essentially
    performs a translation from a very python like language to C, which you
    then compile, and if you do things right can produce standalone modules.
    Type declarations there are optional, and if omitted falls back to a python
    object. If they are included however, you can gain performance boosts for
    certain kinds of work. (Most often though you're simply interfacing to C
    code.)

    ie the groups that could benefit are those that currently go to C/C++
    extensions for performance boosts. (and of course those who just want
    binary executables :) (In the absence of Starkiller being released that
    is...)

    Regards,


    Michael.
     
    Michael Sparks, Dec 24, 2004
    #20
    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. Luis M. Gonzalez

    Guido & Optional Static Typing

    Luis M. Gonzalez, Dec 24, 2004, in forum: Python
    Replies:
    1
    Views:
    288
    Luis M. Gonzalez
    Dec 24, 2004
  2. Tim Churches
    Replies:
    2
    Views:
    305
    Scott David Daniels
    Dec 24, 2004
  3. Christian Convey

    Status of optional static typing in Python?

    Christian Convey, Jun 22, 2006, in forum: Python
    Replies:
    6
    Views:
    313
    John Roth
    Jun 23, 2006
  4. Russ P.

    optional static typing for Python

    Russ P., Jan 27, 2008, in forum: Python
    Replies:
    39
    Views:
    996
    Wildemar Wildenburger
    Jan 30, 2008
  5. Daniel Berger
    Replies:
    22
    Views:
    228
    gabriele renzi
    Dec 1, 2004
Loading...

Share This Page