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

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
type: crash -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: ironpython not support py3.6

[Peter J. Holzer]

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 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 the current state of IronPython 3? The website is very uninformative
(there's a 4 year old blog post saying "we started a repository", but that's
it). The repository gets commits every now and then (so it's obviously not dead
 yet), but neither the readme nor the wiki give a hint beyond "not ready yet".

hp

--=20
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>

--prnws536gtytpj5v
Content-Type: application/pgp-signature; name="signature.asc"

-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAlsuAsMACgkQ8g5IURL+
KF3tZRAArjij8tON0JDZA9HW2eC3hjLEQVR5xk8qvsKOsuLfSZ4vpzF9DyAq+mSy
R+poIBfJwQglBeHs3yMOhxzsynZHD8sdoO6BtdAAZHNlgl8aCAzRQqxxJxOSi9RY
A0VfL1IGt8M7FiT//nttpxGKknSaDVNy37H/fPSertJOD7QIvh7OjOD1wpnfFpg7
JO4B5Q1R4J2HBVwqszcsJgoBJtQLTKg4peZVqyLrKZeF6nr8YyPmtx4pHLGLYTtX
gH1K25dERjWpv0soISd0GI6aCJvr7Pmm6OmxNK8Qw+wB1maDxAkI/tVCs3HZRIsf
q6BW+mWC/WCmNJg+A8QenC8ISp/pBhOaM3WIln0g/FcWEfOOwut9vnQJcyLrFYYW
GXTHhVpJQm5KwcfTTEXh5Czorr6bfIa9IvTOnhZukgRdc0lSDT2JMykmeo97bS9M
rC6GJqk0qVEVw66+M0vbVmaKbzugqH0rsYSGoHiTaAYFyFuq5T+G8etl8phGmpXN
sRw9jRzBj5eoA3toYK4XDRB7hm8JzQjCxJdSjoP3hgmqa7jmozor70pm22nUy8ql
e7ZE9E3cuUyKLe1zAfZ07W8dUo1WcNB9h0zedR53jx29m5W/ouixGZ1VhQN6DcRY
XUYAR66l1Xk4AZxXrKWmYAfxlC2PION/oHykev2nR5sCgFrF1Xw=
=dC9K
-END PGP SIGNATURE-

--prnws536gtytpj5v--

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ironpython not support py3.6

[wxjmfauth]

  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 characters ! Try with IronPython 2.7.8.

PS Yes, I know, it is based on .NET !!!

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: ironpython not support py3.6

[denis akhiyarov]

  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 a working IronPython 3.6.

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ironpython not support py3.6

[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 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 the current state of IronPython 3? The website is very uninformative
(there's a 4 year old blog post saying "we started a repository", but that's
it). The repository gets commits every now and then (so it's obviously not dead
 yet), but neither the readme nor the wiki give a hint beyond "not ready yet".

hp

--=20
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>

--prnws536gtytpj5v
Content-Type: application/pgp-signature; name="signature.asc"

-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEETtJbRjyPwVTYGJ5k8g5IURL+KF0FAlsuAsMACgkQ8g5IURL+
KF3tZRAArjij8tON0JDZA9HW2eC3hjLEQVR5xk8qvsKOsuLfSZ4vpzF9DyAq+mSy
R+poIBfJwQglBeHs3yMOhxzsynZHD8sdoO6BtdAAZHNlgl8aCAzRQqxxJxOSi9RY
A0VfL1IGt8M7FiT//nttpxGKknSaDVNy37H/fPSertJOD7QIvh7OjOD1wpnfFpg7
JO4B5Q1R4J2HBVwqszcsJgoBJtQLTKg4peZVqyLrKZeF6nr8YyPmtx4pHLGLYTtX
gH1K25dERjWpv0soISd0GI6aCJvr7Pmm6OmxNK8Qw+wB1maDxAkI/tVCs3HZRIsf
q6BW+mWC/WCmNJg+A8QenC8ISp/pBhOaM3WIln0g/FcWEfOOwut9vnQJcyLrFYYW
GXTHhVpJQm5KwcfTTEXh5Czorr6bfIa9IvTOnhZukgRdc0lSDT2JMykmeo97bS9M
rC6GJqk0qVEVw66+M0vbVmaKbzugqH0rsYSGoHiTaAYFyFuq5T+G8etl8phGmpXN
sRw9jRzBj5eoA3toYK4XDRB7hm8JzQjCxJdSjoP3hgmqa7jmozor70pm22nUy8ql
e7ZE9E3cuUyKLe1zAfZ07W8dUo1WcNB9h0zedR53jx29m5W/ouixGZ1VhQN6DcRY
XUYAR66l1Xk4AZxXrKWmYAfxlC2PION/oHykev2nR5sCgFrF1Xw=
=dC9K
-END PGP SIGNATURE-

--prnws536gtytpj5v--

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ironpython not support py3.6

[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 characters ! Try with IronPython 2.7.8.

PS Yes, I know, it is based on .NET !!!

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: ironpython not support py3.6

[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 a working IronPython 3.6.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ironpython not support py3.6

[Peter J. Holzer]

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 the current state of IronPython 3? The website is very
uninformative (there's a 4 year old blog post saying "we started a
repository", but that's it). The repository gets commits every now and
then (so it's obviously not dead yet), but neither the readme nor the
wiki give a hint beyond "not ready yet".

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: ironpython not support py3.6

[denis . akhiyarov]

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

[Schachner, Joseph]

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 but iron python not support python 
3.6 yet, any suggest for this?

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ironpython not support py3.6

[Steven D'Aprano]

On Thu, 21 Jun 2018 23:44:40 -0700, fantasywangxg wrote:

> 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?

How big is your budget? Could 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 maybe you can do both, use IronPython only for the parts that really 
need C# integration, and use CPython for the rest:

C# <--> IronPython 2.7 <--> CPython 3.6

although I suspect that will be even more annoying, complicated  and 
fragile.

Have you tried asking this question on an IronPython support forum?


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

-- 
https://mail.python.org/mailman/listinfo/python-list

ironpython not support py3.6

[fantasywangxg]

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

[Cheryl Sabella]

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

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue17994>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

PyDev 5.8.0: Code Coverage fixes, IronPython debugging

[Fabio Zadrozny]

PyDev 5.8.0 Release Highlights

   -

   *Important* PyDev now requires Java 8 and Eclipse 4.6 (Neon) onwards.
   - PyDev 5.2.0 is the last release supporting Eclipse 4.5 (Mars).
   -

   *Code Analysis*
   - Fixed issue getting existing PyLint markers.
  - There's now an Info and an Ignore level.
   -

   *Debugger*
   - The debugger now provides hooks for clients and provides ways to
  extend the handling of custom types. See:
  
https://github.com/fabioz/PyDev.Debugger/tree/master/pydevd_plugins/extensions
(patch
  by *Yuli Fiterman*).
  - Fixed issue where 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/1663
   -

   *Code Coverage*
   - Fixed issue getting code-coverage version. *#PyDev-791*
  - Properly works when running with pytest (provided that pytest-cov
  is installed).
   -

   *Others*
   - Update .yaml file for google app engine project templates (patch by
  *JunjieW*).
  - Upgraded Lucene to 6.1.0 (patch by *Sopot Cela*).
  - Update docstring from parameters (Ctrl+1 on *def*) properly
  considers sphinx with types. *#PyDev-787*
  - Code Completion: Properly finding *__init__* from superclass in
  inherited classes. *#PyDev-802*
  - No longer showing icon to start interactive console in toolbar
  because Eclipse could end up creating multiple entries which were shown
  forever. *#PyDev-708*
  - Other minor bugfixes.

What is PyDev?

PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and
IronPython development.

It comes with goodies such as code completion, syntax highlighting, syntax
analysis, code analysis, refactor, debug, interactive console, etc.

Details on PyDev: http://pydev.org
Details on its development: http://pydev.blogspot.com
What is LiClipse?

LiClipse is a PyDev standalone with goodies such as support for Multiple
cursors, theming, TextMate bundles and a number of other languages such as
Django Templates, Jinja2, Kivy Language, Mako Templates, Html, Javascript,
etc.

It's also a commercial counterpart which helps supporting the development
of PyDev.

Details on LiClipse: http://www.liclipse.com/

Cheers,

--
Fabio Zadrozny
--

Software Developer

LiClipse
http://www.liclipse.com

PyDev - Python Development Environment for Eclipse
http://pydev.org
http://pydev.blogspot.com

PyVmMonitor - Python Profiler
http://www.pyvmmonitor.com/
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

PyDev 5.8.0: Code Coverage fixes, IronPython debugging

[Fabio Zadrozny]

PyDev 5.8.0 Release Highlights

   -

   *Important* PyDev now requires Java 8 and Eclipse 4.6 (Neon) onwards.
   - PyDev 5.2.0 is the last release supporting Eclipse 4.5 (Mars).
   -

   *Code Analysis*
   - Fixed issue getting existing PyLint markers.
  - There's now an Info and an Ignore level.
   -

   *Debugger*
   - The debugger now provides hooks for clients and provides ways to
  extend the handling of custom types. See:
  
https://github.com/fabioz/PyDev.Debugger/tree/master/pydevd_plugins/extensions
(patch
  by *Yuli Fiterman*).
  - Fixed issue where 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/1663
   -

   *Code Coverage*
   - Fixed issue getting code-coverage version. *#PyDev-791*
  - Properly works when running with pytest (provided that pytest-cov
  is installed).
   -

   *Others*
   - Update .yaml file for google app engine project templates (patch by
  *JunjieW*).
  - Upgraded Lucene to 6.1.0 (patch by *Sopot Cela*).
  - Update docstring from parameters (Ctrl+1 on *def*) properly
  considers sphinx with types. *#PyDev-787*
  - Code Completion: Properly finding *__init__* from superclass in
  inherited classes. *#PyDev-802*
  - No longer showing icon to start interactive console in toolbar
  because Eclipse could end up creating multiple entries which were shown
  forever. *#PyDev-708*
  - Other minor bugfixes.

What is PyDev?

PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and
IronPython development.

It comes with goodies such as code completion, syntax highlighting, syntax
analysis, code analysis, refactor, debug, interactive console, etc.

Details on PyDev: http://pydev.org
Details on its development: http://pydev.blogspot.com
What is LiClipse?

LiClipse is a PyDev standalone with goodies such as support for Multiple
cursors, theming, TextMate bundles and a number of other languages such as
Django Templates, Jinja2, Kivy Language, Mako Templates, Html, Javascript,
etc.

It's also a commercial counterpart which helps supporting the development
of PyDev.

Details on LiClipse: http://www.liclipse.com/

Cheers,

--
Fabio Zadrozny
--

Software Developer

LiClipse
http://www.liclipse.com

PyDev - Python Development Environment for Eclipse
http://pydev.org
http://pydev.blogspot.com

PyVmMonitor - Python Profiler
http://www.pyvmmonitor.com/
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mark Lawrence]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

IronPython 2.7.5 Released

[Jeff Hardy]

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 for .NET 3.5, .NET 4, .NET 4.5,
and Silverlight 5.

IronPython 2.7.5 is primarily a collection of bug fixes[2] which
smooths off many of the remaining rough edges. The complete list of
changes[3] is also available.

A major new feature is the inclusion of `ensurepip`, which will
install the `pip` package manager:

```
; -X:Frames is required when using pip
ipy.exe -X:Frames -m ensurepip

; Run from an Administrator console if using IronPython installer
ipy.exe -X:Frames -m pip install html5lib
```

**Note:** The assembly version of IronPython has changed to 2.7.5.0.
All previous 2.7 versions had the same version (2.7.0.40) which caused
issues when different versions were installed. Publisher policy files
are used to so that applications don't have to be recompiled, but
recompiling is strongly recommended.

A huge thanks goes out to Pawel Jasinski, who contributed most of the
changes in this release. Thanks is also due to Simon Opelt, Alex Earl,
Jeffrey Bester, yngipy hernan, Alexander Köplinger,Vincent Ducros, and
fdanny.

For Visual Studio integration, check out Python Tools for Visual
Studio[4] which has support for IronPython as well as CPython, and
many other fantastic features.

IronPython 2.7.5 is also available for embedding via NuGet. The main
package is IronPython, and the standard library is in
IronPython.StdLib.

- Jeff

[1] http://ironpython.codeplex.com/releases/view/169382
[2] http://bit.ly/ipy275fixed
[3] https://github.com/IronLanguages/main/compare/ipy-2.7.4...ipy-2.7.5
[4] http://pytools.codeplex.com/
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

IronPython 2.7.5 Released

[Jeff Hardy]

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 for .NET 3.5, .NET 4, .NET 4.5,
and Silverlight 5.

IronPython 2.7.5 is primarily a collection of bug fixes[2] which
smooths off many of the remaining rough edges. The complete list of
changes[3] is also available.

A major new feature is the inclusion of `ensurepip`, which will
install the `pip` package manager:

```
; -X:Frames is required when using pip
ipy.exe -X:Frames -m ensurepip

; Run from an Administrator console if using IronPython installer
ipy.exe -X:Frames -m pip install html5lib
```

**Note:** The assembly version of IronPython has changed to 2.7.5.0.
All previous 2.7 versions had the same version (2.7.0.40) which caused
issues when different versions were installed. Publisher policy files
are used to so that applications don't have to be recompiled, but
recompiling is strongly recommended.

A huge thanks goes out to Pawel Jasinski, who contributed most of the
changes in this release. Thanks is also due to Simon Opelt, Alex Earl,
Jeffrey Bester, yngipy hernan, Alexander Köplinger,Vincent Ducros, and
fdanny.

For Visual Studio integration, check out Python Tools for Visual
Studio[4] which has support for IronPython as well as CPython, and
many other fantastic features.

IronPython 2.7.5 is also available for embedding via NuGet. The main
package is IronPython, and the standard library is in
IronPython.StdLib.

- Jeff

[1] http://ironpython.codeplex.com/releases/view/169382
[2] http://bit.ly/ipy275fixed
[3] https://github.com/IronLanguages/main/compare/ipy-2.7.4...ipy-2.7.5
[4] http://pytools.codeplex.com/
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Mark Lawrence]

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 rep...@bugs.python.org
http://bugs.python.org/issue19453
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Will IronPython / WPF work on Mac OS X?

[danwgrace]

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?

[Benjamin Kaplan]

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 on top of Mono, so it has access to all the
libraries that Mono supports. That means there's no support for WPF except
for the subset that Silverlight supported (See
http://www.mono-project.com/wpf ).
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Kevin Walzer]

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, I believe...doesn't it run on top 
of .NET? I don't see how it would work on the Mac unless it also worked 
with Mono.


--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
--
https://mail.python.org/mailman/listinfo/python-list

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

[Ian Cordasco]

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, and the 
3.x branches.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17994
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

IronPython + Selenium2Library + Visual Studio + Robot Framwork

[nw . rabea]

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 to selenium2library on visual 
studio iron python?


Thank you,
Rabea
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Jeff Hardy]

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 list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Evans]

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 sys.platform and needs to check for cli as well to 
detect IronPython running on mono on linux/mac os or on windows.

My naive change to workaround the problem was to add the two line test for 
cli amidst getpager() here:

if sys.platform == 'win32' or sys.platform.startswith('os2'):
return lambda text: tempfilepager(plain(text), 'more ')
if sys.platform == 'cli':
return plainpager # IronPython
if hasattr(os, 'system') and os.system('(less) 2/dev/null') == 0:
return lambda text: pipepager(text, 'less')

That two line addition allowed basic function and prevents the hang though 
maybe there is a better pager type that would work on IronPython. In our linux 
and windows tests though neither the tempfilepager nor pipepager would function 
on either platform.

I submitted the report to the IronPython issues tracker and someone there 
suggested posting the patch here.

--
components: Windows
messages: 201750
nosy: owlmonkey
priority: normal
severity: normal
status: open
title: pydoc.py doesn't detect IronPython, help(foo) can hang
type: crash
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19453
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marc-Andre Lemburg]

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
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

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 to handle IronPython 2.6+.
http://hg.python.org/cpython/rev/10a261824b62

New changeset 1f7d8a42904c by Ezio Melotti in branch 'default':
#8964: merge with 3.3.
http://hg.python.org/cpython/rev/1f7d8a42904c

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ezio Melotti]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marc-Andre Lemburg]

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 session:
 
 sys.version
 IronPython 1.0.60816 on .NET 2.0.50727.3643
 IronPython in sys.version
 True
 sys.version.startswith(IronPython)
 True

In that case, I'm +1 on using both to clean up the code.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Martin Matusiak]

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 334
- as keyword: except OSError as why: line 430
- ImportError: No module named os. os and subprocess are missing altogether in 
IronPython 1.0.

That's as far as I looked - there may be other issues still. 

So I decided to isolate this one function and see if it works. It fails because 
re.ASCII does not exist. If I remove that then the function runs and parses its 
own sys.version correctly.

But it may be a bit of a stretch at this point to stay compatible that far back.

--
Added file: http://bugs.python.org/file32221/issue8964_v3.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marc-Andre Lemburg]

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
 - unexpected token open: use of with context manager on line 334
 - as keyword: except OSError as why: line 430
 - ImportError: No module named os. os and subprocess are missing altogether 
 in IronPython 1.0.
 
 That's as far as I looked - there may be other issues still. 
 
 So I decided to isolate this one function and see if it works. It fails 
 because re.ASCII does not exist. If I remove that then the function runs and 
 parses its own sys.version correctly.
 
 But it may be a bit of a stretch at this point to stay compatible that far 
 back.

Well, there's a catch here: the trunk version of platform.py is for
Python 3. This does not need to stay backwards compatible to Python 2
(but keeping it close to the Python 2 version helps make merges easier).

Then there's the Python 2.7 version, which receives patches like yours.
This has to stay compatible for Python versions relying on it, which
are in particular older IronPython and Jython versions that don't
ship with their own stdlib.

I think it's ok to use Python 2.4 as the latest version supported
by the Python 2.7 platform.py. The module is used for creating
Python packages and 2.4 is still used by some Zope/Plone installations.

If IronPython 1.0 does not support Python 2.4, we don't need to
support it in the 2.7 version of platform.py.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Martin Matusiak]

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
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marc-Andre Lemburg]

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, that's all :-)

Thanks, Martin.

Unfortunately, I don't have time in the next few days to check this
in. Could one of the other core devs please do ? Thanks.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ezio Melotti]

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 mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Martin Matusiak]

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 in sys.version
True
 sys.version.startswith(IronPython)
True

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Martin Matusiak]

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: http://bugs.python.org/file32154/issue8964_v2.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Martin Matusiak]

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 
to read otherwise.

--
keywords: +patch
nosy: +numerodix
Added file: http://bugs.python.org/file32146/issue8964.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Berker Peksag]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marc-Andre Lemburg]

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 support from 
platform.py (which is fine, IMO), or change the test to use the .find() method.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

IronPython 2.7.4 Released

[Jeff Hardy]

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 IronPython 2.7-series installation. Assemblies for
embedding are provided for .NET 3.5, .NET 4, .NET 4.5, and Silverlight
5.

IronPython is an implementation of Python that targets Microsoft's
.NET Framework and the open-source Mono framework. It aims to be as
compatible as possible with Python 2.7 while taking advantage of the
.NET Framework's capabilities. It is also easily embedded in .NET
applications to provide scripting capabilities.

Improvements in IronPython 2.7.4 are mainly a collection of bug fixes,
many of which are directed at getting IPython working. Specific
improvements include:

* Many fixes to the ast module (thanks to Pawel Jasinski)
* A bunch of fixes to locale and tty handling (also courtesy of Pawel)
designed to get IPython working.
* .NET 4.5 builds, courtesy of Aleksander Heintz
* Other fixes from Michael van der Kolff, Fraser Tweedale, and Igor (WildOgr)
* A bunch of small fixes backported from the master branch

Android and Silverlight 4 assemblies have been dropped from this
version. The Android assemblies need some more work to be usable with
Xamarin.Android, and Silverlight 4 is just plain dead.

For Visual Studio integration, check out Python Tools for Visual
Studio which has support for IronPython as well as CPython, and many
other fantastic features.

IronPython 2.7.4 is also available for embedding via NuGet. The main
package is IronPython, and the standard library is in
IronPython.StdLib.

- Jeff

[1] https://ironpython.codeplex.com/releases/view/90087
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

Importing modules into IronPython

[HighBeliever]

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 into the project. Is there a way I can do that? Please 
Help.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Importing modules into IronPython

[Benjamin Kaplan]

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 and modified it to work with the dll. But 
 I cant import PyQt4 module into the project. Is there a way I can do that? 
 Please Help.
 --

Generally, extensions that aren't pure Python can only be used with
the interpreter they were designed for. There has been some attempt to
get CPython extensions working under IronPython (there's a tracking
issue on IronPython's bug tracker-
http://ironpython.codeplex.com/workitem/11333), but I don't know how
well it works.
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Jeff Hardy]

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 list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ian Cordasco]

New submission from Ian Cordasco:

Stemming from a StackOverflow question[1] and a conversation with Marc-Andre 
Lemburg via email, I'm filing this issue without any easy way of confirming it 
myself.

It seems that the logic in platform.python_implementation() has been obsoleted 
by a change 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 the 
relevant debugging information to fix this, but it is taking a while to get 
responses. Without his repr(sys.version) I can't submit a patch with this issue.

I've also only tagged Python 2.7 since I have no way of knowing if this occurs 
with Python 3.x or anything earlier.

[1]: 
http://stackoverflow.com/questions/16545027/ironpython-error-in-url-request?noredirect=1#comment23828551_16545027

--
components: Library (Lib), Windows
messages: 189383
nosy: icordasc, lemburg
priority: normal
severity: normal
status: open
title: Change necessary in platform.py to support IronPython
versions: 3rd party, Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17994
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Brian Curtin]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Changes by Antoine Pitrou pit...@free.fr:


--
nosy: +dino.viehland

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17994
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

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 'default':
#7855: merge with 3.3.
http://hg.python.org/cpython/rev/df655ebf74d7

--
nosy: +python-dev

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

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

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ezio Melotti]

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: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ezio Melotti]

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 has also been reported in 
#16396 and should be fixed.

--
nosy: +terry.reedy, zach.ware
versions:  -Python 3.2
Added file: http://bugs.python.org/file30090/issue7855.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Zachary Ware]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Michael Foord]

Changes by Michael Foord mich...@voidspace.org.uk:


--
nosy:  -michael.foord

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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 /
IronPythonhttps://code.google.com/p/pypyodbc/wiki/Enable_SQLAlchemy_on_IronPython
/ PyPy http://pypy.org/ , Python 3.3 / 2.4 / 2.5 / 2.6 / 2.7 , Win /
   Linux / Mac , 32 / 64 bit*
   - *Almost totally same usage as pyodbc http://code.google.com/p/pyodbc* (
   can be seen as a re-implementation of pyodbc in pure Python )
   - *Simple - the whole module is implemented in a single python script
   with less than 3000
lineshttps://github.com/jiangwen365/pypyodbc/blob/master/pypyodbc.py
   *
   - *Built-in 
functionshttps://code.google.com/p/pypyodbc/wiki/pypyodbc_for_access_mdb_file
to
   create and compress Access MDB files on Windows*

Simply try pypyodbc:

import pypyodbc

pypyodbc.win_create_mdb('D:\\database.mdb')

connection_string = 'Driver={Microsoft Access Driver
(*.mdb)};DBQ=D:\\database.mdb'

connection = pypyodbc.connect(connection_string)

SQL = 'CREATE TABLE saleout (id COUNTER PRIMARY KEY,product_name VARCHAR(25));'

connection.cursor().execute(SQL).commit()

...

Samples*A HelloWorld sample of python database
programminghttps://code.google.com/p/pypyodbc/wiki/A_HelloWorld_sample_to_access_mssql_with_python
**Create  Compact Access MDB
databasehttps://code.google.com/p/pypyodbc/wiki/pypyodbc_for_access_mdb_file
*Install

*Download the latest packagehttp://code.google.com/p/pypyodbc/downloads/list
* , unzip to a folder, *double click the setup.py file*, or run

setup.py install

Or if you have pip available:

pip install pypyodbc

Or get the latest pypyodbc.py script from
*GitHubhttps://github.com/jiangwen365/pypyodbc
* (Main Development site)
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Ezio Melotti]

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 mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ezio Melotti]

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 instead?
  2) the test_wintypes should be skipped on platforms where it's not supported. 
 Currently if I try to run test_ctypes I get:
test test_ctypes crashed -- Traceback (most recent call last):
  File /home/wolf/dev/py/3.2/Lib/test/regrtest.py, line 1116, in runtest_inner
indirect_test()
  File /home/wolf/dev/py/3.2/Lib/test/test_ctypes.py, line 11, in test_main
skipped, testcases = ctypes.test.get_tests(ctypes.test, test_*.py, 
verbosity=0)
  File /home/wolf/dev/py/3.2/Lib/ctypes/test/__init__.py, line 64, in 
get_tests
mod = __import__(modname, globals(), locals(), ['*'])
  File /home/wolf/dev/py/3.2/Lib/ctypes/test/test_wintypes.py, line 3, in 
module
from ctypes import wintypes
  File /home/wolf/dev/py/3.2/Lib/ctypes/wintypes.py, line 20, in module
class VARIANT_BOOL(ctypes._SimpleCData):
ValueError: _type_ 'v' not supported

I get this error on 2.7/3.2/3.3/3.4 when I try to import wintypes.
Maybe this should be an ImportError instead?
Unfortunately I'm on Linux, so I can test and commit the patch myself, but feel 
free to address my comments and commit it.

--
versions: +Python 3.3, Python 3.4 -Python 3.1
Added file: http://bugs.python.org/file28037/issue7855-3.2.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7855
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ezio Melotti]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Adam Tauno Williams]

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 reflected on disk until .write_record() is called;  I do this
  because I am frequently moving data from one table to another, making
  changes to the old record contents before creating the new record with the
  changes -- since I do not call .write_record() on the old record those
  changes do not get backed up to disk.
 I strongly recommend being more explicit about usage and when it gets
 written and re-read, 

You need to define a 'session' that tracks records and manages flushing.
Potentially it can hold a pool of weak references to record objects that
have been read from disk.  Record what records are 'dirty' and flush
those to disk explicitly or drop all records ('essentially rollback').
That is the only sane way to manage this.

 rather than relying on garbage collection.

+1 +1 Do *not* rely on implementation details as features.  Sooner or
later doing so will always blow-up.

 Databasing should not be tied to a language's garbage collection.
 Imagine you were to reimplement the equivalent logic in some other
 language - could you describe it clearly? If so, then that's your
 algorithm. If not, you have a problem.


signature.asc
Description: This is a digitally signed message part
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Ethan Furman]

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 probably the 
others) this doesn't work because the record may still be around even 
when it is no longer active because it hasn't been garbage collected yet.


For PyPy I can use `'PyPy' in sys.version` to set a constant 
(REFRESH_FROM_DISK in this case) to disable the cPython optimization; 
does anyone know what strings to look for for the other implementations?


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

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

[Ian Kelly]

On Wed, May 16, 2012 at 3:33 PM, 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 if so
 not hit the disk to get the data;  with PyPy (and probably the others) this
 doesn't work because the record may still be around even when it is no
 longer active because it hasn't been garbage collected yet.

 For PyPy I can use `'PyPy' in sys.version` to set a constant
 (REFRESH_FROM_DISK in this case) to disable the cPython optimization; does
 anyone know what strings to look for for the other implementations?

Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)] on win32
Type help, copyright, credits or license for more information.
 import sys
 sys.subversion
('CPython', 'tags/r271', '86832')

Jython 2.5.2 (Release_2_5_2:7206, Mar 2 2011, 23:12:06)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_31
Type help, copyright, credits or license for more information.
 import sys
 sys.subversion
('Jython', 'tags/Release_2_5_2', '7206')

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!)

[Tim Delaney]

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 if so
 not hit the disk to get the data;  with PyPy (and probably the others) this
 doesn't work because the record may still be around even when it is no
 longer active because it hasn't been garbage collected yet.


What is the distinguishing feature of an active record? What is the
problem if you get back a reference to an inactive record? And if there is
indeed a problem, don't you already have a race condition on CPython?

1. Record is active;
2. Get reference to record through weak ref;
3. Record becomes inactive;
4. Start trying to use the (now inactive) record.

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Ethan Furman]

Ian Kelly wrote:

On Wed, May 16, 2012 at 3:33 PM, 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 if so
not hit the disk to get the data;  with PyPy (and probably the others) this
doesn't work because the record may still be around even when it is no
longer active because it hasn't been garbage collected yet.

For PyPy I can use `'PyPy' in sys.version` to set a constant
(REFRESH_FROM_DISK in this case) to disable the cPython optimization; does
anyone know what strings to look for for the other implementations?


Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)] on win32
Type help, copyright, credits or license for more information.

import sys
sys.subversion

('CPython', 'tags/r271', '86832')

Jython 2.5.2 (Release_2_5_2:7206, Mar 2 2011, 23:12:06)
[Java HotSpot(TM) Client VM (Sun Microsystems Inc.)] on java1.6.0_31
Type help, copyright, credits or license for more information.

import sys
sys.subversion

('Jython', 'tags/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] != 'CPython':
...

Hopefully all the others do have it defined (PyPy does, at least as of 1.8).

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

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

[Ethan Furman]

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 so not hit the disk to get the data;  with
PyPy (and probably the others) this doesn't work because the record
may still be around even when it is no longer active because it
hasn't been garbage collected yet.



What is the distinguishing feature of an active record? What is the 
problem if you get back a reference to an inactive record? And if there 
is indeed a problem, don't you already have a race condition on CPython?


1. Record is active;
2. Get reference to record through weak ref;
3. Record becomes inactive;
4. Start trying to use the (now inactive) record.


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 because I am frequently moving data from one table to another, 
making changes to the old record contents before creating the new record 
with the changes -- since I do not call .write_record() on the old 
record those changes do not get backed up to disk.


With CPython as soon as a record goes out of scope it dies, and the next 
time I try to access that record I will get the disk version, without 
the temporary changes I had made earlier (this is good).  However, with 
PyPy (and others) not all records are destroyed before I try to access 
them again, and I end up seeing the temp data instead of the disk data.


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico]

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
 because I am frequently moving data from one table to another, making
 changes to the old record contents before creating the new record with the
 changes -- since I do not call .write_record() on the old record those
 changes do not get backed up to disk.

I strongly recommend being more explicit about usage and when it gets
written and re-read, rather than relying on garbage collection.
Databasing should not be tied to a language's garbage collection.
Imagine you were to reimplement the equivalent logic in some other
language - could you describe it clearly? If so, then that's your
algorithm. If not, you have a problem.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Tim Delaney]

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 not reflected on disk until .write_record() is called;  I do this
  because I am frequently moving data from one table to another, making
  changes to the old record contents before creating the new record with
 the
  changes -- since I do not call .write_record() on the old record those
  changes do not get backed up to disk.

 I strongly recommend being more explicit about usage and when it gets
 written and re-read, rather than relying on garbage collection.
 Databasing should not be tied to a language's garbage collection.
 Imagine you were to reimplement the equivalent logic in some other
 language - could you describe it clearly? If so, then that's your
 algorithm. If not, you have a problem.


Agreed. To me, this sounds like a perfect case for with: blocks and
explicit reference counting.  Something like (pseudo-python - not runnable):

class Record:
def __init__(self):
self.refs = 0
self.lock = threading.Lock()

def __enter__(self):
with self.lock:
self.refs += 1

def __exit__(self):
with self.lock:
self.refs -=1

if self.refs == 0:
self.write_record()

rest of Record class

rec = record_weakrefs.get('record_name')

if rec is None:
rec = load_record()
record_weakrefs.put('record_name', rec)

with rec:
do_stuff

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Ethan Furman]

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() is called;  I do this
because I am frequently moving data from one table to another, making
changes to the old record contents before creating the new record with the
changes -- since I do not call .write_record() on the old record those
changes do not get backed up to disk.


I strongly recommend being more explicit about usage and when it gets
written and re-read, rather than relying on garbage collection.
Databasing should not be tied to a language's garbage collection.
Imagine you were to reimplement the equivalent logic in some other
language - could you describe it clearly? If so, then that's your
algorithm. If not, you have a problem.


Yeah, I've been thinking about this for a couple hours now;  initially 
(way back when) I didn't want to keep hitting the disk unnecessarily 
-- but all my other supporting data structures go to great lengths to 
not keep records in memory unless the user has them explicitly named or 
contained... I think I've been fighting against myself!  Good news is 
I'm winning.  ;)


~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

[issue7071] distutils and IronPython compatibility

[Éric Araujo]

É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 the 
version number.  I should be able to get Mono and IronPython in a few weeks or 
months and see how much issues there are in distutils and distutils2.)

--
nosy: +eric.araujo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7071
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Unable to make ironpython run in browser with silverlight

[ErichCart ErichCart]

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
  src=http://gestalt.ironpython.net/dlr-20100305.js;/
script
  script type=text/python src=http://github.com/jschementi/
pycon2010/raw/master/repl.py/script
  /head
  body
script type=text/python
  window.Alert(Hello from Python!)
/script

  /body
/html

And in fact, it does, for example here: 
http://ironpython.net/browser/examples/pycon2010/start.html

You will see it if you have silverlight installed.

But the problem is that when I try to make the same code run on my PC,
I can't do it. I create a text file, copy this code there, save it as
test.html, and run with firefox, but nothing happens. Code does not
execute, i just get a blank page. I can't understand the reason why
the same code runs here: 
http://ironpython.net/browser/examples/pycon2010/start.html,
but not on my PC, given that it is a client side code, and not the
server side.

And there is nothing written in firefox error console, when I run it
locally.
But if I host it on my webhosting account, then I get this error:

Error: uncaught exception: [Exception... Component returned failure
code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.send]
nsresult: 0x80004005 (NS_ERROR_FAILURE) location: JS frame :: http://
sitename .com/silverlighttest.html :: DLR_DownloadResource :: line 15
data: no]

I uploaded the html file I am using here: 
http://www.filedropper.com/silverlighttest
But it just a text file with that code with extension changed
to .html.

What can I do?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unable to make ironpython run in browser with silverlight

[ErichCart ErichCart]

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

[Jimmy Schementi]

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

[Sunny]

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: http://silverlighttest.zzl.org/silverlighttest.html , it
runs from a web server, but still gives error.
And it has the same source code as your example, except that I replace
repl.py with the direct link, as you advise on your blog.

I think the problem is with this part:
script type=text/python src=http://github.com/jschementi/pycon2010/
raw/master/repl.py/script

Because when I delete it, it runs properly.

Do you know why is that?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unable to make ironpython run in browser with silverlight

[ErichCart ErichCart]

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: http://silverlighttest.zzl.org/silverlighttest.html , it
runs from a web server, but still gives error.
And it has the same source code as your example, except that I replace
repl.py with the direct link, as you advise on your blog.

I think the problem is with this part:
script type=text/python src=http://github.com/jschementi/
pycon2010/
raw/master/repl.py/script

Because when I delete it, it runs properly.

Do you know why is that?
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: [IronPython] IronPython 2.7 Now Available

[Medcoff, Charles]

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

[Dino Viehland]

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 like HPC 
support) or we'll pull the IpyTools out of the distribution and encourage 
people to go for the separate download.  No changes will likely happen until 
IronPython 3.x though as 2.7 is now out the door and it'd be a pretty 
significant change.

For the time being you'll need to choose one or the other - you can always 
choose to not by either not installing the IpyTools w/ the IronPython install 
and install the PTVS or you can just stick w/ the existing IronPython tools.

 -Original Message-
 From: users-boun...@lists.ironpython.com [mailto:users-
 boun...@lists.ironpython.com] On Behalf Of Medcoff, Charles
 Sent: Sunday, March 13, 2011 2:15 PM
 To: Discussion of IronPython; python-list
 Subject: 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?
 ___
 Users mailing list
 us...@lists.ironpython.com
 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: [IronPython] IronPython 2.7 Now Available

[Medcoff, Charles]

Thanks that helps. I've tried the first option. Not doing much Python stuff at 
the moment, but I'll follow up if I experience any issues with this approach.

I'm very excited that both the language and tools support is forging ahead - 
thanks all.

-Original Message-
From: users-boun...@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 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 like HPC 
support) or we'll pull the IpyTools out of the distribution and encourage 
people to go for the separate download.  No changes will likely happen until 
IronPython 3.x though as 2.7 is now out the door and it'd be a pretty 
significant change.

For the time being you'll need to choose one or the other - you can always 
choose to not by either not installing the IpyTools w/ the IronPython install 
and install the PTVS or you can just stick w/ the existing IronPython tools.

 -Original Message-
 From: users-boun...@lists.ironpython.com [mailto:users- 
 boun...@lists.ironpython.com] On Behalf Of Medcoff, Charles
 Sent: Sunday, March 13, 2011 2:15 PM
 To: Discussion of IronPython; python-list
 Subject: 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?
 ___
 Users mailing list
 us...@lists.ironpython.com
 http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
___
Users mailing list
us...@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-- 
http://mail.python.org/mailman/listinfo/python-list

IronPython 2.7 Now Available

[Jeff Hardy]

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 IronPython Tools for Visual Studio. IronPython
2.7 requires .NET 4.0 or Silverlight 4.

To download IronPython 2.7, visit
http://ironpython.codeplex.com/releases/view/54498. Any bugs should be
reported at http://ironpython.codeplex.com/workitem/list/basic.

Python 2.7 includes a number of features backported from the Python
3.0 series. This release implements the new builtin _io module,
includes dictionary and set comprehensions, set literals, supports
multiple context managers in the with statement, and adds several new
functions to the itertools methods, and auto indexing for the new
string formatting. There are also numerous updates to the standard
library such as ordered dictionaries and the new argparse module.

This release also includes a “IronPython Tools for Visual Studio”
option within the IronPython installer. This enables one install to
get both IronPython and IronPython Visual Studio support assuming you
have an existing installation of Visual Studio 2010. This version of
IronPython Tools includes a number of bug fixes as improved WPF
designer support. The designer fully supports XAML and WPF including
data binding to Python classes dynamically.

To improve interop with modern .NET code such as LINQ, support for
extension methods has been added as the clr.ImportExtensions method.

We’ve also updated the IronPython installer to include documentation
based upon the CPython documentation. This new .chm file includes
documentation on the Python language and standard library. It’s been
extended from the normal Python documentation to include IronPython
specific topics such as the DLR hosting APIs and extending IronPython
from statically typed .NET languages.

We flushed out more support for missing built-in modules which CPython
includes. This release includes the mmap and signal modules bringing
better support for interoperating with unmanaged code, the zlib and
gzip modules for compression, and the subprocess and webbrowser
modules for interacting with other programs.

As usual there are a number of bug fixes and performance improvements.
This release includes major performance improvements in cPickle, the
sum built-in function, and includes support for fast exceptions which
do not use the .NET exception mechanism. There have also been
improvements to significantly reduce memory usage of the IronPython
ASTs. One of the end results of these numerous improvements is that
IronPython’s startup time has decreased by 10% when compared to
IronPython 2.6.1.

This is the first full community release of IronPython, and I want to
give a huge thank you to everyone who was involved in this release.

- Jeff
-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Éric Araujo]

É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 IronPython 2.x version
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Frederic Torres]

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
m...@egenix.com based on the comment in the file platform.py.

It will affect IronPython 2.6 and  IronPython 2.6 For .Net 4.0 and
probably IronPython 2.7.

If you give me linsk to read about how to make a patch I would really
like to contribute to IronPython.

Thanks.
Fred.

On Wed, Dec 22, 2010 at 4:02 AM, Éric Araujo rep...@bugs.python.org wrote:

 É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 IronPython 2.x version
 versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

 ___
 Python tracker rep...@bugs.python.org
 http://bugs.python.org/issue8964
 ___


--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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: http://www.python.org/dev/patches/

In short: check out the py3k branch, add a test that fails in 
Lib/test/test_platform.py (in the test_sys_version method), then patch the code 
to make the test pass.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Microsoft lessening commitment to IronPython and IronRuby

[Jason Earl]

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?

 http://www.mono-project.com/Main_Page

 Anyone thinking of using Mono needs to be aware of the dangers of
 software patents in general, and of .NET in paticular.

 The copyright license for Mono is under free software terms. But that
 gives no license at all for the patents. Novell, who have an exclusive
 deal for those patents, happily encourages use of Mono by third
 parties.

 The controversy has raged for a number of years. For more coverage
 than you have time for, see
 URL:http://techrights.org/wiki/index.php/Mono.  The issue has
 polarised discussion, unfortunately, and there is a lot of
 name-calling and hyperbole on the record now.

 As the Mono site hints, the patent situation for .NET is *very* muddy.
 Microsoft hold patents covering much of .NET, but have made a
 (non-binding) “Community Promise” that applies to *some* parts of .NET
 URL:http://www.mono-project.com/Licensing#Patents.

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.
So where is the promise from Microsoft saying that they won't sue the
Python development team into oblivion, or Python end users, for that
matter?

There isn't one.

So while the Mono promise doesn't cover all of Mono, it does cover
*some* of Mono, which is better than what Python can say.  If you happen
to be believe that Microsoft is likely to attack Free Software via
patents then Mono is arguably the safest choice.  Especially if you
confine yourself to the ECMA-sponsored core and the Free Software
libraries that are not re-implementations of Microsoft's technology.

Jason
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Ben Finney]

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 sued, at any time, for anything. And
any program can, because of the crazy patent system in many countries,
be infringing any (usually large) number of software idea patent claims,
without the programmers having done anything unusual to cause that
situation.

Microsoft, or any other party for that matter, very well may have any
number of software idea patents that could be interpreted to cover
Python's code.

The main difference in the case of Mono is that Microsoft has widely and
repeatedly asserted that such patents do exist, their assertions seem
quite plausible since they wrote the specifications on which Mono is
implemented, its “Community Promise” very carefully does *not* grant any
kind of binding permission to implement or use software ideas from those
patents, and it has consistently wielded other such patents aggressively
and maintains the willingness to continue to do so.

None of that is true for Python. Which is why people aren't saying
Python is a patent trap, but rather that Mono is.

-- 
 \“Most people, I think, don't even know what a rootkit is, so |
  `\ why should they care about it?” —Thomas Hesse, Sony BMG, 2006 |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Tim Roberts]

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.  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.

In the end, it seemed to me that writing an IronPython program was mostly
an exercise of writing it in C# and then translating.  .NET is just too
tuned for C# and VB.  Although IronPython was a good fit, it was just not
a great fit.
-- 
Tim Roberts, t...@probo.com
Providenza  Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Lawrence D'Oliveiro]

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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Stefan Behnel]

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 thing which was ever done in Dotnet.


Erm, this is Microsoft. It's not about being creative, it's about selling 
stuff to users.


Stefan

--
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Gregory Ewing]

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.


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?

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Steven D'Aprano]

On Tue, 10 Aug 2010 18:42:35 +1200, Lawrence D'Oliveiro wrote:

 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.

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/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Steven D'Aprano]

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
 comfortable in those languages tap into the CLR.
 
 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



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Stefan Behnel]

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 statement:

Resolver One is Windows only

This sounds like a major drawback to me. It might be an acceptable early 
project priority if the app is only targeting the desktop, but this system 
additionally claims to be a web-accessible spreadsheet. If this is 
supposed to run on a server, it means that it will always suffer from the 
headless click-here-to-continue problem.


It might not be too hard to port the app to Mono, but the rather explicit 
claim above doesn't make me feel very comfortable about that upgrade path...


Stefan

--
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Ben Finney]

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

Anyone thinking of using Mono needs to be aware of the dangers of
software patents in general, and of .NET in paticular.

The copyright license for Mono is under free software terms. But that
gives no license at all for the patents. Novell, who have an exclusive
deal for those patents, happily encourages use of Mono by third parties.

The controversy has raged for a number of years. For more coverage than
you have time for, see URL:http://techrights.org/wiki/index.php/Mono.
The issue has polarised discussion, unfortunately, and there is a lot of
name-calling and hyperbole on the record now.

As the Mono site hints, the patent situation for .NET is *very* muddy.
Microsoft hold patents covering much of .NET, but have made a
(non-binding) “Community Promise” that applies to *some* parts of .NET
URL:http://www.mono-project.com/Licensing#Patents.

-- 
 \“It is seldom that liberty of any kind is lost all at once.” |
  `\   —David Hume |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Michael Torrie]

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 in those languages tap into the CLR.
 
 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?

Well the only way for a non-.net program to access a .NET library is to
either embed .NET or use some kind of bridge via RPC.

So basically, the answer is no.  You pretty much have to embrace .NET
or not use it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Microsoft lessening commitment to IronPython and IronRuby

[Lawrence D'Oliveiro]

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 in the modern world of
dynamic languages. Looks like it was a failure. Yawn.
-- 
http://mail.python.org/mailman/listinfo/python-list

Microsoft lessening commitment to IronPython and IronRuby

[Neil Hodgson]

   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]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Where is StackPanel in IronPython / .Net 4?

[Ian Hobson]

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 on the line that reads

clr.AddReference('System.Windows.Controls')

Can anyone shed light on what is going wrong?

Many thanks

Ian
--
http://mail.python.org/mailman/listinfo/python-list

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

[Benjamin Kaplan]

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 Namespace I get a Could not add
 reference to assembly
 System.Windows.Controls error on the line that reads

 clr.AddReference('System.Windows.Controls')

 Can anyone shed light on what is going wrong?

 Many thanks

 Ian
 --

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
Assembly:  PresentationFramework (in PresentationFramework.dll)
'''

So you would do
clr.AddReference(PresentationFramework)
import System.Windows.Controls

 http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Ian]

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
Assembly:  PresentationFramework (in PresentationFramework.dll)
'''

So you would do
clr.AddReference(PresentationFramework)
import System.Windows.Controls

   

I tried
from System.Windows.Controls import StackPanel
and it worked fine.

Now I need  VerticalAlignment.Top

From 
http://msdn.microsoft.com/en-us/library/system.windows.verticalalignment%28v=VS.95%29.aspx 
I learn that

this is in the VerticalAlignment Enumeration

Quote
*Namespace:* System.Windows 
http://msdn.microsoft.com/en-us/library/system.windows%28v=VS.95%29.aspx

*Assembly:* System.Windows (in System.Windows.dll)
  ^^^
End quote

So I write

clr.AddReference('System.Windows')

and it errors - Could not add reference to System.Windows

So clearly I still don't understand something rather basic.

More help please.

Thanks

Ian

-- 
http://mail.python.org/mailman/listinfo/python-list

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

[Frederic Torres]

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 is that with previous version of IronPython this was not the case

--
title: Method _sys_version() module Lib\platform.py does parse  correctly 
IronPython 2.x version - Method _sys_version() module Lib\platform.py does not 
parse correctly IronPython 2.x version

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Marc-Andre Lemburg]

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 number and (
 2.6.1 (IronPython 2.6.1 (2.6.10920.0) on .NET 4.0.30319.1)
 
 File: Lib\platform.py
 Function: def _sys_version(sys_version=None):
 Line: 1326

I assume you meant: doesn't correctly parse the version number.

Could you provide a complete example formatted as Python string,
e.g. print repr(sys.version) ?!

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com


2010-07-19: EuroPython 2010, Birmingham, UK38 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/

--
title: Method _sys_version() module Lib\platform.py does parse correctly 
IronPython 2.x version - Method _sys_version() module Lib\platform.py does 
parse  correctly IronPython 2.x version

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8964
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Announcing IronPython 2.6.1

[David DiCato]

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 before and during the RC phase, along with the 
simultaneous release of .NET 4.0, this has become a very exciting release for 
all of us.

IronPython 2.6.1 comes in two flavors - one that runs on top of .NET 4.0, and 
one that runs on any earlier framework starting with .NET 2.0 SP1. They can 
both be downloaded at http://ironpython.codeplex.com/releases/view/36280.

We'd like to place a particular emphasis on the .NET 4.0 flavor of IronPython 
2.6.1 and encourage all of you to try it out. It has a number of advantages 
over the 2.0 version, some of which Dave discusses on his blog at 
http://knowbody.livejournal.com/20751.html. These include faster startup time, 
compatibility with C#'s new dynamic keyword, and access to the numerous new 
features present in the updated Framework. The final release of Microsoft .NET 
Framework 4.0 is publically available as of today, and is required for this 
flavor of IronPython 2.6.1. Download it here: 
http://www.microsoft.com/downloads/details.aspx?FamilyID=9cfb2d51-5ff4-4491-b0e5-b386f32c0992displaylang=en

The IronPython 2.6.1 RC included fixes for well over 50 bugs, large and small. 
Ctypes has had a number of significant updates, including union support, 
variant_bool, and wintypes. Another focus has been on sys.settrace, making 
debugging more reliable. For example, sys.settrace now returns the correct 
frame, supports tracing through modules, and no longer interferes with import 
os. Other notable fixes include thread-safe importing, and the missing error 
code in _winreg exception.

In addition, we've made a substantial improvement in import time. Not only does 
this reduce startup time, but it can speed up the importing of large, 
definition-heavy modules by up to 50%.

As you might imagine, the .NET 4.0 flavor of IronPython 2.6.1 RC has a few of 
its own changes designed for better interoperability with the framework. These 
include fixing some errors with Func and better runtime isolation when 
similarly-named assemblies in different locations are loaded in multiple 
engines. In addition, both the .NET 2.0 and .NET 4.0 builds support the new 
.NET 4.0 IStructuralEquatable and IStructuralComparable interfaces and maps 
them to the  appropriate operations (__eq__, __hash__, __gt__, etc.). In the 
case of .NET 4.0, this replaces IValueEquality as the gold standard for 
defining equality in an interop-friendly manner. In the .NET 2.0 build, these 
interfaces are copied so that their use can be phased in while retaining 
IValueEquality for backwards compatibility.

Since the RC, we have fixed numerous other issues, as well as adding CPython's 
ssl.py to our distribution. We've also made some major unicode-related changes 
in response to your feedback on the mailing list, changes that improve 
compatibility with certain third-party applications including Django. In 
particular, invoking unicode() or using unicode string formatting will now call 
__unicode__() first if it is present on the object. Finally, we've included a 
new code sample that shows how to use  __clrtype__ to create custom CLR classes 
from IronPython. This sample is a sneak preview of what we expect will become a 
fully supported IronPython module, so we encourage anyone who is so inclined to 
try it out and let us know how it goes.

Special thanks to Albert Szilvasy, amajorek, cendalc, clovery, egonw_, Eloff, 
essey, fabiofz, gjones, gpgemini, Haibo Luo, igalse, jazzcat, jdhardy, jlunder, 
JustinCle, klrohe, László de Almásy, laughingboy, lbaker, Lukas Cenovsky, 
marten_range, olav, paulfelix, pl6306, razam, roinet, russomf, sanxiyn, 
see_toronto at web dot de, Thomas Heller, variant77, vernondcole, William 
Reade, and Wolfram for reporting issues and making this a great release. Happy 
scripting!

- The IronPython Team

-- 
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/