Re: [IronPython] Portable use of pickle.dumps()

[Michael Foord]

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

Re: [IronPython] ironpython compared to powershell

[Michael Foord]

jocke khazad wrote:

Hi everyone!

I would like you ask this question that I seem not to get an answer 
for anywhere.


What is the advantage of using ironpython compared to using only 
powershell? Or is it just a personal choice which one you like the best?
Taste comes into it a lot. For example I abhor dynamic scoping 
(Powershell) and much prefer lexical scoping (Python).


IronPython tends to be faster than Powershell (at least in the embedded 
situation in which I compared them) and has more libraries (Python 
libraries as well as .NET) and a larger user community (if you include 
the whole Python community).


All the best,

Michael Foord




Best Regards,

Joakim


___
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

Re: [IronPython] Portable use of pickle.dumps()

[Robert Smallshire]

Hi Michael,

> > 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.

My opening paragraph may be ambiguously worded - by 'interoperability' I
didn't mean the ability to run the same code unchanged on CPython and
IronPython (I have to change the code anyway to use a different database
adapter) - I meant interoperability between pickles persisted into a
database from both IronPython and CPython.

My basic issue is that the 'str' unavoidably implies certain semantics when
calling .NET APIs from IronPython. These APIs interpret str as text rather
than just bytes, which therefore gets transformed by various text encodings,
such as UTF-8 to UTF-16. Such encodings are undesirable for my pickled data
since the result is no longer necessarily a valid pickle.   I suppose the
intention in Python 3.0 is that 'bytes' doesn't carry any semantics with it,
its just data, which is why pickle.dumps() in Python 3.0 returns bytes
rather than str.

I want to push plain old byte arrays into the database from both CPython and
IronPython, so I can avoid any head-scratching confusion with database
adapters and/or databases inappropriately encoding or decoding my data.

> 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).

Thanks. I'll try something based on that.

> Is this a theoretical problem at this stage or an actual problem?

Its an actual problem with SQLiteParameter.Value from the SQLite ADO.NET
provider.  I think our original CPython code is a bit sloppy with respect to
the distinction between text strings and byte arrays, so I'll probably need
to tighten things up on both sides.

Would you agree tha using unicode() and bytes() everywhere and avoiding
str() gives code that has the same meaning in Python 2.6, IronPython 2.6 and
Python 3.0?  Do you think this would be a good guideline to follow until we
can leave Python 2.x behind?

Many thanks,

Rob



___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Portable use of pickle.dumps()

[Michael Foord]

Robert Smallshire wrote:

Hi Michael,

  
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.



My opening paragraph may be ambiguously worded - by 'interoperability' I
didn't mean the ability to run the same code unchanged on CPython and
IronPython (I have to change the code anyway to use a different database
adapter) - I meant interoperability between pickles persisted into a
database from both IronPython and CPython.
  


So are you telling the database that it is binary data or text?

Is the question how do I go from a pickle string in IronPython to a byte 
array that I can pass to the database adaptor without going through an 
explicit encode (which will transform the data)?


(One technique would be to explicitly use pickle protocol 0 which is 
less efficient but only creates ascii characters - this is actually the 
default. Another alternative would be to use JSON or YAML instead of 
pickle.)


Here is an example of getting a byte array from a binary pickle in 
IronPython:


>>> import pickle
>>> class A(object):
...  b = 'hello'
...  c = (None, 'fish', 7.2, 7j)
...  a = {1: 2}
...
>>> p = pickle.dumps(A(), protocol=2)
>>> p
u'\x80\x02c__main__\nA\nq\x00)\x81q\x01}q\x02b.'
>>> from System import Array, Byte
>>> a = Array[Byte](tuple(Byte(ord(c)) for c in p))
>>> a
Array[Byte]((, 


I hope this is at least slightly helpful. :-)

Michael




My basic issue is that the 'str' unavoidably implies certain semantics when
calling .NET APIs from IronPython. These APIs interpret str as text rather
than just bytes, which therefore gets transformed by various text encodings,
such as UTF-8 to UTF-16. Such encodings are undesirable for my pickled data
since the result is no longer necessarily a valid pickle.   I suppose the
intention in Python 3.0 is that 'bytes' doesn't carry any semantics with it,
its just data, which is why pickle.dumps() in Python 3.0 returns bytes
rather than str.

I want to push plain old byte arrays into the database from both CPython and
IronPython, so I can avoid any head-scratching confusion with database
adapters and/or databases inappropriately encoding or decoding my data.

  
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).



Thanks. I'll try something based on that.

  

Is this a theoretical problem at this stage or an actual problem?



Its an actual problem with SQLiteParameter.Value from the SQLite ADO.NET
provider.  I think our original CPython code is a bit sloppy with respect to
the distinction between text strings and byte arrays, so I'll probably need
to tighten things up on both sides.

Would you agree tha using unicode() and bytes() everywhere and avoiding
str() gives code that has the same meaning in Python 2.6, IronPython 2.6 and
Python 3.0?  Do you think this would be a good guideline to follow until we
can leave Python 2.x behind?

Many thanks,

Rob



  



--
http://www.ironpythoninaction.com/

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Portable use of pickle.dumps()

[Michael Foord]

Robert Smallshire wrote:

[snip...]


Is this a theoretical problem at this stage or an actual problem?



Its an actual problem with SQLiteParameter.Value from the SQLite ADO.NET
provider.  I think our original CPython code is a bit sloppy with respect to
the distinction between text strings and byte arrays, so I'll probably need
to tighten things up on both sides.

Would you agree tha using unicode() and bytes() everywhere and avoiding
str() gives code that has the same meaning in Python 2.6, IronPython 2.6 and
Python 3.0?  Do you think this would be a good guideline to follow until we
can leave Python 2.x behind?

  


In Python 2.6 isn't bytes just an alias for str?

IronPython 2.6 may treat it slightly differently however...

On the CPython side I would definitely store text as Unicode as any 
problems you have treating strings as binary data (or vice versa) should 
become obvious a lot sooner.


All the best,

Michael


Many thanks,

Rob



  



--
http://www.ironpythoninaction.com/

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Portable use of pickle.dumps()

[Michael Foord]

Michael Foord wrote:

[snip...]
Here is an example of getting a byte array from a binary pickle in 
IronPython:


>>> import pickle
>>> class A(object):
...  b = 'hello'
...  c = (None, 'fish', 7.2, 7j)
...  a = {1: 2}
...
>>> p = pickle.dumps(A(), protocol=2)
>>> p
u'\x80\x02c__main__\nA\nq\x00)\x81q\x01}q\x02b.'
>>> from System import Array, Byte
>>> a = Array[Byte](tuple(Byte(ord(c)) for c in p))
>>> a
Array[Byte]((, 




And the converse:

>>> p2 = ''.join(chr(c) for c in a)
>>> a2 = pickle.loads(p2)
>>> a2

>>> a2.a
{1: 2}
>>> a2.b
'hello'
>>> a2.c
(None, 'fish', 7.2, 7j)


Michael



I hope this is at least slightly helpful. :-)

Michael



My basic issue is that the 'str' unavoidably implies certain 
semantics when
calling .NET APIs from IronPython. These APIs interpret str as text 
rather
than just bytes, which therefore gets transformed by various text 
encodings,
such as UTF-8 to UTF-16. Such encodings are undesirable for my 
pickled data
since the result is no longer necessarily a valid pickle.   I suppose 
the
intention in Python 3.0 is that 'bytes' doesn't carry any semantics 
with it,

its just data, which is why pickle.dumps() in Python 3.0 returns bytes
rather than str.

I want to push plain old byte arrays into the database from both 
CPython and

IronPython, so I can avoid any head-scratching confusion with database
adapters and/or databases inappropriately encoding or decoding my data.

 
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).



Thanks. I'll try something based on that.

 

Is this a theoretical problem at this stage or an actual problem?



Its an actual problem with SQLiteParameter.Value from the SQLite ADO.NET
provider.  I think our original CPython code is a bit sloppy with 
respect to
the distinction between text strings and byte arrays, so I'll 
probably need

to tighten things up on both sides.

Would you agree tha using unicode() and bytes() everywhere and avoiding
str() gives code that has the same meaning in Python 2.6, IronPython 
2.6 and
Python 3.0?  Do you think this would be a good guideline to follow 
until we

can leave Python 2.x behind?

Many thanks,

Rob



  






--
http://www.ironpythoninaction.com/

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] IronPython 2.6 CodePlex Source Update

[merllab]

This is an automated email letting you know that sources 
have recently been pushed out.  You can download these newer 
sources directly from 
http://ironpython.codeplex.com/SourceControl/changeset/view/53173.

ADDED SOURCES

$/IronPython/IronPython_Main/Src/IronPython/Runtime/BytesConversionAttribute.cs
$/IronPython/IronPython_Main/Src/Tests/plans
$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.derivation.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.derivation.test_ctor_override.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.derivation.test_event_override.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.derivation.test_method_override.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.derivation.test_method_signature.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.derivation.test_property_override.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.derivation.test_simplederive.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.derivation.test_special_method.html
$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.event.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.event.test_delegate.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.event.test_event.html
$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.field.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.field.test_field_misc.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.field.test_fields_inside_enum.html
$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.insert_csharp.html
$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.method.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.method.test_arguments.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.method.test_op_explicit.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.method.test_op_implicit.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.method.test_operators.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.method.test_returnvalue.html
$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.property.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.property.test_indexercs.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.property.test_indexervb.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.property.test_property.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.test_accessibility.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.test_dynamicobjectmodel.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.test_loadorder.html
$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.type.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.type.test_assembly.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.type.test_clr_array.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.type.test_ctor.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.type.test_defaultmember.html

$/IronPython/IronPython_Main/Src/Tests/plans/interop.net.type.test_reachtype.html

DELETED SOURCES

$/IronPython/IronPython_Main/Src/IronPython/Runtime/ProhibitGenericListConversion.cs

MODIFIED SOURCES

$/IronPython/IronPython_Main/Src/IronPython/Runtime/BytesConversionAttribute.cs

$/IronPython/IronPython_Main/Src/Tests/interop/com/dlrcomlib/pytraits/method.py

$/IronPython/IronPython_Main/Src/IronPython/Runtime/Binding/PythonOverloadResolver.cs

$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Ast/ExpressionVisitor.cs

$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/LightLambda.cs

$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Actions/ExpandoObject.cs

$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/LightDelegateCreator.cs

$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Interpreter/LightLambda.Generated.cs

$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Utils/ReadOnlyCollectionBuilder.cs
$/IronPython/IronPython_Main/Src/IronPython/Compiler/PythonGlobal.cs

$/IronPython/IronPython_Main/Src/Tests/interop/net/field/test_initonly_fields.py
$/IronPython/IronPython_Main/Src/Tests/interop/net/field/__init__.py

$/IronPython/IronPython_Main/Src/Tests/interop/net/field/test_fields_inside_enum.py

$/IronPython/IronPython_Main/Src/Tests/interop/net/field/test_field_misc.py

Re: [IronPython] Portable use of pickle.dumps()

[Robert Smallshire]

Hi Michael,

[snip]

> > My opening paragraph may be ambiguously worded - by 
> 'interoperability' 
> > I didn't mean the ability to run the same code unchanged on CPython 
> > and IronPython (I have to change the code anyway to use a different 
> > database
> > adapter) - I meant interoperability between pickles persisted into a
> > database from both IronPython and CPython.
> >   
> 
> So are you telling the database that it is binary data or text?

Binary - the column is a BLOB, but SQLite is dynamically typed, and indeed
weakly typed, and so seems to store pretty much whatever you give it!

> 
> Is the question how do I go from a pickle string in 
> IronPython to a byte 
> array that I can pass to the database adaptor without going 
> through an 
> explicit encode (which will transform the data)?

Yes.

> 
> (One technique would be to explicitly use pickle protocol 0 which is 
> less efficient but only creates ascii characters - this is 
> actually the 
> default. Another alternative would be to use JSON or YAML instead of 
> pickle.)

I'm pickling data in the hundreds of megabytes to multi-gigabyte range, so
the binary pickling format is essential for performance and compactness
reasons. This much we know from our experience with the CPython end of
things.

> 
> Here is an example of getting a byte array from a binary pickle in 
> IronPython:
> 
>  >>> import pickle
>  >>> class A(object):
> ...  b = 'hello'
> ...  c = (None, 'fish', 7.2, 7j)
> ...  a = {1: 2}
> ...
>  >>> p = pickle.dumps(A(), protocol=2)
>  >>> p
> u'\x80\x02c__main__\nA\nq\x00)\x81q\x01}q\x02b.'
>  >>> from System import Array, Byte
>  >>> a = Array[Byte](tuple(Byte(ord(c)) for c in p))
>  >>> a
> Array[Byte]((, 
>  
> I hope this is at least slightly helpful. :-)

Its definitely helpful. The Array[Byte] syntax is new to me, but now I've
looked it up, something along these lines looks to what I need. I'll also be
investigating how the 'bytes' type works in IronPython since it seems to be
a distict type from 'str' and close to what I need.  The database is
actually giving me Array[Byte] back in IronPython when I extract data that's
been inserted by CPython. In fact 'bytes' appears to be constructable from
IList[Byte] in IronPython.

Thanks again for you help,

Rob

P.S. I've just ordered IronPython in Action. :-)

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] Minor bug in conversion of str to bytes?

[Robert Smallshire]

Hello,

Lets create a bytes instance from a str, and convert it back to a str.

>>> a = bytes(ord(c) for c in "Hello World")
>>> a
b'Hello World'
>>> str(a)
"b'Hello World'"

As you can see, the leading b and the quotes become part of the string,
which is unexpected.  I guess the conversion is using __repr__ where it
should use __str__.

Cheers,

Rob

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Portable use of pickle.dumps()

[Vernon Cole]

I would humbly suggest that if you were to use adodbapi for your database
access, the adapter would take care of all of  this for you, and will also
work in Python 3.0. Unfortunatly, the last remaining bug in adodbapi (caused
by a bug in the IronPython COM interface) is in this exact area -- binary
buffers.  If you are actually using only string (or unicode) data, passed as
such, it would work perfectly for you.
  I was hoping to provide you with examples from the adodbapi source code of
how to work around this problem (since your application is doing basically
the same thing.) On reviewing the code, though, I find that I there are no
longer any visible examples of str vs. unicode incompatibily fixes. Iron
Python does that good a job at masking the difference!
  Nevertheless, I can point to a code fragment which handles the difference
between python 2 and python 3, which may be instructive.  The method I used
is to create a local object which is used as if it were a type. That
definition is done once, at import time, and then freely used in the classes
below. You could use a similar construct based on whether IronPython or
CPython were in use.

The following snippet runs in CPython versions 2.3 thru 2.6 and IronPython,
and, after being processed by 2to3.py runs on Python 3.0. Both CPython 2.x
and IronPython use the "else" branch for their object definitions in this
case.


# --- define objects to smooth out Python3000 <-> Python 2.x differences
unicodeType = unicode  #this line will be altered by 2to3.py to '= str'
longType = long#thil line will be altered by 2to3.py to '= int'
memoryViewType = types.BufferType #will be altered to '= memoryview'
if sys.version[0] == '3':
StringTypes = [str]
makeByteBuffer = bytes
else:
makeByteBuffer = buffer
bytes = str
StringTypes = types.StringTypes# will be messed up by 2to3 but never
used


So the code to create a binary blob (as required by PEP 249) becomes:

def Binary(aString):
"""This function constructs an object capable of holding a binary (long)
string value. """
return makeByteBuffer(aString)


Hope this helps some.
--
Vernon Cole
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Portable use of pickle.dumps()

[Vernon Cole]

Follow up to my own comment...

On Fri, May 29, 2009 at 11:38 AM, Vernon Cole  wrote:

> . You could use a similar construct based on whether IronPython or CPython
> were in use.
>

I note that effort is now going forward to port pywin32 to IronPython. When
that happens, my code will break, because it uses:

try:
import win32com.client
onIronPython = False
except ImportError:  # implies running on IronPython
onIronPython = True

in order to detect which environment it is on.

I should change this for the next version of adodbapi.

Question for the group:
  What is a better/best way to test for IronPython vs CPython?
--
Vernon

P.S.
 Robert:
 Thanks for documenting this. I am contemplating a new fork of adodbapi
based on ADO.NET rather than COM (my target is Linux/mono so COM is out of
the question.) I will very likely run into this problem when/if I make that
jump.
--
VC
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Portable use of pickle.dumps()

[Michael Foord]

Vernon Cole wrote:

Follow up to my own comment...

On Fri, May 29, 2009 at 11:38 AM, Vernon Cole > wrote:


. You could use a similar construct based on whether IronPython or
CPython were in use.


I note that effort is now going forward to port pywin32 to IronPython. 
When that happens, my code will break, because it uses:


try:
import win32com.client
onIronPython = False
except ImportError:  # implies running on IronPython
onIronPython = True

in order to detect which environment it is on.

I should change this for the next version of adodbapi.

Question for the group:
  What is a better/best way to test for IronPython vs CPython?


sys.platform == 'cli'

Michael


--
Vernon

P.S.
 Robert:
 Thanks for documenting this. I am contemplating a new fork of 
adodbapi based on ADO.NET  rather than COM (my target 
is Linux/mono so COM is out of the question.) I will very likely run 
into this problem when/if I make that jump.

--
VC



___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Minor bug in conversion of str to bytes?

[Dino Viehland]

Unfortunately there's probably going to continue to be a bunch of corner
cases related to bytes/str/unicode until we move to 3.0.  But hopefully
we can come up w/ reasonable workarounds for most of them.

In this case it seems like we should define __str__ on bytes and make
it return a Unicode string w/o the b''.  We can keep repr in there so
that an explicit repr still gives you the b'' representation...

Ahh, I can't wait until Ipy 3.0!


-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Robert Smallshire
Sent: Friday, May 29, 2009 10:29 AM
To: 'Discussion of IronPython'
Subject: [IronPython] Minor bug in conversion of str to bytes?

Hello,

Lets create a bytes instance from a str, and convert it back to a str.

>>> a = bytes(ord(c) for c in "Hello World")
>>> a
b'Hello World'
>>> str(a)
"b'Hello World'"

As you can see, the leading b and the quotes become part of the string,
which is unexpected.  I guess the conversion is using __repr__ where it
should use __str__.

Cheers,

Rob

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Minor bug in conversion of str to bytes?

[Michael Foord]

Dino Viehland wrote:

Unfortunately there's probably going to continue to be a bunch of corner
cases related to bytes/str/unicode until we move to 3.0.  But hopefully
we can come up w/ reasonable workarounds for most of them.

In this case it seems like we should define __str__ on bytes and make
it return a Unicode string w/o the b''.  We can keep repr in there so
that an explicit repr still gives you the b'' representation...

Ahh, I can't wait until Ipy 3.0!
  


In Python 2.6 the bytes type is just an alias for str I believe, am I 
incorrect? If I am correct why is IronPython 2.6 taking a different 
approach?


Michael



-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Robert Smallshire
Sent: Friday, May 29, 2009 10:29 AM
To: 'Discussion of IronPython'
Subject: [IronPython] Minor bug in conversion of str to bytes?

Hello,

Lets create a bytes instance from a str, and convert it back to a str.

  

a = bytes(ord(c) for c in "Hello World")
a


b'Hello World'
  

str(a)


"b'Hello World'"

As you can see, the leading b and the quotes become part of the string,
which is unexpected.  I guess the conversion is using __repr__ where it
should use __str__.

Cheers,

Rob

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Minor bug in conversion of str to bytes?

[cur...@acm.org]

On Fri, May 29, 2009 at 13:33, Michael Foord wrote:

> Dino Viehland wrote:
>
>> Unfortunately there's probably going to continue to be a bunch of corner
>> cases related to bytes/str/unicode until we move to 3.0.  But hopefully
>> we can come up w/ reasonable workarounds for most of them.
>>
>> In this case it seems like we should define __str__ on bytes and make
>> it return a Unicode string w/o the b''.  We can keep repr in there so
>> that an explicit repr still gives you the b'' representation...
>>
>> Ahh, I can't wait until Ipy 3.0!
>>
>>
>
> In Python 2.6 the bytes type is just an alias for str I believe, am I
> incorrect? If I am correct why is IronPython 2.6 taking a different
> approach?
>
> Michael


Correct. Include\bytesobject.h in CPython 2.6 source is just #defines to
make the PyBytes* names available and pointing to PyString* names.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Portable use of pickle.dumps()

[Robert Smallshire]

Michael,

> Michael Foord wrote:
> > [snip...]
> > Here is an example of getting a byte array from a binary pickle in
> > IronPython:
> >
> > >>> import pickle
> > >>> class A(object):
> > ...  b = 'hello'
> > ...  c = (None, 'fish', 7.2, 7j)
> > ...  a = {1: 2}
> > ...
> > >>> p = pickle.dumps(A(), protocol=2)
> > >>> p
> > u'\x80\x02c__main__\nA\nq\x00)\x81q\x01}q\x02b.'
> > >>> from System import Array, Byte
> > >>> a = Array[Byte](tuple(Byte(ord(c)) for c in p))
> > >>> a
> > Array[Byte]((,
> >  >
> 
> And the converse:
> 
>  >>> p2 = ''.join(chr(c) for c in a)
>  >>> a2 = pickle.loads(p2)
>  >>> a2
> 
>  >>> a2.a
> {1: 2}
>  >>> a2.b
> 'hello'
>  >>> a2.c
> (None, 'fish', 7.2, 7j)

As a result of applying your str <--> Array[Byte] transformations to my
code, the persistence of pickles into SQLite BLOBs is now working as
planned. :-)

You'll also no doubt be pleased to hear that even with these extra
transformations, the IronPython version is around twice as fast as CPython
2.6 on a benchmark performed under completely unscientific conditions -
although there are many factors at play here...

Thanks again,

Rob

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Portable use of pickle.dumps()

[Michael Foord]

Robert Smallshire wrote:

Michael,

  

Michael Foord wrote:


[snip...]
Here is an example of getting a byte array from a binary pickle in
IronPython:

  

import pickle
class A(object):


...  b = 'hello'
...  c = (None, 'fish', 7.2, 7j)
...  a = {1: 2}
...
  

p = pickle.dumps(A(), protocol=2)
p


u'\x80\x02c__main__\nA\nq\x00)\x81q\x01}q\x02b.'
  

from System import Array, Byte
a = Array[Byte](tuple(Byte(ord(c)) for c in p))
a


Array[Byte]((,
  

And the converse:

 >>> p2 = ''.join(chr(c) for c in a)
 >>> a2 = pickle.loads(p2)
 >>> a2

 >>> a2.a
{1: 2}
 >>> a2.b
'hello'
 >>> a2.c
(None, 'fish', 7.2, 7j)



As a result of applying your str <--> Array[Byte] transformations to my
code, the persistence of pickles into SQLite BLOBs is now working as
planned. :-)

You'll also no doubt be pleased to hear that even with these extra
transformations, the IronPython version is around twice as fast as CPython
2.6 on a benchmark performed under completely unscientific conditions -
although there are many factors at play here...

  


Cool. :-)

Michael


Thanks again,

Rob
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Minor bug in conversion of str to bytes?

[Dino Viehland]

Because in IronPython str is just an alias for Unicode.  I think it would
be extremely broken for us to alias all 3 to unicode especially when bytes
clearly has a different meaning.

-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, May 29, 2009 11:34 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Minor bug in conversion of str to bytes?

Dino Viehland wrote:
> Unfortunately there's probably going to continue to be a bunch of corner
> cases related to bytes/str/unicode until we move to 3.0.  But hopefully
> we can come up w/ reasonable workarounds for most of them.
>
> In this case it seems like we should define __str__ on bytes and make
> it return a Unicode string w/o the b''.  We can keep repr in there so
> that an explicit repr still gives you the b'' representation...
>
> Ahh, I can't wait until Ipy 3.0!
>

In Python 2.6 the bytes type is just an alias for str I believe, am I
incorrect? If I am correct why is IronPython 2.6 taking a different
approach?

Michael

>
> -Original Message-
> From: users-boun...@lists.ironpython.com 
> [mailto:users-boun...@lists.ironpython.com] On Behalf Of Robert Smallshire
> Sent: Friday, May 29, 2009 10:29 AM
> To: 'Discussion of IronPython'
> Subject: [IronPython] Minor bug in conversion of str to bytes?
>
> Hello,
>
> Lets create a bytes instance from a str, and convert it back to a str.
>
>
 a = bytes(ord(c) for c in "Hello World")
 a

> b'Hello World'
>
 str(a)

> "b'Hello World'"
>
> As you can see, the leading b and the quotes become part of the string,
> which is unexpected.  I guess the conversion is using __repr__ where it
> should use __str__.
>
> Cheers,
>
> Rob
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Minor bug in conversion of str to bytes?

[Michael Foord]

Dino Viehland wrote:

Because in IronPython str is just an alias for Unicode.  I think it would
be extremely broken for us to alias all 3 to unicode especially when bytes
clearly has a different meaning.

  


Hmm... interesting. :-)

Michael



-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, May 29, 2009 11:34 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Minor bug in conversion of str to bytes?

Dino Viehland wrote:
  

Unfortunately there's probably going to continue to be a bunch of corner
cases related to bytes/str/unicode until we move to 3.0.  But hopefully
we can come up w/ reasonable workarounds for most of them.

In this case it seems like we should define __str__ on bytes and make
it return a Unicode string w/o the b''.  We can keep repr in there so
that an explicit repr still gives you the b'' representation...

Ahh, I can't wait until Ipy 3.0!




In Python 2.6 the bytes type is just an alias for str I believe, am I
incorrect? If I am correct why is IronPython 2.6 taking a different
approach?

Michael

  

-Original Message-
From: users-boun...@lists.ironpython.com 
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Robert Smallshire
Sent: Friday, May 29, 2009 10:29 AM
To: 'Discussion of IronPython'
Subject: [IronPython] Minor bug in conversion of str to bytes?

Hello,

Lets create a bytes instance from a str, and convert it back to a str.




a = bytes(ord(c) for c in "Hello World")
a

  

b'Hello World'



str(a)

  

"b'Hello World'"

As you can see, the leading b and the quotes become part of the string,
which is unexpected.  I guess the conversion is using __repr__ where it
should use __str__.

Cheers,

Rob

___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com





--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Portable use of pickle.dumps()

[Jeff Hardy]

On Fri, May 29, 2009 at 12:05 PM, Vernon Cole  wrote:
> P.S.
>  Robert:
>  Thanks for documenting this. I am contemplating a new fork of adodbapi
> based on ADO.NET rather than COM (my target is Linux/mono so COM is out of
> the question.) I will very likely run into this problem when/if I make that
> jump.

Hi Vernon,
Check out http://bitbucket.org/jdhardy/adonet-dbapi/. I'm not sure
it's what you're looking for, but it may be of use. It's a fork of the
same code from FePy.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] ironpython compared to powershell

[Jeff Hardy]

I prefer to use powershell if I'm dealing with files, registry
entries, AD, and (especially!) external programs - your classic shell
scripting tasks, essentially. It's what it was designed for.

Python, on the other hand, is a fantastic language for building and
extending applications.

- Jeff


On Tue, May 26, 2009 at 7:58 AM, jocke khazad  wrote:
> Hi everyone!
>
> I would like you ask this question that I seem not to get an answer for
> anywhere.
>
> What is the advantage of using ironpython compared to using only powershell?
> Or is it just a personal choice which one you like the best?
>
>
> Best Regards,
>
> Joakim
>
> ___
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] how to work with delegates in IronPython

[Vadim Khaskel]

Hello everybody,

Could somebody help to setup simple delegate in IronPython.

I just need to generate event when list structure gets filled with data, 

and update GUI element.

thanks a lot,

V.

_
Hotmail® has a new way to see what's up with your friends.
http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

[IronPython] IronPython 2.6 and .NET 4.0 (and the GAC)

[Jeff Hardy]

Hi all,
Are there plans to release versions of 2.6 for both .NET 2.0 & .NET
4.0, or are the 4.0 previews just for demonstration?

Also, (as nobody noticed my earlier mail :)), are there plans to
support adding 2.6 to the GAC? When I asked for 2.0, it was mentioned
that there are more stringent requirements for the GAC; I'm just
wondering if those are being targetted.

- Jeff
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com