"Russ P." <russ.paie...@gmail.com> writes:
> Calling a one-word change a "fork" is quite a stretch, I'd say.
I wouldn't. I've forked a project P if I've made a different version of
it which isn't going to be reflected upstream. Now I've got to maintain
my fork, merging in changes from upstream as they happen, and upgrading
all the things which use my new version; if I want to distribute my
program M to other people, they'll also need my forked version of
whatever. Now suppose that two programs A and B both require one-word
changes in P: there's a combinatorial explosion of little patches which
need to be managed.
A fork is a fork, regardless of how big the change is. The problem with
a fork is the maintenance problem it entails.
Besides, if I want to do some hacky debugging in ipython, should I
really have to recompile and reinstall piles of libraries?
>> > Has it occurred to you that some users might actually *want* access
>> > controls? Maybe some users want to actually use the library as the
>> > author intended it to be used. What a bizarre concept!
>>
>> Huh?
>> Then... use it as the author intended. I am _not_ forcing you to use the
>> obj._protected attributes!
>
> But what if I want an automatic check to verify that I am using it as
> the author intended? Is that unreasonable?
You mean that you can't /tell/ whether you typed mumble._seekrit?
You're very strange. It's kind of hard to do by accident. I'd have
thought that you could do that with grep, err...
git grep '\._' | sed 's/self\._//g' | grep '\._'
ought to do as a rough start.
If you can't trust your programmers to make it clear when they're doing
something dubious, I think you have bigger problems.
-- [mdw]
--
http://mail.python.org/mailman/listinfo/python-list
