Thoughts about Python

[John Roth]

"Marco Aschwanden" <PPNTWIMBXFFC at spammotel.com> wrote in message
news:15c2d03b.0402240311.395f5382 at posting.google.com...
> Hi
>
> I don't have to talk about the beauty of Python and its clear and
> readable syntax... but there are a few things that striked me while
> learning Python.
>
> I have collected those thoughts. I am sure there are many discussions
> on the "problems" mentioned here. But I had this thoughts without
> looking into any forums or anything... it is kind of feedback.
>
> Thanks for this marvellous language,
> Marco
>
>
>
> *** Problem: clumsy static class methods
>
> In order to create a static method we have to use a the builtin
> staticmethod(function):
>
> class C (object):
>     def f(arg1, arg2, ...): ...
>     f = staticmethod(f)
>
> Why? The speciality of a "static" method is: It has no access to any
> instance vars. The following class is easier to read and understand
> what a static method is about... as a positive side-effect: self is
> not available and it can't be used!

Since several people have already mentioned that the syntax
is a temporary expedient until such time as a better idea can
be agreed upon, I'll just add one thing. "self" is not a built-in.
There is no requirement that the first parameter of a method
be called "self", although it's easy enough to get that impression.
So it's not possible to distinguish static methods by not having
"self" as the first parameter.

> *** Problem: clumsy properties for classes
>
> property( [fget[, fset[, fdel[, doc]]]])
>
> class C(object):
>     def getx(self): return self.__x
>     def setx(self, value): self.__x = value
>     def delx(self): del self.__x
>     x = property(getx, setx, delx, "I'm the 'x' property.")

[blah...]

There's nothing standing in your way of writing a
metaclass to do this, you know.

> *** Problem: Many builtins are not necessary
>
> Many builtins are not necessary. To name a few: min / max / len
>
> This functions should be defined on the class:
>
> ["I", "like", "Python"].len()
> "I".len()
> {1:"I", "2":"like", 3:"Python"}.len()
> (1,2,3,4).len()
>
> "Throwing away" this builtins would flatten the alreay flat learning
> curve once more (you don't have to learn that many builtins) ... these
> functions belong to the class and they are naturally expected there.
> One weakness of a language as (Visual)Basic, PHP, ... is its payload
> of available functions... Python's OO helps here to diminish the need
> for lots of functions.

That's a common complaint of OO purists about Python. Most
of them miss one rather obvious point: single inheritance languages
that have a root object tend to load that object with lots of utility
functions as methods, and then expect that all derived classes will
kowtow to them and not change their meaning. That makes it very
difficult to add new universal methods: you'll run into existing
classes that use them for something else.

Python's method of doing it takes universal method names
out of a different name space.

> *** Problem: tuples are not necessary

Frankly, there is very little in any programming language that is
necessary. Back when I brushed up against computability theory,
I found that all programs can be written in a language with one operation:
a combination of subtract and conditional branch. That's hardly
practical, though. The question is whether a feature serves a useful
purpose.

Tuples serve two distinct purposes. One is as a cheap version
of a C struct: that is, a data structure in which each element
serves a conceptually different purpose.

The other is as a structure that is immutable so it can be used
as a key in a dict.

One thing to understand about this is that immutability is key:
dicts depend on having a hash key that is somehow derived
from the content of the object, and if the content of a key
changes that key will probably simply be unlocatable: it will be
filed in the dict under the old rather than the new hash code.

Ruby, for instance, does not have that restriction on hash
keys, but it's got other restrictions that are much easier
to trip over.


> *** Problem: builtins list() dict() ...
>
> A list, a dictionary, a str, an int, a float are builtin functions...
>
> myList = list()
> myDict = dict()
> myString = str(45)
>
> The list-function instantiates a new list... it is actually nothing
> but an overloaded List class. Why are the handed in as functions? In a
> OO environment it should be more the instatiation of a class rather
> than a function and classes start with an uppercase letter:
>
> myList = List()
> myDict = Dict()
> myString = String(45)

I think we've discussed the built-in function versus object
attribute issue before.

John Roth