Adam DePrince wrote:
No amount of obfuscation is going to help you.
Theorically, that's true. Anything obfuscated can be broken, just like
the non obfuscated version. However it takes more skills and time to
break it. And that's the point. By raising the barrier for breaking a
product, you just
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
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
"str
Frequently, in Python, code which checks for types, rather than
checking for features, ends up being excessively restrictive and
insufficiently general.
That's true, but checking for the exact features that are going to be
needed by your code is usually quite complicated and painful to
maintain.
Hi Frans,
Since Python doesn't have static typing, how is the same result as traditional
function overloads results in acheived?
With dynamic typing obviously. :-)
You can not reproduce the C++ overload idiom but you can get something
close with manual type testing.
> To in a
> function
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
