This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author drj
Recipients drj, gpolo
Date 2009-02-10.13:02:15
SpamBayes Score 4.762857e-13
Marked as misclassified No
Message-id <8D6498EE-FCEE-450A-8BAB-605E1A9E6A40@pobox.com>
In-reply-to <1234268923.19.0.122980458213.issue5202@psf.upfronthosting.co.za>
Content
On 10 Feb 2009, at 12:28, Guilherme Polo wrote:

>
> Guilherme Polo <ggpolo@gmail.com> added the comment:
>
> Wouldn't it be better if you only ignored the 'illegal seek' error
> instead of ignoring any ioerror (should it even be always discarded) ?

No.

> I
> get a 'bad file descriptor' under Windows 7, but, again, can it be
> always discarded ?

Yes.

To expand: Observe that the exception is raised when we are writing  
the header for the first time.  The exception is not raised when we  
attempt to seek to patch the header, it is raised when we recording  
the file position so that we can seek to it later.

We record the file position even though we might not use it later  
(the file position is only needed if we need to patch the header).

So if we don't need to patch the header, we do not need the file  
position.  So we can clearly ignore any error in attempting to get  
the file position.

If we do need to patch the header, then we need the file position.   
If we do not have the file position (because the earlier attempt to  
get it failed), then patching the header will fail when it attempts a  
seek.  This seems reasonable to me.

>
> You can also reproduce the problem without using wave:
>
>>>> import sys
>>>> sys.stdout.tell()

That does not reproduce the problem.  The problem is not that tell  
raises an exception, the problem is that tell raises an exception and  
it is only being used to get some information that may be not needed  
later.  Therefore the exception should be ignored, and a problem  
should only be raised if it turns out that we did need for  
information that we couldn't get.

>
> I'm really unsure about the proposed patch.

Noted.

I also note that my patch can be improved by removing its last 11 lines.
History
Date User Action Args
2009-02-10 13:02:17drjsetrecipients: + drj, gpolo
2009-02-10 13:02:16drjlinkissue5202 messages
2009-02-10 13:02:15drjcreate