From hindy.ilan at gmail.com Thu Sep 1 01:28:17 2016 From: hindy.ilan at gmail.com (=?UTF-8?B?15DXmdec158g15TXmdeg15PXmQ==?=) Date: Thu, 1 Sep 2016 08:28:17 +0300 Subject: [Ironpython-users] Installing Ver 2.7.6.3 Message-ID: Hi, What is the way to install Ver 2.7.6.3 in windows? is there a setup or install program? Thanks, Ilan Hindy e-mail : Hindy.Ilan at gmail.com celular : +972-54-4292112 home : +972-9-9570521 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hindy.ilan at gmail.com Thu Sep 1 01:37:03 2016 From: hindy.ilan at gmail.com (=?UTF-8?B?15DXmdec158g15TXmdeg15PXmQ==?=) Date: Thu, 1 Sep 2016 08:37:03 +0300 Subject: [Ironpython-users] .pdb file Message-ID: Hi, Can you tell me where can I find ipy.pdb ipyw.pdb etc. Thanks, Ilan Hindy e-mail : Hindy.Ilan at gmail.com celular : +972-54-4292112 home : +972-9-9570521 -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.langbehn at euroimmun.de Thu Sep 1 02:06:34 2016 From: t.langbehn at euroimmun.de (Langbehn, Thimo) Date: Thu, 1 Sep 2016 06:06:34 +0000 Subject: [Ironpython-users] Installing Ver 2.7.6.3 Message-ID: <4687058350CFD140BB34E9EB7960548726BBD3C2@HL-EX-MBS1.de.eu.local> > What is the way to install Ver 2.7.6.3 in windows? > is there a setup or install program? Look here: https://github.com/IronLanguages/main/releases/tag/ipy-2.7.6.3 There is a download link to an MSI Package. Cheers, Thimo From t.langbehn at euroimmun.de Thu Sep 1 02:05:28 2016 From: t.langbehn at euroimmun.de (Langbehn, Thimo) Date: Thu, 1 Sep 2016 06:05:28 +0000 Subject: [Ironpython-users] .pdb file In-Reply-To: References: Message-ID: <4687058350CFD140BB34E9EB7960548726BBD3B9@HL-EX-MBS1.de.eu.local> > Can you tell me where can I find ipy.pdb ipyw.pdb etc. The pdb files are not included in the release, as far as I know. You could build IronPython yourself to create them. Cheers, Thimo From flebber.crue at gmail.com Sat Sep 10 23:50:41 2016 From: flebber.crue at gmail.com (Sayth Renshaw) Date: Sun, 11 Sep 2016 13:50:41 +1000 Subject: [Ironpython-users] Hi In-Reply-To: References: Message-ID: Afternoon Its a sunny sunday in NSW Australia where i am. Heard the podcast the other day and it peaked my interest again since it's been a while since i have looked at ironpython, boo was popular then. Anyway, exciting to see it is living again. Thanks Sayth -------------- next part -------------- An HTML attachment was scrubbed... URL: From spartitraffico at gmail.com Tue Sep 13 11:46:12 2016 From: spartitraffico at gmail.com (Borut Jarc) Date: Tue, 13 Sep 2016 17:46:12 +0200 Subject: [Ironpython-users] Embedded IronPython, Properties with Custom Attributes, __clrtype__ and PropertyGrid Message-ID: Hello, I'm Borut Jarc and I work at A.S.U.I.Ts (Azienda Sanitaria Universitaria Integrata di Trieste) as a Domain Admin. I'm writing an C# 4.0 application to help my Network Admins to manage the subnets configured on our network switches. The application has Iron Python embedded, a simple plugin system and a plugin manager. The plugins are written in IronPython. Everything works fine so now I am writing a configuration dialog for the plugins properties. I'm trying to use a PropertyGrid which I give an instance of an IronPython class. To make use of all the nice features of PropertyGrid like Description, Category and PasswordPropertyText i extended the ClrClass from clrtype module from clrtye sample, implemeting the emit_property method as follows: class MyClrClass(ClrClass): def emit_property(self, typebld, prop, name, clrtype): prpbld = typebld.DefineProperty(name, PropertyAttributes.None, clrtype, None) if prop.fget: getter = self.emitted_methods[(prop.fget.func_name, prop.fget.arg_types)] prpbld.SetGetMethod(getter) if prop.fset: setter = self.emitted_methods[(prop.fset.func_name, prop.fset.arg_types)] prpbld.SetSetMethod(setter) if hasattr(prop.fget, "CustomAttributeBuilders"): for cab in prop.fget.CustomAttributeBuilders: prpbld.SetCustomAttribute(cab) then in my IronPython script I define the class: class OSCommware7_ssh(PluginBase): __metaclass__ = clrtype.MyClrClass _clrnamespace = "PianoIndirizzamentiIP_Tool" _clrfields = {"_username":str, "_password":str, "_prompt":str} Description = clrtype.attribute(DescriptionAttribute) Category = clrtype.attribute(CategoryAttribute) @property @Category("Credentials") @Description("Username for login on Core Switch") @clrtype.accepts() @clrtype.returns(str) def username(self): return self._username @username.setter @clrtype.accepts(str) @clrtype.returns() def username(self, value): self._username = value .... (PluginBase is the c# class with acts as the plugin skeleton. Contais also some plugin helper functions (password encryption decryption)) and in my c# code I do something like: ... _engine = Python.CreateEngine(); _scope = _engine.CreateScope(); _runtime = _engine.Runtime; _root_dir = AddAssemblies(); _scope = _engine.CreateScope(); ... ScriptSource script = _engine.CreateScriptSourceFromFile(path_to_python_script); CompiledCode code = script.Compile(); script.Execute(scope); ... dynamic plugin_instance = my_engine.scope.GetVariable("OSCommware7_ssh")() propertyGrid1.SelectedObject = plugin_instance; ... If I inspect plugin_instance with (System.Reflection.PropertyInfo[])(plugin_instance.GetType().GetProperties()): - ((System.Reflection.PropertyInfo[])(plugin_instance.GetType().GetProperties()))[3] {System.String username} System.Reflection.PropertyInfo {System.Reflection.RuntimePropertyInfo} Attributes None System.Reflection.PropertyAttributes CanRead true bool CanWrite true bool - CustomAttributes Count = 2 System.Collections.Generic.IEnumerable {System.Collections.ObjectModel.ReadOnlyCollection} + [0] {[System.ComponentModel.DescriptionAttribute("Username for login on Core Switch")]} System.Reflection.CustomAttributeData + [1] {[System.ComponentModel.CategoryAttribute("Credentials")]} System.Reflection.CustomAttributeData + Raw View + DeclaringType {Name = "OSCommware7_ssh" FullName = "PianoIndirizzamentiIP_Tool.OSCommware7_ssh"} System.Type {System.RuntimeType} + GetMethod {System.String username()} System.Reflection.MethodInfo {System.Reflection.RuntimeMethodInfo} IsSpecialName false bool MemberType Property System.Reflection.MemberTypes MetadataToken 385875970 int + Module {Snippets.scripting} System.Reflection.Module {System.Reflection.Emit.InternalModuleBuilder} Name "username" string + PropertyType {Name = "String" FullName = "System.String"} System.Type {System.RuntimeType} + ReflectedType {Name = "OSCommware7_ssh" FullName = "PianoIndirizzamentiIP_Tool.OSCommware7_ssh"} System.Type {System.RuntimeType} + SetMethod {Void username(System.String)} System.Reflection.MethodInfo {System.Reflection.RuntimeMethodInfo} + Non-Public members I see all the properties and their CustomAttributes set as expected, but for some reason PropertyGrid simply ignore them. I feel like I'm missing something important but I don't know what. Can someone explain me what I'm doing wrong? Thank you and forgive my poor English... Borut Jarc -------------- next part -------------- An HTML attachment was scrubbed... URL: From pawel.jasinski at gmail.com Sat Sep 17 06:13:16 2016 From: pawel.jasinski at gmail.com (Pawel Jasinski) Date: Sat, 17 Sep 2016 12:13:16 +0200 Subject: [Ironpython-users] string/unicode Message-ID: hi, I have noticed that the long standing string/unicode subject surfaced again in chat (#1414) For long time I was convinced that jython uses the same strategy as ironpython in regards to str/unicode aliasing. There was hope to get cpython compatibility at similar level as jython (e.g. django works under jython). Thanks to Kuno (see https://github.com/IronLanguages/main/pull/1331), I was corrected. jython made a change in 2.5, so str and unicode are distinct types. I believe this change alone made a big difference with respect to their cpython compatibility. Now the question is what stops us from doing the same? We could have a distinctive type entry for str and unicode, but keep the existing implementation which uses .net string as storage for byte strings. The arguments passed to .net will be mapped exactly as they are today. The results coming back from .net would surface as unicode (which they are). Marcus expressed concerns "shipping our own string implementation would be somehow overkill, and could severely hurt performance when interfacing with .NET. I think it's not worth the effort for 2.x" Marcus, does your concern still apply if the implementation follows the "distinctive type entry" idea? The positives I can see: - able to use things out of PyPI without tweaking - no patching of stdlib - no time spend on investigating another bug report which turns out to be str/unicode alias. I would never expect it to cause stack overflow (#1414). - chance to move forward with ironclad - the str/unicode aliasing is the biggest road block when trying to fix numpy integration The negatives I am aware of: - this has a potential to break existing ironpython code which already has a lot of handcrafted tweaks for str/unicode aliasing. This would have to be taken out. - working on this, would take resources from working on 3 I am sure, that as usually I am overlooking and/or trivializing something, so please speak up. cheers, --pawel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ticotimo at gmail.com Sat Sep 17 14:49:39 2016 From: ticotimo at gmail.com (Tim Orling) Date: Sat, 17 Sep 2016 11:49:39 -0700 Subject: [Ironpython-users] string/unicode In-Reply-To: References: Message-ID: As usual, I agree with you Pawel :) That said, I don't have a lot of "handcrafted tweaks for str/unicode aliasing", so it's easy for me to dismiss that negative. To me, your proposal sounds elegant, but I am open to consensus. --Tim On Sat, Sep 17, 2016 at 3:13 AM, Pawel Jasinski wrote: > hi, > > I have noticed that the long standing string/unicode subject surfaced > again in chat (#1414) > For long time I was convinced that jython uses the same strategy as > ironpython in regards to str/unicode aliasing. There was hope to get > cpython compatibility at similar level as jython (e.g. django works under > jython). > > Thanks to Kuno (see https://github.com/IronLanguages/main/pull/1331), I > was corrected. jython made a change in 2.5, so str and unicode are distinct > types. I believe this change alone made a big difference with respect to > their cpython compatibility. > > > Now the question is what stops us from doing the same? > We could have a distinctive type entry for str and unicode, but keep the > existing implementation which uses .net string as storage for byte strings. > The arguments passed to .net will be mapped exactly as they are today. > The results coming back from .net would surface as unicode (which they > are). > > Marcus expressed concerns "shipping our own string implementation would be > somehow overkill, and could severely hurt performance when interfacing with > .NET. I think it's not worth the effort for 2.x" > Marcus, does your concern still apply if the implementation follows the > "distinctive type entry" idea? > > The positives I can see: > - able to use things out of PyPI without tweaking > - no patching of stdlib > - no time spend on investigating another bug report which turns out to be > str/unicode alias. I would never expect it to cause stack overflow (#1414). > - chance to move forward with ironclad - the str/unicode aliasing is the > biggest road block when trying to fix numpy integration > > The negatives I am aware of: > - this has a potential to break existing ironpython code which already has > a lot of handcrafted tweaks for str/unicode aliasing. This would have to be > taken out. > - working on this, would take resources from working on 3 > > I am sure, that as usually I am overlooking and/or trivializing something, > so please speak up. > > cheers, > --pawel > > > _______________________________________________ > 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 Mon Sep 19 05:58:22 2016 From: m.schaber at codesys.com (Markus Schaber) Date: Mon, 19 Sep 2016 09:58:22 +0000 Subject: [Ironpython-users] string/unicode In-Reply-To: References: Message-ID: <727D8E16AE957149B447FE368139F2B5A8B3415A@SERVER10> Hi, Pawel, I?m not that deep into the inner workings of IronPython string handling, my impression until now was that we just used the .NET Strings 1:1, using clever binding for the members. For your approach, I think we we?d need our own wrapper instance around the .NET String objects, so the string instances don?t lose their type. (But maybe we could restrict that to ?byte? strings). But I can see that your approach would circumvent the need of converting our own strings to .NET Strings, by using .NET Strings as underlying storage, eliminating most of the performance problems I feared. Additionally, you mentioned the risk of breaking existing code, so maybe there could be an option switch to the old behavior? I?m not in the position to tell others how to spend their time, but my suggestion is: If you do not have any specific incentive to fix this problem in the generic way for Python 2.7, I think the time is spent better by working on Python 3 support in IronPython (as the world should migrate to Python 3 anyways ?) 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: Ironpython-users [mailto:ironpython-users-bounces+m.schaber=codesys.com at python.org] On Behalf Of Pawel Jasinski Sent: Saturday, September 17, 2016 12:14 PM To: ironpython-users at python.org Subject: [Ironpython-users] string/unicode hi, I have noticed that the long standing string/unicode subject surfaced again in chat (#1414) For long time I was convinced that jython uses the same strategy as ironpython in regards to str/unicode aliasing. There was hope to get cpython compatibility at similar level as jython (e.g. django works under jython). Thanks to Kuno (see https://github.com/IronLanguages/main/pull/1331), I was corrected. jython made a change in 2.5, so str and unicode are distinct types. I believe this change alone made a big difference with respect to their cpython compatibility. Now the question is what stops us from doing the same? We could have a distinctive type entry for str and unicode, but keep the existing implementation which uses .net string as storage for byte strings. The arguments passed to .net will be mapped exactly as they are today. The results coming back from .net would surface as unicode (which they are). Marcus expressed concerns "shipping our own string implementation would be somehow overkill, and could severely hurt performance when interfacing with .NET. I think it's not worth the effort for 2.x" Marcus, does your concern still apply if the implementation follows the "distinctive type entry" idea? The positives I can see: - able to use things out of PyPI without tweaking - no patching of stdlib - no time spend on investigating another bug report which turns out to be str/unicode alias. I would never expect it to cause stack overflow (#1414). - chance to move forward with ironclad - the str/unicode aliasing is the biggest road block when trying to fix numpy integration The negatives I am aware of: - this has a potential to break existing ironpython code which already has a lot of handcrafted tweaks for str/unicode aliasing. This would have to be taken out. - working on this, would take resources from working on 3 I am sure, that as usually I am overlooking and/or trivializing something, so please speak up. cheers, --pawel -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuno.meyer at gmx.ch Fri Sep 23 03:13:39 2016 From: kuno.meyer at gmx.ch (Kuno Meyer) Date: Fri, 23 Sep 2016 09:13:39 +0200 Subject: [Ironpython-users] string/unicode In-Reply-To: References: Message-ID: I think it is a misinterpretation that this topic goes away with Python3. Both Python2 and Python3 provide *two* string types. Hence, having a second string type in IronPython would certainly help Python2 compatibility as well as Python3 compatibility. ? I don't agree with your statement about .NET interop. In .NET interop you need to have unicode strings in any case, and byte strings need to be converted. Hence, handling would probably have to happen like that: - The Python2 way would be to convert the byte string on-the-fly to a unicode string by decoding it with the default encoding. Strings returned from a .NET component will be unicode. Additional thoughts needs to go into handling of ref-ed string arguments. With the hidden on-the-fly conversion, you also loose referential integrity, which might lead to unexpected behaviour in some special cases. - The Python3 way would be to insist on unicode strings and throw some sort of a "wrong argument type" error. But in Python3 mode, string literals are unicode anyway, so most users won't notice the change. ? I have no clear opinion whether System.String as underlying storage implementation for byte strings is a good idea. It certainly would provide some optimization possibilities in the conversion case for ASCII content. ? In conclusion, I think that this conversion is a non-trivial amount of work that mostly helps the compatibility with the Python standard library, but has some serious issues (backwards compatibility, maybe performance) for when accessing .NET code in Python2 mode. But it is still worth considering. ? Kuno ? From ms.subitha at gmail.com Mon Sep 26 07:07:22 2016 From: ms.subitha at gmail.com (subitha sudhakaran) Date: Mon, 26 Sep 2016 16:37:22 +0530 Subject: [Ironpython-users] Run IronPythonscript in Centos Message-ID: Hi IronPython Team, I need to run the unittest created using ironpyython in Centos?. Could you please help me how to run this? Thanks Subitha -------------- next part -------------- An HTML attachment was scrubbed... URL: From slide.o.mix at gmail.com Thu Sep 29 11:43:15 2016 From: slide.o.mix at gmail.com (Slide) Date: Thu, 29 Sep 2016 15:43:15 +0000 Subject: [Ironpython-users] Communitty Meetings Message-ID: We've been having meetings every two weeks for some time now, but I think switching to a monthly (first Thursday) format may be better. If you hang out on Gitter, there is active communication happening quite often, so a bi-weekly format is a bit much at this point. Our next meeting will be Thu, Oct 6, 2016 at 6:00pm UTC. -------------- next part -------------- An HTML attachment was scrubbed... URL: