From pawel.jasinski at gmail.com Mon Aug 1 14:15:34 2016 From: pawel.jasinski at gmail.com (Pawel Jasinski) Date: Mon, 1 Aug 2016 20:15:34 +0200 Subject: [Ironpython-users] sponsors Message-ID: hi this hit the hackers news today https://news.ycombinator.com/item?id=12200777 and i remember some of us are in germany so perhaps it can be used to get someone working on ironpython full time for 6 months cheers --pawel -------------- next part -------------- An HTML attachment was scrubbed... URL: From shyam.pundkar at gmail.com Mon Aug 8 23:18:42 2016 From: shyam.pundkar at gmail.com (Shyam Pundkar) Date: Tue, 9 Aug 2016 08:48:42 +0530 Subject: [Ironpython-users] Security clearance document for iron Python In-Reply-To: References: Message-ID: Dear iron Python team, We are using iron Python 2.7.3. Do you have any document stating that iron python is tested for security flaws? We need it to obtain security clearance from our application risk team. Any document stating iron python 2.7.3 has been checked for security flaws and it's safe to use? Thanks Shyam -------------- next part -------------- An HTML attachment was scrubbed... URL: From slide.o.mix at gmail.com Mon Aug 8 23:28:45 2016 From: slide.o.mix at gmail.com (Slide) Date: Tue, 09 Aug 2016 03:28:45 +0000 Subject: [Ironpython-users] Security clearance document for iron Python In-Reply-To: References: Message-ID: There are no security tests that take place. So, there is no such document. On Mon, Aug 8, 2016, 20:28 Shyam Pundkar wrote: > Dear iron Python team, > > We are using iron Python 2.7.3. Do you have any document stating that iron > python is tested for security flaws? We need it to obtain security > clearance from our application risk team. Any document stating iron python > 2.7.3 has been checked for security flaws and it's safe to use? > > Thanks > Shyam > _______________________________________________ > 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: From beggers at spiegelburg.net Mon Aug 15 03:10:15 2016 From: beggers at spiegelburg.net (Benedikt Eggers) Date: Mon, 15 Aug 2016 07:10:15 +0000 Subject: [Ironpython-users] IronPython Community Meeting Message-ID: <8144d4532ef648ff83d5ee232a4afe34@srvex2013.spiegelburg.net> Hello, the next community meeting will be August 18, 2016 - 18:00 GMT. Agenda notes will follow. Thank you all for your activity in the last days and weeks! - Benedikt Eggers -------------- next part -------------- An HTML attachment was scrubbed... URL: From beggers at spiegelburg.net Wed Aug 17 03:20:37 2016 From: beggers at spiegelburg.net (Benedikt Eggers) Date: Wed, 17 Aug 2016 07:20:37 +0000 Subject: [Ironpython-users] Agenda Community-Meeting Message-ID: <30edf575b7e8449caf567b38b5882f37@srvex2013.spiegelburg.net> Hello, here we have an overview for the next community meeting: https://github.com/IronLanguages/main/wiki/Community-Meeting-August-18,-2016---18:00-GMT Please tell me, if someone wants to add a point to the list. Thank you all for your support in the last weeks, thinks are going really well! - Benedikt Eggers -------------- next part -------------- An HTML attachment was scrubbed... URL: From slide.o.mix at gmail.com Sun Aug 21 00:45:13 2016 From: slide.o.mix at gmail.com (Slide) Date: Sun, 21 Aug 2016 04:45:13 +0000 Subject: [Ironpython-users] IronPython 2.7.6.3 Released Message-ID: On behalf of the IronPython team, I am happy to announce the release of version 2.7.6.3 final which is the first final release version for the 2.7.6 release stream. You can find the release at: https://github.com/IronLanguages/main/releases/tag/v2.7.6.3 There were several issues which were fixed since 2.7.5, a list of which can be seen here : https://github.com/IronLanguages/main/issues?q=label%3A2.7.6+is%3Aclosed . Thanks to many different people for their hard work on this release. The community is becoming more active and working on IronPython again. We plan to have more regular releases, so please check back often. In addition, we are working on becoming part of the .NET Foundation, which will help with getting more people involved and excited about IronPython. If you find any issues, please file them on Github under IronPython/main. Packages are also available via NuGet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.langbehn at euroimmun.de Mon Aug 22 00:26:23 2016 From: t.langbehn at euroimmun.de (Langbehn, Thimo) Date: Mon, 22 Aug 2016 04:26:23 +0000 Subject: [Ironpython-users] IronPython Blog Entry for 2.7.6.3 Message-ID: <4687058350CFD140BB34E9EB7960548726BBC072@HL-EX-MBS1.de.eu.local> Can we create an entry for the Release in http://ironpython.net/blog/ ? Cheers, Thimo -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.schaber at codesys.com Mon Aug 29 06:10:04 2016 From: m.schaber at codesys.com (Markus Schaber) Date: Mon, 29 Aug 2016 10:10:04 +0000 Subject: [Ironpython-users] Binding problem with default parameters in public classes Message-ID: <727D8E16AE957149B447FE368139F2B5A8B18248@SERVER10> Hi, Our tests recently caught a strange regression in our application. One can make existing scripts fail by changing an internal class to public. The attached program reproduces the issue. The problem is that the method has optional parameters, but those are only declared at the interface. Now, when the class changes from ?internal? to ?public?, IronPython binds directly to the public methods without considering the interfaces any more, and thus does not recognize the optional parameters. Now, the question is whether this could be considered a bug in IronPython, or whether it should be considered a bug to implement an interface method without replicating the default parameter values? 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Program.cs URL: From slide.o.mix at gmail.com Mon Aug 29 10:23:10 2016 From: slide.o.mix at gmail.com (Slide) Date: Mon, 29 Aug 2016 14:23:10 +0000 Subject: [Ironpython-users] Binding problem with default parameters in public classes In-Reply-To: <727D8E16AE957149B447FE368139F2B5A8B18248@SERVER10> References: <727D8E16AE957149B447FE368139F2B5A8B18248@SERVER10> Message-ID: What happens if it's an abstract base class instead of an interface? On Mon, Aug 29, 2016, 03:25 Markus Schaber wrote: > Hi, > > > > Our tests recently caught a strange regression in our application. One can > make existing scripts fail by changing an internal class to public. > > > > The attached program reproduces the issue. The problem is that the method > has optional parameters, but those are only declared at the interface. > > > > Now, when the class changes from ?internal? to ?public?, IronPython binds > directly to the public methods without considering the interfaces any more, > and thus does not recognize the optional parameters. > > > > Now, the question is whether this could be considered a bug in IronPython, > or whether it should be considered a bug to implement an interface method > without replicating the default parameter values? > > > > 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.* > _______________________________________________ > 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: From mckennammj at gmail.com Mon Aug 29 15:03:51 2016 From: mckennammj at gmail.com (Michael Mckenna-Mattiaccio) Date: Mon, 29 Aug 2016 15:03:51 -0400 Subject: [Ironpython-users] IronPython and .Net Core and .Net Standard Library? Message-ID: Hello all, I am doing research for a new project at work that will be using Microsoft's .Net Core and .Net Standard Library for the web app and Xamarin for mobile apps. I'm curious how integrated IronPython is to .Net and the features for use with .Net Core either as an alternative or complement to C# and .Net Standard Library. Does anyone have experience in this area? Also interested in IronPython and MVC. Thanks! Best regards, Michael McKenna-Mattiaccio Baruch Zicklin MBA in Entrepreneurship & Operations Management cand. Social Entrepreneur *MiloSets Inc.* Founder, CEO (The best way to contact me is via mckennammj at gmail.com ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From slide.o.mix at gmail.com Mon Aug 29 15:19:17 2016 From: slide.o.mix at gmail.com (Slide) Date: Mon, 29 Aug 2016 19:19:17 +0000 Subject: [Ironpython-users] IronPython and .Net Core and .Net Standard Library? In-Reply-To: References: Message-ID: We are currently working on support for .NET Core. We don't have a working solution yet. On Mon, Aug 29, 2016, 12:18 Michael Mckenna-Mattiaccio wrote: > Hello all, > > I am doing research for a new project at work that will be using > Microsoft's .Net Core and .Net Standard Library for the web app and Xamarin > for mobile apps. I'm curious how integrated IronPython is to .Net and the > features for use with .Net Core either as an alternative or complement to > C# and .Net Standard Library. Does anyone have experience in this area? > Also interested in IronPython and MVC. Thanks! > > Best regards, > > Michael McKenna-Mattiaccio > Baruch Zicklin MBA in Entrepreneurship & Operations Management cand. > Social Entrepreneur > *MiloSets Inc.* > Founder, CEO > > (The best way to contact me is via mckennammj at gmail.com ) > _______________________________________________ > 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: From m.schaber at codesys.com Tue Aug 30 02:53:53 2016 From: m.schaber at codesys.com (Markus Schaber) Date: Tue, 30 Aug 2016 06:53:53 +0000 Subject: [Ironpython-users] Binding problem with default parameters in public classes In-Reply-To: References: <727D8E16AE957149B447FE368139F2B5A8B18248@SERVER10> Message-ID: <727D8E16AE957149B447FE368139F2B5A8B18456@SERVER10> Hi, Slide, Using a public abstract base class produces the same result: If the derived class is internal, the call works fine, if the derived class is public, the call does not work. 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: Slide [mailto:slide.o.mix at gmail.com] Sent: Monday, August 29, 2016 4:24 PM To: Markus Schaber; Discussion of IronPython Subject: Re: [Ironpython-users] Binding problem with default parameters in public classes What happens if it's an abstract base class instead of an interface? On Mon, Aug 29, 2016, 03:25 Markus Schaber > wrote: Hi, Our tests recently caught a strange regression in our application. One can make existing scripts fail by changing an internal class to public. The attached program reproduces the issue. The problem is that the method has optional parameters, but those are only declared at the interface. Now, when the class changes from ?internal? to ?public?, IronPython binds directly to the public methods without considering the interfaces any more, and thus does not recognize the optional parameters. Now, the question is whether this could be considered a bug in IronPython, or whether it should be considered a bug to implement an interface method without replicating the default parameter values? 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. _______________________________________________ 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: From slide.o.mix at gmail.com Tue Aug 30 06:08:31 2016 From: slide.o.mix at gmail.com (Slide) Date: Tue, 30 Aug 2016 10:08:31 +0000 Subject: [Ironpython-users] Binding problem with default parameters in public classes In-Reply-To: <727D8E16AE957149B447FE368139F2B5A8B18456@SERVER10> References: <727D8E16AE957149B447FE368139F2B5A8B18248@SERVER10> <727D8E16AE957149B447FE368139F2B5A8B18456@SERVER10> Message-ID: I can see this both ways (bug and not a bug), so let's err on the side of bug and see if we can make the behaviour match C#. On Mon, Aug 29, 2016, 23:53 Markus Schaber wrote: > Hi, Slide, > > > > Using a public abstract base class produces the same result: If the > derived class is internal, the call works fine, if the derived class is > public, the call does not work. > > > > 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:* Slide [mailto:slide.o.mix at gmail.com] > *Sent:* Monday, August 29, 2016 4:24 PM > *To:* Markus Schaber; Discussion of IronPython > *Subject:* Re: [Ironpython-users] Binding problem with default parameters > in public classes > > > > What happens if it's an abstract base class instead of an interface? > > > > On Mon, Aug 29, 2016, 03:25 Markus Schaber wrote: > > Hi, > > > > Our tests recently caught a strange regression in our application. One can > make existing scripts fail by changing an internal class to public. > > > > The attached program reproduces the issue. The problem is that the method > has optional parameters, but those are only declared at the interface. > > > > Now, when the class changes from ?internal? to ?public?, IronPython binds > directly to the public methods without considering the interfaces any more, > and thus does not recognize the optional parameters. > > > > Now, the question is whether this could be considered a bug in IronPython, > or whether it should be considered a bug to implement an interface method > without replicating the default parameter values? > > > > 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.* > > _______________________________________________ > 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: From m.schaber at codesys.com Tue Aug 30 06:42:55 2016 From: m.schaber at codesys.com (Markus Schaber) Date: Tue, 30 Aug 2016 10:42:55 +0000 Subject: [Ironpython-users] Binding problem with default parameters in public classes In-Reply-To: References: <727D8E16AE957149B447FE368139F2B5A8B18248@SERVER10> <727D8E16AE957149B447FE368139F2B5A8B18456@SERVER10> Message-ID: <727D8E16AE957149B447FE368139F2B5A8B18646@SERVER10> Hi, all, I just tested it with C#, with different results: Using the dynamic keyword, it seems that C# using ?dynamic? does not honor the optional parameter in any ?inherited? case, it only works when the method implementation also provides the default parameter. ? This closely matches the behavior of the ?normal? C# compiler, which delivers compiler errors in those cases ? it works when I either have the interface or ABC as type, or the method implementation also has the default parameter declared. It also chooses the default value depending on the variable type. Thus, it seems that C# is even more restrictive than IronPython right now, at least when the ?dynamic? keyword is used. Just as a side note, we successfully worked around the problem in our use case, so there is no urgent fix necessary, it was more some kind of curiosity of which semantics are considered ?correct?. As changing anything might be a breaking change, I suggest we apply it only in 3.x (in case we fix anything). The output of the extended, attached example is: InternalImpl: Internal: Param: 1 Text: mit text Internal: Param: 2 Text: Internal: Param: 11 Text: See Sharp! Keine ?berladung f?r die DoSomething-Methode nimmt 1-Argumente an. Internal: Param: 21 Text: PublicImpl: Public: Param: 1 Text: mit text DoSomething() takes exactly 2 arguments (1 given) Public: Param: 11 Text: See Sharp! Keine ?berladung f?r die DoSomething-Methode nimmt 1-Argumente an. Public: Param: 21 Text: PublicImplWithDefault: PublicDefault: Param: 1 Text: mit text PublicDefault: Param: 2 Text: PublicDefault: Param: 11 Text: See Sharp! PublicDefault: Param: 12 Text: PublicDefault: Param: 21 Text: PublicDefault: Param: 24 Text: PublicDefault: Param: 28 Text: PublicAbcInternalImpl: InternalABC: Param: 1 Text: mit text InternalABC: Param: 2 Text: InternalABC: Param: 11 Text: See Sharp! Keine ?berladung f?r die DoSomething-Methode nimmt 1-Argumente an. InternalABC: Param: 25 Text: PublicAbcPublicImpl: PublicABC: Param: 1 Text: mit text DoSomething() takes exactly 2 arguments (1 given) PublicABC: Param: 11 Text: See Sharp! Keine ?berladung f?r die DoSomething-Methode nimmt 1-Argumente an. PublicABC: Param: 25 Text: PublicAbcPublicImplWithDefault: PublicABC: Param: 1 Text: mit text PublicABC: Param: 2 Text: PublicABC: Param: 11 Text: See Sharp! PublicABC: Param: 12 Text: PublicABC: Param: 25 Text: 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: Slide [mailto:slide.o.mix at gmail.com] Sent: Tuesday, August 30, 2016 12:09 PM To: Markus Schaber; Discussion of IronPython Subject: Re: [Ironpython-users] Binding problem with default parameters in public classes I can see this both ways (bug and not a bug), so let's err on the side of bug and see if we can make the behaviour match C#. On Mon, Aug 29, 2016, 23:53 Markus Schaber > wrote: Hi, Slide, Using a public abstract base class produces the same result: If the derived class is internal, the call works fine, if the derived class is public, the call does not work. 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: Slide [mailto:slide.o.mix at gmail.com] Sent: Monday, August 29, 2016 4:24 PM To: Markus Schaber; Discussion of IronPython Subject: Re: [Ironpython-users] Binding problem with default parameters in public classes What happens if it's an abstract base class instead of an interface? On Mon, Aug 29, 2016, 03:25 Markus Schaber > wrote: Hi, Our tests recently caught a strange regression in our application. One can make existing scripts fail by changing an internal class to public. The attached program reproduces the issue. The problem is that the method has optional parameters, but those are only declared at the interface. Now, when the class changes from ?internal? to ?public?, IronPython binds directly to the public methods without considering the interfaces any more, and thus does not recognize the optional parameters. Now, the question is whether this could be considered a bug in IronPython, or whether it should be considered a bug to implement an interface method without replicating the default parameter values? 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. _______________________________________________ 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: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Program.cs URL: