How much is set in stone?
Bjorn Pettersen
>
> Chris Barker wrote:
> >
> > While nothing is actually set in stone, some things are pretty well
> > cemented in.
> >
> > Jive Dadson wrote:
> > > Thanks. Before I submit a formal proposal, let me run it by you
> > > guys.
> >
> > That is a good idea, most PEPs start as a discussion here.
> AN a whle
> > lot more start that way and nver make it to a PEP.
> >
> > > I've looked through all the PEPS and I was surprised that my
> > > suggestion is not already there. So, here it is. Please comment.
> >
> > You can bet that this has been proposed by people new to
> Python again
> > and again and again ...
>
> What does that tell you?
That more people (or more experienced Python programmers) don't see this
as a problem?
[snip]
> > If you start changing that too, you
> > really won't have Python anymore!!
> >
>
> The changes I've proposed do not conflict in any way with the
> "Python-ness" of the language. If you don't put "option
> explicit" at the top of your module, it will behave exactly
> the same as it did before.
Not that I'm able to channel Guido, but historically he's been against
adding switches to the compiler to make it behave in some domain
specific way. I'm guessing he would be against "options" that would
basically create two Python syntaxes too. I know I am.
> What we are discussing is not uniquely "Python". Other
> languages have had the dubious feature that the first
> assignment to a variable is its declaration. Invariably,
> people discover that it was a lousy idea. The people who USE
> it discover that. They misspell a variable name and in doing
> so they introduce a bug. The bug may not manifest itself
> until the code is already shipped. Even if they do notice
> the bug before it's too late, it may be very difficult to
> track down. I've been down that road a lot of times.
Note that this happens *only* when your misspelling is on the lhs of an
assignment statement, in *all* other contexts the compiler will complain
at you. I've written several large Python projects and I've never run
into this problem -- i.e. it's not high on my priority list. If it's
important to you I would suggest you run PyChecker
(http://pychecker.sourceforge.net/) on the code...
god-save-us-from-the-newly-converted'ly y'rs
-- bjorn
Barry A. Warsaw
>>>>> "BP" == Bjorn Pettersen <BPett...@NAREX.com> writes:
BP> Note that this happens *only* when your misspelling is on the
BP> lhs of an assignment statement, in *all* other contexts the
BP> compiler will complain at you. I've written several large
BP> Python projects and I've never run into this problem --
BP> i.e. it's not high on my priority list. If it's important to
BP> you I would suggest you run PyChecker
BP> (http://pychecker.sourceforge.net/) on the code...
One possible way to accomplish this is new with Python 2.2. With
new-style classes, you could use a __slots__ attribute to cause any
assignments to misspelled attributes to generate an error. Not
exactly local variable assertions, but maybe close enough where it
matters:
Python 2.2b1+ (#1, Nov 1 2001, 02:06:16)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class NotSoStrict:
... pass
...
>>> n = NotSoStrict()
>>> n.python = 1
>>> n.phyton = 2
>>>
>>> class Strict(object):
... __slots__ = ('python',)
...
>>> s = Strict()
>>> s.python = 1
>>> s.phyton = 2
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'Strict' object has no attribute 'phyton'
guido-left-the-keys-to-his-time-machine-laying-on-his-desk-again-ly y'rs,
-Barry