Making immutable instances
Mike
vimakefile at yahoo.com
Thu Nov 24 11:38:11 EST 2005
"Antoon Pardon" <apardon at forel.vub.ac.be> wrote in message
news:slrndobe1a.15d.apardon at rcpc42.vub.ac.be...
> Op 2005-11-24, Mike schreef <vimakefile at yahoo.com>:
[...snip...]
>> ...but I think Python's voluntary
>> DoThis, _DoThisIfYouReallyHaveTo, and __You'dBetterKnowWhatYou'reDoing__
>> approach is a better way to go than the undefeatable keyword approach.
>
> I disagree.
>
> Suppose I have the following code.
>
> from module import __take_care__
>
> __private_detail__ = ...
>
> I now have two variable that are flaged the same way, but they are not.
>
> __take_care__ is a private variable from an other module which I should
> use with extreme care not to break the other package.
>
> __private_detail__ on the other hand is just keeping private data for
> my own module, which I should care about as just any other variable
> in my module. It are other modules that should take special care
> if they should choose to import this variable.
If you just import the module and use __private_detail__ vs.
module.__take_care__ -- that solves that problem :)
>
> That is why I don't think the underscore prefixes are very usefull.
> They constantly flag to take care with a specific variable, while
> that variable is nothing special within the module itself.
I didn't say that the methods used were perfect or fully expressive, but
just in the right direction.
Maybe there should be a few more variations, and they should be documented
and blessed, and *tools* can honor them as they see fit. (Different syntax
hilighting, lint checking, etc.)
m
>
> --
> Antoon Pardon
More information about the Python-list
mailing list