Python component model

[Peter Maas]

Paul Boddie wrote:
> People who bring up stuff about self and indentation are just showing
> their ignorance, in my opinion, since Python isn't the first language
> to use self in such a way, and many C++ and Java programs use this
> pervasively in order to make attribute scope explicit, whereas the
> indentation matter is only troublesome with bad editing practices. I
> don't think the community should spend any more time on these
> criticisms.

How many programmers don't use Python because of the self issue?
I'm not for changing the semantics here but when I wrote a method with
lots of selfs recently I tried how it would look like if it would be
allowed not to write down 'self', i.e. from

def deposit(self, amount):
    self.balance = self.balance + amount

to

def deposit( , amount):
    .balance = .balance + amount

I see an advantage in not mentioning 'self': using shorter alternatives
like 'my' is possible but considered bad style. I find it unsatisfactory
to provide a degree of freedom and not wanting it to be used. Leaving
out 'self' is like leaving out block markers. You leave out something
that's a matter of taste (self, me, my, block marker positions) and
bring the code in minimal form. Explicit use of self could of course
still be allowed. And a favorite argument against Python would become
pointless.

> However, the GIL and issues of tools and IDEs should be considered in a
> more sophisticated way. 

If I wouldn't read discussions about it I wouldn't probably know that it
exists. But as far as I have understood removing the GIL means a lot of
work and breaking existing code. Perhaps the GIL will die naturally with
the advent of a production ready PyPy. And the Twisted people keep telling
"Repeat with me: there are no threads" :)

> Meanwhile, whilst not an IDE advocate myself, there really does need to
> be further improvements in the analysis of Python source code so that
> people can build improved tools to check Python programs for obvious
> "compile-time" errors and to inspect the behaviour of large amounts of
> code. 

I agree.

One reads occasionally on the python-dev or python-3000 mailing
> lists that some proposed change or other may or may not have an impact
> on "real world" systems such as the standard library, but that no-one
> can really say: we need to move beyond the "Python is just so dynamic"
> meme and develop tools like PyLint and PyChecker much further.

I find it important that Python allows dynamic coding but I agree that it
should allow more compile time checks which would probably also help to
produce faster code.

> This kind of stuff can be tackled by providing better introductory,
> educational or promotional material, with the latter especially
> important to stop the uninformed "rubbishing" that advocates of certain
> other languages seem particularly inclined to indulge in.

I don't think so because advocates tend to use arguments just because they
are handy, not because they don't know better.

-- 
Regards/Gruesse,

Peter Maas, Aachen
E-mail 'cGV0ZXIubWFhc0B1dGlsb2cuZGU=\n'.decode('base64')