[BUG] transport/memory.py doesn't handle strings

[John A Meinel]

Aaron Bentley wrote:
> Robert Collins wrote:
>
>>>On Tue, 2005-10-18 at 16:45 -0500, John A Meinel wrote:
>>>
>>>
>>>>There are a couple of changes that should be made to the
>>>>transport/memory.py implementation.
>>>>First, most of the "put" functions can take either a file-like object, or
>>>>a string. Which means that MemoryTransport.put() shouldn't just call
>>>>read(), it should also check to see if it is already a string. (Either
>>>>that, or we can change the api if you really prefer).
>>>
>>>
>>>I think that the ambigious api is very strange. I'd much rather have
>>>explict put_stream, put_string etc.

I don't think it is that ambiguous. Either it is a string, or it is
considered to be a filelike object.

>
>
> I'd rather have put_iterable, because files are iterables of strings,
> but so are lists, and so are strings.  So all of these have the same result:

Honestly, I think we only have strings and files. Strings because in
lots of places you know the complete content of the file (such as when
creating some of the control files in .bzr/).

I think it is pretty rare that you want to put a list of strings into a
file. And if you did, you could just do "put(''.join(lst))"

I believe that inside most put() functions, it would do exactly that.
(Since you don't want to push a remote file 1 line at a time, at least
in most cases, but certainly not 1 byte at a time).

>
> put_iterable('hello')
> put_iterable(['hel','lo'])
> put_iterable(StringIO('hello'))
>
> I can always adapt an interable into a file, but why bother when we only
> need an iterator of strings in the first place?
>

I will admit that I've started to use more iterators and generators, I
don't know if it makes sense to put() that sort of object across a
transport.

>
>>>>I'm also concerned that MemoryTransport.clone() returns the exact copy of
>>>>itself. Because one of the fundamental bits of Transport objects is that
>>>>they have a "base" where all paths are given relative to that base.
>>>>
>>>>Since all files and directories are stored inside the dictionary as
>>>>relative paths, clone(offset=".bzr/") will fail. And this type of cloning
>>>>is used in bzrlib/branch.py so that the Store objects have "base" set
>>>>appropriately.
>>>
>>>
>>>In bzrlib/branch.py, cloning at the top is checked for by
>>>'new_transport.base == old_transport.base'. I was duplicating that
>>>interface.
>
>
> There should be a test for transport.base != transport.clone('a').base.

Actually, there should be a test that transport.get('a/something') ==
transport.clone('a').get('something')

John
=:->

>
> Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051018/840230ef/attachment.pgp