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