Thoughts about Python

[Duncan Booth]

PPNTWIMBXFFC at spammotel.com (Marco Aschwanden) wrote in 
news:15c2d03b.0402240311.395f5382 at posting.google.com:

> 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.

I think you should spend a bit of time reading the PEPs and the python-dev 
mailing list archives. A lot of what you say has been discussed previously, 
and it would be good if you could take the earlier discussion on board and 
then see where your thoughts lead you.

> 
> *** Problem: clumsy static class methods
> 
This has been widely discussed elsewhere and various solutions have been 
proposed.

> 
> *** Problem: clumsy properties for classes
> 
As for static methods various ways to improve this have been suggested. You 
should read the discussions on python-dev to see the various viewpoints.

> 
> *** 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()

The advantage of min and max as builtins are that they work on any 
sequence. In particular they work on iterators. Having functions that apply 
to an arbitrary sequence avoids a lot of potential code duplication.

> "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.

There are other builtins I would throw away first. Note that you can't 
actually throw any of these builtins away: one of Pythons great strengths 
are the lengths it goes to to maintain backward compatibility. Some of the 
less useful builtins are being relegated to backwaters of the 
documentation, but they will remain as builtins for the foreseeable future.

> 
> 
> *** Problem: tuples are not necessary
> 
> Throw them away in the long run - for now make them depracted. It is
> hard to argue in favour of tuples. There might to 2 reason:
> 
> 1. It is MUCH faster than a list
> 2. We can't live without an immutable list

Forget the speed and memory difference. The main argument for tuples as a 
separate type are to use as dictionary keys. How do you propose to handle 
dictionary keys without tuples?

> 
> *** Problem: builtins list() dict() ...
> 
> A list, a dictionary, a str, an int, a float are builtin functions...

No they aren't. They are types, not 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)
> 

So they don't follow your naming convention. If this is a big problem for 
you, then add some new globals in your own programs. The type 'file' is 
already aliased as 'open'. You can't remove the existing builtins (since 
that would break the library), but there is nothing to stop you adding your 
own either in the __builtin__ module, or as a separate module containing 
your aliases.

FWIW, I agree that the builtins that exist aren't the best choice for type 
names --- too often they collide with the 'obvious' variable names that 
python newcomers choose and then they wonder why their call to 'str' blow 
up when they used a variable 'str' a few lines earlier.