Does Python really follow its philosophy of "Readability counts"?

[Bruno Desthuilliers]

Paul Rubin a écrit :
> Bruno Desthuilliers <bruno.42.desthuilliers at websiteburo.invalid> writes:
>>>  In my limited experience with
>>> Haskell (statically typed but very high level),
>> "dynamic" and "static" were not meant to concern typing here (or at
>> least not only typing).
> 
> I'm not sure what you mean by those terms then.

Python (and some other dynamic OOPLs) allow you to dynamically add / 
remove / replace attributes (inclunding methods), either on a 
per-instance or per-class (at least for class-based oned) basis.

>> Haskell and MLs are indeed statically typed, but with a powerfull type
>> inference system, which gives great support for genericity
>> <ot>(hmmm... is that the appropriate word ?)</ot>
> 
> I think you mean "polymorphism";

Yeps.

> genericity in functional programming
> usually means compile time reflection about types.  (It means
> something different in Java or Ada).
> 
>> Now these are functional languages, so the notion of "access
>> restriction" is just moot in this context !-)
> 
> I'm not sure what you mean by that; Haskell certainly supports access
> restrictions, through its type and module systems.

Same word, somehow different context. What I meant was that since 
functional languages are (supposedly) stateless, there's no state to 
make "private".

But you're right to correct me wrt/ existing access restrictions in Haskell.

>> Ok, I should probably have made clear I was thinking of a hi-level
>> dynamic _imperative_ language vs a low-level static _imperative_
>> language. FP is quite another world.
> 
> I'd say that Python's FP characteristics are an important part of its
> expressiveness.

Indeed - but they do not make Python a functional language[1]. Python is 
based on objects, not on functions, and quite a lot of the support for 
functional programing in Python comes from the object system. Just look 
how functools.partial is implemented. Yes, it could have been 
implemented with a HOF and closures (and there have been such 
implementations), but using a class is still the most pythonic way here.

[1] except for a very formal definition of "functional language".