From jdhardy at gmail.com  Fri Aug  7 07:13:35 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 6 Aug 2015 22:13:35 -0700
Subject: [Ironpython-users] Support of Python 3.x
In-Reply-To: <CANA9pOqRh7y6g0b_O7Us=DXR-aXxC+pCHLwRb7evPRqqHJ6Zcg@mail.gmail.com>
References: <CANA9pOqRh7y6g0b_O7Us=DXR-aXxC+pCHLwRb7evPRqqHJ6Zcg@mail.gmail.com>
Message-ID: <CAF7AXFHrrRotLuO0CS0Ooze8dUNQk=gWcDPG9R=v1q=HEA6zYg@mail.gmail.com>

There are plans, and even some small amount of work
(https://github.com/IronLanguages/ironpython3). However time is the
usual issue.

If you want to help (great!) then a decent introduction to
IronPython's internals is http://aosabook.org/en/ironlang.html. The
main work that needs to be done is to bring the parser up to 3.x;
consider looking at the parser in Python Tools for Visual Studio,
since it's derived from the IronPython parser but supports syntax up
to 3.5. Then, of course, the parser needs to generate code to actually
support that stuff.

I have code for function attributes and kw-only args in a branch
somewhere but they're so old it might be easier to just reimplement
them from scratch using the code as a guide.

There's no better way to learn a language than working on a big program. :)

- Jeff


On Tue, Jul 28, 2015 at 6:44 AM, J?n Gnip <jsemgnip at gmail.com> wrote:
> Hi guys,
> are there any planned releases with python 3.x support? If so, do you know
> estimated dates? What needs to be done and how can I help you with something
> with intermediate python skills and beginner C# skills?
> Thank you for the info.
>
> Droidik
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>

From m.schaber at codesys.com  Fri Aug  7 08:40:33 2015
From: m.schaber at codesys.com (Markus Schaber)
Date: Fri, 7 Aug 2015 06:40:33 +0000
Subject: [Ironpython-users] question
In-Reply-To: <806CEE10BA7D4942B62B9C69A111C5FC2139E853@MBX214.d.ethz.ch>
References: <806CEE10BA7D4942B62B9C69A111C5FC2139E853@MBX214.d.ethz.ch>
Message-ID: <727D8E16AE957149B447FE368139F2B56CCE7964@SERVER10>

Hi, Gandia Augusto,

in contrast to cPython 2.7, IronPython does not have byte-strings. This is due to .NET - strings in .NET are always unicode, they're the same type there. And to convert an Unicode string to a byte array, you will always need an encoding.

The situation wr/t strings is much more similar to cPython 3.x, where str is always unicode.
Whether this concrete occurrence can be considered a bug in IronPython (it should be able to cope with it), I don't know.

On the other hand, a simple reproduction fails on my machine:
IronPython 2.7.5 (2.7.5.0) on .NET 4.0.30319.42000 (32-bit)
Type "help", "copyright", "credits" or "license" for more information.
>>> bytearray
<type 'bytearray'>
>>> bytearray('hallo')
bytearray(b'hallo')
>>> bytearray('hallo???')
bytearray(b'hallo\xe4\xf6\xfc')
>>>

So there must be something more (which IronPython version are you using?)

However, you should be able to work around the problem by specifying an encoding:
>>> bytearray('hallo???', "latin-1")
bytearray(b'hallo\xe4\xf6\xfc')
>>> bytearray('hallo???', "utf-8")
bytearray(b'hallo\xc3\xa4\xc3\xb6\xc3\xbc')

So your code could look something like
...
    else:
        if type(signalValue) is bytearray:
            sigV = (ct.c_ubyte*len(signalValue))(*signalValue)
        if type(signalValue) is unicode:
            signalValue=bytearray(signalValue, 'ascii') # use whatever encoding is appropriate
            sigV = (ct.c_ubyte*len(signalValue))(*signalValue)
        if type(signalValue) is str:
            signalValue=bytearray(signalValue)
            sigV = (ct.c_ubyte*len(signalValue))(*signalValue)
...

Just make sure that you check for unicode before you check for str, as on Ironpython:
>>> unicode is str
True


Best regards

Markus Schaber

CODESYS? a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions
________________________________
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com<mailto:m.schaber at codesys.com> | Web: codesys.com<http://www.codesys.com> | CODESYS store: store.codesys.com<http://store.codesys.com>
CODESYS forum: forum.codesys.com<http://forum.codesys.com>

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
Von: Ironpython-users [mailto:ironpython-users-bounces+m.schaber=codesys.com at python.org] Im Auftrag von Gandia Augusto
Gesendet: Donnerstag, 30. Juli 2015 09:51
An: ironpython-users at python.org
Betreff: [Ironpython-users] question

In this function:

def simxWriteStringStream(clientID, signalName, signalValue, operationMode):
    '''
    Please have a look at the function description/documentation in the V-REP user manual
    '''

    sigV=signalValue
    if sys.version_info[0] == 3:
        if type(signalName) is str:
            signalName=signalName.encode('utf-8')
        if type(signalValue) is bytearray:
            sigV  = (ct.c_ubyte*len(signalValue))(*signalValue)
        if type(signalValue) is str:
            signalValue=signalValue.encode('utf-8')
            sigV  = (ct.c_ubyte*len(signalValue))(*signalValue)
    else:
        if type(signalValue) is bytearray:
            sigV = (ct.c_ubyte*len(signalValue))(*signalValue)
        if type(signalValue) is str:
            signalValue=bytearray(signalValue)#<=============================================================HERE IS WHERE I GET THE ERROR
            sigV = (ct.c_ubyte*len(signalValue))(*signalValue)
    sigV=ct.cast(sigV,ct.POINTER(ct.c_ubyte)) # IronPython needs this
    return c_WriteStringStream(clientID, signalName, sigV, len(signalValue), operationMode)




The error I get is :

Program started
Connected to remote API server
Runtime error (TypeErrorException): unicode argument without an encoding
Traceback:
  line 1052, in simxWriteStringStream, "C:\Program Files (x86)\V-REP3\V-REP_PRO_EDU\programming\remoteApiBindings\python\python\vrep.py"
  line 70, in script


Any idea of what this could be?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150807/2ffc745a/attachment.html>

From m.schaber at codesys.com  Fri Aug  7 09:47:11 2015
From: m.schaber at codesys.com (Markus Schaber)
Date: Fri, 7 Aug 2015 07:47:11 +0000
Subject: [Ironpython-users] Problem with the "in" operator for
In-Reply-To: <CAF7AXFGBZgUsyUDsYJ8j3DbkZ+MtLYzzjySGS7-t0msEQQ6oMQ@mail.gmail.com>
References: <727D8E16AE957149B447FE368139F2B56CCA3E96@SERVER10>
 <1754090284.20150708075520@mail.mipt.ru>
 <727D8E16AE957149B447FE368139F2B56CCA57B9@SERVER10>
 <CAF7AXFGBZgUsyUDsYJ8j3DbkZ+MtLYzzjySGS7-t0msEQQ6oMQ@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B56CCE79D5@SERVER10>

Hi, Jeff,

Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> On Thu, Jul 9, 2015 at 11:50 PM, Markus Schaber
> <m.schaber at codesys.com> wrote:
> > Hi, Ivan,
> >
> > Von: Ivan Pozdeev [mailto:vano at mail.mipt.ru]
> >
> >> > As far as I can see, the "in" operator should return true if any
> >> > object in the enumerable is "equal" to the object given as
> >> >reference:
> >>
> >> Indeed,
> >> https://docs.python.org/2/reference/expressions.html#membership-test-details states:
> >>
> >> For the list and tuple types, x in y is true if and only if there
> >> exists an index i such that x == y[i] is true.
> >>
> >> Now, to check if IronPython honors this.
> >>
> >> > assert a in (a,), 'a is in (a,)'
> >> > assert a in (b,), 'a is in (b,)' # this one fails...
> >>
> >> > As far as I can see via breakpoints, the Equals methods of the
> >> > objects are never actually called, except on the first assertion
> >> > with the == operator.
> >>
> >> My guess is it's cutting corners by comparing hashes instead.
> >
> > Hm, the GetHashCode() method in my example is hardcoded to return
> > 0, and it is not even called (at least, the breakpoint is not hit.
> >
> > There must be something more subtle...
> 
> In theory it should be creating a dynamic call site for "equals" that
> will handle all of the cases (except for types that have a
> __contains__ method) including IDMOP. Which there could very likely
> be a bug in how that is generated; I'm not sure the IDMOP is stuff
> gets excersized as much as it should.

What to do now?

Should I file a bug report on https://github.com/IronLanguages/main/issues ?



Best regards

Markus Schaber

CODESYS? a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.

From jdhardy at gmail.com  Sun Aug  9 17:50:15 2015
From: jdhardy at gmail.com (Jeff Hardy)
Date: Sun, 9 Aug 2015 08:50:15 -0700
Subject: [Ironpython-users] Problem with the "in" operator for
In-Reply-To: <727D8E16AE957149B447FE368139F2B56CCE79D5@SERVER10>
References: <727D8E16AE957149B447FE368139F2B56CCA3E96@SERVER10>
 <1754090284.20150708075520@mail.mipt.ru>
 <727D8E16AE957149B447FE368139F2B56CCA57B9@SERVER10>
 <CAF7AXFGBZgUsyUDsYJ8j3DbkZ+MtLYzzjySGS7-t0msEQQ6oMQ@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B56CCE79D5@SERVER10>
Message-ID: <CAF7AXFFWrhjrK6VmRhDN_3By=WY_JMYG1Yq6zx-uNRcD0AsCew@mail.gmail.com>

On Fri, Aug 7, 2015 at 12:47 AM, Markus Schaber <m.schaber at codesys.com> wrote:
> Hi, Jeff,
>
> Von: Jeff Hardy [mailto:jdhardy at gmail.com]
>> On Thu, Jul 9, 2015 at 11:50 PM, Markus Schaber
>> <m.schaber at codesys.com> wrote:
>> > Hi, Ivan,
>> >
>> > Von: Ivan Pozdeev [mailto:vano at mail.mipt.ru]
>> >
>> >> > As far as I can see, the "in" operator should return true if any
>> >> > object in the enumerable is "equal" to the object given as
>> >> >reference:
>> >>
>> >> Indeed,
>> >> https://docs.python.org/2/reference/expressions.html#membership-test-details states:
>> >>
>> >> For the list and tuple types, x in y is true if and only if there
>> >> exists an index i such that x == y[i] is true.
>> >>
>> >> Now, to check if IronPython honors this.
>> >>
>> >> > assert a in (a,), 'a is in (a,)'
>> >> > assert a in (b,), 'a is in (b,)' # this one fails...
>> >>
>> >> > As far as I can see via breakpoints, the Equals methods of the
>> >> > objects are never actually called, except on the first assertion
>> >> > with the == operator.
>> >>
>> >> My guess is it's cutting corners by comparing hashes instead.
>> >
>> > Hm, the GetHashCode() method in my example is hardcoded to return
>> > 0, and it is not even called (at least, the breakpoint is not hit.
>> >
>> > There must be something more subtle...
>>
>> In theory it should be creating a dynamic call site for "equals" that
>> will handle all of the cases (except for types that have a
>> __contains__ method) including IDMOP. Which there could very likely
>> be a bug in how that is generated; I'm not sure the IDMOP is stuff
>> gets excersized as much as it should.
>
> What to do now?
>
> Should I file a bug report on https://github.com/IronLanguages/main/issues ?

That's probably the best bet, with as minimal a reproduction as
possible. These code generation bugs are the hardest to deal with
because I have to page everything involved back into my brain, and
it's an absolute knot of code to sort through. So, no promises that
I'll get to it anytime soon. :(

- Jeff

From m.schaber at codesys.com  Tue Aug 11 22:35:37 2015
From: m.schaber at codesys.com (Markus Schaber)
Date: Tue, 11 Aug 2015 20:35:37 +0000
Subject: [Ironpython-users] Problem with the "in" operator for
In-Reply-To: <CAF7AXFFWrhjrK6VmRhDN_3By=WY_JMYG1Yq6zx-uNRcD0AsCew@mail.gmail.com>
References: <727D8E16AE957149B447FE368139F2B56CCA3E96@SERVER10>
 <1754090284.20150708075520@mail.mipt.ru>
 <727D8E16AE957149B447FE368139F2B56CCA57B9@SERVER10>
 <CAF7AXFGBZgUsyUDsYJ8j3DbkZ+MtLYzzjySGS7-t0msEQQ6oMQ@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B56CCE79D5@SERVER10>
 <CAF7AXFFWrhjrK6VmRhDN_3By=WY_JMYG1Yq6zx-uNRcD0AsCew@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B56CCEB049@SERVER10>

Hi, Jeff,

> -----Urspr?ngliche Nachricht-----
> Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> Gesendet: Sonntag, 9. August 2015 17:50
> An: Markus Schaber
> Cc: Discussion of IronPython
> Betreff: Re: [Ironpython-users] Problem with the "in" operator for
> 
> On Fri, Aug 7, 2015 at 12:47 AM, Markus Schaber
> <m.schaber at codesys.com> wrote:
> > Hi, Jeff,
> >
> > Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> >> On Thu, Jul 9, 2015 at 11:50 PM, Markus Schaber
> >> <m.schaber at codesys.com> wrote:
> >> > Hi, Ivan,
> >> >
> >> > Von: Ivan Pozdeev [mailto:vano at mail.mipt.ru]
> >> >
> >> >> > As far as I can see, the "in" operator should return true if
> any
> >> >> >object in the enumerable is "equal" to the object given as
> >> >> >reference:
> >> >>
> >> >> Indeed,
> >> >>
> https://docs.python.org/2/reference/expressions.html#membership-test-
> details states:
> >> >>
> >> >> For the list and tuple types, x in y is true if and only if
> there
> >> >> exists an index i such that x == y[i] is true.
> >> >>
> >> >> Now, to check if IronPython honors this.
> >> >>
> >> >> > assert a in (a,), 'a is in (a,)'
> >> >> > assert a in (b,), 'a is in (b,)' # this one fails...
> >> >>
> >> >> > As far as I can see via breakpoints, the Equals methods of
> the
> >> >> > objects are never actually called, except on the first
> assertion
> >> >> > with the == operator.
> >> >>
> >> >> My guess is it's cutting corners by comparing hashes instead.
> >> >
> >> > Hm, the GetHashCode() method in my example is hardcoded to
> return
> >> > 0, and it is not even called (at least, the breakpoint is not
> hit.
> >> >
> >> > There must be something more subtle...
> >>
> >> In theory it should be creating a dynamic call site for "equals"
> that
> >> will handle all of the cases (except for types that have a
> >> __contains__ method) including IDMOP. Which there could very
> likely
> >> be a bug in how that is generated; I'm not sure the IDMOP is stuff
> >> gets excersized as much as it should.
> >
> > What to do now?
> >
> > Should I file a bug report on
> https://github.com/IronLanguages/main/issues ?
> 
> That's probably the best bet, with as minimal a reproduction as
> possible. These code generation bugs are the hardest to deal with
> because I have to page everything involved back into my brain, and
> it's an absolute knot of code to sort through. So, no promises that
> I'll get to it anytime soon. :(
> 
> - Jeff

Thank you.

I did file https://github.com/IronLanguages/main/issues/1222. It seems I did not find the right way to attach C# source files, so I had to paste it into the first comment.


Best regards

Markus Schaber

CODESYS? a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.


From slide.o.mix at gmail.com  Tue Aug 11 23:13:49 2015
From: slide.o.mix at gmail.com (Slide)
Date: Tue, 11 Aug 2015 21:13:49 +0000
Subject: [Ironpython-users] Problem with the "in" operator for
In-Reply-To: <727D8E16AE957149B447FE368139F2B56CCEB049@SERVER10>
References: <727D8E16AE957149B447FE368139F2B56CCA3E96@SERVER10>
 <1754090284.20150708075520@mail.mipt.ru>
 <727D8E16AE957149B447FE368139F2B56CCA57B9@SERVER10>
 <CAF7AXFGBZgUsyUDsYJ8j3DbkZ+MtLYzzjySGS7-t0msEQQ6oMQ@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B56CCE79D5@SERVER10>
 <CAF7AXFFWrhjrK6VmRhDN_3By=WY_JMYG1Yq6zx-uNRcD0AsCew@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B56CCEB049@SERVER10>
Message-ID: <CAPiUgVcD1Sr1_1AOjeahUsm1+fbA3bD6dKGtfVo=08pgx4oQkQ@mail.gmail.com>

The normal method for "attaching" things on GitHub is by creating a Gist
with the contents and then referencing that Gist in the issue.

On Tue, Aug 11, 2015 at 1:36 PM Markus Schaber <m.schaber at codesys.com>
wrote:

> Hi, Jeff,
>
> > -----Urspr?ngliche Nachricht-----
> > Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> > Gesendet: Sonntag, 9. August 2015 17:50
> > An: Markus Schaber
> > Cc: Discussion of IronPython
> > Betreff: Re: [Ironpython-users] Problem with the "in" operator for
> >
> > On Fri, Aug 7, 2015 at 12:47 AM, Markus Schaber
> > <m.schaber at codesys.com> wrote:
> > > Hi, Jeff,
> > >
> > > Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> > >> On Thu, Jul 9, 2015 at 11:50 PM, Markus Schaber
> > >> <m.schaber at codesys.com> wrote:
> > >> > Hi, Ivan,
> > >> >
> > >> > Von: Ivan Pozdeev [mailto:vano at mail.mipt.ru]
> > >> >
> > >> >> > As far as I can see, the "in" operator should return true if
> > any
> > >> >> >object in the enumerable is "equal" to the object given as
> > >> >> >reference:
> > >> >>
> > >> >> Indeed,
> > >> >>
> > https://docs.python.org/2/reference/expressions.html#membership-test-
> > details states:
> > >> >>
> > >> >> For the list and tuple types, x in y is true if and only if
> > there
> > >> >> exists an index i such that x == y[i] is true.
> > >> >>
> > >> >> Now, to check if IronPython honors this.
> > >> >>
> > >> >> > assert a in (a,), 'a is in (a,)'
> > >> >> > assert a in (b,), 'a is in (b,)' # this one fails...
> > >> >>
> > >> >> > As far as I can see via breakpoints, the Equals methods of
> > the
> > >> >> > objects are never actually called, except on the first
> > assertion
> > >> >> > with the == operator.
> > >> >>
> > >> >> My guess is it's cutting corners by comparing hashes instead.
> > >> >
> > >> > Hm, the GetHashCode() method in my example is hardcoded to
> > return
> > >> > 0, and it is not even called (at least, the breakpoint is not
> > hit.
> > >> >
> > >> > There must be something more subtle...
> > >>
> > >> In theory it should be creating a dynamic call site for "equals"
> > that
> > >> will handle all of the cases (except for types that have a
> > >> __contains__ method) including IDMOP. Which there could very
> > likely
> > >> be a bug in how that is generated; I'm not sure the IDMOP is stuff
> > >> gets excersized as much as it should.
> > >
> > > What to do now?
> > >
> > > Should I file a bug report on
> > https://github.com/IronLanguages/main/issues ?
> >
> > That's probably the best bet, with as minimal a reproduction as
> > possible. These code generation bugs are the hardest to deal with
> > because I have to page everything involved back into my brain, and
> > it's an absolute knot of code to sort through. So, no promises that
> > I'll get to it anytime soon. :(
> >
> > - Jeff
>
> Thank you.
>
> I did file https://github.com/IronLanguages/main/issues/1222. It seems I
> did not find the right way to attach C# source files, so I had to paste it
> into the first comment.
>
>
> Best regards
>
> Markus Schaber
>
> CODESYS? a trademark of 3S-Smart Software Solutions GmbH
>
> Inspiring Automation Solutions
>
> 3S-Smart Software Solutions GmbH
> Dipl.-Inf. Markus Schaber | Product Development Core Technology
> Memminger Str. 151 | 87439 Kempten | Germany
> Tel. +49-831-54031-979 | Fax +49-831-54031-50
>
> E-Mail: m.schaber at codesys.com | Web: http://www.codesys.com | CODESYS
> store: http://store.codesys.com
> CODESYS forum: http://forum.codesys.com
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
> Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
>
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received
> this e-mail in error) please notify the sender immediately and destroy
> this e-mail. Any unauthorised copying, disclosure
> or distribution of the material in this e-mail is strictly forbidden.
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150811/a84d986b/attachment.html>

From evan.davey at ekidna.io  Thu Aug 20 01:29:11 2015
From: evan.davey at ekidna.io (Evan Davey)
Date: Thu, 20 Aug 2015 09:29:11 +1000
Subject: [Ironpython-users] System.__ComObject: method or operation not
	implemented
Message-ID: <34BB5D39-1230-4CAF-98B3-9F490C83B3AB@ekidna.io>

HI,

I am trying to use Python to access an Application?s API that has been exposed in C#.  The API uses a client/server model via COM objects (main GUI is the client, functional blocks e.g. Schematic editor implemented as a server.

I have successfully called a number of API methods from python (e.g. to show a message dialog) in the application.

However, when I try to access the interface to the client or server, in Python I get back an object of type System.__ComObject (when these should be of type IClient or ISch_ServerInterface respectively) which then throws a method or operation not implemented error.

I have had some success calling methods via the unbound method e.g.

import DXP
client = DXP.GlobalVars.Client # of type System.__ComObject should be DXP.IClient

DXP.IClient.GetProductVersion(client) # works!

client.GetProductVersion() # throws method or operation not implemented error

Using this work-around would be fine, except that I am now encountering errors where the interface types have been extended e.g.

import EDP
import SCH
server = SCH.GlobalVar.SchServer # of type System.__ComObject should be SCH.ISch_ServerInterface

SCH.ISch_ServerInterface.CreateSchLibrary(server) # throws type has no attribute error
SCH.ISch_ServerInterfaceHelper.CreateSchLibrary(server) # this works


This works in C#

using EDP; // looks like the extension methods are implemented in here
using SCH;

SCH.ISch_ServerInterface server = SCH.GlobalVars.SchServer;
SCH.ISch_Lib lib = server.CreateSchLibrary();

Ideally, I would be able to do some kind of type cast in Python to allow me to use the objects naturally but can use the unbound method if the extension issue can be solved.  
I have tried using clr.ImportExtensons() without success.

Any help appreciated.

Best Regards,
Evan






 



Evan Davey

Ekidna
Email: evan.davey at ekidna.io
Skype: evan.j.davey
Mobile: +61 403 467 661
uk.linkedin.com/pub/evan-davey/4/982/91/ <http://uk.linkedin.com/pub/evan-davey/4/982/91/>
https://twitter.com/ekidna_io <https://twitter.com/ekidna_io>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150820/a6417556/attachment.html>

From slide.o.mix at gmail.com  Fri Aug 21 00:58:25 2015
From: slide.o.mix at gmail.com (Slide)
Date: Thu, 20 Aug 2015 22:58:25 +0000
Subject: [Ironpython-users] PythonTuple.MakeTuple
Message-ID: <CAPiUgVddP-ZgtEPzKwSpeTEj=0AkC7RLw5afNN0LQ0A2Zs0KwA@mail.gmail.com>

Can anyone tell me why this method is internal?!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150820/76a92d08/attachment.html>

From m.schaber at codesys.com  Mon Aug 24 10:27:53 2015
From: m.schaber at codesys.com (Markus Schaber)
Date: Mon, 24 Aug 2015 08:27:53 +0000
Subject: [Ironpython-users] PythonTuple.MakeTuple
In-Reply-To: <CAPiUgVddP-ZgtEPzKwSpeTEj=0AkC7RLw5afNN0LQ0A2Zs0KwA@mail.gmail.com>
References: <CAPiUgVddP-ZgtEPzKwSpeTEj=0AkC7RLw5afNN0LQ0A2Zs0KwA@mail.gmail.com>
Message-ID: <727D8E16AE957149B447FE368139F2B56CD14489@SERVER10>

Hi,

Von: Slide

> Can anyone tell me why this method is internal?!

My educated guess is that it uses the items array by value without copying it, while all public ways to construct the tuple actually copy the sequence you pass. Making that method public would allow users to create a tuple which may be modified by keeping a reference to the array. Making such an API public is rather risky. 

But you can have almost the same effect by using the public PythonTuple constructors directly.

Only the EMPTY optimization will not work, which may or may not be what you want.

PS: Note that IronPython standard library itself can still access said method, as the [InternalsVisibleTo]-Attribute on IronPython allows access to internal methods from the IronPython.Modules and IronPythonTest assemblies.

PS 2: I'm not sure whether the MakeItems() method internally used works correctly when we pass strings which contain non-BMP characters. It seems to assume a character is a single 16-bit unit. We should investigate that, and compare it to Python 2 and 3 behavior with Unicode strings containing non-BMP characters. I'm not mandating for a quick change here, but especially when Python 3.x is targeted with IronPython, we should use the most sensible behavior and (possibly) document it as one of the differences in string handling. (Another one is indexing [] into strings which contain non-BMP characters.)

PS 3: It might be an optimization to add a check o for being a ICollection, and directly allocate an array of the right size and using CopyTo. For large collections, this will be more efficient than the List<Object> constantly reallocating. On the other hand, the assumption may be that it's mostly used for small lists, and the additional type check / dynamic cast makes up for the difference. (However, we might replace bot the "is List" and "o as object[]" branches with the ICollection branch, as both implement ICollection, effectively saving one dynamic cast...)

Best regards

Markus Schaber

CODESYS? a trademark of 3S-Smart Software Solutions GmbH 

Inspiring Automation Solutions 
________________________________________
3S-Smart Software Solutions GmbH 
Dipl.-Inf. Markus Schaber | Product Development Core Technology 
Memminger Str. 151 | 87439 Kempten | Germany 
Tel. +49-831-54031-979 | Fax +49-831-54031-50 

E-Mail: m.schaber at codesys.com | Web: codesys.com | CODESYS store: store.codesys.com 
CODESYS forum: forum.codesys.com 

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 
________________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received 
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure 
or distribution of the material in this e-mail is strictly forbidden. 

From trinderjohn at talktalk.net  Mon Aug 24 23:36:57 2015
From: trinderjohn at talktalk.net (John Trinder)
Date: Mon, 24 Aug 2015 22:36:57 +0100
Subject: [Ironpython-users] Why is IP 3X slower than python 2.7?
Message-ID: <55DB8E79.3010609@talktalk.net>

I've been doing some work with python 2.7 having digressed from 
IronPython to which I shall be returning. The thing I notice most is 
that python 2.7 is roughly 3X faster at executing than IP.

Why is this?

I know python27 compiles scripts into 'C' code => .pyc files and that IP 
does not do this. But even so, IP must compile native code into NET code 
which should run only slightly slower than python27.

Regards and thanks for a good NET implementation of python.

From vernondcole at gmail.com  Tue Aug 25 05:21:30 2015
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Mon, 24 Aug 2015 21:21:30 -0600
Subject: [Ironpython-users] Why is IP 3X slower than python 2.7?
In-Reply-To: <55DB8E79.3010609@talktalk.net>
References: <55DB8E79.3010609@talktalk.net>
Message-ID: <CAH-ZgAe3qFyHiRDhR3xJ8WO+Cm6EUxgpD4h3UhNop46xuShgcA@mail.gmail.com>

On some benchmarks, IronPython is faster than CPython. But, if you are
running short scripts from the command line, IronPython is several seconds
slower, because, as you said, it compiles to dotNET code, which is not
cached for the next run.
The speed difference depends on what you are doing.

On Mon, Aug 24, 2015 at 3:36 PM, John Trinder <trinderjohn at talktalk.net>
wrote:

> I've been doing some work with python 2.7 having digressed from IronPython
> to which I shall be returning. The thing I notice most is that python 2.7
> is roughly 3X faster at executing than IP.
>
> Why is this?
>
> I know python27 compiles scripts into 'C' code => .pyc files and that IP
> does not do this. But even so, IP must compile native code into NET code
> which should run only slightly slower than python27.
>
> Regards and thanks for a good NET implementation of python.
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150824/5c1aab62/attachment.html>

From slide.o.mix at gmail.com  Tue Aug 25 17:24:09 2015
From: slide.o.mix at gmail.com (Slide)
Date: Tue, 25 Aug 2015 15:24:09 +0000
Subject: [Ironpython-users] PythonTuple.MakeTuple
In-Reply-To: <727D8E16AE957149B447FE368139F2B56CD14489@SERVER10>
References: <CAPiUgVddP-ZgtEPzKwSpeTEj=0AkC7RLw5afNN0LQ0A2Zs0KwA@mail.gmail.com>
 <727D8E16AE957149B447FE368139F2B56CD14489@SERVER10>
Message-ID: <CAPiUgVe5KYgBMmEkWraTdKs31BfSr8sOGHciGnb9pxRhkXpMoA@mail.gmail.com>

Hi Markus,

Thank you for your excellent reply to my question. I was able to just use
the constructor, for some reason I thought it wasn't working, when in
reality it was working and I was just adding the incorrect items to the
tuple. I appreciate your response!

Regards.

Slide

On Mon, Aug 24, 2015 at 1:27 AM Markus Schaber <m.schaber at codesys.com>
wrote:

> Hi,
>
> Von: Slide
>
> > Can anyone tell me why this method is internal?!
>
> My educated guess is that it uses the items array by value without copying
> it, while all public ways to construct the tuple actually copy the sequence
> you pass. Making that method public would allow users to create a tuple
> which may be modified by keeping a reference to the array. Making such an
> API public is rather risky.
>
> But you can have almost the same effect by using the public PythonTuple
> constructors directly.
>
> Only the EMPTY optimization will not work, which may or may not be what
> you want.
>
> PS: Note that IronPython standard library itself can still access said
> method, as the [InternalsVisibleTo]-Attribute on IronPython allows access
> to internal methods from the IronPython.Modules and IronPythonTest
> assemblies.
>
> PS 2: I'm not sure whether the MakeItems() method internally used works
> correctly when we pass strings which contain non-BMP characters. It seems
> to assume a character is a single 16-bit unit. We should investigate that,
> and compare it to Python 2 and 3 behavior with Unicode strings containing
> non-BMP characters. I'm not mandating for a quick change here, but
> especially when Python 3.x is targeted with IronPython, we should use the
> most sensible behavior and (possibly) document it as one of the differences
> in string handling. (Another one is indexing [] into strings which contain
> non-BMP characters.)
>
> PS 3: It might be an optimization to add a check o for being a
> ICollection, and directly allocate an array of the right size and using
> CopyTo. For large collections, this will be more efficient than the
> List<Object> constantly reallocating. On the other hand, the assumption may
> be that it's mostly used for small lists, and the additional type check /
> dynamic cast makes up for the difference. (However, we might replace bot
> the "is List" and "o as object[]" branches with the ICollection branch, as
> both implement ICollection, effectively saving one dynamic cast...)
>
> Best regards
>
> Markus Schaber
>
> CODESYS? a trademark of 3S-Smart Software Solutions GmbH
>
> Inspiring Automation Solutions
> ________________________________________
> 3S-Smart Software Solutions GmbH
> Dipl.-Inf. Markus Schaber | Product Development Core Technology
> Memminger Str. 151 | 87439 Kempten | Germany
> Tel. +49-831-54031-979 | Fax +49-831-54031-50
>
> E-Mail: m.schaber at codesys.com | Web: codesys.com | CODESYS store:
> store.codesys.com
> CODESYS forum: forum.codesys.com
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
> Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
> ________________________________________
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received
> this e-mail in error) please notify the sender immediately and destroy
> this e-mail. Any unauthorised copying, disclosure
> or distribution of the material in this e-mail is strictly forbidden.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150825/6cf500f6/attachment.html>

From kaushikbhanu at gmail.com  Fri Aug 21 00:49:51 2015
From: kaushikbhanu at gmail.com (Bhanu Kaushik)
Date: Thu, 20 Aug 2015 16:49:51 -0600
Subject: [Ironpython-users] Using Scikit learn models in C#
Message-ID: <CAMn_EOoxCzEDUpJSSZGhjQwkeNOc8iGJ81+=ePeyAc--RFDt1g@mail.gmail.com>

Hello ,

I have built a couple of models using scikitlearn (Great package !!)

I want to integrate these models for scoring data in a C# based
application.

Has anyone has success in delivering scikit learn predictions in C#/.net ?

I have looked into IronPython, but i believe, scikit learn is not supported
yet. I may be wrong !


Any help is greatly appreciated.


Thanks, Regards,
Bhanu Kaushik, PhD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150820/38e4304f/attachment.html>

From jcolman at billtrust.com  Fri Aug 21 18:30:41 2015
From: jcolman at billtrust.com (Jake Colman)
Date: Fri, 21 Aug 2015 12:30:41 -0400
Subject: [Ironpython-users] Embedded Engine and Tracebacks
Message-ID: <CAJ=yxog-UXnbc94oqwm_dY5-Rys22+CbXoSn-VYfq7D2F9TJbA@mail.gmail.com>

I'm using IronPython 2.75 embedded in a C++/C# application.  If the script
we are executing has a syntax error I want to see a traceback that contains
the line number of the error.  This only seems to work if I specify the
"Debug" engine option.  Is this to be expected?  According to my reading,
the Debug option turns off garbage collection and I wouldn't Debug turned
on for a release build.  Is there a solution for this?

Instead of this:

global name 'foobar' is not defined
IronPython.Runtime.UnboundNameException: global name 'foobar' is not defined

I always want to see this:

global name 'foobar' is not defined
IronPython.Runtime.UnboundNameException: global name 'foobar' is not
defined   at
IronPython.Runtime.Operations.PythonOps.GetVariable(CodeContext context,
String name, Boolean isGlobal, Boolean lightThrow)   at
IronPython.Runtime.Operations.PythonOps.GetGlobal(CodeContext context,
String name)   at <unnamed>$4.InitScript$129(PythonFunction $function) in
C:\vc\scripts\FOOBAR.py:line 2965

Thanks!


*Jake Colman*Director, Software Development
Office: 609.235.1010
Direct: 609.235.0792
Email: jcolman at billtrust.com
www.billtrust.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150821/2d318719/attachment.html>

From m.schaber at codesys.com  Fri Aug 28 11:44:07 2015
From: m.schaber at codesys.com (Markus Schaber)
Date: Fri, 28 Aug 2015 09:44:07 +0000
Subject: [Ironpython-users] Licenses shipped with IronPython 2.7.5
Message-ID: <727D8E16AE957149B447FE368139F2B56CD1A94D@SERVER10>

Hi,

it seems that the Licenses shipped with IronPython 2.7.5 are not actually up to date.

The License.StdLib.txt file seems to be 1:1 copied from the cPython standard library, which is not appropriate, as IronPython does not ship OpenSSL nor Berkeley DB, as far as I can see. On the other hand, source files like the Xmlrpclibpy or validate.py come with their own licenses which are not noted within said file.

That means I'll need to do a more thorough investigation as we're redistributing IronPython, and our lawyers want everything to be clean.

Does any accurate license file for the standard library shipped with IronPython 2.7.5 exist?

If not, would you be interested in a contribution of such a file?

Best regards

Markus Schaber

CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions
________________________________
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.schaber at codesys.com<mailto:m.schaber at codesys.com> | Web: codesys.com<http://www.codesys.com> | CODESYS store: store.codesys.com<http://store.codesys.com>
CODESYS forum: forum.codesys.com<http://forum.codesys.com>

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150828/0f0d5fac/attachment.html>