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). I'll add support for "b" and "t" to the blob code if no one objects. -- Benji York Senior Software Engineer Zope Corporation
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. Jim -- Jim Fulton Zope Corporation
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 My comment is absolutly of topic. Just skip it if you don't have time...
Betreff: Re: [Zope-dev] Blobs and modes
[...]
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.
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. Regards Roger Ineichen
-- Benji York Senior Software Engineer Zope Corporation _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
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
On Fri, 2008-10-24 at 15:50 -0400, Benji York wrote:
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.
It's intended to be similar but not identical. We originally did support 'b' and 't' but decided, as Jim pointed out, hat we only care for binary data and thus only the binary modes. I can't remember the reason that drove us to actually rip it out. Maybe the archive of zodb-dev knows.
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.
I'm not sure what you're saying. It's not the __init__ problem, as .open() is described on the Blob class. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
participants (5)
-
Benji York -
Christian Theune -
Jacob Holm -
Jim Fulton -
Roger Ineichen