[melbourne-pug] Coding idiom

[Justin Warren]

On Mon, 2006-05-08 at 23:23 +1000, Bill Birch wrote:
> On Fri, 5 May 2006 10:57 am, Maurice Ling wrote:
> 
> >
> > I am hoping that Bill's type system is able to strike a middle ground on
> > this, allowing developers to define their own coding conventions which
> > is mappable to a standard type system as metaknowledge, or something
> > like that.
> >
> Hi,
> 
> A type system would help reason about the code. There's been various proposals 
> to add "interfaces" a la Java to Python. These have merit to solve this 
> issue. The technique is to first define an interface or interfaces, then the 
> implementation class methods or attributes that are not in in the interfaces 
> are effectively private. By declaring interfaces you are publically 
> committing to honour some methods, but caveat user on the others.  Because 
> the interface is separated you don't have the issues with underscores in  
> names. The type system just allows you to capture the method signatures and 
> have code to introspect them at runtime.

This is something I don't really understand as I don't have the
background; I chose engineering. :) Could you possibly explain it? There
may be others on the list who are interested in some CS fundamentals,
too. Not understanding it well enough is a large contributor to my
apprehension.

> Zope has an interface package which you can use right now. I have not used it 
> (yet). Has anyone? It looks clunky. 
> http://svn.zope.org/Zope3/trunk/src/zope/interface/README.txt?view=markup

I've used bits of it with my dealings with Zope and Twisted. It's not
integrated into the python internals, but it seems to work quite well.

> You -could- use a decorator to scare people away:
> 
> def private(x) : return x
> def protected(x) : return x
> def public(x) : return x

Why do people want to turn Python into C++ or Java? Why are you trying
to scare away people who want to use your code?

> class Ubeaut(object):
> 
> 	@private
> 	def hairyDetailedFunctionNoOneShouldUse(self): pass

	def ButWhatIfINeedToBecauseYouDidntImplementThePublicFunctionINeed(eh)

> 	@public
> 	def goForIt(self): pass
> 
> Not very original. But is blindingly obvious what you mean. If you stick with 
> this system one day you could code up something more snazzy than the identity 
> function. 
> 
> Personally I am against using underscores to  give subtle meanings, and I am 
> glad we have decorators. Perhaps one day the magic underscore behaviour of 
> import will be replaced with a decorator. 

Perhaps I don't see underscores as being so subtle. I'm all for an
explicit mechanism of telling someone that certain portions of the API
are stable and will be honoured, while other parts are volatile or not
for public consumption. I'm not a big fan of someone preventing me from
getting something done because they've prematurely optimised their API,
leaving out something I believe should be there, and then preventing me
from doing it myself because they've locked down the private functions.

If public/private/whatever is simply a sign placed near the function
warning me that I'm doing something dangerous, then fine. I might have a
very good reason for doing it, and be confident in my ability to do so.
I don't want the software making it arbitrarily difficult for me to get
something done.

That's one of the reasons I love Python so much. It doesn't get in my
way as much as C++ or Java or Eiffel.

-- 
Justin Warren <daedalus at eigenmagic.com>