[Patches] [ python-Patches-1214879 ] Support non-file source/dest in marshal

SourceForge.net noreply at sourceforge.net
Sun Aug 7 23:38:45 CEST 2005


Patches item #1214879, was opened at 2005-06-04 19:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214879&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support non-file source/dest in marshal

Initial Comment:
I own bug #780354.  The problem is that socket.makefile() no
longer returns a true file.  This breaks code that had assumed
it did.  The marshal module is one such instance.

In the above bug's corresponce Martin stated:

    Instead, I think the C modules that expect file objects need
    to be fixed.

Later on Martin stated that he thought it would be fine to simply
document the limitation for the marshal module.  I ignored that
and fixed it in the attached patch.  It includes modified docs and
an updated test suite.

It's obviously somewhat slower than the current version when
reading/writing true files.  That's to be expected.  I wanted to
get it right first.  I imagine something can be done to speed
things up in the common case (run PyFile_Check() and make
calls to stdio functions if it is a true file).

Even if this patch is rejected, the modified test_marshal.py
should probably be kept (with suitable deletions), as it refactors
the individual tests into helper functions, thus avoiding a lot
of code duplication and potential future cut-n-paste errors.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2005-08-07 23:38

Message:
Logged In: YES 
user_id=21627

I think I would prefer if WFILE continued to support FILE*
as a special case, for performance reasons.

Also, since write() will be called really often (once per
byte), it might be worth to speed up the call somewhat:
- look up file.write initially, and store that in WFILE,
instead of storing the object itself. Make sure to DECREF
.write when you are done.
- Call the function through a tuple, to avoid the argument
parsing. You know in advance that there is a single only a
single argument, and that this is a string.

Also, I'm worried about the error handling. If .write()
raises an exception, marshalling should abort, IMO. The
right way would be to add an error code to all w_*
functions, and immediately return when there was an error.
However, just putting the WFILE into an error state (by
setting p->error to 3), and then refusing to perform further
.write calls might be sufficient.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1214879&group_id=5470


More information about the Patches mailing list