On Fri, Oct 24, 2008 at 3:28 PM, Jim Fulton <jim@zope.com> wrote:

On Oct 24, 2008, at 3:24 PM, Benji York wrote:

...

Is there a good reason blobs don't support "b" or "t" in the mode strings passed to "open"? I'm refactoring some code that expects a file-like object to use blobs and it wants to pass "wb" as the mode (which is a sane thing to do).

Blobs are implicitly binary. (Note the "B" in Blob.)

...

I'll add support for "b" and "t" to the blob code if no one objects.

I object.

BTW, this questions should have been asked o zodb-dev.

[yep, copied on this message] For perpetuity: In a private discussion Jim explained that the blob .open() method returns things intended to be file-like, but the method itself isn't intended to mimic Python's "open" function, and as-such doesn't support the additional mode variations. This distinction is similar to why __init__ methods aren't described in (zope.interface) interfaces; how you construct an object isn't prescribed by the interface exposed by the object itself. -- Benji York Senior Software Engineer Zope Corporation

Hi Benji and Roger Roger Ineichen wrote:

Hi Benji

My comment is absolutly of topic. Just skip it if you don't have time...

Staying on the off-topic...

I agree on not describe the constructor signature. But I can't agree on the reason why.

If you have to use an existing framework with defined interfaces the missing constructor signature doesn't make sence if the framework at the same time offers implementations which use a specific signature. It's just a leak of information.

I'm also against describing the __init__ signature in an interfaces but there is another reason.

The missing __init__ signature in the interfaces make only sense if it comes to reduce the variants of it. It whould not be helpful to have several different named interfaces just because they support another constructor signature.

But describing a constructor signature is not in general a bad thing.

What I think you are saying is that you also want to have the signature for the object factory somewhere. That makes good sense, but usually isn't part of the API for the the object itself. It belongs in a different interface that is used by those that *create* the objects, rather than *use* the objects. So you can have any number of interfaces for creating the object, and a single interface for working on the object once it is there. That makes a lot of sense to me. <rant>Unfortunately the __init__ method plays a dual role in python. It defines the constructor signature and is called automatically by the *real* constructor (which I would argue is the __call__ method on the type, at least for new-style objects). However, it is also a regular instance method that can be called from anywhere, and so is in a sense a part of the API for the object. I believe this dualism is the root of much evil, or at least confusion, whenever "super" calls and/or interfaces are being discussed.</rant> That said, and returning to the original issue. I don't see the reason why Blob.open shouldn't just ignore the 'b' flag and just give an error if someone tries to give it a 't'. If that makes it useful in more cases, I'd be all for it. Regards Jacob Holm