Re: [IronPython] IronPython 2.7.1 3.x Development
Hi, Thomas, I did know about the assembly version being part of the name, but I did not know yet about the extern aliases. I'm learning something new every day... Thanks a lot! Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 -Ursprüngliche Nachricht- Von: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] Im Auftrag von Tomas Matousek Gesendet: Mittwoch, 16. März 2011 17:41 An: Discussion of IronPython Betreff: Re: [IronPython] IronPython 2.7.1 3.x Development Yes, you can do it and w/o any glue - the version of the assembly is a part of the name, so the assemblies are in fact not named identically. Only the files are and they can be either in GAC or in a different subdirectory of your app. Your App.config can specify subdirectories used to look for assemblies [1]. To choose the namespace/class from one assembly or the other use extern aliases [2] in your code. Tomas [1] http://msdn.microsoft.com/en-us/library/823z9h8w(VS.80).aspx [2] http://www.davidarno.org/c-howtos/aliases-overcoming-name-conflicts- part-2-extern-alias/ -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Markus Schaber Sent: Wednesday, March 16, 2011 12:24 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.7.1 3.x Development Hi, Von Tomas Matousek As I wrote, we host IronPython inside our application, so shebang and file name suffixes are irrelevant - but we could use the shebang as a marker for python 3 (given that we can host both versions side-by-side) and parse the source manually to find out which version to use - at least for a specific grace period. I think we can support this - it would be no different than using IronPython and IronRuby side by side, if we do it right. We'd probably have to rename IronPython.dll to IronPython3.dll as well, but that's not a big deal. The assemblies are strongly named so I don't think that the name change would be necessary. Maybe we will need some tricks to solve the reference problems - I don't know whether you can reference two identically named assemblies containing identically named classes from the same C# dll, even if they are signed differently. But I think some kind of glue layer dlls could easily solve that. Thanks, Markus ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.7.1 3.x Development
Hi, Von Tomas Matousek As I wrote, we host IronPython inside our application, so shebang and file name suffixes are irrelevant - but we could use the shebang as a marker for python 3 (given that we can host both versions side-by-side) and parse the source manually to find out which version to use - at least for a specific grace period. I think we can support this - it would be no different than using IronPython and IronRuby side by side, if we do it right. We'd probably have to rename IronPython.dll to IronPython3.dll as well, but that's not a big deal. The assemblies are strongly named so I don't think that the name change would be necessary. Maybe we will need some tricks to solve the reference problems - I don't know whether you can reference two identically named assemblies containing identically named classes from the same C# dll, even if they are signed differently. But I think some kind of glue layer dlls could easily solve that. Thanks, Markus ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.7.1 3.x Development
Yes, you can do it and w/o any glue - the version of the assembly is a part of the name, so the assemblies are in fact not named identically. Only the files are and they can be either in GAC or in a different subdirectory of your app. Your App.config can specify subdirectories used to look for assemblies [1]. To choose the namespace/class from one assembly or the other use extern aliases [2] in your code. Tomas [1] http://msdn.microsoft.com/en-us/library/823z9h8w(VS.80).aspx [2] http://www.davidarno.org/c-howtos/aliases-overcoming-name-conflicts-part-2-extern-alias/ -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Markus Schaber Sent: Wednesday, March 16, 2011 12:24 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.7.1 3.x Development Hi, Von Tomas Matousek As I wrote, we host IronPython inside our application, so shebang and file name suffixes are irrelevant - but we could use the shebang as a marker for python 3 (given that we can host both versions side-by-side) and parse the source manually to find out which version to use - at least for a specific grace period. I think we can support this - it would be no different than using IronPython and IronRuby side by side, if we do it right. We'd probably have to rename IronPython.dll to IronPython3.dll as well, but that's not a big deal. The assemblies are strongly named so I don't think that the name change would be necessary. Maybe we will need some tricks to solve the reference problems - I don't know whether you can reference two identically named assemblies containing identically named classes from the same C# dll, even if they are signed differently. But I think some kind of glue layer dlls could easily solve that. Thanks, Markus ___ 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] IronPython 2.7.1 3.x Development
Hi, Jeff, Von: Jeff Hardy With the 2.7 out the door, it's time to start thinking about 3.x. I've created a ipy-2.7-maint branch for continued 2.7 work (and it needs some), and any 3.x work will go on master. Any 2.7 fixes that also go into 3.x (and really, most of them should) go into the 2.7 branch *first*, and then be cherry-picked into master (yes, I'll write some docs on that). This is to (hopefully) prevent any 3.x features from being inadvertently backported to 2.7. Your plans sound good for us. But we're just releasing a product hosting IronPython 2.6.2, as we're still bound to .NET 2.0 for some months, but our plans to upgrade to .NET 4.0 are on the way. So we are interested in smooth migration paths for our customers. Will it be possible to integrate / host both python 2.x (2.7.x) and 3.x in the same application? And is there some mechanism to auto-recognize whether a Script is python 2.x or 3.x syntax? Maybe some from __future__ import Python3 or something? If there's work needed in that area, maybe I can convince my seniors that we contribute. (I used to work a lot with Python and contribute to free projects in some of my former working places...) Best regards Markus Schaber -- We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.7.1 3.x Development
#!/usr/bin/ipy3 A shebang on the first line is the usual way of specifying which scripting engine to use on a posix system. If introspection were to be used to select between python versions, that would be the most obvious way to do it. Windows (tm) prefers to use filename extensions, which is why .pyw is used to specify a GUI program. The command shell does not open the file to see what's inside AFAIK. It was suggested in the past that .ipy might be used to specify IronPython programs. If that idea were carried to its logical end, one would use .ipy3w to specify an IronPython 3.x GUI script. That is a bit frightening. What about the idea of a semi-standard python dispatch program which lives on the search path, introspects the script, and calls the appropriate engine? Perhaps it could even manage to capture tracebacks sent to stderr when a script dies? -- Vernon Cole (sent from my 'droid phone) On Mar 15, 2011 3:20 AM, Markus Schaber m.scha...@3s-software.com wrote: Hi, Jeff, Von: Jeff Hardy With the 2.7 out the door, it's time to start thinking about 3.x. I've created a ipy-2.7-maint ... Your plans sound good for us. But we're just releasing a product hosting IronPython 2.6.2, as we're still bound to .NET 2.0 for some months, but our plans to upgrade to .NET 4.0 are on the way. So we are interested in smooth migration paths for our customers. Will it be possible to integrate / host both python 2.x (2.7.x) and 3.x in the same application? And is there some mechanism to auto-recognize whether a Script is python 2.x or 3.x syntax? Maybe some from __future__ import Python3 or something? If there's work needed in that area, maybe I can convince my seniors that we contribute. (I used to work a lot with Python and contribute to free projects in some of my former working places...) Best regards Markus Schaber -- We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 ___ Users mailing list Users@lists.ironpython.com http:/... ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.7.1 3.x Development
On 15/03/2011 07:18, Vernon Cole wrote: #!/usr/bin/ipy3 A shebang on the first line is the usual way of specifying which scripting engine to use on a posix system. If introspection were to be used to select between python versions, that would be the most obvious way to do it. Windows (tm) prefers to use filename extensions, which is why .pyw is used to specify a GUI program. The command shell does not open the file to see what's inside AFAIK. It was suggested in the past that .ipy might be used to specify IronPython programs. If that idea were carried to its logical end, one would use .ipy3w to specify an IronPython 3.x GUI script. That is a bit frightening. What about the idea of a semi-standard python dispatch program which lives on the search path, introspects the script, and calls the appropriate engine? Perhaps it could even manage to capture tracebacks sent to stderr when a script dies? There has been a long discussion recently on Python-dev [1] suggesting the creation of exactly such a launcher program for Python on Windows. Mark Hammond (copied) said he would implement it. Including IronPython support is a fine idea. All the best, Michael [1] http://mail.python.org/pipermail/python-dev/2011-March/108872.html -- Vernon Cole (sent from my 'droid phone) On Mar 15, 2011 3:20 AM, Markus Schaber m.scha...@3s-software.com mailto:m.scha...@3s-software.com wrote: Hi, Jeff, Von: Jeff Hardy With the 2.7 out the door, it's time to start thinking about 3.x. I've created a ipy-2.7-maint ... Your plans sound good for us. But we're just releasing a product hosting IronPython 2.6.2, as we're still bound to .NET 2.0 for some months, but our plans to upgrade to .NET 4.0 are on the way. So we are interested in smooth migration paths for our customers. Will it be possible to integrate / host both python 2.x (2.7.x) and 3.x in the same application? And is there some mechanism to auto-recognize whether a Script is python 2.x or 3.x syntax? Maybe some from __future__ import Python3 or something? If there's work needed in that area, maybe I can convince my seniors that we contribute. (I used to work a lot with Python and contribute to free projects in some of my former working places...) Best regards Markus Schaber -- We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 tel:%2B49-831-54031-0 | Fax +49-831-54031-50 tel:%2B49-831-54031-50 Email: m.scha...@3s-software.com mailto:m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 ___ Users mailing list Users@lists.ironpython.com mailto:Users@lists.ironpython.com http:/... ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.7.1 3.x Development
Hi, Vernon, Von: Vernon Cole #!/usr/bin/ipy3 A shebang on the first line is the usual way of specifying which scripting engine to use on a posix system. As I wrote, we host IronPython inside our application, so shebang and file name suffixes are irrelevant - but we could use the shebang as a marker for python 3 (given that we can host both versions side-by-side) and parse the source manually to find out which version to use - at least for a specific grace period. Best regards Markus Schaber ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.7.1 3.x Development
On Tue, Mar 15, 2011 at 9:55 AM, Markus Schaber m.scha...@3s-software.com wrote: As I wrote, we host IronPython inside our application, so shebang and file name suffixes are irrelevant - but we could use the shebang as a marker for python 3 (given that we can host both versions side-by-side) and parse the source manually to find out which version to use - at least for a specific grace period. I think we can support this - it would be no different than using IronPython and IronRuby side by side, if we do it right. We'd probably have to rename IronPython.dll to IronPython3.dll as well, but that's not a big deal. How you decide which to use would be up to you, though. Would this be useful for anyone else as well? - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.7.1 3.x Development
The assemblies are strongly named so I don't think that the name change would be necessary. Tomas -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jeff Hardy Sent: Tuesday, March 15, 2011 11:08 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.7.1 3.x Development On Tue, Mar 15, 2011 at 9:55 AM, Markus Schaber m.scha...@3s-software.com wrote: As I wrote, we host IronPython inside our application, so shebang and file name suffixes are irrelevant - but we could use the shebang as a marker for python 3 (given that we can host both versions side-by-side) and parse the source manually to find out which version to use - at least for a specific grace period. I think we can support this - it would be no different than using IronPython and IronRuby side by side, if we do it right. We'd probably have to rename IronPython.dll to IronPython3.dll as well, but that's not a big deal. How you decide which to use would be up to you, though. Would this be useful for anyone else as well? - Jeff ___ 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] IronPython 2.7.1 3.x Development
Michael; IIRC you are at pycon. (I am at the wrong end of America and Mark is at the wrong end of Earth. I couldn't make it.) Can you create/find a bof session to hash out a standard shebang? It should be something good enough that 2to3 could have a fixer for it. -- [ reminder for the day: Now is better than never.] Mark: Were you thinking part of the pywin32 distribution, or CPython itself? Either way we should have a compatible/identical tool installed with IronPython. The thing should be Frankensteinian enough that I can have it cling to my favorite distribution even when I install several others beside it. (Perhaps an environment variable or .python file?) -- Both/Group: What about Jython? I have been using Jython 2.5 lately (not my fault -- a college class is making me learn Java after avoiding it for 20+ years -- but I installed the Jython support in NetBeans, too) and discover that they are having similar problems with how to crank up a Jython script from the command line. The java -jar ... string is nasty. This starter program could be a triple solution. Too much? -- Vernon P.S. -- and when I double-click on a file named setup.py automatically add install to the generated command line. Tue, Mar 15, 2011 at 8:28 AM, Michael Foord fuzzy...@voidspace.org.ukwrote: On 15/03/2011 07:18, Vernon Cole wrote: #!/usr/bin/ipy3 A shebang on the first line is the usual way of specifying which scripting engine to use on a posix system. If introspection were to be used to select between python versions, that would be the most obvious way to do it. Windows (tm) prefers to use filename extensions, which is why .pyw is used to specify a GUI program. The command shell does not open the file to see what's inside AFAIK. It was suggested in the past that .ipy might be used to specify IronPython programs. If that idea were carried to its logical end, one would use .ipy3w to specify an IronPython 3.x GUI script. That is a bit frightening. What about the idea of a semi-standard python dispatch program which lives on the search path, introspects the script, and calls the appropriate engine? Perhaps it could even manage to capture tracebacks sent to stderr when a script dies? There has been a long discussion recently on Python-dev [1] suggesting the creation of exactly such a launcher program for Python on Windows. Mark Hammond (copied) said he would implement it. Including IronPython support is a fine idea. All the best, Michael ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] IronPython 2.7.1 3.x Development
With the 2.7 out the door, it's time to start thinking about 3.x. I've created a ipy-2.7-maint branch for continued 2.7 work (and it needs some), and any 3.x work will go on master. Any 2.7 fixes that also go into 3.x (and really, most of them should) go into the 2.7 branch *first*, and then be cherry-picked into master (yes, I'll write some docs on that). This is to (hopefully) prevent any 3.x features from being inadvertently backported to 2.7. I'll pull in the 3.2 standard lib and tests very soon, and then work on the parser/compiler changes and such can start. I'm not expecting to have a reasonable 3.x release until fall at the earliest, although I would like to get nightly builds set up so people can still try it easily in the meantime. For now, the 3.x series will have the 3.0 version number; whether it becomes 3.2 or 3.3 remains to be seen. There's still a lot of stuff that should go into 2.7.1 - bug fixes, new modules, etc. Ideally I'd like to see that released in 6-8 weeks, which puts it around the beginning of May, and then on basically the same cycle as long as there's fixes to go in. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython 2.7.1 3.x Development
Sounds like a good plan, Jeff. I got a quick hint the other day that IronPython 3.2 might not be as hard as we think... I was running a test of adodbapi -- IPy 2.7 RC2 ran it fine, but CPython 2.7 had errors. I was starting to debug the CPython when I discovered that I was running the Python _3_ version of the test suite! The error was in the Unicode vs String logic. IronPython already does the right (P3k) thing. -- Vernon On Mon, Mar 14, 2011 at 12:24 AM, Jeff Hardy jdha...@gmail.com wrote: With the 2.7 out the door, it's time to start thinking about 3.x. I've created a ipy-2.7-maint branch for continued 2.7 work (and it needs some), and any 3.x work will go on master. Any 2.7 fixes that also go into 3.x (and really, most of them should) go into the 2.7 branch *first*, and then be cherry-picked into master (yes, I'll write some docs on that). This is to (hopefully) prevent any 3.x features from being inadvertently backported to 2.7. I'll pull in the 3.2 standard lib and tests very soon, and then work on the parser/compiler changes and such can start. I'm not expecting to have a reasonable 3.x release until fall at the earliest, although I would like to get nightly builds set up so people can still try it easily in the meantime. For now, the 3.x series will have the 3.0 version number; whether it becomes 3.2 or 3.3 remains to be seen. There's still a lot of stuff that should go into 2.7.1 - bug fixes, new modules, etc. Ideally I'd like to see that released in 6-8 weeks, which puts it around the beginning of May, and then on basically the same cycle as long as there's fixes to go in. - Jeff ___ 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] IronPython 2.7.1 3.x Development
On Mon, Mar 14, 2011 at 7:50 AM, Vernon Cole vernondc...@gmail.com wrote: I was running a test of adodbapi -- IPy 2.7 RC2 ran it fine, but CPython 2.7 had errors. I was starting to debug the CPython when I discovered that I was running the Python _3_ version of the test suite! The error was in the Unicode vs String logic. IronPython already does the right (P3k) thing. Yep - the unicode support is the single biggest change in Py3k, and we already support it. Pulling the new stdlib tests in is easy as well. There are some parser changes (function annotations) but even those should be minor. I'm really optimistic. - Jeff ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
