eliminating the xlrd1 fork

[Phillip M. Feldman]

I would like to eliminate my `xlrd1` fork, but three issues in `xlrd`
must
be addressed before I can do this:

(1) When I run `xlrd`, thousands of warnings messages spew out. I
need some
mechanism for suppressing these. It is true that I can currently
direct them
to a file, but I'd prefer that they not be generated in the first
place.

(2) Currently, `sys.getsizeof` returns a size that is incorrect.
(I've made an
unsuccessful attempt to address this).

(3) The open_workbook function must store the name of the file as an
attribute
of the workbook object that is created and returned by the function.
(This is
necessary so that a function that receives the book object or a
worksheet object
can generate a suitable error message that names the offending file).

Phillip

[Chris Withers]

On 03/06/2012 18:28, Phillip M. Feldman wrote:
> (1) When I run `xlrd`, thousands of warnings messages spew out. I
> need some
> mechanism for suppressing these. It is true that I can currently
> direct them
> to a file, but I'd prefer that they not be generated in the first
> place.

Have you tried the latest 0.7.x release?

> (2) Currently, `sys.getsizeof` returns a size that is incorrect.
> (I've made an
> unsuccessful attempt to address this).

This problem falls into the "too hard" and "not worth solving" category.
sys.getsizeof doesn't, as far as I know, generally work. Off list, I've
already explained the "correct" way to solve this problem, using
guppy/heapy.

> (3) The open_workbook function must store the name of the file as an
> attribute
> of the workbook object that is created and returned by the function.
> (This is
> necessary so that a function that receives the book object or a
> worksheet object
> can generate a suitable error message that names the offending file).

Again, as discussed offline, this isn't a usecase anyone other than you
seems to have. I'm -0 on this, but I'm open to suggestions from John as
to whether this is something he'd like to see.

Now, it sounds like you'll want to keep your "fork". I will, publicly
this time, request that if you choose to do so that you rename your fork
rather than having a distractingly similar name for something that has
already got largely out of sync. (I've seen at least two bugfixes make
their way into the GitHub master for xlrd, I'm hoping to cut a 0.7.x
release featuring them as soon as I get a chance.)

cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk