type checking

Discussion in 'Python' started by sashan, Oct 12, 2003.

  1. sashan

    sashan Guest

    I'm a Python newbie. I have been using c++ for 5 years and before that I
    was programming in Pascal. The one thing that annoys me about python
    is dynamic typing because I find myself making typographical errors of
    the sort that would under C++ be picked up by the compiler at compiler
    time. With Python I have to wait for the error to appear at runtime in
    order for me to correct it. I find this inefficient. Any advice about
    how to get around this would be appreciated.
     
    sashan, Oct 12, 2003
    #1
    1. Advertising

  2. sashan

    Jules Dubois Guest

    On Sun, 12 Oct 2003 15:56:19 +1300, in article
    <bmafsm$3i9$>, sashan wrote:

    > [...] The one thing that annoys me about python
    > is dynamic typing because I find myself making typographical errors of
    > the sort that would under C++ be picked up by the compiler at compiler
    > time.


    Ask yourself how much static type-checking costs you versus how much
    dynamic type errors cost you. If your answer demands static type-checking,
    Python is not a good choice for you.

    > Any advice about
    > how to get around this would be appreciated.


    Python, Smalltalk, and other languages are designed without static
    type-checking. Getting around this kind of design decision can be
    exceptionally difficult or impossible.
     
    Jules Dubois, Oct 12, 2003
    #2
    1. Advertising

  3. On Sun, 12 Oct 2003 15:56:19 +1300, sashan <>
    wrote:

    >I'm a Python newbie. I have been using c++ for 5 years and before that I
    > was programming in Pascal. The one thing that annoys me about python
    >is dynamic typing because I find myself making typographical errors of
    >the sort that would under C++ be picked up by the compiler at compiler
    >time. With Python I have to wait for the error to appear at runtime in
    >order for me to correct it. I find this inefficient. Any advice about
    >how to get around this would be appreciated.


    Personally, I find that I rarely make these errors in Python. Having
    the right datatype is in any case no guarantee of having the right
    value.

    In Python, bugs are primarily avoided by writing clear code (so that
    it is hard to make non-obvious errors) and detected by testing (which
    is the only approach that checks whether the requirements are met).

    There are also alternative self-consistency checking schemes such as
    design-by-contract that may work well for you, though they do operate
    at run time rather than compile time.

    If you really do need static typing (as opposed to simply needing to
    get used to the change), Python is simply the wrong choice of
    language. Either Java, C# or Delphi may be a good option for you.


    --
    Steve Horne

    steve at ninereeds dot fsnet dot co dot uk
     
    Stephen Horne, Oct 12, 2003
    #3
  4. sashan

    Donn Cave Guest

    Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
    ....
    | If you really do need static typing (as opposed to simply needing to
    | get used to the change), Python is simply the wrong choice of
    | language. Either Java, C# or Delphi may be a good option for you.

    Also consider functional languages with strong static typing and
    type inference - Haskell, Clean, ML, Objective CAML. Even if they
    eventually turn out to be unsuitable for the task at hand, they
    offer an interesting and rigorous abstraction of computer programming.

    Donn Cave,
     
    Donn Cave, Oct 12, 2003
    #4
  5. sashan

    Terry Reedy Guest

    "sashan" <> wrote in message
    news:bmafsm$3i9$...
    > I'm a Python newbie. I have been using c++ for 5 years and before

    that I
    > was programming in Pascal. The one thing that annoys me about

    python
    > is dynamic typing because I find myself making typographical errors

    of
    > the sort that would under C++ be picked up by the compiler at

    compiler
    > time.


    I am beginning to realize that different people probably have
    different typo 'profiles', so that I missed typing checks less than I
    'missed' writing type declarations (which are another opportunity for
    error ;-).

    > With Python I have to wait for the error to appear at runtime in
    > order for me to correct it.


    In my experience with small functions and programs, Python error
    reports come about as fast or faster as C error reports did a decade
    ago. Syntax
    errors get reported at compile time for Python also.

    > I find this inefficient. Any advice about
    > how to get around this would be appreciated.


    I suspect that people sometimes became dependent on the system they
    use finding the errors it is good at finding, and become a bit
    careless with respect to that type of error and focus proofreading on
    others that that system is less good at finding. I probably worry
    less about syntax errors with Python than I did with Fortran on
    punched cards (and an hour or more of turnaround time).

    Terry J. Reedy
     
    Terry Reedy, Oct 12, 2003
    #5
  6. sashan

    F. GEIGER Guest

    "sashan" <> schrieb im Newsbeitrag
    news:bmafsm$3i9$...
    > I'm a Python newbie. I have been using c++ for 5 years and before that I
    > was programming in Pascal. The one thing that annoys me about python
    > is dynamic typing because I find myself making typographical errors of
    > the sort that would under C++ be picked up by the compiler at compiler
    > time. With Python I have to wait for the error to appear at runtime in
    > order for me to correct it. I find this inefficient. Any advice about
    > how to get around this would be appreciated.
    >


    Use pychecker for that. It really helps to find typos.

    Cheers
    Franz GEIGER
     
    F. GEIGER, Oct 12, 2003
    #6
  7. sashan

    Miki Tebeka Guest

    Hello sashan,

    > I'm a Python newbie. I have been using c++ for 5 years and before that I
    > was programming in Pascal. The one thing that annoys me about python
    > is dynamic typing because I find myself making typographical errors of
    > the sort that would under C++ be picked up by the compiler at compiler
    > time. With Python I have to wait for the error to appear at runtime in
    > order for me to correct it. I find this inefficient. Any advice about
    > how to get around this would be appreciated.


    I'll think you'll find dynamic typing saving you time. See
    http://www.mindview.net/WebLog/log-0025 for more details.

    pychecker does dome checking, but it can't find all the errors that a
    statically typed language compiler will find.

    IMO the best practice in dynamically typed language is to spend some
    of the time you've saved on writing an extensive testing framework.
    This will catch much more bugs (including logical ones) that no
    compiler will ever catch. See PyUnit for a good framework.

    HTH.
    Miki
     
    Miki Tebeka, Oct 12, 2003
    #7
  8. sashan

    sashan Guest


    >
    > I am beginning to realize that different people probably have
    > different typo 'profiles', so that I missed typing checks less than I
    > 'missed' writing type declarations (which are another opportunity for
    > error ;-).
    >
    >


    I suppose that's one way of looking at it. At least I'm not having to
    correct both the function signature in the header in implementation file.

    >
    > I suspect that people sometimes became dependent on the system they
    > use finding the errors it is good at finding,


    I think this is my situation at the moment.
     
    sashan, Oct 12, 2003
    #8
  9. sashan

    sashan Guest

    Donn Cave wrote:
    > Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
    > ...
    > | If you really do need static typing (as opposed to simply needing to
    > | get used to the change), Python is simply the wrong choice of
    > | language. Either Java, C# or Delphi may be a good option for you.
    >
    > Also consider functional languages with strong static typing and
    > type inference - Haskell, Clean, ML, Objective CAML. Even if they
    > eventually turn out to be unsuitable for the task at hand, they
    > offer an interesting and rigorous abstraction of computer programming.
    >
    > Donn Cave,


    If it was practical I'd use OCaml or Haskell but they don't have the
    external libraries I need.
     
    sashan, Oct 12, 2003
    #9
  10. sashan wrote:

    > Donn Cave wrote:
    >> Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
    >> ...
    >> | If you really do need static typing (as opposed to simply needing to
    >> | get used to the change), Python is simply the wrong choice of
    >> | language. Either Java, C# or Delphi may be a good option for you.
    >>
    >> Also consider functional languages with strong static typing and
    >> type inference - Haskell, Clean, ML, Objective CAML. Even if they
    >> eventually turn out to be unsuitable for the task at hand, they
    >> offer an interesting and rigorous abstraction of computer programming.
    >>
    >> Donn Cave,

    >
    > If it was practical I'd use OCaml or Haskell but they don't have the
    > external libraries I need.


    http://ocamlffi.sourceforge.net/

    SWIG also suppors OCaml since 1.3.14 (haven't tried that out).


    Alex
     
    Alex Martelli, Oct 12, 2003
    #10
  11. Donn Cave wrote:

    > Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
    > ...
    > | If you really do need static typing (as opposed to simply needing to
    > | get used to the change), Python is simply the wrong choice of
    > | language. Either Java, C# or Delphi may be a good option for you.
    >
    > Also consider functional languages with strong static typing and
    > type inference - Haskell, Clean, ML, Objective CAML. Even if they
    > eventually turn out to be unsuitable for the task at hand, they
    > offer an interesting and rigorous abstraction of computer programming.


    I'd like to second Donn's recommendation and express reservations
    on Stephen's. Java &c just don't have a high enough semantic level
    to give you the same productivity as Python. The languages Donn
    lists *DO* (well, I haven't actually tried out Clean, but it looks to me
    as if it does). O'CAML in particular is multi-paradigm, a bit rambling, and
    perhaps not with the most elegant syntax -- sort of like C++ in these
    respects -- but, also like C++ (and Python) takes a LOT of care to
    practically FIT IN with your need for solution (e.g. SWIG supports it
    to ease interfacing external C=coded libraries). And the base paradigm
    of O'CAML is statically typed (even too strict maybe, if you still have to
    write +. instead of just + when you're summing floats...) AND very high
    level (functional). Haskell is even more mind-expanding and much more
    elegant, though perhaps its practicality is (sigh) lesser. Standard ML may
    be a bit in-between, perhaps (don't know it as well as the others).

    In the end, if you're REALLY keen for static typing you owe it to yourself
    to try the real thing, rather than the semi-strict Java &c approaches. If
    you're looking to learn, Haskell is hard to beat; if to get practical
    solutions to problems, O'CAML may be better. Python is IMHO wonderful
    if you DON'T make a fetish of static typing (you might want to try Erlang
    for pure functional programming without static typing, btw).

    Many of us who used to revere static typing (e.g., Robert Martin, well
    noted consultant and author, former editor of C++Report) are on record
    as having acknowledged that dynamic typing in fact works better for us.
    It just took us a few years to realize this, and vast experience with both
    kinds of languages.

    If your mind is shaped differently from ours, so that static typing DOES
    work better for you even after you've thoroughly familiarized yourself with
    a good dynamic-typing language, then moving to a good static-typing
    language may indeed be the best strategy for you -- and today's wealth
    of choices means no practical restrictions need stop you from doing that.


    Alex
     
    Alex Martelli, Oct 12, 2003
    #11
  12. On Sun, 12 Oct 2003 10:42:12 GMT, Alex Martelli <>
    wrote:

    >Donn Cave wrote:
    >
    >> Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
    >> ...
    >> | If you really do need static typing (as opposed to simply needing to
    >> | get used to the change), Python is simply the wrong choice of
    >> | language. Either Java, C# or Delphi may be a good option for you.
    >>
    >> Also consider functional languages with strong static typing and
    >> type inference - Haskell, Clean, ML, Objective CAML. Even if they
    >> eventually turn out to be unsuitable for the task at hand, they
    >> offer an interesting and rigorous abstraction of computer programming.

    >
    >I'd like to second Donn's recommendation and express reservations
    >on Stephen's. Java &c just don't have a high enough semantic level
    >to give you the same productivity as Python.


    I suggested C# - _not_ C. That is a very different thing. C# is
    probably slightly higher level than Java - though not in Pythons
    league, of course.

    I made the suggestions I did mostly because I know each of those
    languages has a rich set of libraries available. I am far less certain
    of the extent of the libraries for functional languages as on the
    whole I've only played with them.

    A good language can mean big gains, but not necessarily as big as
    someone else having written key parts of your application for you in
    the form of libraries - and testing them too.

    So that, to me, is a key question - which (functional or other)
    languages have the richest and most mature libraries (obviously
    relevant to sashans requirements), and how do they compare to those
    available in Python on the one hand, or Java, C# etc on the other.

    An additional issue is familiarity - if sashan is having a hard time
    adapting to Python, I suspect he'll find functional languages require
    an even bigger paradigm shift. Java and C# require relatively few
    mindset adjustments relative to C++.


    --
    Steve Horne

    steve at ninereeds dot fsnet dot co dot uk
     
    Stephen Horne, Oct 12, 2003
    #12
  13. sashan

    Carl Banks Guest

    sashan wrote:
    > I'm a Python newbie. I have been using c++ for 5 years and before that I
    > was programming in Pascal. The one thing that annoys me about python
    > is dynamic typing because I find myself making typographical errors of
    > the sort that would under C++ be picked up by the compiler at compiler
    > time. With Python I have to wait for the error to appear at runtime in
    > order for me to correct it. I find this inefficient. Any advice about
    > how to get around this would be appreciated.



    Sashan, it seems that what you are looking for is not static typing,
    per se, but declarations. Here's an old post I made about a trick
    where you can declare variables, and have the function throw an
    exception if there are any undeclared locals:

    http://tinyurl.com/qnmc

    It does not declare types, but it catches typos. You might want to
    use it to help you transition to Python. However, if you're still
    using Python a few months from now (likely :), I bet you'll have
    adapted to Python's implicit variable declarations.


    --
    CARL BANKS http://www.aerojockey.com/software

    As the newest Lady Turnpot descended into the kitchen wrapped only in
    her celery-green dressing gown, her creamy bosom rising and falling
    like a temperamental souffle, her tart mouth pursed in distaste, the
    sous-chef whispered to the scullery boy, "I don't know what to make of
    her."
    --Laurel Fortuner, Montendre, France
    1992 Bulwer-Lytton Fiction Contest Winner
     
    Carl Banks, Oct 12, 2003
    #13
  14. Stephen Horne wrote:
    ...
    >>> | language. Either Java, C# or Delphi may be a good option for you.

    ...
    >>I'd like to second Donn's recommendation and express reservations
    >>on Stephen's. Java &c just don't have a high enough semantic level
    >>to give you the same productivity as Python.

    >
    > I suggested C# - _not_ C. That is a very different thing. C# is


    Sure. "&c" stands for "etc", in this context "and all the others [which
    you had mentioned]".

    > A good language can mean big gains, but not necessarily as big as
    > someone else having written key parts of your application for you in
    > the form of libraries - and testing them too.


    Definitely. But SWIG often helps a lot -- if the library's around for C,
    it's not far from your favourite SWIG-supported language.

    > An additional issue is familiarity - if sashan is having a hard time
    > adapting to Python, I suspect he'll find functional languages require
    > an even bigger paradigm shift. Java and C# require relatively few
    > mindset adjustments relative to C++.


    True, they're closer to C++ in many respects than Python is (except
    that Python, like C++, is multi-paradigm, has multiple inheritance,
    allows operator overloading, lets you pick and choose among GUI
    toolkits rather than coming with one, etc -- but probably not the kinds
    of things one will have most "mindset adjustments" about).

    By the same token, Java and C# will give few benefits if you already
    master C++ -- perhaps a little help with memory management to be
    offset against losing templates, a HUGE loss to adjust to, and such
    niceties as the "resource allocation is construction" idiom. If one
    masters C++ and is looking for productivity higher enough to matter,
    Python (or other similar VHLLs) and FP languages are much more
    likely to produce it than Java or C# are.


    Alex
     
    Alex Martelli, Oct 12, 2003
    #14
  15. sashan

    Anand Pillai Guest

    I consider Python as high-level psuedo-code. It helps me in
    programming, since you dont make mistakes while writing
    psuedo-code. So it follows by induction that you dont make
    these mistakes like static type errors while programming python.

    It is a different approach, by altering your thinking, rather
    than relying on tools. Works for me ;-)

    Write python program as you would write a flow chart or psuedo-code.
    The language constructs are so damn intuitive that it allows you
    the freedom to do so.

    In the second iteration you can do type checking by perhaps
    using the built-in 'type' meta call.


    -Anand

    sashan <> wrote in message news:<bmb6f1$qqj$>...
    > Donn Cave wrote:
    > > Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
    > > ...
    > > | If you really do need static typing (as opposed to simply needing to
    > > | get used to the change), Python is simply the wrong choice of
    > > | language. Either Java, C# or Delphi may be a good option for you.
    > >
    > > Also consider functional languages with strong static typing and
    > > type inference - Haskell, Clean, ML, Objective CAML. Even if they
    > > eventually turn out to be unsuitable for the task at hand, they
    > > offer an interesting and rigorous abstraction of computer programming.
    > >
    > > Donn Cave,

    >
    > If it was practical I'd use OCaml or Haskell but they don't have the
    > external libraries I need.
     
    Anand Pillai, Oct 13, 2003
    #15
  16. On 13 Oct 2003 00:50:18 -0700, (Anand Pillai)
    wrote:

    >I consider Python as high-level psuedo-code. It helps me in
    >programming, since you dont make mistakes while writing
    >psuedo-code. So it follows by induction that you dont make
    >these mistakes like static type errors while programming python.
    >
    >It is a different approach, by altering your thinking, rather
    >than relying on tools. Works for me ;-)


    While I agree that most likely sashan needs a change of mindset rather
    than a language with static typing, this is an unrealistically
    impressive claim.

    There is no context where I do not sometimes make mistakes, including
    pseudocode.

    Of course errors do tend to be much rarer in Python, mainly because I
    am concentrating on the program logic, rather than being distracted by
    the overheads of the language.


    --
    Steve Horne

    steve at ninereeds dot fsnet dot co dot uk
     
    Stephen Horne, Oct 13, 2003
    #16
  17. On Sun, 12 Oct 2003 20:27:50 GMT, Alex Martelli <>
    wrote:

    >Stephen Horne wrote:
    > ...
    >>>> | language. Either Java, C# or Delphi may be a good option for you.

    > ...
    >>>I'd like to second Donn's recommendation and express reservations
    >>>on Stephen's. Java &c just don't have a high enough semantic level
    >>>to give you the same productivity as Python.

    >>
    >> I suggested C# - _not_ C. That is a very different thing. C# is

    >
    >Sure. "&c" stands for "etc", in this context "and all the others [which
    >you had mentioned]".


    Sorry - I wasn't aware of that abbreviation.

    >> A good language can mean big gains, but not necessarily as big as
    >> someone else having written key parts of your application for you in
    >> the form of libraries - and testing them too.

    >
    >Definitely. But SWIG often helps a lot -- if the library's around for C,
    >it's not far from your favourite SWIG-supported language.


    Good point. Having heard of but never used SWIG, it's not something
    that I had considered.

    >By the same token, Java and C# will give few benefits if you already
    >master C++ -- perhaps a little help with memory management to be
    >offset against losing templates, a HUGE loss to adjust to, and such
    >niceties as the "resource allocation is construction" idiom.


    Yes, that is very true. I believe MS are adding generics to C#, but
    with such big changes being planned that just rubs in the fact that C#
    is an immature language resting on an immature library.

    I had assumed that the "resource allocation is construction" idiom
    could be applied in any language with both constructors and
    exceptions. There are only two issues that I can think of that would
    seriously affect it...

    1. If the language still tries to call a destructor for an object
    when its constructor raised an exception.

    2. The lack of automatic destruction of member and base components of
    an object if a later part of the objects constuctor propogates an
    exception.

    3. If the libraries do not consistently apply the idiom.

    I assume it's mainly the second and third part where this is an issue.

    It hasn't really been an issue so far, but I guess C# constructors
    should be written so that they never propogate an exception - the
    object should always be constructed in a self-consistent state even if
    that state flags an error. Which immediately defeats the whole point
    of exceptions.

    I guess this might be less serious in a language with full garbage
    collection - member fields which were initialised will still get
    garbage collected, for instance, and any resources they reference will
    get freed when that happens. But that seems like a dangerous system to
    rely on. For instance, what happens if you need to access one of those
    resources before the GC frees it.

    This is one issue I already have with Java/C# style garbage collection
    - if you need to ensure that resources are available when needed, you
    still end up doing explicit 'deletes' anyway. Fortunately, it's only
    in this particular case when that becomes impossible.

    In Python, it doesn't seem to be an issue - presumably because Pythons
    garbage collection is based on reference counting so destruction
    happens immediately when the last reference has gone. I'm not sure
    what happens when there are reference cycles, though - I know Python
    handles them, but I'm not sure if they delay the garbage collection.

    Hmmm - a thought provoking issue. Thanks for pointing it out.


    --
    Steve Horne

    steve at ninereeds dot fsnet dot co dot uk
     
    Stephen Horne, Oct 13, 2003
    #17
  18. Stephen Horne wrote:
    ...
    >>By the same token, Java and C# will give few benefits if you already
    >>master C++ -- perhaps a little help with memory management to be
    >>offset against losing templates, a HUGE loss to adjust to, and such
    >>niceties as the "resource allocation is construction" idiom.

    >
    > Yes, that is very true. I believe MS are adding generics to C#, but


    Generics are also coming in Java (I've lost track of the # of times
    i've heard them announced as imminent over the last few years, but
    surely ONE of these times it will be true:).

    > with such big changes being planned that just rubs in the fact that C#
    > is an immature language resting on an immature library.


    Can't say that of Java, yet "generics are coming" applies to both:).


    > I had assumed that the "resource allocation is construction" idiom
    > could be applied in any language with both constructors and
    > exceptions. There are only two issues that I can think of that would
    > seriously affect it...


    [then listing 3 of them -- nobody expects the spanish inquisition!-)]

    4. the destructor is called when it happens to be called, including
    perhaps never if the garbage collector never needs to reclaim
    _memory_, which is the only resource it directly tracks

    C++'s idiom depends on destruction happening _at once_ for
    automatic variables going out of scope:

    // some preliminaries executed w/o holding the lock
    {
    LockHolder holder(thelock);

    // the guts, executed while holding the lock
    }

    with LockHolder's ctor calling the acquire, and its dtor the
    release, for the lock being held; making the whole idiom roughly
    equivalent to, but handier than, Java's or Python's try/finally.

    If holder's destructor is liable to be called hours later when
    the GC needs it to recover a little memory, the idiom is no use.

    > rely on. For instance, what happens if you need to access one of those
    > resources before the GC frees it.


    Exactly.

    > In Python, it doesn't seem to be an issue - presumably because Pythons
    > garbage collection is based on reference counting so destruction
    > happens immediately when the last reference has gone. I'm not sure
    > what happens when there are reference cycles, though - I know Python
    > handles them, but I'm not sure if they delay the garbage collection.


    Yes, they do (delay the GC, and perhaps delay it indefinitely, since,
    in particular, reference loops including objects with __del__ are NOT
    unraveled -- the GC punts on the need to call the __del__'s in some
    order it cannot possibly infer).

    The "immediate destruction when last reference gone" is an implementation
    specific detail of CPython -- handy, but there's quite a price paid for
    it, so the _language_ makes no guarantees. So you have try/finally for
    those cases where you NEED guarantees (not as handy, admittedly).


    > Hmmm - a thought provoking issue. Thanks for pointing it out.


    You're welcome!


    Alex
     
    Alex Martelli, Oct 13, 2003
    #18
  19. Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk> writes:

    > In Python, it doesn't seem to be an issue - presumably because Pythons
    > garbage collection is based on reference counting so destruction
    > happens immediately when the last reference has gone. I'm not sure
    > what happens when there are reference cycles, though - I know Python
    > handles them, but I'm not sure if they delay the garbage collection.


    They do. By how much, well, depends.

    Cheers,
    mwh

    --
    I'm okay with intellegent buildings, I'm okay with non-sentient
    buildings. I have serious reservations about stupid buildings.
    -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)
     
    Michael Hudson, Oct 13, 2003
    #19
  20. On Mon, 13 Oct 2003 11:52:31 GMT, Alex Martelli <>
    wrote:

    >The "immediate destruction when last reference gone" is an implementation
    >specific detail of CPython -- handy, but there's quite a price paid for
    >it, so the _language_ makes no guarantees. So you have try/finally for
    >those cases where you NEED guarantees (not as handy, admittedly).


    Ah - I think I've just had one of those subtle but important paradigm
    shifts. Resource management (for resources other than memory) simply
    rests on slightly different language mechanisms in Python and Java
    than it does in C++.

    Oddly enough, I think my Python code has reflected this for some time
    without me noticing the issue.


    --
    Steve Horne

    steve at ninereeds dot fsnet dot co dot uk
     
    Stephen Horne, Oct 13, 2003
    #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. heyo
    Replies:
    3
    Views:
    944
    Dan Pop
    Apr 1, 2004
  2. Tom Bradford
    Replies:
    4
    Views:
    642
    Florian Diesch
    Mar 10, 2006
  3. Delaney, Timothy (Tim)

    RE: Type Hinting vs Type Checking and Preconditions

    Delaney, Timothy (Tim), Mar 7, 2006, in forum: Python
    Replies:
    7
    Views:
    512
    Paul Boddie
    Mar 8, 2006
  4. Tom Bradford
    Replies:
    3
    Views:
    402
    Alex Martelli
    Mar 9, 2006
  5. Randell D.
    Replies:
    12
    Views:
    265
    Randell D.
    Jul 6, 2005
Loading...

Share This Page