Thoughts about Python

[Michael Hudson]

PPNTWIMBXFFC at spammotel.com (Marco Aschwanden) writes:

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

See PEP 318 (and current discussion on python-dev).

> 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!
> 
> class c (object):
>     def staticMethod(arg1, arg2, ...):
>         # self is not handed in... hence I can't use the instance vars
>         pass
>     def normalMethod(self, arg1, arg2, ...):
>         pass
> 
> There is no need for the builtin... as I understand it: the builtin is
> a workaround...

What's so special about self?  I really don't like the idea of
argument names keying this kind of change in behaviour.

> *** 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.")
> 
> 
> I don't like this one either. It is not necessary because it describes
> something that should be clear by looking at the class/code. A
> convention would make the syntax clearer and more intuitive and by
> looking at the definition of a method you would know: This is a
> getter, setter or deleter. My proposal:
> 
> all getters start with __get__
> all setters start with __set__
> all deleters start with __del__
> 
> If someone uses:
> 
> prop.x = 5
> 
> Python checks whether the var 'x' exists on prop. If it does - it is
> set. If it doesn't exist Python checks for '__set__x' if it doesn't
> exist either... a AttributeError is raised:
> 
> 
> class PropertyExample(object):
>     """A demonstration class for the property idea.
> 
>     This class is used afterwards as follows:
>     prop = PropertyExample()
>     prop.x = 5 # __set__x(self, 5) is called behind the scenes
>     print prop.x # __get__x(self) is called behind the scenes
>     del prop.x # __del__x(self) is called behind the scenes"""
> 
>     def __init__(self):
>         self.__x = None
>         
>     def __del__x(self):
>         del self.__x
>     def __get__x(self):
>         return self.__x
>     def __set__x(self, value):
>         self.__x = value

You seem really fond of magic names...

By the way, Python 2.2 introduced the capacity for staticmethods and
properties and consciously decided not to add syntax for the same
until there was some experience in using these things.  So it's known
that there is some discomfort here, but it's not yet clear (to me, at
least) what a good syntax *is*.  I hope you're not too offended if I
say that your suggestion doesn't seem instantly wonderful.

> *** Problem: Many builtins are not necessary

Pah.  So what?  If you want minimailty scheme is over there ====>

> Many builtins are not necessary. To name a few: min / max / len
> 
> This functions should be defined on the class:

Says you!

[...]

> *** Problem: tuples are not necessary

Says you!  Here's a hint: hash([]).

[...]
> *** Problem: builtins list() dict() ...
> 
> A list, a dictionary, a str, an int, a float are builtin functions...
> 
> myList = list()
> myDict = dict()
> myString = str(45)

Pedantry: no they're not, they're builtin types.

I think you might be expecting something other of Python than what it
is.  Nothing you suggest is completely ridiculous, just, well,
slightly un-Pythonic.  I suggest you continue using Python for a few
more weeks and read your list again.

Cheers,
mwh

-- 
  MARVIN:  Oh dear, I think you'll find reality's on the blink again.
                   -- The Hitch-Hikers Guide to the Galaxy, Episode 12