[issue19453] pydoc.py doesn't detect IronPython, help(foo) can hang

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19453] pydoc.py doesn't detect IronPython, help(foo) can hang

Change by Serhiy Storchaka : -- type: crash -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

Re: ironpython not support py3.6

From: "Peter J. Holzer" From: "Peter J. Holzer" --prnws536gtytpj5v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2018-06-22 17:20:29 -0700, denis.akhiya...@gmail.com wrote: > Either wait for

Re: ironpython not support py3.6

To: Steven D'Aprano From: "wxjmfauth" To: Steven D'Aprano From: wxjmfa...@gmail.com Le vendredi 22 juin 2018 11:07:15 UTC+2, Steven D'Aprano a ─CcritΓ : > > C# <--> IronPython 2.7 <--> CPython 3.6 > C# <--> IronPython 2.7. It will not work. Coding of c

RE: ironpython not support py3.6

To: Schachner, Joseph From: "denis akhiyarov" To: Schachner, Joseph From: denis.akhiya...@gmail.com Either wait for IronPython 3.6, use COM interop, pythonnet, subprocess, or things like gRPC. Based on PyPy experience, it is probably 1-2 years of sponsored development to get

Re: ironpython not support py3.6

From: "Peter J. Holzer" --prnws536gtytpj5v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2018-06-22 17:20:29 -0700, denis.akhiya...@gmail.com wrote: > Either wait for IronPython 3.6, use COM inter

Re: ironpython not support py3.6

To: Steven D'Aprano From: wxjmfa...@gmail.com Le vendredi 22 juin 2018 11:07:15 UTC+2, Steven D'Aprano a ─CcritΓ : > > C# <--> IronPython 2.7 <--> CPython 3.6 > C# <--> IronPython 2.7. It will not work. Coding of characters ! Try with IronPython 2.7.8. PS Yes,

RE: ironpython not support py3.6

To: Schachner, Joseph From: denis.akhiya...@gmail.com Either wait for IronPython 3.6, use COM interop, pythonnet, subprocess, or things like gRPC. Based on PyPy experience, it is probably 1-2 years of sponsored development to get a working IronPython 3.6. --- BBBS/Li6 v4.10 Toy-3 * Origin

Re: ironpython not support py3.6

On 2018-06-22 17:20:29 -0700, denis.akhiya...@gmail.com wrote: > Either wait for IronPython 3.6, use COM interop, pythonnet, > subprocess, or things like gRPC. Based on PyPy experience, it is > probably 1-2 years of sponsored development to get a working > IronPython 3.6. What is

RE: ironpython not support py3.6

Either wait for IronPython 3.6, use COM interop, pythonnet, subprocess, or things like gRPC. Based on PyPy experience, it is probably 1-2 years of sponsored development to get a working IronPython 3.6. -- https://mail.python.org/mailman/listinfo/python-list

RE: ironpython not support py3.6

Wait. -Original Message- From: fantasywan...@gmail.com Sent: Friday, June 22, 2018 2:45 AM To: python-list@python.org Subject: ironpython not support py3.6 We have a project implemented with c# and python, iron python is a good choice for us to integrate these two tech together

Re: ironpython not support py3.6

d you pay the IronPython developers to build support for 3.6? Probably not... Do you need fully managed .Net code from Python? If not "Python for .Net" may suit: https://pythonnet.github.io/ Either stick to the latest version of IronPython (2.7), or the latest of CPython (3.6). Or ma

ironpython not support py3.6

We have a project implemented with c# and python, iron python is a good choice for us to integrate these two tech together but iron python not support python 3.6 yet, any suggest for this? -- https://mail.python.org/mailman/listinfo/python-list

[issue17994] Change necessary in platform.py to support IronPython

Change by Cheryl Sabella <chek...@gmail.com>: -- resolution: -> duplicate stage: test needed -> resolved status: open -> closed superseder: -> platform._sys_version does not parse correctly IronPython 2.x version ___ P

PyDev 5.8.0: Code Coverage fixes, IronPython debugging

the debugger could end up removing quotes on args. *#PyDev-797* - The debugger now works with IronPython again -- although note that *IronPython* *2.7.6* and *2.7.7* have a critical bug which prevents IronPython from working in PyDev: https://github.com/IronLanguages/main/issues

PyDev 5.8.0: Code Coverage fixes, IronPython debugging

the debugger could end up removing quotes on args. *#PyDev-797* - The debugger now works with IronPython again -- although note that *IronPython* *2.7.6* and *2.7.7* have a critical bug which prevents IronPython from working in PyDev: https://github.com/IronLanguages/main/issues

[issue17994] Change necessary in platform.py to support IronPython

Mark Lawrence added the comment: Cpython was changed via #8964 to handle this situation. -- nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17994

IronPython 2.7.5 Released

On behalf of the IronPython team, I'm very happy to announce the release of IronPython 2.7.5[1]. Like all IronPython 2.7-series releases, .NET 4 is required to install it. Installing this release will replace any existing IronPython 2.7-series installation. Assemblies for embedding are provided

IronPython 2.7.5 Released

On behalf of the IronPython team, I'm very happy to announce the release of IronPython 2.7.5[1]. Like all IronPython 2.7-series releases, .NET 4 is required to install it. Installing this release will replace any existing IronPython 2.7-series installation. Assemblies for embedding are provided

[issue19453] pydoc.py doesn't detect IronPython, help(foo) can hang

Mark Lawrence added the comment: There's a two line patch inline in msg201750. If it's acceptable I'll do a formal patch myself unless someone else wants to pick this up. -- nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware ___ Python tracker

Will IronPython / WPF work on Mac OS X?

Hello, I am thinking of using IronPython to build an Python application. Using WPF in Visual Studio to draw the GUI and create the XAML. Can I then run this Python application on a Mac OS X (10.8)? Thanks. -- https://mail.python.org/mailman/listinfo/python-list

Re: Will IronPython / WPF work on Mac OS X?

On Aug 4, 2014 6:23 AM, danwgr...@gmail.com wrote: Hello, I am thinking of using IronPython to build an Python application. Using WPF in Visual Studio to draw the GUI and create the XAML. Can I then run this Python application on a Mac OS X (10.8)? Thanks. -- Nope. IronPython on Mac runs

Re: Will IronPython / WPF work on Mac OS X?

On 8/4/14, 8:17 AM, danwgr...@gmail.com wrote: Hello, I am thinking of using IronPython to build an Python application. Using WPF in Visual Studio to draw the GUI and create the XAML. Can I then run this Python application on a Mac OS X (10.8)? Thanks. IronPython is a Windows-only product

[issue17994] Change necessary in platform.py to support IronPython

Ian Cordasco added the comment: I missed the fact that the user gave me the information from sys.version: https://stackoverflow.com/questions/16545027/ironpython-error-in-url-request?noredirect=1#comment23847257_16545027 I'll throw together a failing test with this and run it against 2.7

IronPython + Selenium2Library + Visual Studio + Robot Framwork

Hi All, I already familiar with the python, selenium2library and robot framwork. But i don't know how to connect those things with the ironpython in visual studio. How to integrate pyhton with selenium2library in visual studio by using ironpython, is there a special dll to make import

[issue19453] pydoc.py doesn't detect IronPython, help(foo) can hang

Changes by Jeff Hardy jdha...@gmail.com: -- nosy: +jeff.hardy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19453 ___ ___ Python-bugs-list mailing

[issue19453] pydoc.py doesn't detect IronPython, help(foo) can hang

New submission from David Evans: The pager functions used by help() in StdLib's pydoc.py don't detect IronPython correctly and the result is a lack of functionality or in some cases a hang. This is similar to issue 8110 in that the code attempts to detect windows with a check for win32 from

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Marc-Andre Lemburg added the comment: On 21.10.2013 02:07, Ezio Melotti wrote: Ezio Melotti added the comment: Fixed, thanks for the patch! Thanks, Ezio, for the check-in. -- ___ Python tracker rep...@bugs.python.org

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Roundup Robot added the comment: New changeset 04a163f93ad4 by Ezio Melotti in branch '2.7': #8964: fix platform._sys_version to handle IronPython 2.6+. http://hg.python.org/cpython/rev/04a163f93ad4 New changeset 10a261824b62 by Ezio Melotti in branch '3.3': #8964: fix platform._sys_version

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Ezio Melotti added the comment: Fixed, thanks for the patch! -- assignee: - ezio.melotti resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8964

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Marc-Andre Lemburg added the comment: On 19.10.2013 07:06, Martin Matusiak wrote: Martin Matusiak added the comment: It seems the versions of IronPython 1.0 mentioned in test cases do actually support the in keyword, so the first version of the patch is probably sufficient. Example

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Martin Matusiak added the comment: Attaching a v3 which uses in and startswith. Just for good measure I ran this module on IronPython 1.0 and it fails on import: - bytes literal: b'(__libc_init)' - if as infix operator: line 177 - unexpected token open: use of with context manager on line

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Marc-Andre Lemburg added the comment: On 19.10.2013 12:11, Martin Matusiak wrote: Attaching a v3 which uses in and startswith. Just for good measure I ran this module on IronPython 1.0 and it fails on import: - bytes literal: b'(__libc_init)' - if as infix operator: line 177

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Martin Matusiak added the comment: Double checked that the test passes against both default and 2.7 branches. Is there anything else that needs to happen here or are you satisfied, Marc-Andre? -- ___ Python tracker rep...@bugs.python.org

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Marc-Andre Lemburg added the comment: On 19.10.2013 13:37, Martin Matusiak wrote: Martin Matusiak added the comment: Double checked that the test passes against both default and 2.7 branches. Is there anything else that needs to happen here or are you satisfied, Marc-Andre? No,

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8964 ___ ___ Python-bugs-list

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Martin Matusiak added the comment: It seems the versions of IronPython 1.0 mentioned in test cases do actually support the in keyword, so the first version of the patch is probably sufficient. Example session: sys.version IronPython 1.0.60816 on .NET 2.0.50727.3643 IronPython

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Martin Matusiak added the comment: Hm, I see. Actually, in is already used in this function a little further down: elif PyPy in sys_version: So we should change both occurrences then. I'm attaching a v2 with these changes. -- Added file:

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Martin Matusiak added the comment: I've checked sys.version on IronPython 2.6.1, 2.6.2 (same format) and 2.7.4 (slightly different). The patch includes two new test cases. I've also taken the liberty of adding some newlines in between the items in the dict as I found this code very hard

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Changes by Berker Peksag berker.pek...@gmail.com: -- stage: needs patch - patch review versions: +Python 3.4 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8964 ___

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Marc-Andre Lemburg added the comment: The patch looks good, except one nit: if 'IronPython' in sys_version is probably not supported in IronPython 2.0, since support for n-char in m-char tests were added after Python 2.1. Now, you can either leave this in and remove the IronPython 2.0

IronPython 2.7.4 Released

On behalf of the IronPython team, I'm happy to announce the final release of IronPython 2.7.4[1]. This release includes everything from IronPython 2.7.3 and earlier. Like all IronPython 2.7-series releases, .NET 4 is required to install it. Installing this release will replace any existing

Importing modules into IronPython

Hi, I have to shift a Python 2.7 program to run in Windows. Doing that has forced me to use IronPython because my program is dependent on a .dll file that uses .NET framework. I moved all my code to Iron Python and modified it to work with the dll. But I cant import PyQt4 module

Re: Importing modules into IronPython

On Wed, Jul 3, 2013 at 3:05 PM, HighBeliever akshay.k...@gmail.com wrote: Hi, I have to shift a Python 2.7 program to run in Windows. Doing that has forced me to use IronPython because my program is dependent on a .dll file that uses .NET framework. I moved all my code to Iron Python

[issue17994] Change necessary in platform.py to support IronPython

Changes by Jeff Hardy jdha...@gmail.com: -- nosy: +jeff.hardy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17994 ___ ___ Python-bugs-list mailing

[issue17994] Change necessary in platform.py to support IronPython

made in IronPython. As it is now, it checks that the slice, sys.version[:10], is IronPython. Seemingly due to a change in IronPython, this no longer is a correct condition for checking that the implementation is IronPython. I'm trying to work with the question author on StackOverflow to provide

[issue17994] Change necessary in platform.py to support IronPython

Changes by Brian Curtin br...@python.org: -- nosy: +brian.curtin stage: - test needed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17994 ___

[issue17994] Change necessary in platform.py to support IronPython

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +dino.viehland ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17994 ___ ___ Python-bugs-list

[issue7855] Add test cases for ctypes/winreg for issues found in IronPython

Roundup Robot added the comment: New changeset 5f82b68c1f28 by Ezio Melotti in branch '3.3': #7855: Add tests for ctypes/winreg for issues found in IronPython. Initial patch by Dino Viehland. http://hg.python.org/cpython/rev/5f82b68c1f28 New changeset df655ebf74d7 by Ezio Melotti in branch

[issue7855] Add test cases for ctypes/winreg for issues found in IronPython

Roundup Robot added the comment: New changeset e71406d8ed5d by Ezio Melotti in branch '2.7': #7855: Add tests for ctypes/winreg for issues found in IronPython. Initial patch by Dino Viehland. http://hg.python.org/cpython/rev/e71406d8ed5d

[issue7855] Add test cases for ctypes/winreg for issues found in IronPython

Ezio Melotti added the comment: This should be fixed now. Thanks for the report and the patch (and thanks Zach for confirming that it works on Windows and for the review)! -- assignee: dino.viehland - ezio.melotti resolution: - fixed stage: patch review - committed/rejected status:

[issue7855] Add test cases for ctypes/winreg for issues found in IronPython

Ezio Melotti added the comment: The attached patch now passes on Linux. I raised a SkipTest on non-Windows platforms and changed Lib/ctypes/test/__init__.py to handle it. If someone can confirm that the patch works on Windows I'll commit it. The ValueError I reported in my previous message

[issue7855] Add test cases for ctypes/winreg for issues found in IronPython

Zachary Ware added the comment: The patch works fine on Win 7 for me. I left a couple comments on Rietveld, neither of which is of great importance. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7855

[issue7855] Add test cases for ctypes/winreg for issues found in IronPython

Changes by Michael Foord mich...@voidspace.org.uk: -- nosy: -michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7855 ___ ___

PyPyODBC 1.0.5 released. (DBI 2.0 ODBC module compatible with PyPy, IronPython and SQLAlchemy)

Changes in Ver 1.0.5 (and 1.0.4, 1.0.3, 1.0.2, 1.0.1) - *Fix several bugs under Python 3.x* - *Add Mac / iODBC platform support* - *Improved ODBC ANSI / unicode mode support* Features - *One pure Python script, runs on CPython /

[issue7855] Add test cases for ctypes/winreg for issues found in IronPython

Ezio Melotti added the comment: Dino, what's the status of this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7855 ___ ___ Python-bugs-list

[issue7855] Add test cases for ctypes/winreg for issues found in IronPython

Ezio Melotti added the comment: I made the latest 3.x patch hg import-able and cleaned up a few nits (whitespace, naming conventions, and used assertIs). I have 2 comments though: 1) the winreg test is defined in Win64WinregTests. Is it specific to x64 or should it go in BaseWinregTests

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Changes by Ezio Melotti ezio.melo...@gmail.com: -- keywords: +easy versions: +Python 3.3 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8964 ___

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

On Thu, 2012-05-17 at 11:13 +1000, Chris Angelico wrote: On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote: A record is an interesting critter -- it is given life either from the user or from the disk-bound data; its fields can then change, but those changes are not

cPython, IronPython, Jython, and PyPy (Oh my!)

Just hit a snag: In cPython the deterministic garbage collection allows me a particular optimization when retrieving records from a dbf file -- namely, by using weakrefs I can tell if the record is still in memory and active, and if so not hit the disk to get the data; with PyPy (and

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

') I don't know what IronPython or PyPy return, but it should be something other than 'CPython'. -- http://mail.python.org/mailman/listinfo/python-list

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

On 17 May 2012 07:33, Ethan Furman et...@stoneleaf.us wrote: Just hit a snag: In cPython the deterministic garbage collection allows me a particular optimization when retrieving records from a dbf file -- namely, by using weakrefs I can tell if the record is still in memory and active, and

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

/Release_2_5_2', '7206') I don't know what IronPython or PyPy return, but it should be something other than 'CPython'. Thanks! That will do the trick. On CPython 2.4 .subversion does not exist, so I'll use: subversion = getattr(sys, 'subversion', None) if subversion is not None and subversion[0

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

Tim Delaney wrote: On 17 May 2012 07:33, Ethan Furman wrote: Just hit a snag: In cPython the deterministic garbage collection allows me a particular optimization when retrieving records from a dbf file -- namely, by using weakrefs I can tell if the record is still in memory and active, and if

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote: A record is an interesting critter -- it is given life either from the user or from the disk-bound data;  its fields can then change, but those changes are not reflected on disk until .write_record() is called;  I do this

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

On 17 May 2012 11:13, Chris Angelico ros...@gmail.com wrote: On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote: A record is an interesting critter -- it is given life either from the user or from the disk-bound data; its fields can then change, but those changes are

Re: cPython, IronPython, Jython, and PyPy (Oh my!)

Chris Angelico wrote: On Thu, May 17, 2012 at 9:01 AM, Ethan Furman et...@stoneleaf.us wrote: A record is an interesting critter -- it is given life either from the user or from the disk-bound data; its fields can then change, but those changes are not reflected on disk until .write_record()

[issue7071] distutils and IronPython compatibility

Éric Araujo mer...@netwok.org added the comment: I think this change was wrong. Please see my rationale in http://bugs.python.org/issue12119. (BTW, I’d be surprised if byte compilation was the only compat issue with distutils and IronPython. For a start, sys.version[:3] is used to get

Unable to make ironpython run in browser with silverlight

Basically i am following this tutorial: http://blog.jimmy.schementi.com/2010/03/pycon-2010-python-in-browser.html According to it, this code should run fine: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; html head script type=text/javascript

Re: Unable to make ironpython run in browser with silverlight

Here is how it looks on free webhosting account: http://silverlighttest.zzl.org/silverlighttest.html It is supposed to show a window with Hello from python, but it shows smth else completely. -- http://mail.python.org/mailman/listinfo/python-list

Re: Unable to make ironpython run in browser with silverlight

You need to run it from a web-server; it doesn't work when running from file:// due to Silverlight's security sandbox. Read the comments on my blog-post, it mentions the web-server there. -- http://mail.python.org/mailman/listinfo/python-list

Re: Unable to make ironpython run in browser with silverlight

On May 26, 9:44 am, Jimmy Schementi jscheme...@gmail.com wrote: You need to run it from a web-server; it doesn't work when running from file:// due to Silverlight's security sandbox. Read the comments on my blog-post, it mentions the web-server there. I see.. But here:

Re: Unable to make ironpython run in browser with silverlight

On May 26, 9:44 am, Jimmy Schementi jscheme...@gmail.com wrote: You need to run it from a web-server; it doesn't work when running from file:// due to Silverlight's security sandbox. Read the comments on my blog-post, it mentions the web-server there. I see.. But here:

RE: [IronPython] IronPython 2.7 Now Available

Can someone on the list clarify differences or overlap between the tools included in this release, and the PTVS release? -- http://mail.python.org/mailman/listinfo/python-list

RE: [IronPython] IronPython 2.7 Now Available

The PTVS release is really an extended version of the tools in IronPython 2.7. It adds support for CPython including debugging, profiling, etc... while still supporting IronPython as well. We'll likely either replace the tools distributed w/ IronPython with this version (maybe minus things

RE: [IronPython] IronPython 2.7 Now Available

...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Sunday, March 13, 2011 2:22 PM To: Discussion of IronPython; python-list Subject: Re: [IronPython] IronPython 2.7 Now Available The PTVS release is really an extended version of the tools in IronPython

IronPython 2.7 Now Available

On behalf of the IronPython team, I'm very pleased to announce the release of IronPython 2.7. This release contains all of the language features of Python 2.7, as well as several previously missing modules and numerous bug fixes. IronPython 2.7 also includes built-in Visual Studio support through

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Éric Araujo mer...@netwok.org added the comment: Do you want to work on a patch? -- nosy: +eric.araujo stage: - needs patch title: Method _sys_version() module Lib\platform.py does not parse correctly IronPython 2.x version - platform._sys_version does not parse correctly

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Frederic Torres fredericaltor...@gmail.com added the comment: Eric, Yes I like to. But I am not familiar how to submit a patch. The file that need to be patched is C:\Program Files (x86)\IronPython 2.6\Lib\platform.py for IronPython 2.6. I thought this file was maintained by Marc-Andre Lemburg

[issue8964] platform._sys_version does not parse correctly IronPython 2.x version

Éric Araujo mer...@netwok.org added the comment: This is the tracker for CPython, not IronPython, but I assume they synchronize their standard modules with ours, so I think this bug should be fixed here (not in 2.6 though, this old version only gets security fixes). Guidelines for patches

Re: Microsoft lessening commitment to IronPython and IronRuby

On Tue, Aug 10 2010, Ben Finney wrote: Steven D'Aprano steve-remove-t...@cybersource.com.au writes: On Tue, 10 Aug 2010 20:07:06 +1200, Gregory Ewing wrote: Is there any way for a non-.NET program to access a .NET library? Or is it necessary to drink the entire bottle of .NET kool-aid?

Re: Microsoft lessening commitment to IronPython and IronRuby

Jason Earl je...@notengoamigos.org writes: Which is more of a promise than Microsoft has given to Python. I am not arguing for Mono, as I am not a fan. But if you honestly think that Python doesn't infringe on some of Microsoft's patents you are crazy. It's quite true that anyone can be

Re: Microsoft lessening commitment to IronPython and IronRuby

Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote: Frankly I never understood the point of IronPython and IronRuby. They seemed like a desperate attempt to keep Dotnet relevant in the modern world of dynamic languages. Looks like it was a failure. Yawn. I'm not sure that's really fair

Re: Microsoft lessening commitment to IronPython and IronRuby

In message 7fr16650meigqgmj8rh0n3a66q9r4j4...@4ax.com, Tim Roberts wrote: The .NET Common Language Runtime is a vast and very useful class library, including two complete GUI systems. Used only by corporate code-cutter drones. Go on, name one creative thing which was ever done in Dotnet. --

Re: Microsoft lessening commitment to IronPython and IronRuby

Lawrence D'Oliveiro, 10.08.2010 08:42: In message7fr16650meigqgmj8rh0n3a66q9r4j4...@4ax.com, Tim Roberts wrote: The .NET Common Language Runtime is a vast and very useful class library, including two complete GUI systems. Used only by corporate code-cutter drones. Go on, name one creative

Re: Microsoft lessening commitment to IronPython and IronRuby

Tim Roberts wrote: I'm not sure that's really fair. The .NET Common Language Runtime is a vast and very useful class library, including two complete GUI systems. The thought was that IronPython and IronRuby would let people who were comfortable in those languages tap into the CLR

Re: Microsoft lessening commitment to IronPython and IronRuby

. Go on, name one creative thing which was ever done in Dotnet. Not just Dotnet, but Python on Dotnet. http://www.python.org/about/success/resolver/ http://blog.jonudell.net/2007/09/27/first-look-at-resolver-an-ironpython-based-spreadsheet/ -- Steven -- http://mail.python.org/mailman

Re: Microsoft lessening commitment to IronPython and IronRuby

On Tue, 10 Aug 2010 20:07:06 +1200, Gregory Ewing wrote: Tim Roberts wrote: I'm not sure that's really fair. The .NET Common Language Runtime is a vast and very useful class library, including two complete GUI systems. The thought was that IronPython and IronRuby would let people who were

Re: Microsoft lessening commitment to IronPython and IronRuby

Steven D'Aprano, 10.08.2010 10:04: On Tue, 10 Aug 2010 18:42:35 +1200, Lawrence D'Oliveiro wrote: Go on, name one creative thing which was ever done in Dotnet. Not just Dotnet, but Python on Dotnet. http://www.python.org/about/success/resolver/ At the very end of that article, I found this

Re: Microsoft lessening commitment to IronPython and IronRuby

Steven D'Aprano steve-remove-t...@cybersource.com.au writes: On Tue, 10 Aug 2010 20:07:06 +1200, Gregory Ewing wrote: Is there any way for a non-.NET program to access a .NET library? Or is it necessary to drink the entire bottle of .NET kool-aid? http://www.mono-project.com/Main_Page

Re: Microsoft lessening commitment to IronPython and IronRuby

On 08/10/2010 02:07 AM, Gregory Ewing wrote: Tim Roberts wrote: I'm not sure that's really fair. The .NET Common Language Runtime is a vast and very useful class library, including two complete GUI systems. The thought was that IronPython and IronRuby would let people who were comfortable

Re: Microsoft lessening commitment to IronPython and IronRuby

In message tq17o.2754$fh2@viwinnwfe02.internal.bigpond.com, Neil Hodgson wrote: http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html Frankly I never understood the point of IronPython and IronRuby. They seemed like a desperate attempt to keep Dotnet relevant

Microsoft lessening commitment to IronPython and IronRuby

There is a blog post from Jimmy Schementi who previously worked at Microsoft on IronRuby about the state of dynamic language work there. http://blog.jimmy.schementi.com/2010/08/start-spreading-news-future-of-jimmy.html Neil -- http://mail.python.org/mailman/listinfo/python-list

[issue7855] Add test cases for ctypes/winreg for issues found in IronPython

Mark Lawrence breamore...@yahoo.co.uk added the comment: Gentle poke in ribs can this be committed por favor? -- nosy: +BreamoreBoy versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7855

Where is StackPanel in IronPython / .Net 4?

Hi All, According to this page http://msdn.microsoft.com/en-us/library/system.windows.controls.stackpanel.aspx StackPanel is in the System.Windows.Controls Namespace When I try and set up a reference to that Namespace I get a Could not add reference to assembly System.Windows.Controls error

Re: Where is StackPanel in IronPython / .Net 4?

On Sun, Jun 27, 2010 at 10:36 AM, Ian Hobson i...@ianhobson.co.uk wrote: Hi All, According to this page http://msdn.microsoft.com/en-us/library/system.windows.controls.stackpanel.aspx StackPanel is in the System.Windows.Controls Namespace When I try and set up a reference to that

Re: Where is StackPanel in IronPython / .Net 4?

Hi Benjamin - and thanks for your reply. I'm now really confused. On 27/06/2010 20:05, Benjamin Kaplan wrote: You don't add references to namespaces. You add references to assemblies and you then you import the namespace. From the documentation: ''' Namespace: System.Windows.Controls

[issue8964] Method _sys_version() module Lib\platform.py does not parse correctly IronPython 2.x version

Frederic Torres fredericaltor...@gmail.com added the comment: print repr(sys_version) returns '2.6.1 (IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.3603)' The format of sys.version now start with a version number 2.6.1 (IronPythons 2.6.1 (2.6.10920.0) on .NET 4.0.30319.1) My guess

[issue8964] Method _sys_version() module Lib\platform.py does parse correctly IronPython 2.x version

Marc-Andre Lemburg m...@egenix.com added the comment: Frederic Torres wrote: New submission from Frederic Torres fredericaltor...@gmail.com: Method _sys_version() module Lib\platform.py does parse correctly IronPython 2.x version The format of sys.version now start with a version

Announcing IronPython 2.6.1

Hello Python Community, We're pleased to announce the final release of IronPython 2.6.1. This version of IronPython makes great strides in stability and compatibility, including a considerable number of targeted bugfixes. This is our largest servicing release to date, and with your help both

  1   2   3   4   5   >