Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Pythonmarshal.c, 1.79, 1.80

[Armin]
Crash. Which means that there is no way in 2.4.0 to marshal an object in the
old version format as a string -- you'd have to work around by writing a real file and reading it back :-(
[Aahz]
Brown bag time?
Perhaps a rather quick Py2.4.1 would be in order. Ideally, it should include other important fixes: * Tim's critical thread bug http://www.python.org/sf/1069160 * Compile of _socket fails on 2.4 (SGI Orion only) http://www.python.org/sf/1086642 (waiting for a developer who has this set-up) * sys.stdin segfaults on invalid stdin http://www.python.org/sf/1084766 (Jeff Epler has already isolated the problem) * truncated gzip file triggers zlibmodule segfault http://www.python.org/sf/1083110 (assigned to Andrew) * various installer issues (all currently assigned to Martin) * bad arg type to isspace in struct module http://www.python.org/sf/1072182 (assigned to me) * fix bug in StringIO.truncate - length not changed http://www.python.org/sf/951915 (assigned to me) * Fix for off-by-one bug in urllib.URLopener.retrieve http://www.python.org/sf/810023 (assigned to me) Raymond

On Mon, 20 Dec 2004 15:03:13 -0500, Barry Warsaw <barry@python.org> wrote:
On Mon, 2004-12-20 at 12:48, Raymond Hettinger wrote:
Perhaps a rather quick Py2.4.1 would be in order.
+1
Nothing wrong with an incremental release, but none of these sound like critical bugs to me. Jeremy

On Mon, Dec 20, 2004, Jeremy Hylton wrote:
On Mon, 20 Dec 2004 15:03:13 -0500, Barry Warsaw <barry@python.org> wrote:
On Mon, 2004-12-20 at 12:48, Raymond Hettinger wrote:
Perhaps a rather quick Py2.4.1 would be in order.
+1
Nothing wrong with an incremental release, but none of these sound like critical bugs to me.
You don't think a blowup in marshal is critical? Mind expanding on that? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis

On Mon, 20 Dec 2004 18:25:39 -0500, Aahz <aahz@pythoncraft.com> wrote:
On Mon, Dec 20, 2004, Jeremy Hylton wrote:
On Mon, 20 Dec 2004 15:03:13 -0500, Barry Warsaw <barry@python.org> wrote:
On Mon, 2004-12-20 at 12:48, Raymond Hettinger wrote:
Perhaps a rather quick Py2.4.1 would be in order.
+1
Nothing wrong with an incremental release, but none of these sound like critical bugs to me.
You don't think a blowup in marshal is critical? Mind expanding on that?
An undocumented extension to marshal causes a segfault. It's certainly a bug worth fixing. It doesn't sound like a critical bug to me. Jeremy

[Jeremy Hylton on a quick 2.4.1]
Nothing wrong with an incremental release, but none of these sound like critical bugs to me.
[Aahz]
You don't think a blowup in marshal is critical? Mind expanding on that?
[Jeremy]
An undocumented extension to marshal causes a segfault. It's certainly a bug worth fixing. It doesn't sound like a critical bug to me.
The new optional ``version`` argument to marshal.dumps() is documented. The easiest way to see that is to look at 2.4's marshal.dumps() docs <wink>. Unfortunately, it was wholly untested. Still, it's a new-in-2.4 gimmick, and no pre-2.4 code could be using it. I suppose Armin found a use for it in 2.4, but I'm still scratching my head. If ZODB doesn't already depend on it, how useful can it be? QED WRT "my" critical thread bug, I asked that everyone pretend I hadn't submitted it until a month after 2.4 was released. That hasn't happened yet, so I refuse to admit it exists. FWIW, I'd press on with 2.3.5 first, while it can still attract some volunteer effort.

Hi Tim, On Mon, Dec 20, 2004 at 07:26:25PM -0500, Tim Peters wrote:
Still, it's a new-in-2.4 gimmick, and no pre-2.4 code could be using it. I suppose Armin found a use for it in 2.4, but I'm still scratching my head. If ZODB doesn't already depend on it, how useful can it be? QED
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. Now that we essentially can't use this trick any more because of the 2.4.0 bug, we reverted to repr/eval, which is quite slower (and actually not guaranteed to work across Python versions either: string escapes sometimes change). 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. Armin

Armin Rigo wrote:
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.
this is a rather common use case. </F>

[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().

Hi Tim, On Tue, Dec 21, 2004 at 05:21:29PM -0500, Tim Peters wrote:
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.
My mistake, I seemed to remember something along these lines but you are obviously right. Python 1.5.2 reads all escapes of a recent Python just fine. Armin

Raymond Hettinger wrote:
Perhaps a rather quick Py2.4.1 would be in order.
Ideally, it should include other important fixes: [...] * Fix for off-by-one bug in urllib.URLopener.retrieve http://www.python.org/sf/810023 (assigned to me)
Is http://www.python.org/sf/1062060 perhaps of similar importance? (fix for urllib.urlretrieve silently truncating download) --Irmen

Raymond Hettinger wrote:
Perhaps a rather quick Py2.4.1 would be in order.
Ideally, it should include other important fixes: [...] * Fix for off-by-one bug in urllib.URLopener.retrieve http://www.python.org/sf/810023 (assigned to me)
Is http://www.python.org/sf/1062060 perhaps of similar importance? (fix for urllib.urlretrieve silently truncating download)
That seems reasonable to me. There is no point in having the error pass silently. Raymond

Raymond Hettinger wrote:
* Fix for off-by-one bug in urllib.URLopener.retrieve http://www.python.org/sf/810023 (assigned to me)
Is http://www.python.org/sf/1062060 perhaps of similar importance? (fix for urllib.urlretrieve silently truncating download)
That seems reasonable to me. There is no point in having the error pass silently.
Well, I wanted to make the patches that Johannes suggested, but ran into trouble when building the Python docs from CVS source (see my other message about this). Also, I'm not sure how a test-case should be constructed for this patch? Can the Python regression test download stuff as part of a test? Or is there some other way to make a testcase for this. --Irmen

Irmen de Jong wrote:
Also, I'm not sure how a test-case should be constructed for this patch? Can the Python regression test download stuff as part of a test? Or is there some other way to make a testcase for this.
Hmm - perhaps start a server on the local machine at the start of the test, and tear it down at the end? you've then got full control of that server and can make it do whatever you want. Or replace the socket objects with mock objects? Tim Delaney

Tim Delaney wrote:
Irmen de Jong wrote:
Also, I'm not sure how a test-case should be constructed for this patch? Can the Python regression test download stuff as part of a test? Or is there some other way to make a testcase for this.
Hmm - perhaps start a server on the local machine at the start of the test, and tear it down at the end? you've then got full control of that server and can make it do whatever you want.
Or replace the socket objects with mock objects?
Thanks for those suggestions. Let's see what I can concoct. Never made (or studied in detail) a python regression test case before so now is a good time :) --Irmen

On Tue, Dec 21, 2004 at 08:00:22PM +0100, Irmen de Jong wrote:
Thanks for those suggestions. Let's see what I can concoct.
Never made (or studied in detail) a python regression test case before so now is a good time :)
You might be especially interested in 'class urlopen_HttpTests' in test_urllib.py and all the Mock* classes in test_urllib2.py. BTW, don't hesitate to ask for help in the bug/patch. I'm happy to help, though I might be a bit slow to answer. Cheers, Johannes
participants (11)
-
Aahz
-
Armin Rigo
-
Barry Warsaw
-
Fredrik Lundh
-
Irmen de Jong
-
Jeremy Hylton
-
Johannes Gijsbers
-
Raymond Hettinger
-
Raymond Hettinger
-
Tim Delaney
-
Tim Peters