By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,402 Members | 1,047 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,402 IT Pros & Developers. It's quick & easy.

Optional Static Typing: Part II

P: n/a
Guido has posted a second blog entry on the optional static typing
initiative.
I like this a lot better than the first.

http://www.artima.com/weblogs/viewpost.jsp?thread=86641

Now, the base objective seems to be to incorporate PyChecker
functionality into the root. This in turn requires type inference,
which in turn strongly suggests type annotations to help the
inferencer out over rough spots.

I like this approach a lot.

There's also an explicit recognition that there are a lot of
use cases for being able to access type information at
run time.

I also like this. I'm kind of neutral to the idea of using it
for actual type checking: I don't think that it catches that
many errors if the developer is doing a decent job of
testing. However, since it's going to be supplemental to
type inference, it will be a lot less intrusive.

There's a new approach to interfaces that looks
intriguing. One nice part is the ability to include
Design By Contract type preconditions with the
interface. It will be even better if they can be checked
at compile time, or by the PyChecker functionality.

I have to say this turned my attitude around on the
subject: I'm quite in favor of the direction Guido
seems to be going.

John Roth
Jul 18 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Tue, 4 Jan 2005, John Roth wrote:
Guido has posted a second blog entry on the optional static typing
initiative.
I like this a lot better than the first.


Declarative approach is even more human-oriented than algorithmic one.
If Python is to support declarations, let it support declarative programming
paradigm with full-blown inference engine </joke>.

So, why not add some logic approach to type declarations? I hope
that "type" is understood in a generic programming way: it will be a
big win for Python to provide grounds for GP 'concept' concept ;)
Why not? Python program right now are nearer to GP than C++'s.
'Concept' is not mere "interface", but interface + semantic behaviour.
And to describe that behaviour logic is needed (right now it could be done
with asserts).

I propose to skip 'interface' support with Python and go stright to
GP concepts :>

This way Python will be ahead with innovation and type/interface/concept
declarations will not be seen as atavisms but a step forward from OOP.

I hope GvR waited so long not implementing interfaces to implement something
better, concepts for example ;-) Right now concepts are expressed informally
in the docstrings.
Sincerely yours, Roman Suzi
--
rn*@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3
Jul 18 '05 #2

P: n/a
John Roth <ne********@jhrothjr.com> wrote:
Now, the base objective seems to be to incorporate PyChecker
functionality into the root. This in turn requires type inference,
which in turn strongly suggests type annotations to help the
inferencer out over rough spots.

I like this approach a lot.


If he makes the type inferencer "proud", that might help alleviate
the fears around here that it will become standard practice to put
type annotations on everything. That is, if you explicitly annotate
a function in the same way that the inferencer would have inferenced
it, the PyChecker thingie would emit a message saying:

"I'm no dummy! I could have told you that foo() takes an 'int' and
returns a 'bool'. What do you think I am, stupid? Duuu-uhhh!"

:)

Jul 18 '05 #3

P: n/a
John Roth wrote:
http://www.artima.com/weblogs/viewpost.jsp?thread=86641


Nitpicking: I don't think he's necessarily in good company w.r.t. types
vs classes. Take Ada, for example. In Ada, a class is a set of types
(in particular, the type and all its subtypes), which is kind of the
opposite way Guido claims to see it. Not the Ada is relevant, and not
that there is ever any agreement on terminology in computer science,
but still.

Based on their English language meanings, I would tend to agree with
Ada's terminology. But, based on how the terminology developed for
computer languages (especially under the influence of C++), it seems
that most people would regard class as more of an implementation.

Another question: can anyone think of something an interface statement
could syntactically that an interface metaclass couldn't? I couldn't
think of anything, based on the description, and it's not like th BDFL
to throw out keywords for things that current syntax can handle. It
leads me to suspect that maybe he has something up his sleeve. Hmm.
--
CARL BANKS

Jul 18 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.