RE: Type Hinting vs Type Checking and Preconditions

Discussion in 'Python' started by Delaney, Timothy (Tim), Mar 7, 2006.

  1. wrote:

    > You can look at this, its API looks very well thought out to me:
    > http://oakwinter.com/code/typecheck/
    >
    >> Now, on the other hand, if we were to introduce a purely optional
    >> type hint to the function prototype, such as follows:
    >> def multiplyByTwo(value:int): return value * 2

    >
    > I don't think Python will have something like this...


    It's actually something that has been being considered for Python 3.0
    for a long time.

    Search for `python optional static typing` for discussions - the first
    two links from Google are blog entries by Guido from a year ago (there's
    also a third one linked from PEP 3000).

    Tim Delaney
     
    Delaney, Timothy (Tim), Mar 7, 2006
    #1
    1. Advertising

  2. Delaney, Timothy (Tim)

    Tom Bradford Guest

    Thanks for the info... Kinda comforting that Guido's syntactic ideas
    were somewhat similar to my own.
     
    Tom Bradford, Mar 7, 2006
    #2
    1. Advertising

  3. Delaney, Timothy (Tim)

    Guest

    Delaney, Timothy (Tim):
    > Search for `python optional static typing` for discussions - the first
    > two links from Google are blog entries by Guido from a year ago (there's
    > also a third one linked from PEP 3000).


    I am sorry. Yes, I have read those posts about a year ago, and I
    remember most of them, but I can remember that the syntax was discussed
    a lot... Nothing real has come out of those discussions, I think. We'll
    see.
    I like the typecheck API, it's not perfect but it's not bad (and can
    probably be improved still, removing some parts, changing some names,
    adding some things, etc.) and it allows most of the things suggested by
    Guido, plus other things, without the need to change the language
    syntax at all. Can't such annotations be used by the interpreter (and
    by Psyco) to produce much faster code? I remember that for Guido the
    purpose of optional types wasn't much for speed, but for other purposes
    (like to build very large and complex systems, as Zope), but using it
    for speed purposes in smaller programs too can be cute :)

    Bye,
    bearophile
     
    , Mar 7, 2006
    #3
  4. Delaney, Timothy (Tim)

    Donn Cave Guest

    In article <>,
    "Delaney, Timothy (Tim)" <> wrote:

    > wrote:
    >
    > > You can look at this, its API looks very well thought out to me:
    > > http://oakwinter.com/code/typecheck/
    > >
    > >> Now, on the other hand, if we were to introduce a purely optional
    > >> type hint to the function prototype, such as follows:
    > >> def multiplyByTwo(value:int): return value * 2

    > >
    > > I don't think Python will have something like this...

    >
    > It's actually something that has been being considered for Python 3.0
    > for a long time.
    >
    > Search for `python optional static typing` for discussions - the first
    > two links from Google are blog entries by Guido from a year ago (there's
    > also a third one linked from PEP 3000).


    But surely, never with the proposed semantics (quoted to
    match [non]attribution), with automatic conversion of
    "14" to 14 --

    > >> The python interpreter could do the work of casting the incoming
    > >> parameter to an int (if it is not already) before it is multipled,
    > >> resulting in the desired result or a typecasting error otherwise.
    > >> Furthermore, it could do it more efficiently than a developer having to
    > >> put conditional code at the beginning of traditionally typecasting
    > >> functions.


    I know awk works a bit like that, maybe Perl? but it's
    surely way out of place in Python.

    Donn Cave,
     
    Donn Cave, Mar 8, 2006
    #4
  5. Delaney, Timothy (Tim)

    msoulier Guest

    > It's actually something that has been being considered for Python 3.0
    > for a long time.


    I will never understand why we can't just leave a good language alone,
    and instead keep trying to make it everything for all people. If I want
    strong typing, I'll use Java or C++. And don't tell me to just "not use
    it", because the more that's added to the core language, the harder it
    becomes to inherit code, the ease of which being something that Python
    is supposed to stand for.

    Mike Soulier
     
    msoulier, Mar 8, 2006
    #5
  6. Delaney, Timothy (Tim)

    Tom Bradford Guest

    Really what we're talking about here is weak typing in the form of
    optional type hinting performed on a function by function basis. As an
    option, what it would do is allow an author to semantically 'hint' to
    the interpreter that a function is expecting a certain type, and
    perform any implicit conversion if the passed type is not what was
    expected, thus translating to a semantically expected result.

    It is my feeling that this doesn't represent a sea-change in the way
    Python does things, and it's certainly *not* the way things are done in
    Java or C++, as both of those languages are strongly typed, wherein you
    can't even pass a parameter if it isn't of the expected type, or a
    subclass thereof.

    The fact is, that with a system such as this, you could just 'not use
    it', and none would be the wiser, as it's an authorship extension
    rather than a calling extension. What I was suggesting is that nothing
    change other than function/method prototypes, and that everything,
    everwhere, at all times continues to be represented as scalars.
     
    Tom Bradford, Mar 8, 2006
    #6
  7. Tom Bradford wrote:
    > Really what we're talking about here is weak typing in the form of
    > optional type hinting performed on a function by function basis....

    Not what most of the world calls weak typing.

    > It is my feeling that this doesn't represent a sea-change in the way
    > Python does things, and it's certainly *not* the way things are done in
    > Java or C++, as both of those languages are strongly typed, wherein you
    > can't even pass a parameter if it isn't of the expected type, or a
    > subclass thereof.

    But I would call both of those languages weakly typed (and Python
    strongly typed).
    Any _correct_ type system must have contra-variant typing on results and
    co-variant typing on values.

    Java's type system breaks because it has decided to have arrays (which
    are both in and out, therefore "pinned" as to type) obey the subtype
    relationship of the elements of that array.

    So:
    array of truck-driver

    is a subtype of:
    array of driver

    and a procedure:

    procedure stores(driver[] arr, driver gus)
    arr[1] = gus

    Will type check as type-correct when passed a taxi-cab driver.

    I suspect such problems can be found in C++ as well, but I never
    hunted very hard.

    --Scott David Daniels
     
    Scott David Daniels, Mar 8, 2006
    #7
  8. Delaney, Timothy (Tim)

    Paul Boddie Guest

    Tom Bradford skrev:
    > Really what we're talking about here is weak typing in the form of


    Careful with the terminology! Weak typing is something else entirely.

    > optional type hinting performed on a function by function basis. As an
    > option, what it would do is allow an author to semantically 'hint' to
    > the interpreter that a function is expecting a certain type, and
    > perform any implicit conversion if the passed type is not what was
    > expected, thus translating to a semantically expected result.


    But is it adaptation or some weaker form of that concept, where "x :
    int" just means that you call the "int" function on "x" to coerce it
    (with an exception raised if that doesn't work), or is it more of a
    type-checking system, where you call "isinstance(x, int)" and raise an
    exception if that test returns false?

    > It is my feeling that this doesn't represent a sea-change in the way
    > Python does things, and it's certainly *not* the way things are done in
    > Java or C++, as both of those languages are strongly typed, wherein you
    > can't even pass a parameter if it isn't of the expected type, or a
    > subclass thereof.


    Careful with the terminology, again! That calling a function with the
    wrong type of argument ultimately leads to a run-time exception is
    actually a sign that Python also has strong typing - it just doesn't
    enforce particular argument types when actually calling a function or
    method (but typically instead when looking up attributes and methods on
    objects). Certainly, explicit type-checking (the second case above) is
    different from how Python currently does things (except for a few
    low-level calls), whereas some form of coercion is not the same as how
    Python currently behaves, since passing an object of some
    previously-unknown numeric type into a function which performs
    multiplication wouldn't result in the conversion of that object into an
    int or float, for example.

    > The fact is, that with a system such as this, you could just 'not use
    > it', and none would be the wiser, as it's an authorship extension
    > rather than a calling extension. What I was suggesting is that nothing
    > change other than function/method prototypes, and that everything,
    > everwhere, at all times continues to be represented as scalars.


    I don't follow the scalars reference - sounds like Perl terminology to
    me - but whilst "x : int" might be convenient notation for either
    type-checking or coercion/adaptation, the problem would soon arise
    where paranoid developers add such notation to their code in order to
    insist that only types that they can think of be used with their APIs.
    The consequence would be arbitrary limits on extensibility - you'd
    actually have to update code to work with new or
    previously-unconsidered kinds of objects - and with this, you'd soon be
    "the wiser" about usage of the feature in question.

    As C++ has shown, when designing exotic notations to describe types,
    you end up with a language in itself to do that job; at which point you
    might arguably be better served by either writing your type
    declarations in Python rather than starting with an insufficient
    mini-language which grows into a monster or, as I'd rather like to
    imagine, employing alternative approaches to deal with program
    analysis.

    Paul
     
    Paul Boddie, Mar 8, 2006
    #8
    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. Replies:
    4
    Views:
    647
  2. Tom Bradford
    Replies:
    4
    Views:
    639
    Florian Diesch
    Mar 10, 2006
  3. Tom Bradford
    Replies:
    3
    Views:
    399
    Alex Martelli
    Mar 9, 2006
  4. Randell D.
    Replies:
    12
    Views:
    264
    Randell D.
    Jul 6, 2005
  5. Joseph L. Casale

    Descriptor type hinting

    Joseph L. Casale, Feb 27, 2014, in forum: Python
    Replies:
    2
    Views:
    73
    Joseph L. Casale
    Feb 28, 2014
Loading...

Share This Page