"Russ P." <russ.paie...@gmail.com> writes: > Was this library module released in source form? > > If so, then why would you care that it has enforced access > restrictions? You can just take them out, then do whatever you would > have done had they not been there to start with. I don't see how that > is any more work than figuring out what internals you need to access. > Either way you need to read and understand the code.
I could do. But in practice internal details often aren't horrifically unstable. If I fork the library, I've now got to mess with distributing the forked version, and keeping the patch up to date -- the codebase is likely to be much more volatile than the internals I'm hacking on. It's just not such a good tradeoff. See elsewhere where I described hacking Python's `long' representation. You'd have me fork the Python interpreter. That doesn't seem like a win to me. > Wait ... it wasn't released in source form? Then how would you even > know what internals you need to access? We call them `disassemblers' and `debuggers'. Sometimes even simple experimentation is sufficient. > And why would you use something that goes against your philosophy of > openness anyway? I try not to. Sometimes I fail. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
