Robert Smallshire wrote:
Hello,
I'm trying to get some commercial code for a simple object database we have
written for Python 2.6 to work with IronPython 2.6. In Python 2.6 the return
type of pickle.dumps() is str, which is of course a byte string. In
IronPython 2.6 it is also str, which is of course a unicode string. This
'compatibility' is fine until I put those strings into a database, at which
point my interoperability between CPython and IronPython goes off the rails.
How is this actually a problem?
I mean, can you provide a specific example of where a string in
IronPython doesn't behave as a byte string in CPython. I'm sure there
are such examples, but those may be bugs that the IPy team can fix. In
practise I've encountered these problems very rarely.
For example "data = [ord(c) for c in some_string]" has behaved as
expected many times for me in IronPython (and could help you turn
strings into bytes).
Is this a theoretical problem at this stage or an actual problem?
Michael
I notice that in Python 3.0 the return type of pickle.dumps() is now
'bytes', which is much better. I don't imagine you're about to change the
return type in IronPython 2.x to bytes even though that would arguably be
the right thing to do. I intend to provide a compatibility wrapper around
pickle that returns a bytes instance on CPython 2.6, IronPython 2.6 and
Python 3.0.
What is the preferred way to transform my unicode 'str' in IronPython into a
'bytes' instance in IronPython that will be byte-compatible with what I'm
getting from CPython?
Many thanks,
Rob
Robert Smallshire
from home on behalf of
Roxar Software Solutions
Currently in Norway (UTC +1 hours)
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
