Message112496
| Author |
alexandre.vassalotti |
| Recipients |
alexandre.vassalotti, belopolsky, eric.araujo, exarkun, hinsen, lemburg, loewis, obamausa8, pitrou, rhettinger |
| Date |
2010年08月02日.16:43:22 |
| SpamBayes Score |
0.00317669 |
| Marked as misclassified |
No |
| Message-id |
<1280767404.91.0.281950170819.issue9276@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
The security issue mentioned previously has been known for years. And, it is easy to protect against. See http://docs.python.org/py3k/library/pickle.html#restricting-globals
Also I am against adding pickling support to code objects. Code objects have no backward-compatibility constraint unlike pickles.
Antoine is right about we should be using a method fully-qualified name to pickle it. However, the problem with this approach is a method doesn't always have fully-qualified name (see issue3657). ForkingPickler in Lib/multiprocessing/forking.py uses this approach to add pickling support to methods. |
|