From: Philippe Fremy <pfremy@inseal.com>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] type inference for python
Date: Wed, 02 Feb 2005 00:06:35 +0100 [thread overview]
Message-ID: <42000B7B.5000204@inseal.com> (raw)
In-Reply-To: <1107261444.23973.324.camel@pelican.wigram>
Hi Skaller,
Thank you for your very detailed explanation. You have obviously
dedicated a lot of thought to the problem. I know understand that it is
indeed necessary to almost rerun the interpreter to check the code.
Actually, that's what pychecker does.
But even running the interprter would probably not be enough. I knew
when asking that the problem was probably beyound my reach. Now, I know
why :-).
> Sure, but what do you mean 'trick Python'? Writing code
> based on the specified semantics -- including exception handling --
> is not a trick.
Actually, I realise that there are many usage patterns for python. Some
people like you use it for its highly dynamic nature. I use it mainly as
an easy Java/C++ replacement and it would be ok for me to drop many of
the dynamic aspect, in order to get more type and execution safety.
> Unfortunately, 'most code' is easily type checked by a
> single test case.
Well, it is so easy to make a small mistake with big consequences. An
intern just wrote some code for me where he was supposed to return a
list. In one case, he would return a None instead of an empty list, and
broke the program the whole concept (always review the code written by
intenrs :-).
There should be a way to avoid that kind of silly mistakes.
> you might consider establishing a protocol for type annotations
This is already being discussed in python-dev by more advanced
programmer than I am. And raises a lot of controversy on how to do it
and whether it will be useful.
Anyway, discussing the topic gave me a higher view of the problem.
Python is currently a single solution (CPython) that lends itself to
many programming paradigm, but in an unsatisfactory manners for some of
them.
I would like to get rid of the dynamically nature of the language
sometimes, which some people consider equivalent to killing it. That's
how I would react if somebody suggested to "remove all the OO crap of
python" and use it like a good pascal replacement. Still, it would be a
valid use.
The good news is that a solution is coming for this problem: pypy. This
generated implementation of python should allows to build python
interpreter with different feature set. They also have a nice program
flow chart where they can infer types and optimise code to a wild level.
So, I just have to find myself another fun project :-). Thank you for
your answers.
regards,
Philippe
--
Philippe Fremy
InSeal Technical Director
tel: +33 6 07 98 76 44
next prev parent reply other threads:[~2005-02-01 23:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-01 5:26 Philippe Fremy
2005-02-01 6:56 ` [Caml-list] " Richard Cole
2005-02-01 6:58 ` skaller
2005-02-01 10:54 ` Philippe Fremy
2005-02-01 12:37 ` skaller
2005-02-01 23:06 ` Philippe Fremy [this message]
2005-02-01 7:25 ` Nicolas Cannasse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42000B7B.5000204@inseal.com \
--to=pfremy@inseal.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox