«

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

Thanks for the info... Kinda comforting that Guido's syntactic ideas
were somewhat similar to my own.

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

In article <mailman.2860.1141769413.27775.python->,
"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,

> 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

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 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

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