Re: Next step after pychecker

Francis> But Skip, I am sure that you can easily find an example by Francis> yourself. For example, replace "+" by a function that does Francis> different things depending on its argument type. Sure. I was thinking of the optimization use of type inferencing, forgetting the subject o

Re: Next step after pychecker

On Tue, 01 Feb 2005 16:27:48 -0600, John Roth wrote: > > "Sylvain Thenault" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> On Tue, 01 Feb 2005 05:18:12 +0100, Philippe Fremy wrote: >> >> Did you take a look at the starkiller [1] and pypy projects [2] ? > > Has anything happened

Re: Next step after pychecker

Skip Montanaro wrote: Francis> "Every well-formed expression of the language can be assigned a Francis> type that can be deduced from the constituents of the Francis> expression alone." Bird and Wadler, Introduction to Functional Francis> Programming, 1988 Francis> This is certa

Re: Next step after pychecker

To complete Philippe's answer : As Bird and Wadler continue : "The major consequence of the discipline imposed by strong-typing is that any expression which cannot be assigned a "sensible" type is regarded as not being well-formed and is rejected by the computer before evaluation. Such express

Re: Next step after pychecker

Skip Montanaro wrote: Francis> "Every well-formed expression of the language can be assigned a Francis> type that can be deduced from the constituents of the Francis> expression alone." Bird and Wadler, Introduction to Functional Francis> Programming, 1988 Francis> This is certa

Re: Next step after pychecker

Le mercredi 2 Février 2005 00:28, Philippe Fremy a écrit : > I really hope that pypy will provide that kind of choice. Give me python > with eiffel like contracts, super speed optimisation thank to type > inference and I will be super happy. That's also my dream. Type inference not so much for spe

Re: Next step after pychecker

Philippe Fremy <[EMAIL PROTECTED]> wrote: > Any other idea of a fun python improvement project I could join without > too much hassle ? I can't help but thinking that pychecker ought to be > able to do a better job. Have a look at pypy -- around the key idea of reimplementing Python's runtime in

Re: Next step after pychecker

"Steven Bethard" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > So I assume the language spec is basically the grammar and the > Language Reference docs[1]? Yes. The de facto governing syntax specification is the grammar file in the source code from which the parser is generate

Re: Next step after pychecker

Terry Reedy wrote: > Nothing about bytecode is part of the language spec. And CPython > bytecode is version specific. If the CPython implementation changed > from a virtual stack machine to a virtual register machine, as was > once discussed, the stack-oriented byte code would be replaced by a >

Re: Next step after pychecker

"Steven Bethard" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I don't know much about what pychecker does, but if it works with the > bytecode, shouldn't it be fine for jython and IronPython? I thought the > bytecode was part of the language spec, and what was CPython specific

Re: Next step after pychecker

Francis> "Every well-formed expression of the language can be assigned a Francis> type that can be deduced from the constituents of the Francis> expression alone." Bird and Wadler, Introduction to Functional Francis> Programming, 1988 Francis> This is certainly not the case fo

Re: Next step after pychecker

I do not want to discourage Philippe Fremy but I think that this would be very very difficult to do without modifying Python itself. That's the conclusion I reached to too after lurking on the ocaml list. What FP languages rely upon to achieve type inference is a feature named "strong typing".

Re: Next step after pychecker

"Sylvain Thenault" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Tue, 01 Feb 2005 05:18:12 +0100, Philippe Fremy wrote: Did you take a look at the starkiller [1] and pypy projects [2] ? Has anything happened to Starkiller since PyCon 2004? The latest mention I can find on Google i

RE: Next step after pychecker

huy wrote: > do not yet have good coverage. TDD is a quite hard to practice as a > beginner. It's even harder to bolt onto an existing codebase :( Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list

Re: Next step after pychecker [StarKiller?]

Hi, Do you have some more pointers to the StarKiller project ? According to the paper some implementation of this very interesting project exists. Thank you Francis Girard Le mardi 1 Février 2005 11:21, Sylvain Thenault a écrit : > On Tue, 01 Feb 2005 05:18:12 +0100, Philippe Fremy wrote: > >

Re: Next step after pychecker

Hi, I do not want to discourage Philippe Fremy but I think that this would be very very difficult to do without modifying Python itself. What FP languages rely upon to achieve type inference is a feature named "strong typing". A clear definition of strong typing is : "Every well-formed express

Re: Next step after pychecker

A frequent error I encounter try: ...do something... except IOError: log('encounter an error %s line %d' % filename) Here in the string interpolation I should supply (filename,lineno). Usually I have a lot of unittesting to catch syntax error in the main code. But it is very difficu

Re: Next step after pychecker

> But it can be useful to restrict type variety in certain situations > e.g. prime number calculation :) And it would probably also be useful > to check violations of restrictions before running the program in > normal mode. But that's what (oca)ml and the like do - they exactly don't force you to

Re: Next step after pychecker

Jacek Generowicz schrieb: You also gain not having to clutter your code with all the type declarations. And you gain not having to decide what types you will use too early on in development. But it can be useful to restrict type variety in certain situations e.g. prime number calculation :) And it

Re: Next step after pychecker

On Tue, 01 Feb 2005 05:18:12 +0100, Philippe Fremy wrote: > Hi, Hi > I would like to develop a tool that goes one step further than pychecker > to ensure python program validity. The idea would be to get close to what > people get on ocaml: a static verification of all types of the program,

Re: Next step after pychecker

Paul Rubin writes: > Philippe Fremy <[EMAIL PROTECTED]> writes: > > I would like to develop a tool that goes one step further than > > pychecker to ensure python program validity. The idea would be to get > > close to what people get on ocaml: a static verification of al

Re: Next step after pychecker

Paul Rubin wrote: Philippe Fremy <[EMAIL PROTECTED]> writes: I would like to develop a tool that goes one step further than pychecker to ensure python program validity. The idea would be to get close to what people get on ocaml: a static verification of all types of the program, without any kind of

Re: Next step after pychecker

Philippe Fremy wrote: I would like to develop a tool that goes one step further than pychecker to ensure python program validity. The idea would be to get close to what people get on ocaml: a static verification of all types of the program, without any kind of variable declaration. This would de

Re: Next step after pychecker

Philippe Fremy <[EMAIL PROTECTED]> writes: > I would like to develop a tool that goes one step further than > pychecker to ensure python program validity. The idea would be to get > close to what people get on ocaml: a static verification of all types > of the program, without any kind of variable

Next step after pychecker

Hi, I would like to develop a tool that goes one step further than pychecker to ensure python program validity. The idea would be to get close to what people get on ocaml: a static verification of all types of the program, without any kind of variable declaration. This would definitely brin