Merge lp://qastaging/~vila/bzr/lockable-config-files into lp://qastaging/bzr

305 + @classmethod
306 + def from_bytes(cls, unicode_bytes):

It seems a little weird to call it 'unicode_bytes' and to have the function be 'from_bytes'. What about 'from_unicode(cls, unicode_content)' ?

I also thought that 'lock_write' would take care of reload(), so that callers couldn't actually get it wrong. (reload whenever the lock transitions from 0 => 1 lockers.)

This seems ok enough to land, but it also seems like it could be improved.

> 305 + @classmethod
> 306 + def from_bytes(cls, unicode_bytes):
>
> It seems a little weird to call it 'unicode_bytes' and to have the function be
> 'from_bytes'. What about 'from_unicode(cls, unicode_content)' ?

I just went with what spiv proposed.

I changed it to from_string(str_or_unicode).

>
> I also thought that 'lock_write' would take care of reload(), so that callers
> couldn't actually get it wrong. (reload whenever the lock transitions from 0
> => 1 lockers.)

Hmm, that may be worth considering, but it's outside the scope of this bug.
I've not change the over data model here and forcing the call to reload
may block some use cases. What if I want to inspect the values already known
by the config before reloading from disk (which must happen inside the lock
scope) ?

The constraint to call reload() (which is new, like LockableConfig) shouldn't
be a such burden for new adopters and could even help them understand what
is really happening here (also note that I only needed to add *3* calls and
that reload() usage is more than hinted in LockableConfig docstring).

> This seems ok enough to land, but it also seems like it could be improved.

What can't ? But since this is my third submission for this bug, I think
I've spend enough time on it ;) I intend to keep working in the config area
anyway.

Vincent Ladeuil wrote:
> > 305 + @classmethod
> > 306 + def from_bytes(cls, unicode_bytes):
> >
> > It seems a little weird to call it 'unicode_bytes' and to have the function be
> > 'from_bytes'. What about 'from_unicode(cls, unicode_content)' ?
>
> I just went with what spiv proposed.

IIRC, I proposed (or meant to propose) calling that “utf8_bytes”.

-Andrew.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/29/2010 7:49 PM, Andrew Bennetts wrote:
> Vincent Ladeuil wrote:
>>> 305 + @classmethod
>>> 306 + def from_bytes(cls, unicode_bytes):
>>>
>>> It seems a little weird to call it 'unicode_bytes' and to have the function be
>>> 'from_bytes'. What about 'from_unicode(cls, unicode_content)' ?
>>
>> I just went with what spiv proposed.
>
> IIRC, I proposed (or meant to propose) calling that “utf8_bytes”.
>
> -Andrew.
>

Right, so my big concern is calling something 'unicode' when it is a
bytes string, or calling it 'bytes' when it is a unicode string. And
calling it 'unicode_bytes' always gets it wrong in one way or another :).

If it can be either than calling the parameter "unicode_or_bytes" though
doing "from_bytes(u'unicode-string')" would also look wrong in practice.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkx74ZcACgkQJdeBCYSNAAOwMwCgirTL4Dkt7N6ycqZCALusZVcy
QDIAn3eX0ZcLYvrVqinDIDnxmSt+8Eym
=/eoB
-----END PGP SIGNATURE-----