[Armin Rigo] > Some code in the 'py' lib used to use marshal to send simple objects between > the main process and a subprocess. We ran into trouble when we extended the > idea to a subprocess that would actually run via ssh on a remote machine, and > the remote machine's Python version didn't match the local one. The obvious > quick fix was to set the 'version' argument to 0 and pretend that it would be > fine forever.
Yes, I believed you had *some* use for it <wink>. > Now that we essentially can't use this trick any more because of the 2.4.0 > bug, Well, you can still use 2.3.4 -- or wait for 2.4.1 -- or use your patched 2.4. Or use the stock 2.4, but set up a "marshal server" running 2.3.4 <heh>. > we reverted to repr/eval, which is quite slower (and actually not guaranteed > to > work across Python versions either: string escapes sometimes change). Really? The precise rules str's __repr__ uses for which escapes to produce certainly change, but I don't recall any case outside Unicodeland where a new string escape was ever introduced. So, e.g., current Python str.__repr__() produces '\n' for a newline, while long-ago Pythons produced '\012', but all versions of Python *accept* either form of escape. The biggest change of this kind was moving from octal escapes to hex escapes in Python 2.1, but hex escapes have always been accepted -- repr() just didn't produce them before 2.1. > We avoid to use cPickle because we want to be sure that only "simple > enough" objects are sent over this way -- essentially nothing that depends on > a precise Python module to be installed and identical on both machines. It's possible (but irksome) to subclass pickle.py's Pickler class, and override its save_global() and save_inst() methods. For example, replace them with one-liners that just raise an exception. Then any attempt to pickle an object requiring a specific module will raise that exception. But if you're worried about speed, going thru pickle.py is significantly slower than going thru repr(). _______________________________________________ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com