Sean Russell wrote:

> Emiliano wrote:
> 
> > Sean Russell wrote:
> >> Ummm... then don't use global data.  At worst, you'd be no worse off than
> ....
> > You might not use it, but your i-know-better neighbour will.
> 
> Then it will be her variables that will be overwritten, not mine.

Which is great if you work in isolation and interface cleanly. It's
not so great if people work on one package where the separation is not
so clear.

> Really, using global variables is such a poor programming habit that I 
> believe that if you have someone on your team using them, you have more 
> problems than just global variables.

So why not make them impossible?

> Ah. I can appreciate that.  I'd rather have flexibility in choosing the 
> coding standards because coding styles should be dynamic.  If someone has a 
> better idea about how to make code readable or more maintainable that 
> Python's rigid style doesn't allow, then too bad.  While this is true of 
> any programming language to some extent, the flexibility allowed by Ruby 
> provides more wiggle room.

OK, so that means coding style can differ from year to year. I don't
see that as a plus. Where I work with C we work according to the safer
C guidelines. No deviations for whatever hype passes along or whatever
hotshot guru entered. I don't work in that project anymore but it
served us extremely well during its time; a project spanning multiple
years and people coming and leaving, it was well worth the grumbling
people would do about the anal/ugly/unreadable/<fill-in-excuse> we
took in the beginning.

> I feel that language-imposed style limitations are more restrictive of 
> creative freedom than those imposed on the project level.  If you don't 
> have any ability to change, you'll never improve, and you'll never discover 
> a *better* way of doing things.

Which is perfectly true for algorithmic work. I wouldn't count coding
guidelines the 'creative freedom'.

> Well, my last project, which had a team of 5, and about 50k lines of code 
> in Java, had some coding standards that we uniformly adhered to.  There 
> were only three ways to tell the difference in any of the code:
> 
> 1) You knew which code you wrote because you remembered writing it
> 2) You looked at the comments
> 3) If there were any really long variable names, it was my code.
> 
> So I'd argue that Python would not have changed this in the least.  In 

So it wouldn't have hindered you either once you got past the initial
shock.

> fact, we used the "official" Java style guide with some minor changes to 
> the variable naming scheme.  These changes were, in our opinions,  
> significant improvements on the "official" style guide.  If the Java 
> compiler itself had imposed those style restrictions, we wouldn't have been 
> able to use our naming scheme.  This is the core of my disagreement with 
> enforcing styles at the language level.

Python doesn't enforce a naming scheme, and I wouldn't stand for a
compiler that would.

> I disagree.  With Python, the coding standards are inflexible.  Python is 
> not going to change; you have no chance to provide input; control of the 
> style is so far removed from you that you are, in effect, insignificant.  
> If control is local, you have input.  It may be ignored; you may be 
> outvoted; it may be such a legacy standard that changing it would be 
> impossible.  This is still at the *worst case* no worse off than if you 
> were using Python, and the opportunity for it being *better* is much, much 
> greater.

I'll agree to disagree. Not all matters ned be democratic.

I can't believe I'm taking a stand for Python. Put it down to loving a
good discussion anytime.

Emile