From sanxiyn at gmail.com  Mon May  1 06:37:19 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Mon, 1 May 2006 13:37:19 +0900
Subject: [IronPython] Regex incompatibility
Message-ID: <5b0248170604302137i73715d50ld41a566e26f57e62@mail.gmail.com>

# test.py
import re
m = re.match('(?P<test>a)(b)', 'ab')
print m.groups()

# CPython
('a', 'b')

# IronPython
('b', 'a')

Seo Sanghyeon


From sanxiyn at gmail.com  Mon May  1 11:56:50 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Mon, 1 May 2006 18:56:50 +0900
Subject: [IronPython] socket for IronPython update
Message-ID: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>

I updated socket for IronPython modules again:
http://sparcs.kaist.ac.kr/~tinuviel/fepy/lib/

Changes since the last update, which was ssl.py, are:
* Implement sendto()
* Fix a bug in close()
* Implement functions to deal with IP addresses (inet_aton/inet_ntoa)
* Add select module

Now you need to download 3 files: socket.py, ssl.py and select.py. I
will think about making a proper release in the future.

Seo Sanghyeon


From sanxiyn at gmail.com  Mon May  1 12:53:16 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Mon, 1 May 2006 19:53:16 +0900
Subject: [IronPython] None as a dictionary key
Message-ID: <5b0248170605010353w42fbab80n67d305a8f1745a4b@mail.gmail.com>

# test.py
d = {}
d[None, 1] = 2

# IronPython
SystemError: Object reference not set to an instance of an object.

Seo Sanghyeon


From dinov at exchange.microsoft.com  Mon May  1 17:27:43 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 1 May 2006 08:27:43 -0700
Subject: [IronPython] None as a dictionary key
In-Reply-To: <5b0248170605010353w42fbab80n67d305a8f1745a4b@mail.gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E02ADE24C@df-foxhound-msg.exchange.corp.microsoft.com>

Ahh, we missed that corner case.  Great bug, thanks for keeping these coming.  We'll get this one fixed for beta 7.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Monday, May 01, 2006 3:53 AM
To: Discussion of IronPython
Subject: [IronPython] None as a dictionary key

# test.py
d = {}
d[None, 1] = 2

# IronPython
SystemError: Object reference not set to an instance of an object.

Seo Sanghyeon
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Mon May  1 17:29:03 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 1 May 2006 08:29:03 -0700
Subject: [IronPython] Regex incompatibility
In-Reply-To: <5b0248170604302137i73715d50ld41a566e26f57e62@mail.gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E02ADE24E@df-foxhound-msg.exchange.corp.microsoft.com>

Thanks for the bug report.  I've got this one filed although I'm not sure if we'll get it fixed for beta 7 or not - it may be a little more involved depending on exactly what's going wrong here.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Sunday, April 30, 2006 9:37 PM
To: Discussion of IronPython
Subject: [IronPython] Regex incompatibility

# test.py
import re
m = re.match('(?P<test>a)(b)', 'ab')
print m.groups()

# CPython
('a', 'b')

# IronPython
('b', 'a')

Seo Sanghyeon
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Mon May  1 17:31:40 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 1 May 2006 08:31:40 -0700
Subject: [IronPython] [Python-Dev] __getslice__ usage in sre_parse
In-Reply-To: <ca471dc20604300830i7cc814f9o183107b6e71329b2@mail.gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E02ADE24F@df-foxhound-msg.exchange.corp.microsoft.com>

I've also opened a bug for supporting __getslice__ in IronPython.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: python-dev-bounces+dinov=microsoft.com at python.org [mailto:python-dev-bounces+dinov=microsoft.com at python.org] On Behalf Of Guido van Rossum
Sent: Sunday, April 30, 2006 8:31 AM
To: Sanghyeon Seo
Cc: Discussion of IronPython; python-dev at python.org
Subject: Re: [Python-Dev] __getslice__ usage in sre_parse

On 4/28/06, Sanghyeon Seo <sanxiyn at gmail.com> wrote:
> Hello,
>
> Python language reference 3.3.6 deprecates __getslice__. I think it's
> okay that UserList.py has it, but sre_parse shouldn't use it, no?

Well, as long as the deprecated code isn't removed, there's no reason
why other library code shouldn't use it. So I disagree that
technically there's a reason why sre_parse shouldn't use it.

> __getslice__ is not implemented in IronPython and this breaks usage of
> _sre.py, a pure-Python implementation of _sre, on IronPython:
> http://ubique.ch/code/_sre/
>
> _sre.py is needed for me because IronPython's own regex implementation
> using underlying .NET implementation is not compatible enough for my
> applications. I will write a separate bug report for this.
>
> It should be a matter of removing __getslice__ and adding
> isinstance(index, slice) check in __getitem__. I would very much
> appreciate it if this is fixed before Python 2.5.

You can influence the fix yourself -- please write a patch (relative
to Python 2.5a2 that was just released), submit it to Python's patch
tracker on SourceForge (read python.org/dev first), and then sending
an email here to alert the developers. This ought to be done well
before the planned 2.5b1 release (see PEP 256 for the 2.5 release
timeline). You should make sure that the patched Python 2.5 passes all
unit tests before submitting your test.

Good luck!

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/dinov%40microsoft.com


From dinov at exchange.microsoft.com  Mon May  1 17:34:38 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 1 May 2006 08:34:38 -0700
Subject: [IronPython] unicode bug?
In-Reply-To: <44548A49.6050702@spiralcomms.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E02ADE257@df-foxhound-msg.exchange.corp.microsoft.com>

Thanks for the bug report, I've got it filed in our bug database.

I'm thinking we should be able to get to this one for beta 7 if it doesn't end up being too complex (Unicode can always be trickier than you initially expect).



Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cheemeng
Sent: Sunday, April 30, 2006 2:59 AM
To: users at lists.ironpython.com
Subject: [IronPython] unicode bug?

hi,

Sq2 = u'\xb2'
u = unicode(Sq2)
print u is Sq2

in CPython, the unicode function returns back the same str,
in IP, an exception is thrown,
UnicodeDecodeError: Unable to translate bytes [B2] at index 0 from
specified code page to Unicode.

regards,
cheemeng
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From jvm_cop at spamcop.net  Mon May  1 18:15:20 2006
From: jvm_cop at spamcop.net (J. Merrill)
Date: Mon, 01 May 2006 12:15:20 -0400
Subject: [IronPython] unicode bug?
References: <44548A49.6050702@spiralcomms.com>
Message-ID: <7.0.1.0.2.20060501120513.04440540@wheresmymailserver.com>

(This presumes that IronPython has separate string and unicode types, like CPython does.  If that's not the case, well, "never mind...")

Shouldn't it be the case that calling   typename(value)   does as little work as possible if the value is already of the specified type?  That is, it would be a shame if
    i = 5
    j = int(i)
did a lot of work to ensure that i is a valid int (within range of 32-bit integer etc).  So the sample code should not be testing to see if the already-unicode-string can be converted to a unicode string -- should it?  (That doesn't mean that there's no problem that could be demonstrated by slightly different code, like   u = unicode (Sq2 + 'hello')   for example.)

Shouldn't the error message say "from code page XXX to unicode" rather than saying "from specified code page to unicode"?  How else to know (without a lot of investigation) what code page was "specified"?

At 11:34 AM 5/1/2006, Dino Viehland wrote (in part)
>Thanks for the bug report, I've got it filed in our bug database.
>
>I'm thinking we should be able to get to this one for beta 7 if it doesn't end up being too complex (Unicode can always be trickier than you initially expect).
>
>-----Original Message-----
>From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cheemeng
>Sent: Sunday, April 30, 2006 2:59 AM
>To: users at lists.ironpython.com
>Subject: [IronPython] unicode bug?
>
>hi,
>
>Sq2 = u'\xb2'
>u = unicode(Sq2)
>print u is Sq2
>
>in CPython, the unicode function returns back the same str,
>in IP, an exception is thrown,
>UnicodeDecodeError: Unable to translate bytes [B2] at index 0 from
>specified code page to Unicode.
>
>regards,
>cheemeng


J. Merrill / Analytical Software Corp




From dinov at exchange.microsoft.com  Mon May  1 18:34:39 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 1 May 2006 09:34:39 -0700
Subject: [IronPython] unicode bug?
In-Reply-To: <7.0.1.0.2.20060501120513.04440540@wheresmymailserver.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E02ADE2C9@df-foxhound-msg.exchange.corp.microsoft.com>

The problem, as you correctely pointed out, is that we don't actually have separate data types for ASCII & Unicode strings - we only have Unicode strings.

Therefore when you ask for a Unicode string from an ASCII string we have to do some magic to figure out whether you're using your string as a byte array that contains the bytes for a Unicode string, or if you're using your string as a Unicode string and we need to return you back the original string.

I agree w/ you that the error message could be better - my guess would be that the "specified code page" here is ASCII but that really is just a guess.  And if I'm guessing I'm betting most other people won't know what's going on either :).



Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of J. Merrill
Sent: Monday, May 01, 2006 9:15 AM
To: Discussion of IronPython
Subject: Re: [IronPython] unicode bug?

(This presumes that IronPython has separate string and unicode types, like CPython does.  If that's not the case, well, "never mind...")

Shouldn't it be the case that calling   typename(value)   does as little work as possible if the value is already of the specified type?  That is, it would be a shame if
    i = 5
    j = int(i)
did a lot of work to ensure that i is a valid int (within range of 32-bit integer etc).  So the sample code should not be testing to see if the already-unicode-string can be converted to a unicode string -- should it?  (That doesn't mean that there's no problem that could be demonstrated by slightly different code, like   u = unicode (Sq2 + 'hello')   for example.)

Shouldn't the error message say "from code page XXX to unicode" rather than saying "from specified code page to unicode"?  How else to know (without a lot of investigation) what code page was "specified"?

At 11:34 AM 5/1/2006, Dino Viehland wrote (in part)
>Thanks for the bug report, I've got it filed in our bug database.
>
>I'm thinking we should be able to get to this one for beta 7 if it doesn't end up being too complex (Unicode can always be trickier than you initially expect).
>
>-----Original Message-----
>From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Cheemeng
>Sent: Sunday, April 30, 2006 2:59 AM
>To: users at lists.ironpython.com
>Subject: [IronPython] unicode bug?
>
>hi,
>
>Sq2 = u'\xb2'
>u = unicode(Sq2)
>print u is Sq2
>
>in CPython, the unicode function returns back the same str,
>in IP, an exception is thrown,
>UnicodeDecodeError: Unable to translate bytes [B2] at index 0 from
>specified code page to Unicode.
>
>regards,
>cheemeng


J. Merrill / Analytical Software Corp


_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From redmoon17 at gmail.com  Tue May  2 09:01:19 2006
From: redmoon17 at gmail.com (Chu Kevin)
Date: Tue, 2 May 2006 15:01:19 +0800
Subject: [IronPython] socket for IronPython update
In-Reply-To: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>
References: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>
Message-ID: <41d7f4a90605020001l7318aedbt5d4e0d85b9092dff@mail.gmail.com>

I always wish that IronPython can run Zope/Plone.
a importance module is socket,but your socket still not run sample
network application eg: edna

2006/5/1, Sanghyeon Seo <sanxiyn at gmail.com>:
> I updated socket for IronPython modules again:
> http://sparcs.kaist.ac.kr/~tinuviel/fepy/lib/
>
> Changes since the last update, which was ssl.py, are:
> * Implement sendto()
> * Fix a bug in close()
> * Implement functions to deal with IP addresses (inet_aton/inet_ntoa)
> * Add select module
>
> Now you need to download 3 files: socket.py, ssl.py and select.py. I
> will think about making a proper release in the future.
>
> Seo Sanghyeon
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From sanxiyn at gmail.com  Tue May  2 09:04:21 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 2 May 2006 16:04:21 +0900
Subject: [IronPython] socket for IronPython update
In-Reply-To: <41d7f4a90605020001l7318aedbt5d4e0d85b9092dff@mail.gmail.com>
References: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>
	<41d7f4a90605020001l7318aedbt5d4e0d85b9092dff@mail.gmail.com>
Message-ID: <5b0248170605020004k3430c3f7n907608e1f5276a1e@mail.gmail.com>

2006/5/2, Chu Kevin <redmoon17 at gmail.com>:
> I always wish that IronPython can run Zope/Plone.
> a importance module is socket, but your socket still not run sample
> network application eg: edna

What is edna and where can I download it?

I currently test my socket.py against SimpleHTTPServer in Python
Standard Library, CherryPy (in progress), and dnspython for UDP
support.

Seo Sanghyeon


From anders.olme at gmail.com  Tue May  2 09:55:12 2006
From: anders.olme at gmail.com (Anders Olme)
Date: Tue, 2 May 2006 09:55:12 +0200
Subject: [IronPython] socket for IronPython update
In-Reply-To: <5b0248170605020004k3430c3f7n907608e1f5276a1e@mail.gmail.com>
References: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>
	<41d7f4a90605020001l7318aedbt5d4e0d85b9092dff@mail.gmail.com>
	<5b0248170605020004k3430c3f7n907608e1f5276a1e@mail.gmail.com>
Message-ID: <e3b9ef850605020055w19f87794scce34507200c89b4@mail.gmail.com>

Hello,

I found this edna on sourceforge <http://edna.sourceforge.net/> don't know
if it is the right edna though..

BRG Anders Olme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060502/9d2cb52b/attachment.html>

From sanxiyn at gmail.com  Tue May  2 09:55:24 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 2 May 2006 16:55:24 +0900
Subject: [IronPython] Time since the epoch
Message-ID: <5b0248170605020055g2d6747baya099b967c9ae83fc@mail.gmail.com>

Hello,

Python library reference 6.11 says, "The epoch is the point where the
time starts. On January 1st of that year, at 0 hours, the "time since
the epoch'' is zero. For Unix, the epoch is 1970."

To me this seems to suggest that the epoch may vary among platforms
and implementations as long as it's consistent. Am I correct?

For example, does it make sense to file bug reports to Python projects
assuming that time.time() returns seconds since the Unix epoch?

I am asking because currently Python and IronPython returns very
different values for time.time() even if they run on the same computer
and at the same time.

Seo Sanghyeon


From sanxiyn at gmail.com  Tue May  2 09:58:03 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 2 May 2006 16:58:03 +0900
Subject: [IronPython] socket for IronPython update
In-Reply-To: <e3b9ef850605020055w19f87794scce34507200c89b4@mail.gmail.com>
References: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>
	<41d7f4a90605020001l7318aedbt5d4e0d85b9092dff@mail.gmail.com>
	<5b0248170605020004k3430c3f7n907608e1f5276a1e@mail.gmail.com>
	<e3b9ef850605020055w19f87794scce34507200c89b4@mail.gmail.com>
Message-ID: <5b0248170605020058y39521427x45d5964419f6aba9@mail.gmail.com>

2006/5/2, Anders Olme <anders.olme at gmail.com>:
> I found this edna on sourceforge <http://edna.sourceforge.net/> don't know
> if it is the right edna though..

Yeah, already found it and experimented with it. It actually runs with
my socket module and a tiny patch. See my "time since the epoch" post
for an interesting problem edna discovered.

Seo Sanghyeon


From sanxiyn at gmail.com  Tue May  2 11:55:25 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 2 May 2006 18:55:25 +0900
Subject: [IronPython] os.stat doesn't return time values in seconds
Message-ID: <5b0248170605020255l74845291r3388d76c84e75fbf@mail.gmail.com>

# test.py
import os, time
name = "newfile"
f = open(name, "w")
f.close()
t = time.time()
mt = os.stat(name).st_mtime
print t, mt

Expected result: t and mt doesn't differ by more than 1.

Attached patch fixes the problem.

Seo Sanghyeon
-------------- next part --------------
--- IronPython/Modules/nt.cs.orig	2006-04-18 14:23:18.000000000 +0900
+++ IronPython/Modules/nt.cs	2006-05-02 18:51:08.000000000 +0900
@@ -297,7 +297,8 @@
 
         [PythonType("stat_result")]
         public class StatResult {
-            internal long mode, ino, dev, nlink, uid, gid, size, atime, mtime, ctime;
+            internal long mode, ino, dev, nlink, uid, gid, size;
+            internal double atime, mtime, ctime;
 
             public StatResult() {
             }
@@ -316,13 +317,13 @@
                 this.ctime = ctime;
             }
 
-            public long StatATime {
+            public double StatATime {
                 [PythonName("st_atime")]
                 get {
                     return atime;
                 }
             }
-            public long StatCTime {
+            public double StatCTime {
                 [PythonName("st_ctime")]
                 get {
                     return ctime;
@@ -352,7 +353,7 @@
                     return mode;
                 }
             }
-            public long StatMTime {
+            public double StatMTime {
                 [PythonName("st_mtime")]
                 get {
                     return mtime;
@@ -401,9 +402,9 @@
             StatResult sr = new StatResult();
 
             try {
-                sr.atime = Directory.GetLastAccessTime(path).Ticks;
-                sr.ctime = Directory.GetCreationTime(path).Ticks;
-                sr.mtime = Directory.GetLastWriteTime(path).Ticks;
+                sr.atime = Directory.GetLastAccessTime(path).Ticks / 1.0e7;
+                sr.ctime = Directory.GetCreationTime(path).Ticks / 1.0e7;
+                sr.mtime = Directory.GetLastWriteTime(path).Ticks / 1.0e7;
 
                 if (Directory.Exists(path)) {
                     sr.mode = 0x4000;

From dinov at exchange.microsoft.com  Tue May  2 17:21:09 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 2 May 2006 08:21:09 -0700
Subject: [IronPython] os.stat doesn't return time values in seconds
In-Reply-To: <5b0248170605020255l74845291r3388d76c84e75fbf@mail.gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E02BE8B5F@df-foxhound-msg.exchange.corp.microsoft.com>

Thanks for the bug report, we'll fix this for beta 7.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Tuesday, May 02, 2006 2:55 AM
To: Discussion of IronPython
Subject: [IronPython] os.stat doesn't return time values in seconds

# test.py
import os, time
name = "newfile"
f = open(name, "w")
f.close()
t = time.time()
mt = os.stat(name).st_mtime
print t, mt

Expected result: t and mt doesn't differ by more than 1.

Attached patch fixes the problem.

Seo Sanghyeon


From xmlhacker at gmail.com  Tue May  2 20:04:43 2006
From: xmlhacker at gmail.com (M. David Peterson)
Date: Tue, 2 May 2006 12:04:43 -0600
Subject: [IronPython] socket for IronPython update
In-Reply-To: <5b0248170605020004k3430c3f7n907608e1f5276a1e@mail.gmail.com>
References: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>
	<41d7f4a90605020001l7318aedbt5d4e0d85b9092dff@mail.gmail.com>
	<5b0248170605020004k3430c3f7n907608e1f5276a1e@mail.gmail.com>
Message-ID: <eab75e160605021104x6cc03209gd750341e6dce97a9@mail.gmail.com>

Do you have CherryPy running via IronPython?

I've copied Sylvain Hellegouarch, one of the CP project developers as
I know he has had this on his list of things to get working.

There's a lot of folks, including myself, that  would LOVE to see CP
running via IronPython...  Sylvain, it seems that maybe Seo and you
could compare notes?  I'd love to help where I can.... just not quite
sure where/what work needs to be done.

On 5/2/06, Sanghyeon Seo <sanxiyn at gmail.com> wrote:
> 2006/5/2, Chu Kevin <redmoon17 at gmail.com>:
> > I always wish that IronPython can run Zope/Plone.
> > a importance module is socket, but your socket still not run sample
> > network application eg: edna
>
> What is edna and where can I download it?
>
> I currently test my socket.py against SimpleHTTPServer in Python
> Standard Library, CherryPy (in progress), and dnspython for UDP
> support.
>
> Seo Sanghyeon
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

From sh at defuze.org  Tue May  2 20:27:35 2006
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Tue, 02 May 2006 19:27:35 +0100
Subject: [IronPython] socket for IronPython update
In-Reply-To: <eab75e160605021104x6cc03209gd750341e6dce97a9@mail.gmail.com>
References: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>	
	<41d7f4a90605020001l7318aedbt5d4e0d85b9092dff@mail.gmail.com>	
	<5b0248170605020004k3430c3f7n907608e1f5276a1e@mail.gmail.com>
	<eab75e160605021104x6cc03209gd750341e6dce97a9@mail.gmail.com>
Message-ID: <4457A497.4030609@defuze.org>

Hi all,

>
>
> I've copied Sylvain Hellegouarch, one of the CP project developers as
> I know he has had this on his list of things to get working.
Indeed. I've tried a few things already but I always ran into issues.
>
> There's a lot of folks, including myself, that  would LOVE to see CP
> running via IronPython...  Sylvain, it seems that maybe Seo and you
> could compare notes?  I'd love to help where I can.... just not quite
> sure where/what work needs to be done.
I'd love to check out your progress Seo and help as I can.

- Sylvain


From xmlhacker at gmail.com  Tue May  2 20:37:03 2006
From: xmlhacker at gmail.com (M. David Peterson)
Date: Tue, 2 May 2006 12:37:03 -0600
Subject: [IronPython] socket for IronPython update
In-Reply-To: <4457A497.4030609@defuze.org>
References: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>
	<41d7f4a90605020001l7318aedbt5d4e0d85b9092dff@mail.gmail.com>
	<5b0248170605020004k3430c3f7n907608e1f5276a1e@mail.gmail.com>
	<eab75e160605021104x6cc03209gd750341e6dce97a9@mail.gmail.com>
	<4457A497.4030609@defuze.org>
Message-ID: <eab75e160605021137g339b7843s78e99e1f2103d1f@mail.gmail.com>

Cool :)  Sylvain, as mentioned in IM, my lack of experience with Python
keeps me from getting too involved with bug reporting on this list as I'm
never quite sure if its my lack of experience with Python, or an actual
bug.  I'd rather not learn how to program in Python by making a fool of
myself first (if that makes sense :)

On the flip side, I can help quite a bit in developing things from the
C#/.NET side, but as mentioned in the initial email, I just need to know
where and what that is...

Between the two of you (Seo, and yourself) I'll look forward to
understanding where I can help from the above regard. :)

On 5/2/06, Sylvain Hellegouarch <sh at defuze.org> wrote:
>
> Hi all,
>
> >
> >
> > I've copied Sylvain Hellegouarch, one of the CP project developers as
> > I know he has had this on his list of things to get working.
> Indeed. I've tried a few things already but I always ran into issues.
> >
> > There's a lot of folks, including myself, that  would LOVE to see CP
> > running via IronPython...  Sylvain, it seems that maybe Seo and you
> > could compare notes?  I'd love to help where I can.... just not quite
> > sure where/what work needs to be done.
> I'd love to check out your progress Seo and help as I can.
>
> - Sylvain
>



--
<M:D/>

M. David Peterson
http://www.xsltblog.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060502/bbdd957b/attachment.html>

From sanxiyn at gmail.com  Wed May  3 03:19:55 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Wed, 3 May 2006 10:19:55 +0900
Subject: [IronPython] socket for IronPython update
In-Reply-To: <4457A497.4030609@defuze.org>
References: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>
	<41d7f4a90605020001l7318aedbt5d4e0d85b9092dff@mail.gmail.com>
	<5b0248170605020004k3430c3f7n907608e1f5276a1e@mail.gmail.com>
	<eab75e160605021104x6cc03209gd750341e6dce97a9@mail.gmail.com>
	<4457A497.4030609@defuze.org>
Message-ID: <5b0248170605021819p497fb9d3q2341d522af7d80ed@mail.gmail.com>

2006/5/3, Sylvain Hellegouarch <sh at defuze.org>:
> > I've copied Sylvain Hellegouarch, one of the CP project developers as
> > I know he has had this on his list of things to get working.
> Indeed. I've tried a few things already but I always ran into issues.

Just out of curiousity, are you using my socket.py?

My current plan is to implement settimeout() and zlib, and try again
running CP. A curious fact is that CP *does* check for presense of
settimeout() on socket in one place (and fallback), but not in other
places. Oversight?

Seo Sanghyeon


From xmlhacker at gmail.com  Wed May  3 08:57:52 2006
From: xmlhacker at gmail.com (M. David Peterson)
Date: Wed, 3 May 2006 00:57:52 -0600
Subject: [IronPython] socket for IronPython update
In-Reply-To: <5b0248170605021819p497fb9d3q2341d522af7d80ed@mail.gmail.com>
References: <5b0248170605010256u6bcde115x89505c63d4b63a94@mail.gmail.com>
	<41d7f4a90605020001l7318aedbt5d4e0d85b9092dff@mail.gmail.com>
	<5b0248170605020004k3430c3f7n907608e1f5276a1e@mail.gmail.com>
	<eab75e160605021104x6cc03209gd750341e6dce97a9@mail.gmail.com>
	<4457A497.4030609@defuze.org>
	<5b0248170605021819p497fb9d3q2341d522af7d80ed@mail.gmail.com>
Message-ID: <eab75e160605022357r15019392kee3123aef7257151@mail.gmail.com>

Hi Seo,

Let me first thank you for all of your work...  It's helped me a TON as I
attempt to both learn the Python language as well as attempt to utilize
IronPython in a couple of projects that I am working on that have been or
are in process of being developed in C#, to then utilize Python > IronPython
to extend and simplify from there.  In fact one of these projects,
AtomicRSS.NET (which is a simple binding to Microsoft's RSS/Web Feed API to
allow (hopefully) a losless two-way data exchange of Atom web feeds with the
RSS engine as well as a simple, straight forward to store and publish
content using Atom Publishing Protocol  (APP)), has a specific focus to
integrate CherryPy and Demokritos (an APP engine written by James Tauber)
via IronPython to accomplish the overall task at hand.

I mention this mainly because of the fact that it was through your work that
I passed along to Sylvain, which then through his recommendation convinced
me that this was the proper route to take with this project.  If you start
here > http://dev.extensibleforge.net/wiki/AtomicRSS.NET < and move through
to 'Evaluate' you'll notice several of your tutorials and code samples that
have peeked my interest and have made note of on the project wiki for
reference.  With all of this... Thanks!  You've been a great help and I
really appreciate.

So coming back to your questions:

re: socket.py > Yes, I do know that Sylvain has been using this, as have I.

re: the rest... Definitely a question for Sylvain.

NOTE: My current project > GlobalClip (an extension to MS's LiveClipboard
that implements a globally accessible clipboard for storing and sharing
content > http://dev.extensibleforge.net/wiki/GlobalClip < ), while the core
engine (in the repository accessible from the above link) is written in C#,
my intention is to extend from the core engine the client-side application
that implements a XAML-based GUI that ties into a local CherryPy instance
(this actually will (more than likely) be running via nuxle.us >
http://dev.extensibleforge.net/wiki/nuXle.us < Yet Another Project that
Sylvain and I are working together on) to act as a personal clipboard
repository that is accessible to any machine you give permission to access.
Your work already has, and will continue to be a part of both of these
mentioned projects...

With this in mind... I owe you a huge amount of gratitude for helping in
getting me over various issues I have run across along the way as well as
providing these modules to implement and extend from.

Thanks a TON!! :D


On 5/2/06, Sanghyeon Seo <sanxiyn at gmail.com> wrote:
>
> 2006/5/3, Sylvain Hellegouarch <sh at defuze.org>:
> > > I've copied Sylvain Hellegouarch, one of the CP project developers as
> > > I know he has had this on his list of things to get working.
> > Indeed. I've tried a few things already but I always ran into issues.
>
> Just out of curiousity, are you using my socket.py?
>
> My current plan is to implement settimeout() and zlib, and try again
> running CP. A curious fact is that CP *does* check for presense of
> settimeout() on socket in one place (and fallback), but not in other
> places. Oversight?
>
> Seo Sanghyeon
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



--
<M:D/>

M. David Peterson
http://www.xsltblog.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060503/ff94be56/attachment.html>

From sanxiyn at gmail.com  Wed May  3 18:41:26 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 4 May 2006 01:41:26 +0900
Subject: [IronPython] None == ''
Message-ID: <5b0248170605030941h2e87c10fg8cf759aa3b3893b0@mail.gmail.com>

Oh, not again...

>>> None == ''
SystemError: Object reference not set to an instance of an object

Seo Sanghyeon


From trimbo at gmail.com  Wed May  3 18:47:48 2006
From: trimbo at gmail.com (Chris Trimble)
Date: Wed, 3 May 2006 09:47:48 -0700
Subject: [IronPython] None == ''
In-Reply-To: <5b0248170605030941h2e87c10fg8cf759aa3b3893b0@mail.gmail.com>
References: <5b0248170605030941h2e87c10fg8cf759aa3b3893b0@mail.gmail.com>
Message-ID: <a5f0cf200605030947o27ae3bcx43483d37dd9cc6d2@mail.gmail.com>

On 5/3/06, Sanghyeon Seo <sanxiyn at gmail.com> wrote:
>
> Oh, not again...
>
> >>> None == ''
> SystemError: Object reference not set to an instance of an object


On the other hand

>>> '' == None
False
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060503/46013462/attachment.html>

From sanxiyn at gmail.com  Wed May  3 18:50:42 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 4 May 2006 01:50:42 +0900
Subject: [IronPython] None == ''
In-Reply-To: <a5f0cf200605030947o27ae3bcx43483d37dd9cc6d2@mail.gmail.com>
References: <5b0248170605030941h2e87c10fg8cf759aa3b3893b0@mail.gmail.com>
	<a5f0cf200605030947o27ae3bcx43483d37dd9cc6d2@mail.gmail.com>
Message-ID: <5b0248170605030950q4aa962ecy943b4f54d0943f59@mail.gmail.com>

2006/5/4, Chris Trimble <trimbo at gmail.com>:
> On the other hand
>
> >>> '' == None
> False

Indeed. It must be very tricky to get all the comparisons right.

Well, cheer up, IronPython team. If your tests make sure that old bugs
don't return, you can be assured that I will eventually find all
corner cases hidden. :-)

Seo Sanghyeon


From haiboluo at exchange.microsoft.com  Wed May  3 19:24:02 2006
From: haiboluo at exchange.microsoft.com (Haibo Luo)
Date: Wed, 3 May 2006 10:24:02 -0700
Subject: [IronPython] None == ''
In-Reply-To: <5b0248170605030950q4aa962ecy943b4f54d0943f59@mail.gmail.com>
Message-ID: <C880917115D23741B1FF3565AF50A096026D726C@df-foxhound-msg.exchange.corp.microsoft.com>

We apologize for this regression. I filed a bug for this issue again.

Just want to let you know we are actively working on rich comparison to make sure ironpython is consistent with cpython in most cases.

Thanks!

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Wednesday, May 03, 2006 9:51 AM
To: Discussion of IronPython
Subject: Re: [IronPython] None == ''

2006/5/4, Chris Trimble <trimbo at gmail.com>:
> On the other hand
>
> >>> '' == None
> False

Indeed. It must be very tricky to get all the comparisons right.

Well, cheer up, IronPython team. If your tests make sure that old bugs
don't return, you can be assured that I will eventually find all
corner cases hidden. :-)

Seo Sanghyeon
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From michael.foord at resolversystems.com  Thu May  4 19:05:02 2006
From: michael.foord at resolversystems.com (Michael Foord)
Date: Thu, 04 May 2006 18:05:02 +0100
Subject: [IronPython] Comparing Tuples Bug
Message-ID: <445A343E.1080808@resolversystems.com>

Hello all,


I'm not sure if this has already been picked up on, I realise several 
compare bugs have. My apologies if this is a dup.

CPython :

 >>> (set(),) == (set(),)
True
 >>>

IronPython-Beta6:

 >>> (set(),) == (set(),)
Traceback (most recent call last):
  File , line 0, in input##0
TypeError: cannot compare sets using cmp()
 >>>

All the best,


Michael Foord
http://www.resolversystems.com



From dinov at exchange.microsoft.com  Thu May  4 19:08:46 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 4 May 2006 10:08:46 -0700
Subject: [IronPython] Comparing Tuples Bug
In-Reply-To: <445A343E.1080808@resolversystems.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E0343D5F8@df-foxhound-msg.exchange.corp.microsoft.com>

It looks like we've actually got that one fixed for the upcoming beta 7.  But thanks for reporting it, and certainly keep them coming if you notice any more.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, May 04, 2006 10:05 AM
To: Discussion of IronPython
Subject: [IronPython] Comparing Tuples Bug

Hello all,


I'm not sure if this has already been picked up on, I realise several
compare bugs have. My apologies if this is a dup.

CPython :

 >>> (set(),) == (set(),)
True
 >>>

IronPython-Beta6:

 >>> (set(),) == (set(),)
Traceback (most recent call last):
  File , line 0, in input##0
TypeError: cannot compare sets using cmp()
 >>>

All the best,


Michael Foord
http://www.resolversystems.com

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From sanxiyn at gmail.com  Thu May  4 19:14:05 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Fri, 5 May 2006 02:14:05 +0900
Subject: [IronPython] CherryPy on IronPython up but not running
Message-ID: <5b0248170605041014r5e922fbcpe938750e39838a9d@mail.gmail.com>

I would like to share some of my progress on running CherryPy on
IronPython. Yes it starts up. No it doesn't process any request.

Following are steps to reproduce this result. I would be very
interested to here about your experience.

1. Install Mono

1.1.13.x versions won't work. This usually means you can't use Mono
packaged by your distribution.

For this howto I am using the Linux binary installer for x86, Mono
1.1.15_1, and I recommend you to use it too. It should work on any
Linux distributions, and does not require root privilege to install,
and uninstalls cleanly. If your platform is not x86, you should
compile from the source.

Of course if you are on Windows, you just need .NET 2.0 runtime, and
you can skip this step.

2. Download IronPython and CherryPy

I assume you know how to do these. I used IronPython 1.0 Beta 6 and
CherryPy 2.2.1.

3. Extract archive

>From now on I assume Unix-y command line. If you are on Windows
perform equivalent steps on that platform.

$ unzip IronPython-1.0-Beta6.zip
$ tar zxf CherryPy-2.2.1.tar.gz

4. Copy CPython libraries

This assumes you have CPython 2.4 installed on your system. I am using
Debian GNU/Linux package python2.4 version 2.4.3-3.

$ cd IronPython-1.0-Beta6
$ rm -rf Lib
$ cp -a /usr/lib/python2.4 Lib

5. Download my socket libraries

IronPython doesn't include built-in socket module yet, so I wrote one
myself. Download it and replace CPython's socket.py with it.

$ cd Lib
$ rm socket.py
$ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/lib/socket.py
$ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/lib/ssl.py

Let's move up.

$ cd ..
$ cd ..

6. Download my patches

patch-lib patches CPython standard library to workaround Mono bugs.
You don't need it if you are using MS.NET.

Details: IronPython uses .NET 2.0 GetEncodings() method to process
Python source file encoding declaration. This method is not
implemented in Mono. inspect.py, used indirectly by CherryPy, includes
source file encoding declaration.

$ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/ironcherry/patch-lib

patch-cherrypy patches CherryPy to workaround IronPython bugs, and in
one case, CPython dependency. Hopefully parts due to IronPython bugs
won't be needed in the future.

Details: IronPython currently lacks datetime.datetime class, so
_cputil.py patch rewrites timestamping code with time.strftime. For
various reasons sessionfilter won't work yet, so delete the code from
__init__.py and comment out the code from filters/__init__.py.
IronPython doesn't have zlib built-in module yet, so disable
gzipfilter. lib/cptools.py implements "safe eval" to read the config
file using the compiler package, which depends on CPython's internal
parser module, which I don't think IronPython can reasonably
implement. I replaced this with eval(). Finally, _cpengine.py is
patched to workaround IronPython's comparison bug. More on this bug
here:
http://lists.ironpython.com/pipermail/users-ironpython.com/2006-May/002248.html

$ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/ironcherry/patch-cherrypy

7. Apply patches

$ cd IronPython-1.0-Beta6
$ patch -p0 < ../patch-lib
$ cd ..

$ cd CherryPy-2.2.1
$ patch -p0 < ../patch-cherrypy
$ cd ..

8. Download sample CherryPy application and configuration

test.py is just the simplest possible CherryPy application imaginable.

test.conf turns off autoreloading, because it uses os.spawnve which is
not yet implemented in IronPython.

$ cd CherryPy-2.2.1
$ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/ironcherry/test.py
$ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/ironcherry/test.conf

9. Run

$ mono ../IronPython-1.0-Beta6/IronPythonConsole.exe test.py

05/May/2006:2:10:16 CONFIG INFO Server parameters:
05/May/2006:2:10:16 CONFIG INFO   server.environment: development
05/May/2006:2:10:16 CONFIG INFO   server.log_to_screen: True
05/May/2006:2:10:16 CONFIG INFO   server.log_file:
05/May/2006:2:10:16 CONFIG INFO   server.log_tracebacks: True
05/May/2006:2:10:17 CONFIG INFO   server.log_request_headers: True
05/May/2006:2:10:17 CONFIG INFO   server.protocol_version: HTTP/1.0
05/May/2006:2:10:17 CONFIG INFO   server.socket_host:
05/May/2006:2:10:17 CONFIG INFO   server.socket_port: 8080
05/May/2006:2:10:17 CONFIG INFO   server.socket_file:
05/May/2006:2:10:17 CONFIG INFO   server.reverse_dns: False
05/May/2006:2:10:17 CONFIG INFO   server.socket_queue_size: 5
05/May/2006:2:10:17 CONFIG INFO   server.thread_pool: 10
05/May/2006:2:10:19 HTTP INFO Serving HTTP on http://localhost:8080/

Nice. Now access the site from the web browser, and you get...

05/May/2006:2:11:09 HTTP INFO Request Headers:
  Content-Type:
  Remote-Host: 127.0.0.1
  KEEP-ALIVE: 300
  ACCEPT-LANGUAGE: ko,en;q=0.5
  USER-AGENT: Mozilla/5.0 (X11; U; Linux i686; ko-KR; rv:1.8.0.3)
Gecko/20060326 Firefox/1.5.0.3 (Debian-1.5.dfsg+1.5.0.3-1)
  Remote-Addr: 127.0.0.1
  ACCEPT-CHARSET: EUC-KR,utf-8;q=0.7,*;q=0.7
  Content-Length:
  HOST: localhost:8080
  ACCEPT-ENCODING: gzip,deflate
  CONNECTION: keep-alive
  ACCEPT: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Segmentation fault

And I'm stuck there.

Seo Sanghyeon


From michael.foord at resolversystems.com  Fri May  5 17:45:42 2006
From: michael.foord at resolversystems.com (Michael Foord)
Date: Fri, 05 May 2006 16:45:42 +0100
Subject: [IronPython] Adding a string to a float - bug
Message-ID: <445B7326.7090807@resolversystems.com>

Hello all,

Another IronPython peculiarity (present in beta 6) :

CPython :

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> 2.4 + 'ff'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'float' and 'str'
 >>>


IronPython :

IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> 2.0 + 'ff'
Traceback (most recent call last):
  File , line 0, in input##0
  File mscorlib, line unknown, in System.IConvertible.ToDouble
  File mscorlib, line unknown, in ToDouble
  File mscorlib, line unknown, in Parse
  File mscorlib, line unknown, in ParseDouble
  File mscorlib, line unknown, in StringToNumber
SystemError: Input string was not in a correct format.
 >>>

This makes it harder to trap these errors. :-)

All the best,


Michael Foord
http://www.resolversystems.com


From haiboluo at exchange.microsoft.com  Fri May  5 17:49:43 2006
From: haiboluo at exchange.microsoft.com (Haibo Luo)
Date: Fri, 5 May 2006 08:49:43 -0700
Subject: [IronPython] Adding a string to a float - bug
In-Reply-To: <445B7326.7090807@resolversystems.com>
Message-ID: <C880917115D23741B1FF3565AF50A09602EB0416@df-foxhound-msg.exchange.corp.microsoft.com>

Thanks for the bug. We will try to fix it in next release.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, May 05, 2006 8:46 AM
To: Discussion of IronPython
Subject: [IronPython] Adding a string to a float - bug

Hello all,

Another IronPython peculiarity (present in beta 6) :

CPython :

Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> 2.4 + 'ff'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for +: 'float' and 'str'
 >>>


IronPython :

IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> 2.0 + 'ff'
Traceback (most recent call last):
  File , line 0, in input##0
  File mscorlib, line unknown, in System.IConvertible.ToDouble
  File mscorlib, line unknown, in ToDouble
  File mscorlib, line unknown, in Parse
  File mscorlib, line unknown, in ParseDouble
  File mscorlib, line unknown, in StringToNumber
SystemError: Input string was not in a correct format.
 >>>

This makes it harder to trap these errors. :-)

All the best,


Michael Foord
http://www.resolversystems.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From korpse-ironpython at kaydash.za.net  Fri May  5 17:49:55 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Fri, 05 May 2006 17:49:55 +0200
Subject: [IronPython] Overriding derived methods
Message-ID: <445B7423.1000107@kaydash.za.net>

Hi,

I'm wondering how I override methods in a derived object, I'm not sure 
whether this is the problem I'm experiencing or not but it looks that way.

Defining my own form object, with OnKeyUp method:

 >>> class MyForm(Form):
...   def OnKeyUp(self, e):
...     print '!!!'
...     Form.OnKeyUp(self, e)
...

The problem is that OnKeyUp in my Python object doesn't actually fire 
when it should. I know I could do this by attaching an event but 
according to the MSDN docs overriding the method in derived classes is 
the preferred way to handle the event, it certainly seems cleaner.

Regards
-- 
Jonathan



From michael.foord at resolversystems.com  Fri May  5 17:51:17 2006
From: michael.foord at resolversystems.com (Michael Foord)
Date: Fri, 05 May 2006 16:51:17 +0100
Subject: [IronPython] Adding strings to floats
Message-ID: <445B7475.6030204@resolversystems.com>

Hello all,

I've discovered a 'feature' of IronPython, that diverges fairly wildly 
from the Python spec :

IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> 2.0 + "3.5"
5.5
 >>>

I think it speaks for itself...

All the best,


Michael Foord
http://www.resolversystems.com


From dinov at exchange.microsoft.com  Fri May  5 18:02:43 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 5 May 2006 09:02:43 -0700
Subject: [IronPython] Adding strings to floats
In-Reply-To: <445B7475.6030204@resolversystems.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E0343DE1C@df-foxhound-msg.exchange.corp.microsoft.com>

Yep, we shouldn't be trying the conversion in this case, we'll get rid of this "feature".  Thanks for the report.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, May 05, 2006 8:51 AM
To: Discussion of IronPython
Subject: [IronPython] Adding strings to floats

Hello all,

I've discovered a 'feature' of IronPython, that diverges fairly wildly
from the Python spec :

IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
 >>> 2.0 + "3.5"
5.5
 >>>

I think it speaks for itself...

All the best,


Michael Foord
http://www.resolversystems.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Fri May  5 18:03:42 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 5 May 2006 09:03:42 -0700
Subject: [IronPython] Overriding derived methods
In-Reply-To: <445B7423.1000107@kaydash.za.net>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E0343DE1F@df-foxhound-msg.exchange.corp.microsoft.com>

There's a bug in beta 5 and beta 6 where we can sometimes fail to call the correct derived method.  You can work around the bug in many cases w/:

Class MyForm(Form):
        def __init__(self):
                self.OnKeyUp = self.OnKeyUp
        def OnKeyUp(self, e):
                ...

Unfortunately you can still get some erattic behavior w/ the workaround in place.

This will be fixed for our beta 7 release.  This happens only when deriving from a type that has a large number of virtual methods, and unfortunately System.Windows.Forms hits this pretty heavily.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Jacobs
Sent: Friday, May 05, 2006 8:50 AM
To: Discussion of IronPython
Subject: [IronPython] Overriding derived methods

Hi,

I'm wondering how I override methods in a derived object, I'm not sure
whether this is the problem I'm experiencing or not but it looks that way.

Defining my own form object, with OnKeyUp method:

 >>> class MyForm(Form):
...   def OnKeyUp(self, e):
...     print '!!!'
...     Form.OnKeyUp(self, e)
...

The problem is that OnKeyUp in my Python object doesn't actually fire
when it should. I know I could do this by attaching an event but
according to the MSDN docs overriding the method in derived classes is
the preferred way to handle the event, it certainly seems cleaner.

Regards
--
Jonathan

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From xmlhacker at gmail.com  Sun May  7 01:30:28 2006
From: xmlhacker at gmail.com (M. David Peterson)
Date: Sat, 6 May 2006 17:30:28 -0600
Subject: [IronPython] CherryPy on IronPython up but not running
In-Reply-To: <5b0248170605041014r5e922fbcpe938750e39838a9d@mail.gmail.com>
References: <5b0248170605041014r5e922fbcpe938750e39838a9d@mail.gmail.com>
Message-ID: <eab75e160605061630u4d902dfbu6802375197e53e2d@mail.gmail.com>

Hi Seo,

I am just catching up on email... I will follow your outlined sequence later
today and see if their is anything I can add to this...  I'll report back my
findings.

Thanks!

On 5/4/06, Sanghyeon Seo <sanxiyn at gmail.com> wrote:
>
> I would like to share some of my progress on running CherryPy on
> IronPython. Yes it starts up. No it doesn't process any request.
>
> Following are steps to reproduce this result. I would be very
> interested to here about your experience.
>
> 1. Install Mono
>
> 1.1.13.x versions won't work. This usually means you can't use Mono
> packaged by your distribution.
>
> For this howto I am using the Linux binary installer for x86, Mono
> 1.1.15_1, and I recommend you to use it too. It should work on any
> Linux distributions, and does not require root privilege to install,
> and uninstalls cleanly. If your platform is not x86, you should
> compile from the source.
>
> Of course if you are on Windows, you just need .NET 2.0 runtime, and
> you can skip this step.
>
> 2. Download IronPython and CherryPy
>
> I assume you know how to do these. I used IronPython 1.0 Beta 6 and
> CherryPy 2.2.1.
>
> 3. Extract archive
>
> >From now on I assume Unix-y command line. If you are on Windows
> perform equivalent steps on that platform.
>
> $ unzip IronPython-1.0-Beta6.zip
> $ tar zxf CherryPy-2.2.1.tar.gz
>
> 4. Copy CPython libraries
>
> This assumes you have CPython 2.4 installed on your system. I am using
> Debian GNU/Linux package python2.4 version 2.4.3-3.
>
> $ cd IronPython-1.0-Beta6
> $ rm -rf Lib
> $ cp -a /usr/lib/python2.4 Lib
>
> 5. Download my socket libraries
>
> IronPython doesn't include built-in socket module yet, so I wrote one
> myself. Download it and replace CPython's socket.py with it.
>
> $ cd Lib
> $ rm socket.py
> $ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/lib/socket.py
> $ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/lib/ssl.py
>
> Let's move up.
>
> $ cd ..
> $ cd ..
>
> 6. Download my patches
>
> patch-lib patches CPython standard library to workaround Mono bugs.
> You don't need it if you are using MS.NET.
>
> Details: IronPython uses .NET 2.0 GetEncodings() method to process
> Python source file encoding declaration. This method is not
> implemented in Mono. inspect.py, used indirectly by CherryPy, includes
> source file encoding declaration.
>
> $ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/ironcherry/patch-lib
>
> patch-cherrypy patches CherryPy to workaround IronPython bugs, and in
> one case, CPython dependency. Hopefully parts due to IronPython bugs
> won't be needed in the future.
>
> Details: IronPython currently lacks datetime.datetime class, so
> _cputil.py patch rewrites timestamping code with time.strftime. For
> various reasons sessionfilter won't work yet, so delete the code from
> __init__.py and comment out the code from filters/__init__.py.
> IronPython doesn't have zlib built-in module yet, so disable
> gzipfilter. lib/cptools.py implements "safe eval" to read the config
> file using the compiler package, which depends on CPython's internal
> parser module, which I don't think IronPython can reasonably
> implement. I replaced this with eval(). Finally, _cpengine.py is
> patched to workaround IronPython's comparison bug. More on this bug
> here:
>
> http://lists.ironpython.com/pipermail/users-ironpython.com/2006-May/002248.html
>
> $ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/ironcherry/patch-cherrypy
>
> 7. Apply patches
>
> $ cd IronPython-1.0-Beta6
> $ patch -p0 < ../patch-lib
> $ cd ..
>
> $ cd CherryPy-2.2.1
> $ patch -p0 < ../patch-cherrypy
> $ cd ..
>
> 8. Download sample CherryPy application and configuration
>
> test.py is just the simplest possible CherryPy application imaginable.
>
> test.conf turns off autoreloading, because it uses os.spawnve which is
> not yet implemented in IronPython.
>
> $ cd CherryPy-2.2.1
> $ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/ironcherry/test.py
> $ wget http://sparcs.kaist.ac.kr/~tinuviel/fepy/ironcherry/test.conf
>
> 9. Run
>
> $ mono ../IronPython-1.0-Beta6/IronPythonConsole.exe test.py
>
> 05/May/2006:2:10:16 CONFIG INFO Server parameters:
> 05/May/2006:2:10:16 CONFIG INFO   server.environment: development
> 05/May/2006:2:10:16 CONFIG INFO   server.log_to_screen: True
> 05/May/2006:2:10:16 CONFIG INFO   server.log_file:
> 05/May/2006:2:10:16 CONFIG INFO   server.log_tracebacks: True
> 05/May/2006:2:10:17 CONFIG INFO   server.log_request_headers: True
> 05/May/2006:2:10:17 CONFIG INFO   server.protocol_version: HTTP/1.0
> 05/May/2006:2:10:17 CONFIG INFO   server.socket_host:
> 05/May/2006:2:10:17 CONFIG INFO   server.socket_port: 8080
> 05/May/2006:2:10:17 CONFIG INFO   server.socket_file:
> 05/May/2006:2:10:17 CONFIG INFO   server.reverse_dns: False
> 05/May/2006:2:10:17 CONFIG INFO   server.socket_queue_size: 5
> 05/May/2006:2:10:17 CONFIG INFO   server.thread_pool: 10
> 05/May/2006:2:10:19 HTTP INFO Serving HTTP on http://localhost:8080/
>
> Nice. Now access the site from the web browser, and you get...
>
> 05/May/2006:2:11:09 HTTP INFO Request Headers:
>   Content-Type:
>   Remote-Host: 127.0.0.1
>   KEEP-ALIVE: 300
>   ACCEPT-LANGUAGE: ko,en;q=0.5
>   USER-AGENT: Mozilla/5.0 (X11; U; Linux i686; ko-KR; rv:1.8.0.3)
> Gecko/20060326 Firefox/1.5.0.3 (Debian-1.5.dfsg+1.5.0.3-1)
>   Remote-Addr: 127.0.0.1
>   ACCEPT-CHARSET: EUC-KR,utf-8;q=0.7,*;q=0.7
>   Content-Length:
>   HOST: localhost:8080
>   ACCEPT-ENCODING: gzip,deflate
>   CONNECTION: keep-alive
>   ACCEPT: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9
> ,text/plain;q=0.8,image/png,*/*;q=0.5
> Segmentation fault
>
> And I'm stuck there.
>
> Seo Sanghyeon
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



--
<M:D/>

M. David Peterson
http://www.xsltblog.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060506/b49d40a2/attachment.html>

From korpse-ironpython at kaydash.za.net  Sun May  7 01:33:52 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Sun, 07 May 2006 01:33:52 +0200
Subject: [IronPython] who is using ironpython in projects ?
In-Reply-To: <590FCAE72E27D54CA1EADE7293BB444F0442295E@hqemmail04.nvidia.com>
References: <590FCAE72E27D54CA1EADE7293BB444F0442295E@hqemmail04.nvidia.com>
Message-ID: <445D3260.4020803@kaydash.za.net>

Kevin Bjorke wrote:
> We are: 
> http://developer.nvidia.com/object/fx-composer2-pipeline-gdc-2006.html

That is a pretty awesome looking piece of software, Kevin!

-- 
Jonathan


From info at geatec.com  Sun May  7 11:55:18 2006
From: info at geatec.com (J. de  Hooge)
Date: Sun, 7 May 2006 11:55:18 +0200
Subject: [IronPython] serialization
Message-ID: <000001c671bc$5c1331f0$6402a8c0@GEADELL>

Hi all,

 

Upto beta 4, I've been using a home-patched version of Cpython 2.4 's
pickle.py to serialize objects.

It stopped working for beta 5 (and using a patched version isn't what I want
in the end)

 

Can anyone tell me what's currently the best option for pickling (or
generally serializing) IronPython objects?

And what would be the preferred solution as soon as version 1.0 (definitive)
is released?

 

Thanks

Jacques de Hooge

info at geatec.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060507/62dc1ec1/attachment.html>

From korpse-ironpython at kaydash.za.net  Sun May  7 17:58:29 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Sun, 07 May 2006 17:58:29 +0200
Subject: [IronPython] Static methods that look similar to instance methods?
Message-ID: <445E1925.9000203@kaydash.za.net>

Hi,

I recently ran into a bit of a puzzling situation where I was getting None 
instead of a Vector3, and I think that IronPython thinks it should calling the 
instance method. Here are the two function signatures:

 >>> print Vector3.Unproject.__doc__
Void Unproject(object viewport, Matrix projection, Matrix view, Matrix world)
static Vector3 Unproject(Vector3 v, object viewport, Matrix projection, Matrix 
view, Matrix world)

Assuming I'm correct, how would I go about forcing it to call the static function?

Thanks
-- 
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master


From korpse-ironpython at kaydash.za.net  Sun May  7 18:10:55 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Sun, 07 May 2006 18:10:55 +0200
Subject: [IronPython] Attempt to update field 'Z' on value type 'Vector3';
 value type fields cannot be directly modified
Message-ID: <445E1C0F.1080503@kaydash.za.net>

Hi, me again!

I realise the error seems logical enough, but it isn't right. The 
documentation for Vector3 specifies that the fields X, Y and Z are all 
read/write and indeed C# code has no boggle doing just that. 
Vector3.GetType().IsValueType is true; I guess relying on IsValueType isn't 
enough.

-- 
Jonathan



From sanxiyn at gmail.com  Sun May  7 18:48:01 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Mon, 8 May 2006 01:48:01 +0900
Subject: [IronPython] Attempt to update field 'Z' on value type
	'Vector3'; value type fields cannot be directly modified
In-Reply-To: <445E1C0F.1080503@kaydash.za.net>
References: <445E1C0F.1080503@kaydash.za.net>
Message-ID: <5b0248170605070948o19eedfs8a44aab4258425c@mail.gmail.com>

2006/5/8, Jonathan Jacobs <korpse-ironpython at kaydash.za.net>:
> I realise the error seems logical enough, but it isn't right. The
> documentation for Vector3 specifies that the fields X, Y and Z are all
> read/write and indeed C# code has no boggle doing just that.
> Vector3.GetType().IsValueType is true; I guess relying on IsValueType isn't
> enough.

Have you read this?
http://channel9.msdn.com/wiki/default.aspx/IronPython.ValueTypes

Seo Sanghyeon


From korpse-ironpython at kaydash.za.net  Sun May  7 22:20:15 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Sun, 07 May 2006 22:20:15 +0200
Subject: [IronPython] Attempt to update field 'Z' on value
 type	'Vector3'; value type fields cannot be directly modified
In-Reply-To: <5b0248170605070948o19eedfs8a44aab4258425c@mail.gmail.com>
References: <445E1C0F.1080503@kaydash.za.net>
	<5b0248170605070948o19eedfs8a44aab4258425c@mail.gmail.com>
Message-ID: <445E567F.2090705@kaydash.za.net>

Sanghyeon Seo wrote:
> Have you read this?
> http://channel9.msdn.com/wiki/default.aspx/IronPython.ValueTypes

As far as I understand the Vector3 type: it is a struct with public fields, 
are these subject to these quirks too? One wouldn't expect structs to need 
getters and setters that somewhat defeats the point of struct, doesn't it?

-- 
Jonathan



From jvm_cop at spamcop.net  Mon May  8 00:51:19 2006
From: jvm_cop at spamcop.net (J. Merrill)
Date: Sun, 07 May 2006 18:51:19 -0400
Subject: [IronPython] Static methods that look similar to instance
 methods?
In-Reply-To: <445E1925.9000203@kaydash.za.net>
References: <445E1925.9000203@kaydash.za.net>
Message-ID: <7.0.1.0.2.20060507184900.08ddc3e8@wheresmymailserver.com>

In C# you could use   Vector3.Unproject    but that might not work in IP.  Have you tried it?

At 11:58 AM 5/7/2006, Jonathan Jacobs wrote
>Hi,
>
>I recently ran into a bit of a puzzling situation where I was getting None 
>instead of a Vector3, and I think that IronPython thinks it should calling the 
>instance method. Here are the two function signatures:
>
> >>> print Vector3.Unproject.__doc__
>Void Unproject(object viewport, Matrix projection, Matrix view, Matrix world)
>static Vector3 Unproject(Vector3 v, object viewport, Matrix projection, Matrix 
>view, Matrix world)
>
>Assuming I'm correct, how would I go about forcing it to call the static function?
>
>Thanks
>-- 
>Jonathan
>
>When you meet a master swordsman,
>show him your sword.
>When you meet a man who is not a poet,
>do not show him your poem.
>                 -- Rinzai, ninth century Zen master


J. Merrill / Analytical Software Corp




From korpse-ironpython at kaydash.za.net  Mon May  8 09:26:59 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Mon, 08 May 2006 09:26:59 +0200
Subject: [IronPython] Static methods that look similar to instance
	methods?
In-Reply-To: <7.0.1.0.2.20060507184900.08ddc3e8@wheresmymailserver.com>
References: <445E1925.9000203@kaydash.za.net>
	<7.0.1.0.2.20060507184900.08ddc3e8@wheresmymailserver.com>
Message-ID: <445EF2C3.7000602@kaydash.za.net>

J. Merrill wrote:
> In C# you could use   Vector3.Unproject    but that might not work in IP.  Have you tried it?

I guess I neglected to mention the part where I explained what I was doing. :)

Calling Vector3.Unproject (in an attempt to call the static method) results in 
a "None" return value, while the first parameter is modified, essentially 
behaving like the instance method version rather than the static method 
version. Either IP thinks this is something like obj.method(objInstance, 
*args) or it will only try and match the static signature later, which it 
never gets around to.

-- 
Jonathan



From simon.dahlbacka at gmail.com  Mon May  8 12:37:57 2006
From: simon.dahlbacka at gmail.com (Simon Dahlbacka)
Date: Mon, 8 May 2006 13:37:57 +0300
Subject: [IronPython] Static methods that look similar to instance
	methods?
In-Reply-To: <445EF2C3.7000602@kaydash.za.net>
References: <445E1925.9000203@kaydash.za.net>
	<7.0.1.0.2.20060507184900.08ddc3e8@wheresmymailserver.com>
	<445EF2C3.7000602@kaydash.za.net>
Message-ID: <57124720605080337g427ec1c0r94c165517e4c550@mail.gmail.com>

I suppose the problem is that the following is valid (and even used) python
code

C:\>python
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class C(object):
...     def foo(self):
...             print self
...
>>> inst = C()
>>> inst.foo()
<__main__.C object at 0x00944FF0>
>>> C.foo(inst)
<__main__.C object at 0x00944FF0>
>>>

/Simon

Btw, why do you need both a static and a non-static method with the same
name?

On 5/8/06, Jonathan Jacobs <korpse-ironpython at kaydash.za.net> wrote:
>
> J. Merrill wrote:
> > In C# you could use   Vector3.Unproject    but that might not work in
> IP.  Have you tried it?
>
> I guess I neglected to mention the part where I explained what I was
> doing. :)
>
> Calling Vector3.Unproject (in an attempt to call the static method)
> results in
> a "None" return value, while the first parameter is modified, essentially
> behaving like the instance method version rather than the static method
> version. Either IP thinks this is something like obj.method(objInstance,
> *args) or it will only try and match the static signature later, which it
> never gets around to.
>
> --
> Jonathan
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060508/5139f1c2/attachment.html>

From korpse-ironpython at kaydash.za.net  Mon May  8 16:18:52 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Mon, 08 May 2006 16:18:52 +0200
Subject: [IronPython] Static methods that look similar to
	instance	methods?
In-Reply-To: <57124720605080337g427ec1c0r94c165517e4c550@mail.gmail.com>
References: <445E1925.9000203@kaydash.za.net>	<7.0.1.0.2.20060507184900.08ddc3e8@wheresmymailserver.com>	<445EF2C3.7000602@kaydash.za.net>
	<57124720605080337g427ec1c0r94c165517e4c550@mail.gmail.com>
Message-ID: <445F534C.902@kaydash.za.net>

Simon Dahlbacka wrote:
> I suppose the problem is that the following is valid (and even used) 
> python code

Quite right.

> Btw, why do you need both a static and a non-static method with the same 
> name?

Well, it's not my code, it's from the Managed DirectX API.
-- 
Jonathan



From andrzej.krzywda at resolversystems.com  Mon May  8 17:08:57 2006
From: andrzej.krzywda at resolversystems.com (Andrzej Krzywda)
Date: Mon, 08 May 2006 16:08:57 +0100
Subject: [IronPython] Ignoring dont_inherit compiler flag
Message-ID: <445F5F09.9010702@resolversystems.com>

Hi,

IronPython ignores the dont_inherit compiler flag:

IronPython Beta 6:

 >>> from __future__ import division
 >>> exec(compile("print 2/3", "<string>", "exec", 0, 1), {})
0.666666666667


CPython:

 >>> from __future__ import division
 >>> exec(compile("print 2/3", "<string>", "exec", 0, 1), {})
0

Andrzej Krzywda




From andrzej.krzywda at resolversystems.com  Mon May  8 17:08:55 2006
From: andrzej.krzywda at resolversystems.com (Andrzej Krzywda)
Date: Mon, 08 May 2006 16:08:55 +0100
Subject: [IronPython] Compiler flags
Message-ID: <445F5F07.1090205@resolversystems.com>

Hi all,

It seems that IronPython doesn't deal correctly with compiler flags 
(8192 is the compiler flag for __future__.division).

IronPython Beta 6

 >>> exec(compile("print 2/3", "<string>", "exec", 8192), {})
0


CPython
 >>> exec(compile("print 2/3", "<string>", "exec", 8192), {})
0.666666666667

Andrzej Krzywda


From Martin.Maly at microsoft.com  Mon May  8 17:47:45 2006
From: Martin.Maly at microsoft.com (Martin Maly)
Date: Mon, 8 May 2006 08:47:45 -0700
Subject: [IronPython] Static methods that look similar
	to	instance	methods?
In-Reply-To: <445F534C.902@kaydash.za.net>
Message-ID: <5C0A6F919D675745BB1DBA7412DB68F548FEBB26@df-foxhound-msg.exchange.corp.microsoft.com>

IronPython uses the style of the call to determine which of the 2 methods it will prefer:

Class.Method(instance, parameter)       ... will prefer static method
instance.Method(parameter)              ... will prefer instance method

So this should work. However, we made changes to the overload resolution code recently so this may be a case that escaped us. I'll file a bug and hopefully we'll get to it before the next beta.

Martin


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Jacobs
Sent: Monday, May 08, 2006 7:19 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Static methods that look similar to instance methods?

Simon Dahlbacka wrote:
> I suppose the problem is that the following is valid (and even used)
> python code

Quite right.

> Btw, why do you need both a static and a non-static method with the same
> name?

Well, it's not my code, it's from the Managed DirectX API.
--
Jonathan

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From Martin.Maly at microsoft.com  Mon May  8 17:48:29 2006
From: Martin.Maly at microsoft.com (Martin Maly)
Date: Mon, 8 May 2006 08:48:29 -0700
Subject: [IronPython] Compiler flags
In-Reply-To: <445F5F07.1090205@resolversystems.com>
Message-ID: <5C0A6F919D675745BB1DBA7412DB68F548FEBB2A@df-foxhound-msg.exchange.corp.microsoft.com>

A great bug, thanks! We'll fix it.

Martin

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Andrzej Krzywda
Sent: Monday, May 08, 2006 8:09 AM
To: users at lists.ironpython.com
Subject: [IronPython] Compiler flags

Hi all,

It seems that IronPython doesn't deal correctly with compiler flags
(8192 is the compiler flag for __future__.division).

IronPython Beta 6

 >>> exec(compile("print 2/3", "<string>", "exec", 8192), {})
0


CPython
 >>> exec(compile("print 2/3", "<string>", "exec", 8192), {})
0.666666666667

Andrzej Krzywda
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From Martin.Maly at microsoft.com  Mon May  8 17:57:50 2006
From: Martin.Maly at microsoft.com (Martin Maly)
Date: Mon, 8 May 2006 08:57:50 -0700
Subject: [IronPython] Ignoring dont_inherit compiler flag
In-Reply-To: <445F5F09.9010702@resolversystems.com>
Message-ID: <5C0A6F919D675745BB1DBA7412DB68F548FEBB40@df-foxhound-msg.exchange.corp.microsoft.com>

Thanks for the bug report!

Martin

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Andrzej Krzywda
Sent: Monday, May 08, 2006 8:09 AM
To: users at lists.ironpython.com
Subject: [IronPython] Ignoring dont_inherit compiler flag

Hi,

IronPython ignores the dont_inherit compiler flag:

IronPython Beta 6:

 >>> from __future__ import division
 >>> exec(compile("print 2/3", "<string>", "exec", 0, 1), {})
0.666666666667


CPython:

 >>> from __future__ import division
 >>> exec(compile("print 2/3", "<string>", "exec", 0, 1), {})
0

Andrzej Krzywda


_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From ziga.seilnacht at gmail.com  Tue May  9 00:35:47 2006
From: ziga.seilnacht at gmail.com (=?UTF-8?B?xb1pZ2EgU2VpbG5hY2h0?=)
Date: Tue, 09 May 2006 00:35:47 +0200
Subject: [IronPython] Some incompatibilities with CPython
Message-ID: <445FC7C3.8040905@gmail.com>

Hello,

while playing with the last version of IronPython (1.0.60420),
I noticed the following bugs (the errors are given in comments,
while the expected output is from a Python 2.4.3 and should be
usable as doctest):

  - Classes (types) are missing a __class__ attribute:

     >>> class C(object): pass
     ...
     >>> C.__class__                    # Raises AttributeError
     <type 'type'>

  - The metaclass is determined incorrectly:

     >>> class M_A(type):
     ...     def __new__(meta, name, bases, dict):
     ...         print 'metaclass:', meta.__name__, 'class:', name
     ...         return type.__new__(meta, name, bases, dict)
     ...
     >>> class M_B(M_A):
     ...     pass
     ...
     >>> class A:
     ...     __metaclass__ = M_A
     ...
     metaclass: M_A class: A
     >>> class B:
     ...     __metaclass__ = M_B
     ...
     metaclass: M_B class: B
     >>> class C(A, B):                 # prints only metaclass: M_A class: C
     ...     pass
     ...
     metaclass: M_A class: C
     metaclass: M_B class: C
     >>> type(C).__name__               # this prints 'M_A' instead
     'M_B'

    CPython uses the following rules to determine the right
    metaclass for C:

     - Since C does not have a __metaclass__ attribute,
       its type is determined from its bases.
     - A is the first base, therfore its type (M_A) is called;
       unfortunately this is not the way metaclasses are
       supposed to work; the most derived metaclass should
       be selected.
     - M_A's __new__ method calls type.__new__.
     - In type.__new__, it is determined that M_A is not
       the best type for class C; it should be actually M_B.
     - Since type.__new__ was called with wrong metaclass
       as the first argument, it calls the correct metaclass.
     - This calls M_B.__new__, which again calls type.__new__,
       but this time with M_B as the first argument, which
       is correct.

    type's __new__ method should start with the following:

     class Classic:
         pass
     ClassType = type(Classic)


     class Type(type):

         """
         Metaclass that follows CPython's behaviour in "metaclass resolution".

         Code is taken from CPython's Objects/typeobject.c file.
         """
         def __new__(meta, name, bases, dict):
             winner = meta
             for cls in bases:
                 candidate = type(cls)
                 if candidate is ClassType:
                     continue
                 if issubclass(winner, candidate):
                     continue
                 if issubclass(candidate, winner):
                     winner = candidate
                     continue
                 raise TypeError("metaclass conflict: ...")
             if winner is not meta and winner.__new__ != Type.__new__:
                 return winner.__new__(winner, name, bases, dict)
             return type.__new__(winner, name, bases, dict)

  - Coercion rules are incorrect:

    Reference manual http://docs.python.org/dev/ref/coercion-rules.html says:

    Exception to the previous item: if the left operand is an instance
    of a built-in type or a new-style class, and the right operand is an
    instance of a proper subclass of that type or class and overrides the
    base's __rop__() method, the right operand's __rop__() method is tried
    before the left operand's __op__() method.

     >>> class A(object):
     ...     def __add__(self, other):
     ...         print self.__class__.__name__
     ...     __radd__ = __add__
     ...
     >>> class B(A):
     ...     def __add__(self, other):
     ...         print self.__class__.__name__
     ...     __radd__ = __add__
     ...
     >>> class C(A): pass
     ...
     >>> a = A()
     >>> b = B()
     >>> c = C()
     >>> a + b                          # prints A
     B
     >>> a + c
     A

  - Method's member 'im_inst' has the wrong name; it should be called 'im_self':

     >>> class C(object):
     ...     def meth(self): pass
     ...
     >>> print C.meth.im_self           # raises AttributeError
     None

  - instancemethod's constructor requires the third argument:

     >>> MethodType = type(C.meth)
     >>> MethodType(C.meth.im_func, 1)  # raises TypeError
     <bound method ?.meth of 1>

  - __get__ methods require the second argument:

     >>> def f(self='spam'):
     ...     print self
     ...
     >>> cm = classmethod(f)
     >>> sm = staticmethod(f)
     >>> prop = property(f)
     >>> f.__get__(1)()                 # raises TypeError
     1
     >>> cm.__get__(1)()                # raises TypeError
     <type 'int'>
     >>> sm.__get__(1)()                # raises TypeError
     spam
     >>> prop.__get__(1)                # raises TypeError
     1

  - classmethods don't pass the class' metaclass to method constructor:

     >>> class D(object):
     ...     @classmethod
     ...     def classmeth(cls): pass
     ...
     >>> D.classmeth.im_class           # prints <class '__main__.D'>
     <type 'type'>

  - builtin object super has a lot of limitations:

     - it is missing the __self_class__ member, and doesn't expose
       any of its members as attributes:

     >>> class A(object):
     ...     def __init__(self, name):
     ...         self.__name__ = name
     ...     def meth(self):
     ...         print self.__name__
     ...     classmeth = classmethod(meth)
     ...
     >>> class B(A):
     ...     pass
     ...
     >>> b = B('b')
     >>> sup = super(B, b)
     >>> sup.__thisclass__.__name__     # raises AttributeError
     'B'
     >>> sup.__self__.__name__          # raises AttributeError
     'b'
     >>> sup.__self_class__.__name__    # raises AttributeError
     'B'

     - it works only for a limited amount of descriptors, since it
       passes itself as the second argument to the __get__ methods,
       where it should pass __self_class__:

     >>> sup.classmeth()                # raises AttributeError
     B

     - it doesn't work when both arguments are classes, since it
       allways stores the second argument in its __self__ member,
       even when it should store it in its __self_class__ member.
       As a consequence it passes the second class as the first
       argument to the __get__ methods:

     >>> sup = super(B, B)
     >>> sup.__thisclass__.__name__     # raises AttributeError
     'B'
     >>> sup.__self__.__name__          # raises AttributeError
     'B'
     >>> sup.__self_class__.__name__    # raises AttributeError
     'B'
     >>> sup.meth()                     # raises AttributeError
     Traceback (most recent call last):
         ...
     TypeError: unbound method meth() must be called with B instance as first argument (got nothing instead)
     >>> sup.classmeth()                # raises AttributeError
     B

     - unbound super objects don't act as descriptors:

     >>> class A(object):
     ...     def meth(self):
     ...         print "A.meth called"
     ...
     >>> class B(A):
     ...     def meth(self):
     ...         print "B.meth called"
     ...         return self.__super.meth()
     ...
     >>> B._B__super = super(B)
     >>> b = B()
     >>> b.meth()                       # raises TypeError
     B.meth called
     A.meth called

I hope this report helps,
Ziga


From predrg at gmail.com  Tue May  9 01:51:21 2006
From: predrg at gmail.com (Predrag Radovic)
Date: Tue, 9 May 2006 01:51:21 +0200
Subject: [IronPython]  CherryPy on IronPython up but not running
Message-ID: <445fd97e.784e5e17.266e.ffffd631@mx.gmail.com>

Hello Seo,

I tried to start CherryPy 2.1.0 on the Windows with .NET 2.0 runtime and
IronPython 1.0 Beta 6. After tweaking here and there, adding few stub
modules (like datetime, sha, zlib) and using your excellent socket.py
replacement module, the most basic example (tut01_helloworld.py) works but
has to be modified.

First major problem is that IronPython apparently doesn't support assigning
attributes to (un)bounded methods. For example,

>>> class A:
...   def f(self): pass
...   f.test = 123
...
>>> A.f
<unbound method A.f>
>>> A.f.test
Traceback (most recent call last):
  File , line 0, in input##5
AttributeError: 'instancemethod' object has no attribute 'test'
>>> a=A()
>>> a.f
<bound method instance.f of <__main__.A instance at 0x000000000000002B>>
>>> a.f.test
Traceback (most recent call last):
  File , line 0, in input##8
AttributeError: 'instancemethod' object has no attribute 'test'

This is working in CPython:

>>> class A:
...   def f(self): pass
...   f.test = 123
...
>>> A.f
<unbound method A.f>
>>> A.f.test
123
>>> a=A()
>>> a.f
<bound method A.f of <__main__.A instance at 0x008F1A58>>
>>> a.f.test
123
>>>

This is how I modified tut01_helloworld.py. I doubt this is feasible
approach for other already developed code which uses CherryPy.

class Index:
  def __call__(self):
    print 'Index',self # we don't have access and any idea of existance of
HelloWorld... another problem I guess
    return "<html><body>Hello world!</body></html>\n\n"

class HelloWorld:
    """ Sample request handler class. """

    index = Index()

    #def index(self):
    #    # CherryPy will call this method for the root URI ("/") and send
    #    # its return value to the client. Because this is tutorial
    #    # lesson number 01, we'll just send something really simple.
    #    # How about...
    #    return "Hello world!\n\n"

    # Expose the index method through the web. CherryPy will never
    # publish methods that don't have the exposed attribute set to True.
    index.exposed = True
 
Solution for the second problem is easy, in your socket.py:

def makefile(self, mode='r', bufsize=-1):
        stream = NetworkStream(self.socket)
        return file(stream) # -> file(stream, mode+'b') # it must be binary
because '\r's will be duplicated in the HTTP response

Hope this helps a bit,
Predrag



From jritter at prairiegames.com  Tue May  9 04:14:23 2006
From: jritter at prairiegames.com (Josh Ritter)
Date: Mon, 8 May 2006 21:14:23 -0500
Subject: [IronPython] PEP 342 - Coroutines via Enhanced Generators
References: <445fd97e.784e5e17.266e.ffffd631@mx.gmail.com>
Message-ID: <001701c6730e$4a646e30$0400000a@spooge>

I really like Python 2.5's coroutines implemented via enhanced generator 
support.

http://www.python.org/dev/peps/pep-0342

I am wondering if there is a timeline for IronPython to support them?

IronPython looks great... coroutines and a Twisted reactor would be really 
fun :)

Thanks,
-Josh Ritter
Prairie Games, Inc
http://www.prairiegames.com







From simon.dahlbacka at gmail.com  Tue May  9 07:27:28 2006
From: simon.dahlbacka at gmail.com (Simon Dahlbacka)
Date: Tue, 9 May 2006 08:27:28 +0300
Subject: [IronPython] CherryPy on IronPython up but not running
In-Reply-To: <445fd97e.784e5e17.266e.ffffd631@mx.gmail.com>
References: <445fd97e.784e5e17.266e.ffffd631@mx.gmail.com>
Message-ID: <57124720605082227g3b578135r9c8465f30e414d32@mail.gmail.com>

> First major problem is that IronPython apparently doesn't support
> assigning
> attributes to (un)bounded methods. For example,


AFAIR, you could expose a method in CherryPy, either by directly setting the
attribute, or by using a decorator @exposed or somesuch. (It is however
likely that the decorator approach also is hit by the attribute limitation,
I don't normally use CherryPy, and haven't got IronPython installed on this
machine either.. so this is just general thoughts)

/Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060509/e4a1a5dc/attachment.html>

From ivan.chollet at lynanda.com  Tue May  9 16:02:15 2006
From: ivan.chollet at lynanda.com (ivan chollet)
Date: Tue, 9 May 2006 16:02:15 +0200
Subject: [IronPython] deriving IronPython
Message-ID: <20060509140157.035E927413@smtp5-g19.free.fr>

Hi everyone, 

 

I thought it would be rather cool if the developers of IronPython changed
the protection levels in some of IronPython classes. I mean, PythonEngine or
PythonCommandLine are classes that are subject to be subclassed. Maybe you
could set them to "protected virtual"., so that we all can derive from
IronPython without having to touch a single byte of the source code?

 

Regards,

Ivan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060509/ba6edc79/attachment.html>

From dinov at exchange.microsoft.com  Tue May  9 18:05:48 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 9 May 2006 09:05:48 -0700
Subject: [IronPython] PEP 342 - Coroutines via Enhanced Generators
In-Reply-To: <001701c6730e$4a646e30$0400000a@spooge>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E1FE2601B@df-foxhound-msg.exchange.corp.microsoft.com>

Our current goal for 1.0 is Python 2.4 compatibility, so we wouldn't be able to get to this until after we ship 1.0 later this year.

I've opened a bug to track the issue though just so we don't lose it when we start doing future planning.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Josh Ritter
Sent: Monday, May 08, 2006 7:14 PM
To: Discussion of IronPython
Subject: [IronPython] PEP 342 - Coroutines via Enhanced Generators

I really like Python 2.5's coroutines implemented via enhanced generator
support.

http://www.python.org/dev/peps/pep-0342

I am wondering if there is a timeline for IronPython to support them?

IronPython looks great... coroutines and a Twisted reactor would be really
fun :)

Thanks,
-Josh Ritter
Prairie Games, Inc
http://www.prairiegames.com





_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Tue May  9 18:10:04 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 9 May 2006 09:10:04 -0700
Subject: [IronPython] Some incompatibilities with CPython
In-Reply-To: <445FC7C3.8040905@gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E1FE26026@df-foxhound-msg.exchange.corp.microsoft.com>

Thanks for the bugs!  This is a great list of incompatibilities, I've gone ahead and opened a bug to track these.

I don't know that we'll get all of these fixed for the next release, but we'll certainly look into fixing what we can, and getting the rest fixed shortly after that.  If some of these are more important to you than others let us know and we'll try to prioritize appropriately.



Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of ?iga Seilnacht
Sent: Monday, May 08, 2006 3:36 PM
To: users at lists.ironpython.com
Subject: [IronPython] Some incompatibilities with CPython

Hello,

while playing with the last version of IronPython (1.0.60420),
I noticed the following bugs (the errors are given in comments,
while the expected output is from a Python 2.4.3 and should be
usable as doctest):

  - Classes (types) are missing a __class__ attribute:

     >>> class C(object): pass
     ...
     >>> C.__class__                    # Raises AttributeError
     <type 'type'>

  - The metaclass is determined incorrectly:

     >>> class M_A(type):
     ...     def __new__(meta, name, bases, dict):
     ...         print 'metaclass:', meta.__name__, 'class:', name
     ...         return type.__new__(meta, name, bases, dict)
     ...
     >>> class M_B(M_A):
     ...     pass
     ...
     >>> class A:
     ...     __metaclass__ = M_A
     ...
     metaclass: M_A class: A
     >>> class B:
     ...     __metaclass__ = M_B
     ...
     metaclass: M_B class: B
     >>> class C(A, B):                 # prints only metaclass: M_A class: C
     ...     pass
     ...
     metaclass: M_A class: C
     metaclass: M_B class: C
     >>> type(C).__name__               # this prints 'M_A' instead
     'M_B'

    CPython uses the following rules to determine the right
    metaclass for C:

     - Since C does not have a __metaclass__ attribute,
       its type is determined from its bases.
     - A is the first base, therfore its type (M_A) is called;
       unfortunately this is not the way metaclasses are
       supposed to work; the most derived metaclass should
       be selected.
     - M_A's __new__ method calls type.__new__.
     - In type.__new__, it is determined that M_A is not
       the best type for class C; it should be actually M_B.
     - Since type.__new__ was called with wrong metaclass
       as the first argument, it calls the correct metaclass.
     - This calls M_B.__new__, which again calls type.__new__,
       but this time with M_B as the first argument, which
       is correct.

    type's __new__ method should start with the following:

     class Classic:
         pass
     ClassType = type(Classic)


     class Type(type):

         """
         Metaclass that follows CPython's behaviour in "metaclass resolution".

         Code is taken from CPython's Objects/typeobject.c file.
         """
         def __new__(meta, name, bases, dict):
             winner = meta
             for cls in bases:
                 candidate = type(cls)
                 if candidate is ClassType:
                     continue
                 if issubclass(winner, candidate):
                     continue
                 if issubclass(candidate, winner):
                     winner = candidate
                     continue
                 raise TypeError("metaclass conflict: ...")
             if winner is not meta and winner.__new__ != Type.__new__:
                 return winner.__new__(winner, name, bases, dict)
             return type.__new__(winner, name, bases, dict)

  - Coercion rules are incorrect:

    Reference manual http://docs.python.org/dev/ref/coercion-rules.html says:

    Exception to the previous item: if the left operand is an instance
    of a built-in type or a new-style class, and the right operand is an
    instance of a proper subclass of that type or class and overrides the
    base's __rop__() method, the right operand's __rop__() method is tried
    before the left operand's __op__() method.

     >>> class A(object):
     ...     def __add__(self, other):
     ...         print self.__class__.__name__
     ...     __radd__ = __add__
     ...
     >>> class B(A):
     ...     def __add__(self, other):
     ...         print self.__class__.__name__
     ...     __radd__ = __add__
     ...
     >>> class C(A): pass
     ...
     >>> a = A()
     >>> b = B()
     >>> c = C()
     >>> a + b                          # prints A
     B
     >>> a + c
     A

  - Method's member 'im_inst' has the wrong name; it should be called 'im_self':

     >>> class C(object):
     ...     def meth(self): pass
     ...
     >>> print C.meth.im_self           # raises AttributeError
     None

  - instancemethod's constructor requires the third argument:

     >>> MethodType = type(C.meth)
     >>> MethodType(C.meth.im_func, 1)  # raises TypeError
     <bound method ?.meth of 1>

  - __get__ methods require the second argument:

     >>> def f(self='spam'):
     ...     print self
     ...
     >>> cm = classmethod(f)
     >>> sm = staticmethod(f)
     >>> prop = property(f)
     >>> f.__get__(1)()                 # raises TypeError
     1
     >>> cm.__get__(1)()                # raises TypeError
     <type 'int'>
     >>> sm.__get__(1)()                # raises TypeError
     spam
     >>> prop.__get__(1)                # raises TypeError
     1

  - classmethods don't pass the class' metaclass to method constructor:

     >>> class D(object):
     ...     @classmethod
     ...     def classmeth(cls): pass
     ...
     >>> D.classmeth.im_class           # prints <class '__main__.D'>
     <type 'type'>

  - builtin object super has a lot of limitations:

     - it is missing the __self_class__ member, and doesn't expose
       any of its members as attributes:

     >>> class A(object):
     ...     def __init__(self, name):
     ...         self.__name__ = name
     ...     def meth(self):
     ...         print self.__name__
     ...     classmeth = classmethod(meth)
     ...
     >>> class B(A):
     ...     pass
     ...
     >>> b = B('b')
     >>> sup = super(B, b)
     >>> sup.__thisclass__.__name__     # raises AttributeError
     'B'
     >>> sup.__self__.__name__          # raises AttributeError
     'b'
     >>> sup.__self_class__.__name__    # raises AttributeError
     'B'

     - it works only for a limited amount of descriptors, since it
       passes itself as the second argument to the __get__ methods,
       where it should pass __self_class__:

     >>> sup.classmeth()                # raises AttributeError
     B

     - it doesn't work when both arguments are classes, since it
       allways stores the second argument in its __self__ member,
       even when it should store it in its __self_class__ member.
       As a consequence it passes the second class as the first
       argument to the __get__ methods:

     >>> sup = super(B, B)
     >>> sup.__thisclass__.__name__     # raises AttributeError
     'B'
     >>> sup.__self__.__name__          # raises AttributeError
     'B'
     >>> sup.__self_class__.__name__    # raises AttributeError
     'B'
     >>> sup.meth()                     # raises AttributeError
     Traceback (most recent call last):
         ...
     TypeError: unbound method meth() must be called with B instance as first argument (got nothing instead)
     >>> sup.classmeth()                # raises AttributeError
     B

     - unbound super objects don't act as descriptors:

     >>> class A(object):
     ...     def meth(self):
     ...         print "A.meth called"
     ...
     >>> class B(A):
     ...     def meth(self):
     ...         print "B.meth called"
     ...         return self.__super.meth()
     ...
     >>> B._B__super = super(B)
     >>> b = B()
     >>> b.meth()                       # raises TypeError
     B.meth called
     A.meth called

I hope this report helps,
Ziga
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Tue May  9 18:16:10 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 9 May 2006 09:16:10 -0700
Subject: [IronPython] deriving IronPython
In-Reply-To: <20060509140157.035E927413@smtp5-g19.free.fr>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E1FE26032@df-foxhound-msg.exchange.corp.microsoft.com>

Is there some specific functionality you'd like to override?  We certainly wouldn't want to make all the methods virtual as it'd be a large backwards compatibility burden, but we are actively looking at trying to improve these APIs so whatever specific feedback you'd have hear would be great to hear.

Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of ivan chollet
Sent: Tuesday, May 09, 2006 7:02 AM
To: 'Discussion of IronPython'
Subject: [IronPython] deriving IronPython

Hi everyone,

I thought it would be rather cool if the developers of IronPython changed the protection levels in some of IronPython classes. I mean, PythonEngine or PythonCommandLine are classes that are subject to be subclassed. Maybe you could set them to "protected virtual"..., so that we all can derive from IronPython without having to touch a single byte of the source code?

Regards,
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060509/dab15ba4/attachment.html>

From bashmohandes at gmail.com  Tue May  9 20:41:08 2006
From: bashmohandes at gmail.com (Mohammed Hossam)
Date: Tue, 9 May 2006 21:41:08 +0300
Subject: [IronPython] Problem between Iron Python and Windows Workflow
	Foundation WWF
Message-ID: <18bfce840605091141s3816d1f8oad1d2c9bbbdfabb3@mail.gmail.com>

I've tried to use Iron Python with WWF, but it seems that there is a problem
when passing inputs of type System.Type in some API's like
WorkflowRuntime.CreateWorkflow
that takes a System.Type input of a type that supposed to be inheriting from
one of WWF activity classes like SequentialWorkflowActivity
this is the code i wrote

import clr
clr.AddReference("System.Workflow.Runtime")
clr.AddReference("System.Workflow.ComponentModel")
clr.AddReference("System.Workflow.Activities")
from System.Workflow.Activities import *
from System.Workflow.Runtime import *
from System.Workflow.Activities import *

class MyWorkflow(SequentialWorkflowActivity):
    def __init__(self):
        SequentialWorkflowActivity.__init__(self)
        self.codeActivity = CodeActivity()
        self.codeActivity.ExecuteCode += self.SayHello
        self.codeActivity.Name = "Hello"
        self.Activities.Add(self.codeActivity)

    def SayHello(sender, args):
        print "Hello"



def Started(sender, args):
    print "Started\n"


def Completed(sender, args):
    print "Completed"


tf = MyWorkflow()

rt = WorkflowRuntime()
rt.WorkflowStarted += Started
rt.WorkflowCompleted += Completed
instance = rt.CreateWorkflow(tf.GetType())
instance.Start()

and this was the error
Traceback (most recent call last):
  File , line 0, in input##0
  File , line 0, in __import__##4
  File  workflow.py, line 35, in Initialize
  File , line 0, in CreateWorkflow##17
  File System.Workflow.Runtime, line unknown, in CreateWorkflow
  File System.Workflow.Runtime, line unknown, in InternalCreateWorkflow
  File System.Workflow.Runtime, line unknown, in GetWorkflowExecutor
  File System.Workflow.Runtime, line unknown, in Load
  File System.Workflow.Runtime, line unknown, in InitializeExecutor
  File System.Workflow.Runtime, line unknown, in GetRootActivity
  File System.Workflow.Runtime, line unknown, in LoadRootActivity
  File System.Workflow.Runtime, line unknown, in CreateInstance
*ValueError: The input workflow type must define a public, parameterless
constructor.

so please if you know a way arround please tell me

Thanks in advance
*--
=-=-=-=-=-=-=-=-=-=-=-=
Mohammed Hossam Eldin
bashmohandes at gmail.com
mobile: +2012 3818978
www.SilverKey.us
Personal Blogs
http://spaces.msn.com/bashmohandes
Technical Blogs
http://spellcoder.com/blogs/bashmohandes
=-=-=-=-=-=-=-=-=-=-=-=-=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060509/38395020/attachment.html>

From sanxiyn at gmail.com  Wed May 10 05:22:43 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Wed, 10 May 2006 12:22:43 +0900
Subject: [IronPython] Getting attributes from instancemethod
Message-ID: <5b0248170605092022p4339c3fcm20be27512caf0126@mail.gmail.com>

Hello, this is just a clarification of a bug reported by Predrag Radovic:
http://lists.ironpython.com/pipermail/users-ironpython.com/2006-May/002278.html

# test.py
class C:
    def m(self):
        pass
    m.x = 1
im = C.m
print im.x

# CPython
1

# IronPython
AttributeError: 'instancemethod' object has no attribute 'x'

Seo Sanghyeon


From sanxiyn at gmail.com  Wed May 10 05:28:59 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Wed, 10 May 2006 12:28:59 +0900
Subject: [IronPython] Getting attributes from instancemethod (patch)
Message-ID: <5b0248170605092028q1ff0909bq3d806c96c91245e@mail.gmail.com>

In the mean time, Predrag, can you test an attached patch? If it works
it should be possible to try more complex CherryPy applications, which
may discover more problems.

Seo Sanghyeon
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: instancemethod_getattr.txt
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060510/9cd01034/attachment.txt>

From ivan.chollet at lynanda.com  Wed May 10 16:13:07 2006
From: ivan.chollet at lynanda.com (ivan chollet)
Date: Wed, 10 May 2006 16:13:07 +0200
Subject: [IronPython] deriving IronPython
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214E1FE26032@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <20060510141307.54B4F275A4@smtp5-g19.free.fr>

For instance, people often would like to override methods such as
DumpStackTraces in PythonEngine or SuperConsole's methods, as well as
PythonCommandLine's methods.
IronPython's kernel is clearly not a request (unless someone would want to
rewrite it from scratch...), only the uppermost layers should ever be
concerned by overriding.
Methods such as PythonEngine.setStdout(...) are really helpful. That's the
kind of features we like, but it would be rather painful for you to develop
a comprehensive API with tons of such functions. Maybe being able to simply
override methods would be easier from the user's POV. I'm not fully
qualified to answer such questions but I thought that a simple user's
position could provide you with a different insight in IP's design issues.
Hope this helps!

Ivan chollet




-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: mardi 9 mai 2006 18:16
To: Discussion of IronPython
Subject: Re: [IronPython] deriving IronPython

Is there some specific functionality you'd like to override?  We certainly
wouldn't want to make all the methods virtual as it'd be a large backwards
compatibility burden, but we are actively looking at trying to improve these
APIs so whatever specific feedback you'd have hear would be great to hear=



From michael.foord at resolversystems.com  Wed May 10 17:57:16 2006
From: michael.foord at resolversystems.com (Michael Foord)
Date: Wed, 10 May 2006 16:57:16 +0100
Subject: [IronPython] Printing Exceptions
Message-ID: <44620D5C.3000601@resolversystems.com>

Hello all,

Ok, so this one is trivial - but you never know, it might turn up 
elsewhere in another guise. :-)

CPython

 >>> print '%s' % Exception()

 >>>

IronPython Beta 6

 >>> print '%s' % Exception()
None
 >>>

All the best,


Michael Foord
http://www.resolversystems.com


From yalvi at exchange.microsoft.com  Wed May 10 18:49:56 2006
From: yalvi at exchange.microsoft.com (Yasir Alvi)
Date: Wed, 10 May 2006 09:49:56 -0700
Subject: [IronPython] Printing Exceptions
In-Reply-To: <44620D5C.3000601@resolversystems.com>
Message-ID: <2D38793E06D9DE4492851464072026929DEE350B@df-foxhound-msg.exchange.corp.microsoft.com>


        Thanks for the bug report!  We will try to fix this for our next Beta.

Yasir

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, May 10, 2006 8:57 AM
To: Discussion of IronPython
Subject: [IronPython] Printing Exceptions

Hello all,

Ok, so this one is trivial - but you never know, it might turn up
elsewhere in another guise. :-)

CPython

 >>> print '%s' % Exception()

 >>>

IronPython Beta 6

 >>> print '%s' % Exception()
None
 >>>

All the best,


Michael Foord
http://www.resolversystems.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From predrg at gmail.com  Thu May 11 00:24:26 2006
From: predrg at gmail.com (Predrag Radovic)
Date: Thu, 11 May 2006 00:24:26 +0200
Subject: [IronPython] Getting attributes from instancemethod (patch)
In-Reply-To: <5b0248170605092028q1ff0909bq3d806c96c91245e@mail.gmail.com>
Message-ID: <44626827.109075cd.14f6.3276@mx.gmail.com>

The patch (instancemethod_getattr.txt) works! (on .NET 2.0 and IronPython
1.0 Beta 6)

I tested it with CherryPy 2.1.0 and its tutorials. Simple tutorials
generally work. (6 works / 4 fails)

Sometimes strange thing is happening when CheeryPy 2.1.0 starts serving. Up
to 10 initial connections/requests could be queued somehow, then rapidly
processed. For every of these initial requests following exception is
produced:

Traceback (most recent call last):
  File "D:\Python23\Lib\site-packages\cherrypy\_cpwsgiserver.py", line 190,
in write
    self.send_headers()
  File "D:\Python23\Lib\site-packages\cherrypy\_cpwsgiserver.py", line 208,
in send_headers
    self.wfile.write(self.environ["SERVER_PROTOCOL"] + " " + self.status +
"\r\n")
IOError: Unable to write data to the transport connection: An established
connection was aborted by the software in your host machine.

After this strange initial period, normal (successful) immediate processing
is performed for every request I manually initiate from the browser.

Manually initiated (Ctrl+C) shutdown works but before process exits I must
perform one more request to unblock further execution to exit.

Blocking could be related to threads and sockets somehow.

General performance remarks (compared to CPython2.3):
-slow loading
-slow execution
-more then 100MB RAM allocated (CPython takes less then 20MB)

I tried running CherryPy 2.2.1 (with your patches applied) and from what I
can see in the log and exception tracebacks it loads but there are some
problems (maybe related to network communication). Then CherryPy 2.2.1
starts continuously returning 500 Internal Server error. I'll check it more
carefully soon.

What is the more complex CherryPy application you would test first as soon
as we get confidance that basic CherryPy stuff is working?

Predrag

> -----Original Message-----
> From: users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
> Sent: Wednesday, May 10, 2006 5:29
> To: Discussion of IronPython
> Subject: Re: [IronPython] Getting attributes from 
> instancemethod (patch)
> 
> In the mean time, Predrag, can you test an attached patch? If 
> it works it should be possible to try more complex CherryPy 
> applications, which may discover more problems.
> 
> Seo Sanghyeon
> 



From sanxiyn at gmail.com  Thu May 11 03:10:25 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 11 May 2006 10:10:25 +0900
Subject: [IronPython] Question to IronPython team
Message-ID: <5b0248170605101810q6df9e962ye5866a4aee3624ff@mail.gmail.com>

Do you plan to include socket module in IronPython before releasing
IronPython 1.0?

Seo Sanghyeon


From redmoon17 at gmail.com  Thu May 11 04:23:46 2006
From: redmoon17 at gmail.com (Kevin Chu)
Date: Thu, 11 May 2006 10:23:46 +0800
Subject: [IronPython] IronPython and LINQ
Message-ID: <41d7f4a90605101923o6da2c8efg2c8b77d6c9a34a51@mail.gmail.com>

LINQ Preview May 2006 released!
Can IronPython use LINQ?

-- 
Once in a Redmoon


From redmoon17 at gmail.com  Thu May 11 04:44:03 2006
From: redmoon17 at gmail.com (Kevin Chu)
Date: Thu, 11 May 2006 10:44:03 +0800
Subject: [IronPython] IronPython and LINQ
Message-ID: <41d7f4a90605101944i51e71ea3g7032048dff621d6d@mail.gmail.com>

LINQ preview may 2006 released!
Can IP use LINQ?

-- 
Once in a Redmoon


From sh at defuze.org  Thu May 11 09:20:38 2006
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Thu, 11 May 2006 08:20:38 +0100 (BST)
Subject: [IronPython] Question to IronPython team
In-Reply-To: <5b0248170605101810q6df9e962ye5866a4aee3624ff@mail.gmail.com>
References: <5b0248170605101810q6df9e962ye5866a4aee3624ff@mail.gmail.com>
Message-ID: <41003.194.221.74.7.1147332038.squirrel@mail1.python-hosting.com>

> Do you plan to include socket module in IronPython before releasing
> IronPython 1.0?

I cannot deny this would be a great decision to be made :D

- Sylvain


From sanxiyn at gmail.com  Thu May 11 11:26:55 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 11 May 2006 18:26:55 +0900
Subject: [IronPython] Inheritance problem
Message-ID: <5b0248170605110226q2a24a8a9j68d928395ba9d1ac@mail.gmail.com>

# test.py
class C(object): pass
class D(object): pass
class E(D): pass
class F(C, E): pass

# IronPython
TypeError: order for classes object has been seen in the class hierachy before D

Seo Sanghyeon


From mailinglist.account at gmail.com  Thu May 11 11:43:42 2006
From: mailinglist.account at gmail.com (Anthony Tarlano)
Date: Thu, 11 May 2006 11:43:42 +0200
Subject: [IronPython] Question to IronPython team
In-Reply-To: <41003.194.221.74.7.1147332038.squirrel@mail1.python-hosting.com>
References: <5b0248170605101810q6df9e962ye5866a4aee3624ff@mail.gmail.com>
	<41003.194.221.74.7.1147332038.squirrel@mail1.python-hosting.com>
Message-ID: <f2b573190605110243q2f1c189uc743d862899c10a5@mail.gmail.com>

It would be a good idea to wrap the cpython socket.dll with some
unmanaged code using using p/invoke to calls into the cpython socket
module to be 100% seamless..

Anthony

On 5/11/06, Sylvain Hellegouarch <sh at defuze.org> wrote:
> > Do you plan to include socket module in IronPython before releasing
> > IronPython 1.0?
>
> I cannot deny this would be a great decision to be made :D
>
> - Sylvain
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


From yalvi at exchange.microsoft.com  Thu May 11 18:53:49 2006
From: yalvi at exchange.microsoft.com (Yasir Alvi)
Date: Thu, 11 May 2006 09:53:49 -0700
Subject: [IronPython] Inheritance problem
In-Reply-To: <5b0248170605110226q2a24a8a9j68d928395ba9d1ac@mail.gmail.com>
Message-ID: <2D38793E06D9DE4492851464072026929DEE3E32@df-foxhound-msg.exchange.corp.microsoft.com>


        Seo, thanks for the bug.  I've logged it in our bug database and we'll try to get to it for our next Beta.

Thanks,
Yasir

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Thursday, May 11, 2006 2:27 AM
To: Discussion of IronPython
Subject: [IronPython] Inheritance problem

# test.py
class C(object): pass
class D(object): pass
class E(D): pass
class F(C, E): pass

# IronPython
TypeError: order for classes object has been seen in the class hierachy before D

Seo Sanghyeon
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From Shri.Borde at microsoft.com  Fri May 12 01:03:50 2006
From: Shri.Borde at microsoft.com (Shri Borde)
Date: Thu, 11 May 2006 16:03:50 -0700
Subject: [IronPython] IronPython and LINQ
In-Reply-To: <41d7f4a90605101923o6da2c8efg2c8b77d6c9a34a51@mail.gmail.com>
Message-ID: <E033BA171234D54E8C3A766090317CED40A77FDE@df-foxhound-msg.exchange.corp.microsoft.com>

Hi Kevin,

IronPython 1.0 will not support LINQ. We have started to look at it, but will seriously look at it after the summer. It is a meaty issue given that many of the concepts in LINQ are based on static typing.

Here is the LINQ information for those who haven't seen it yet - http://msdn.microsoft.com/data/ref/linq/.

Thanks
Shri

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu
Sent: Wednesday, May 10, 2006 7:24 PM
To: Discussion of IronPython
Subject: [IronPython] IronPython and LINQ

LINQ Preview May 2006 released!
Can IronPython use LINQ?

--
Once in a Redmoon
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From redmoon17 at gmail.com  Fri May 12 05:04:24 2006
From: redmoon17 at gmail.com (Kevin Chu)
Date: Fri, 12 May 2006 11:04:24 +0800
Subject: [IronPython] IronPython and LINQ
In-Reply-To: <E033BA171234D54E8C3A766090317CED40A77FDE@df-foxhound-msg.exchange.corp.microsoft.com>
References: <41d7f4a90605101923o6da2c8efg2c8b77d6c9a34a51@mail.gmail.com>
	<E033BA171234D54E8C3A766090317CED40A77FDE@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <41d7f4a90605112004g2e892156m6bb3d16bf2e69520@mail.gmail.com>

I see that in C# v3 have many dynamic language feature. eg:

Lambda Expressions -Pred<Customer> = |c| c.City == "London";
Expression Trees - Expression<Pred<Customer>> = |c| c.City == "London";
Object Intializers -Contact c = new Contact { Name = "Bill", Phone = "?" };
Anonymous Types -new { Name = "Bill", Phone = "?" }
Type Inference --var c = new { Name = "Bill", Phone = "?" };
Extension Methods--static void Method(this IEnumerable<T> src)

what policy ms have in dynamic language between c# and IronPython.

2006/5/12, Shri Borde <Shri.Borde at microsoft.com>:
> Hi Kevin,
>
> IronPython 1.0 will not support LINQ. We have started to look at it, but will seriously look at it after the summer. It is a meaty issue given that many of the concepts in LINQ are based on static typing.
>
> Here is the LINQ information for those who haven't seen it yet - http://msdn.microsoft.com/data/ref/linq/.
>
> Thanks
> Shri
>
> Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu
> Sent: Wednesday, May 10, 2006 7:24 PM
> To: Discussion of IronPython
> Subject: [IronPython] IronPython and LINQ
>
> LINQ Preview May 2006 released!
> Can IronPython use LINQ?
>
> --
> Once in a Redmoon
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


-- 
Once in a Redmoon

From kfarmer at thuban.org  Fri May 12 09:37:06 2006
From: kfarmer at thuban.org (Keith J. Farmer)
Date: Fri, 12 May 2006 00:37:06 -0700
Subject: [IronPython] IronPython and LINQ
In-Reply-To: <41d7f4a90605112004g2e892156m6bb3d16bf2e69520@mail.gmail.com>
Message-ID: <C02467D265F3F64E87DED53F9C3DE29C32DB50@nostromo.circle-cross.home>

Actually, these features are not dynamic in the "Python is a dynamic
language" sense.  There are no features which add new members to a type
at runtime, for example, nor is there any weak typing.  C# remains a
static, strongly-typed language.

Lambda Expressions -- this is syntactic sugar which allows a single
syntax to be compiled into either delegates or expression trees
Expression Trees -- simple object trees to encode an expression
Object Initializers -- syntactic sugar
Anonymous Types -- compiler-assisted type generation.  The type is
created by the compiler and given an unknowable name.
Type Inference -- again, sugar for "the type implied by the right hand
side of the assignment"
Extension methods -- more sugar.  barInstance.Method(baz) is compiled to
BarExtensions.Method(barInstance, baz)

.. None of these do anything that wasn't possible before.  They just
make doing it easier.

-----
Keith J. Farmer // kfarmer at thuban.org
-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu
Sent: Thursday, 11 May 2006 20:04
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython and LINQ

I see that in C# v3 have many dynamic language feature. eg:

Lambda Expressions -Pred<Customer> = |c| c.City == "London";
Expression Trees - Expression<Pred<Customer>> = |c| c.City == "London";
Object Intializers -Contact c = new Contact { Name = "Bill", Phone =
"..." };
Anonymous Types -new { Name = "Bill", Phone = "..." }
Type Inference --var c = new { Name = "Bill", Phone = "..." };
Extension Methods--static void Method(this IEnumerable<T> src)

what policy ms have in dynamic language between c# and IronPython.

2006/5/12, Shri Borde <Shri.Borde at microsoft.com>:
> Hi Kevin,
>
> IronPython 1.0 will not support LINQ. We have started to look at it,
but will seriously look at it after the summer. It is a meaty issue
given that many of the concepts in LINQ are based on static typing.
>
> Here is the LINQ information for those who haven't seen it yet -
http://msdn.microsoft.com/data/ref/linq/.
>
> Thanks
> Shri
>
> Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE
-11F0-45DF-8B78-DC1B43134038)
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu
> Sent: Wednesday, May 10, 2006 7:24 PM
> To: Discussion of IronPython
> Subject: [IronPython] IronPython and LINQ
>
> LINQ Preview May 2006 released!
> Can IronPython use LINQ?
>
> --
> Once in a Redmoon
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>


-- 
Once in a Redmoon


From andrzej.krzywda at resolversystems.com  Mon May 15 15:53:02 2006
From: andrzej.krzywda at resolversystems.com (Andrzej Krzywda)
Date: Mon, 15 May 2006 14:53:02 +0100
Subject: [IronPython] out parameters
Message-ID: <446887BE.1090908@resolversystems.com>

Hi all,

Having the following piece of C# code (note the ignore parameter):  

    public class C
    {
        public static int M(out int i, out int j, out int k, bool ignore)
        {
            i = 20;
            j = 30;
            k = 40;
            return 10;
        }
    }


we call it from IronPython Beta 6:

i = C.M(True)

and we get :

        Unhandled Exception: generate:  type: System.DBNull
   at IronPython.Compiler.CodeGen.EmitRawConstant(Object value)
   at 
IronPython.Compiler.ReflectOptimizer.MultiCallGenerator.EmitDefaultValue(I
nt32 param, MethodTracker method)
   at 
IronPython.Compiler.ReflectOptimizer.MultiCallGenerator.EmitParameter(Meth
odTracker method, ParameterInfo pi, Int32 param)
   at 
IronPython.Compiler.ReflectOptimizer.MultiCallGenerator.EmitParameters(Met
hodTracker method, ParameterInfo[] pis, Int32 paramOffset)
   at 
IronPython.Compiler.ReflectOptimizer.MultiCallGenerator.EmitFinalCall(Meth
odTracker method)
   at IronPython.Compiler.ReflectOptimizer.MultiCallGenerator.Walk(Int32 
param,
ParamTreeNode node)
   at IronPython.Compiler.ParamTree.WalkWorker(IParamWalker callback, 
ParamTreeN
ode curNode, Int32 depth)
   at IronPython.Compiler.ParamTree.Walk(IParamWalker callback)
   at IronPython.Compiler.ReflectOptimizer.GenerateTargetMethod(TypeGen 
tg, Stri
ng name, FunctionType funcType, MethodTracker[] methods, Int32 argCnt, 
Boolean p
aramsMethod)
   at IronPython.Compiler.ReflectOptimizer.GenerateAllTargets(TypeGen 
tg, String
 name, MethodTracker[] methods, FunctionType funcType)
   at IronPython.Compiler.ReflectOptimizer.MakeFunction(BuiltinFunction rm)
   at IronPython.Runtime.ReflectedMethodBase.OptimizeMethod()
   at IronPython.Runtime.ReflectedMethodBase.TryOptimizedCall(Object[] 
args, Obj
ect& ret)
   at IronPython.Runtime.ReflectedMethodBase.TryCallWorker(Object[] 
args, Object
& ret)
   at IronPython.Runtime.ReflectedMethodBase.Call(Object[] args)
   at IronPython.Runtime.ReflectedMethodBase.Call(ICallerContext 
context, Object
[] args)
   at IronPython.Runtime.ReflectedMethodBase.Call(ICallerContext 
context, Object
 arg0)
   at IronPython.Runtime.Ops.CallWithContext(ICallerContext context, 
Object func
, Object arg0)
   at __main__.testOut$f0(FunctionEnvironment16Dictionary $env, Object 
self) in
C:\IronPythonTest.py:line 21
   at IronPython.Runtime.Function1.Call(Object arg0)
   at IronPython.Runtime.Ops.Call(Object func, Object arg0)
   at IronPython.Runtime.Method.Call()
   at IronPython.Runtime.Ops.CallWithContext(ICallerContext context, 
Object func
)

However, if we change the order of the parameters so that "bool ignore" 
is the first one, it works !%$?"#@&&*

We think this worked in beta 4, as we only caught this when moving our 
code to the beta 6 IronPython.

See the following email for previous discussions on the subject :

    
http://lists.ironpython.com/pipermail/users-ironpython.com/2005-May/000644.html

Andrzej Krzywda
Michael Foord
http://www.resolversystems.com


From shafranov at gmail.com  Mon May 15 16:04:42 2006
From: shafranov at gmail.com (Alexander Shafranov)
Date: Mon, 15 May 2006 18:04:42 +0400
Subject: [IronPython] making assemblies
Message-ID: <74fc943d0605150704h23c85d35n819cdd1cdaf8b442@mail.gmail.com>

Hi all,

Why standalone compiler isn't provided for IronPython? I see only
IronPythonConsole.
Is there any way to create IronPython assembly, usable from C#?

Alexander.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060515/ca042c87/attachment.html>

From dinov at exchange.microsoft.com  Mon May 15 17:59:44 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 15 May 2006 08:59:44 -0700
Subject: [IronPython] making assemblies
In-Reply-To: <74fc943d0605150704h23c85d35n819cdd1cdaf8b442@mail.gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E387FB0AF@df-foxhound-msg.exchange.corp.microsoft.com>

This is something that we're slowly working on but may not have done in time for v1.0.  We do have some compiler support in IronPython, but the assemblies aren't usable from C#.  The challenge here is mapping a highly dynamic language like Python into a world that C# can see w/o altering the language semantics of Python.

Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Alexander Shafranov
Sent: Monday, May 15, 2006 7:05 AM
To: users at lists.ironpython.com
Subject: [IronPython] making assemblies

Hi all,

Why standalone compiler isn't provided for IronPython? I see only IronPythonConsole.
Is there any way to create IronPython assembly, usable from C#?

Alexander.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060515/6040a268/attachment.html>

From dinov at exchange.microsoft.com  Mon May 15 18:10:46 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 15 May 2006 09:10:46 -0700
Subject: [IronPython] out parameters
In-Reply-To: <446887BE.1090908@resolversystems.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E387FB0CE@df-foxhound-msg.exchange.corp.microsoft.com>

Thanks for the bug report.  This is due to the enabling of our optimized code paths for all calls into C#.  I'll get a bug on this one filed and it should be fixed for beta 7 (tentatively scheduled for later this week).

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Andrzej Krzywda
Sent: Monday, May 15, 2006 6:53 AM
To: users at lists.ironpython.com
Subject: [IronPython] out parameters

Hi all,

Having the following piece of C# code (note the ignore parameter):

    public class C
    {
        public static int M(out int i, out int j, out int k, bool ignore)
        {
            i = 20;
            j = 30;
            k = 40;
            return 10;
        }
    }


we call it from IronPython Beta 6:

i = C.M(True)

and we get :

        Unhandled Exception: generate:  type: System.DBNull
   at IronPython.Compiler.CodeGen.EmitRawConstant(Object value)
   at
IronPython.Compiler.ReflectOptimizer.MultiCallGenerator.EmitDefaultValue(I
nt32 param, MethodTracker method)
   at
IronPython.Compiler.ReflectOptimizer.MultiCallGenerator.EmitParameter(Meth
odTracker method, ParameterInfo pi, Int32 param)
   at
IronPython.Compiler.ReflectOptimizer.MultiCallGenerator.EmitParameters(Met
hodTracker method, ParameterInfo[] pis, Int32 paramOffset)
   at
IronPython.Compiler.ReflectOptimizer.MultiCallGenerator.EmitFinalCall(Meth
odTracker method)
   at IronPython.Compiler.ReflectOptimizer.MultiCallGenerator.Walk(Int32
param,
ParamTreeNode node)
   at IronPython.Compiler.ParamTree.WalkWorker(IParamWalker callback,
ParamTreeN
ode curNode, Int32 depth)
   at IronPython.Compiler.ParamTree.Walk(IParamWalker callback)
   at IronPython.Compiler.ReflectOptimizer.GenerateTargetMethod(TypeGen
tg, Stri
ng name, FunctionType funcType, MethodTracker[] methods, Int32 argCnt,
Boolean p
aramsMethod)
   at IronPython.Compiler.ReflectOptimizer.GenerateAllTargets(TypeGen
tg, String
 name, MethodTracker[] methods, FunctionType funcType)
   at IronPython.Compiler.ReflectOptimizer.MakeFunction(BuiltinFunction rm)
   at IronPython.Runtime.ReflectedMethodBase.OptimizeMethod()
   at IronPython.Runtime.ReflectedMethodBase.TryOptimizedCall(Object[]
args, Obj
ect& ret)
   at IronPython.Runtime.ReflectedMethodBase.TryCallWorker(Object[]
args, Object
& ret)
   at IronPython.Runtime.ReflectedMethodBase.Call(Object[] args)
   at IronPython.Runtime.ReflectedMethodBase.Call(ICallerContext
context, Object
[] args)
   at IronPython.Runtime.ReflectedMethodBase.Call(ICallerContext
context, Object
 arg0)
   at IronPython.Runtime.Ops.CallWithContext(ICallerContext context,
Object func
, Object arg0)
   at __main__.testOut$f0(FunctionEnvironment16Dictionary $env, Object
self) in
C:\IronPythonTest.py:line 21
   at IronPython.Runtime.Function1.Call(Object arg0)
   at IronPython.Runtime.Ops.Call(Object func, Object arg0)
   at IronPython.Runtime.Method.Call()
   at IronPython.Runtime.Ops.CallWithContext(ICallerContext context,
Object func
)

However, if we change the order of the parameters so that "bool ignore"
is the first one, it works !%$?"#@&&*

We think this worked in beta 4, as we only caught this when moving our
code to the beta 6 IronPython.

See the following email for previous discussions on the subject :


http://lists.ironpython.com/pipermail/users-ironpython.com/2005-May/000644.html

Andrzej Krzywda
Michael Foord
http://www.resolversystems.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From alex at syzmk.com  Mon May 15 22:09:27 2006
From: alex at syzmk.com (Alex Henderson)
Date: Tue, 16 May 2006 08:09:27 +1200
Subject: [IronPython] Line numbers in snippets...
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214E387FB0AF@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <00d801c6785b$78190320$6601a8c0@tokai>

We've been using IronPython as a scripting engine in one of our products
that's in development for a while now, works great :)

However when executing code which has syntax errors in it we can't seem to
get line numbers back from the exception, or find any compilation context we
can examine for a list of errors - which makes it difficult to diagnose
problems obviously.

I figure this is probably a limitation of the execute method, unless I've
missed something... is there a different approach we could use where we will
get line numbers when an error occurs?

Chez,

 - Alex



From dinov at exchange.microsoft.com  Mon May 15 22:20:41 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 15 May 2006 13:20:41 -0700
Subject: [IronPython] Line numbers in snippets...
In-Reply-To: <00d801c6785b$78190320$6601a8c0@tokai>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EE7005A8E@df-foxhound-msg.exchange.corp.microsoft.com>

We recently made a change so that PythonSyntaxError contains a Line, Column, Filename, and some other properties on it that you should be able to get at for this information.  Is that what you're looking for?


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Alex Henderson
Sent: Monday, May 15, 2006 1:09 PM
To: 'Discussion of IronPython'
Subject: [IronPython] Line numbers in snippets...

We've been using IronPython as a scripting engine in one of our products
that's in development for a while now, works great :)

However when executing code which has syntax errors in it we can't seem to
get line numbers back from the exception, or find any compilation context we
can examine for a list of errors - which makes it difficult to diagnose
problems obviously.

I figure this is probably a limitation of the execute method, unless I've
missed something... is there a different approach we could use where we will
get line numbers when an error occurs?

Chez,

 - Alex

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From alex at syzmk.com  Mon May 15 22:48:05 2006
From: alex at syzmk.com (Alex Henderson)
Date: Tue, 16 May 2006 08:48:05 +1200
Subject: [IronPython] Line numbers in snippets...
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214EE7005A8E@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <00dc01c67860$ddf76790$6601a8c0@tokai>

Not quite... my problem is I don't have a PythonSyntaxError thrown, I
believe that's because I'm actually receiving a python generated exception,
for instance I might catch a PythonNameError when someone incorrectly spells
a variable name... and that doesn't contain any information I can use the
locate where in the snippet string the error occurred... Is there a way to
get this information out of the PythonEngine itself perhaps?

The reason I ask that I just want to implement a feature where by a user can
look at a log "view" in our product, see an error has occurred in their
script, and be able to double click the entry and navigate to our code
editor and be on the right line for fixing the problem - for this to happen
we need to be able to extract some details of where the error occurred when
using PythonEngine.Execute...

Any ideas I would be greatly appreciated... :)

Chez,

 - Alex

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Tuesday, 16 May 2006 8:21 a.m.
> To: Discussion of IronPython
> Subject: Re: [IronPython] Line numbers in snippets...
> 
> We recently made a change so that PythonSyntaxError contains a Line,
> Column, Filename, and some other properties on it that you should be able
> to get at for this information.  Is that what you're looking for?
> 
> 
> Do you want to help develop Dynamic languages on CLR?
> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-
> 11F0-45DF-8B78-DC1B43134038)
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Alex Henderson
> Sent: Monday, May 15, 2006 1:09 PM
> To: 'Discussion of IronPython'
> Subject: [IronPython] Line numbers in snippets...
> 
> We've been using IronPython as a scripting engine in one of our products
> that's in development for a while now, works great :)
> 
> However when executing code which has syntax errors in it we can't seem to
> get line numbers back from the exception, or find any compilation context
> we
> can examine for a list of errors - which makes it difficult to diagnose
> problems obviously.
> 
> I figure this is probably a limitation of the execute method, unless I've
> missed something... is there a different approach we could use where we
> will
> get line numbers when an error occurs?
> 
> Chez,
> 
>  - Alex
> 
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From dinov at exchange.microsoft.com  Mon May 15 22:55:00 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 15 May 2006 13:55:00 -0700
Subject: [IronPython] Line numbers in snippets...
In-Reply-To: <00dc01c67860$ddf76790$6601a8c0@tokai>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EE7005B17@df-foxhound-msg.exchange.corp.microsoft.com>

Ahh, ok...  Can you wrap the user code you run w/ more python code?  If you could then you could do:

try:
        // run user code
except:
        import sys
        print sys.exc_info()[2].tb_lineno
        print sys.exc_info()[2].tb_frame.f_code.co_filename

That's the Python way to get this information.  Let us know if that seems to burdensome.  If so we could look at a way to expose this information via the engine APIs instead of requiring you to create this wrapper.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Alex Henderson
Sent: Monday, May 15, 2006 1:48 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Line numbers in snippets...

Not quite... my problem is I don't have a PythonSyntaxError thrown, I
believe that's because I'm actually receiving a python generated exception,
for instance I might catch a PythonNameError when someone incorrectly spells
a variable name... and that doesn't contain any information I can use the
locate where in the snippet string the error occurred... Is there a way to
get this information out of the PythonEngine itself perhaps?

The reason I ask that I just want to implement a feature where by a user can
look at a log "view" in our product, see an error has occurred in their
script, and be able to double click the entry and navigate to our code
editor and be on the right line for fixing the problem - for this to happen
we need to be able to extract some details of where the error occurred when
using PythonEngine.Execute...

Any ideas I would be greatly appreciated... :)

Chez,

 - Alex

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Tuesday, 16 May 2006 8:21 a.m.
> To: Discussion of IronPython
> Subject: Re: [IronPython] Line numbers in snippets...
>
> We recently made a change so that PythonSyntaxError contains a Line,
> Column, Filename, and some other properties on it that you should be able
> to get at for this information.  Is that what you're looking for?
>
>
> Do you want to help develop Dynamic languages on CLR?
> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-
> 11F0-45DF-8B78-DC1B43134038)
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Alex Henderson
> Sent: Monday, May 15, 2006 1:09 PM
> To: 'Discussion of IronPython'
> Subject: [IronPython] Line numbers in snippets...
>
> We've been using IronPython as a scripting engine in one of our products
> that's in development for a while now, works great :)
>
> However when executing code which has syntax errors in it we can't seem to
> get line numbers back from the exception, or find any compilation context
> we
> can examine for a list of errors - which makes it difficult to diagnose
> problems obviously.
>
> I figure this is probably a limitation of the execute method, unless I've
> missed something... is there a different approach we could use where we
> will
> get line numbers when an error occurs?
>
> Chez,
>
>  - Alex
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From alex at syzmk.com  Mon May 15 23:03:47 2006
From: alex at syzmk.com (Alex Henderson)
Date: Tue, 16 May 2006 09:03:47 +1200
Subject: [IronPython] Line numbers in snippets...
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214EE7005B17@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <00e601c67863$0f37fa20$6601a8c0@tokai>

Ahhh... hadn't thought about that ;o) hmm... All the calls to the script
engine are wrapped up against a simplified engine interface as it is, as we
are attempting to be at least partly script-engine agnostic... so I can't
see why I couldn't do that, and wrap the exception in one of our own, tagged
with the additional error location info.

I'll give it a go, and if you don't hear from me then you'll know it
worked...  I'm a bit of a python newbie, I assume it's easy enough to grab
hold of a stack trace as well as the line number etc?

Thanks Dino,
 
 - Alex

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Tuesday, 16 May 2006 8:55 a.m.
> To: Discussion of IronPython
> Subject: Re: [IronPython] Line numbers in snippets...
> 
> Ahh, ok...  Can you wrap the user code you run w/ more python code?  If
> you could then you could do:
> 
> try:
>         // run user code
> except:
>         import sys
>         print sys.exc_info()[2].tb_lineno
>         print sys.exc_info()[2].tb_frame.f_code.co_filename
> 
> That's the Python way to get this information.  Let us know if that seems
> to burdensome.  If so we could look at a way to expose this information
> via the engine APIs instead of requiring you to create this wrapper.
> 
> 
> Do you want to help develop Dynamic languages on CLR?
> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-
> 11F0-45DF-8B78-DC1B43134038)
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Alex Henderson
> Sent: Monday, May 15, 2006 1:48 PM
> To: 'Discussion of IronPython'
> Subject: Re: [IronPython] Line numbers in snippets...
> 
> Not quite... my problem is I don't have a PythonSyntaxError thrown, I
> believe that's because I'm actually receiving a python generated
> exception,
> for instance I might catch a PythonNameError when someone incorrectly
> spells
> a variable name... and that doesn't contain any information I can use the
> locate where in the snippet string the error occurred... Is there a way to
> get this information out of the PythonEngine itself perhaps?
> 
> The reason I ask that I just want to implement a feature where by a user
> can
> look at a log "view" in our product, see an error has occurred in their
> script, and be able to double click the entry and navigate to our code
> editor and be on the right line for fixing the problem - for this to
> happen
> we need to be able to extract some details of where the error occurred
> when
> using PythonEngine.Execute...
> 
> Any ideas I would be greatly appreciated... :)
> 
> Chez,
> 
>  - Alex
> 
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com [mailto:users-
> > bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> > Sent: Tuesday, 16 May 2006 8:21 a.m.
> > To: Discussion of IronPython
> > Subject: Re: [IronPython] Line numbers in snippets...
> >
> > We recently made a change so that PythonSyntaxError contains a Line,
> > Column, Filename, and some other properties on it that you should be
> able
> > to get at for this information.  Is that what you're looking for?
> >
> >
> > Do you want to help develop Dynamic languages on CLR?
> >
> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-
> > 11F0-45DF-8B78-DC1B43134038)
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com [mailto:users-
> > bounces at lists.ironpython.com] On Behalf Of Alex Henderson
> > Sent: Monday, May 15, 2006 1:09 PM
> > To: 'Discussion of IronPython'
> > Subject: [IronPython] Line numbers in snippets...
> >
> > We've been using IronPython as a scripting engine in one of our products
> > that's in development for a while now, works great :)
> >
> > However when executing code which has syntax errors in it we can't seem
> to
> > get line numbers back from the exception, or find any compilation
> context
> > we
> > can examine for a list of errors - which makes it difficult to diagnose
> > problems obviously.
> >
> > I figure this is probably a limitation of the execute method, unless
> I've
> > missed something... is there a different approach we could use where we
> > will
> > get line numbers when an error occurs?
> >
> > Chez,
> >
> >  - Alex
> >
> > _______________________________________________
> > users mailing list
> > users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > _______________________________________________
> > users mailing list
> > users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From dinov at exchange.microsoft.com  Mon May 15 23:13:36 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 15 May 2006 14:13:36 -0700
Subject: [IronPython] Line numbers in snippets...
In-Reply-To: <00e601c67863$0f37fa20$6601a8c0@tokai>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EE7005B6D@df-foxhound-msg.exchange.corp.microsoft.com>

The stack trace is a little odd in that it's given to you as a linked list, and you need to pull it out by indexing into an array, but other than that it's straight forward (the only thing different from what I showed you below is sys.exc_info()[2].tb_next will get you the 2nd frame (and .tb_next on that, and so on)...

Even if you do get it to work let us know how painful it is, that'll help us prioritize considering making this easier in the future.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Alex Henderson
Sent: Monday, May 15, 2006 2:04 PM
To: 'Discussion of IronPython'
Subject: Re: [IronPython] Line numbers in snippets...

Ahhh... hadn't thought about that ;o) hmm... All the calls to the script
engine are wrapped up against a simplified engine interface as it is, as we
are attempting to be at least partly script-engine agnostic... so I can't
see why I couldn't do that, and wrap the exception in one of our own, tagged
with the additional error location info.

I'll give it a go, and if you don't hear from me then you'll know it
worked...  I'm a bit of a python newbie, I assume it's easy enough to grab
hold of a stack trace as well as the line number etc?

Thanks Dino,

 - Alex

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Tuesday, 16 May 2006 8:55 a.m.
> To: Discussion of IronPython
> Subject: Re: [IronPython] Line numbers in snippets...
>
> Ahh, ok...  Can you wrap the user code you run w/ more python code?  If
> you could then you could do:
>
> try:
>         // run user code
> except:
>         import sys
>         print sys.exc_info()[2].tb_lineno
>         print sys.exc_info()[2].tb_frame.f_code.co_filename
>
> That's the Python way to get this information.  Let us know if that seems
> to burdensome.  If so we could look at a way to expose this information
> via the engine APIs instead of requiring you to create this wrapper.
>
>
> Do you want to help develop Dynamic languages on CLR?
> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-
> 11F0-45DF-8B78-DC1B43134038)
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Alex Henderson
> Sent: Monday, May 15, 2006 1:48 PM
> To: 'Discussion of IronPython'
> Subject: Re: [IronPython] Line numbers in snippets...
>
> Not quite... my problem is I don't have a PythonSyntaxError thrown, I
> believe that's because I'm actually receiving a python generated
> exception,
> for instance I might catch a PythonNameError when someone incorrectly
> spells
> a variable name... and that doesn't contain any information I can use the
> locate where in the snippet string the error occurred... Is there a way to
> get this information out of the PythonEngine itself perhaps?
>
> The reason I ask that I just want to implement a feature where by a user
> can
> look at a log "view" in our product, see an error has occurred in their
> script, and be able to double click the entry and navigate to our code
> editor and be on the right line for fixing the problem - for this to
> happen
> we need to be able to extract some details of where the error occurred
> when
> using PythonEngine.Execute...
>
> Any ideas I would be greatly appreciated... :)
>
> Chez,
>
>  - Alex
>
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com [mailto:users-
> > bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> > Sent: Tuesday, 16 May 2006 8:21 a.m.
> > To: Discussion of IronPython
> > Subject: Re: [IronPython] Line numbers in snippets...
> >
> > We recently made a change so that PythonSyntaxError contains a Line,
> > Column, Filename, and some other properties on it that you should be
> able
> > to get at for this information.  Is that what you're looking for?
> >
> >
> > Do you want to help develop Dynamic languages on CLR?
> >
> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-
> > 11F0-45DF-8B78-DC1B43134038)
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com [mailto:users-
> > bounces at lists.ironpython.com] On Behalf Of Alex Henderson
> > Sent: Monday, May 15, 2006 1:09 PM
> > To: 'Discussion of IronPython'
> > Subject: [IronPython] Line numbers in snippets...
> >
> > We've been using IronPython as a scripting engine in one of our products
> > that's in development for a while now, works great :)
> >
> > However when executing code which has syntax errors in it we can't seem
> to
> > get line numbers back from the exception, or find any compilation
> context
> > we
> > can examine for a list of errors - which makes it difficult to diagnose
> > problems obviously.
> >
> > I figure this is probably a limitation of the execute method, unless
> I've
> > missed something... is there a different approach we could use where we
> > will
> > get line numbers when an error occurs?
> >
> > Chez,
> >
> >  - Alex
> >
> > _______________________________________________
> > users mailing list
> > users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > _______________________________________________
> > users mailing list
> > users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From alex at syzmk.com  Mon May 15 23:17:52 2006
From: alex at syzmk.com (Alex Henderson)
Date: Tue, 16 May 2006 09:17:52 +1200
Subject: [IronPython] Line numbers in snippets...
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214EE7005B6D@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <00ea01c67865$06c67fe0$6601a8c0@tokai>

Sure thing I'll keep you posted.

Chez,

 - Alex

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> Sent: Tuesday, 16 May 2006 9:14 a.m.
> To: Discussion of IronPython
> Subject: Re: [IronPython] Line numbers in snippets...
> 
> The stack trace is a little odd in that it's given to you as a linked
> list, and you need to pull it out by indexing into an array, but other
> than that it's straight forward (the only thing different from what I
> showed you below is sys.exc_info()[2].tb_next will get you the 2nd frame
> (and .tb_next on that, and so on)...
> 
> Even if you do get it to work let us know how painful it is, that'll help
> us prioritize considering making this easier in the future.
> 
> Do you want to help develop Dynamic languages on CLR?
> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-
> 11F0-45DF-8B78-DC1B43134038)
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Alex Henderson
> Sent: Monday, May 15, 2006 2:04 PM
> To: 'Discussion of IronPython'
> Subject: Re: [IronPython] Line numbers in snippets...
> 
> Ahhh... hadn't thought about that ;o) hmm... All the calls to the script
> engine are wrapped up against a simplified engine interface as it is, as
> we
> are attempting to be at least partly script-engine agnostic... so I can't
> see why I couldn't do that, and wrap the exception in one of our own,
> tagged
> with the additional error location info.
> 
> I'll give it a go, and if you don't hear from me then you'll know it
> worked...  I'm a bit of a python newbie, I assume it's easy enough to grab
> hold of a stack trace as well as the line number etc?
> 
> Thanks Dino,
> 
>  - Alex
> 
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com [mailto:users-
> > bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> > Sent: Tuesday, 16 May 2006 8:55 a.m.
> > To: Discussion of IronPython
> > Subject: Re: [IronPython] Line numbers in snippets...
> >
> > Ahh, ok...  Can you wrap the user code you run w/ more python code?  If
> > you could then you could do:
> >
> > try:
> >         // run user code
> > except:
> >         import sys
> >         print sys.exc_info()[2].tb_lineno
> >         print sys.exc_info()[2].tb_frame.f_code.co_filename
> >
> > That's the Python way to get this information.  Let us know if that
> seems
> > to burdensome.  If so we could look at a way to expose this information
> > via the engine APIs instead of requiring you to create this wrapper.
> >
> >
> > Do you want to help develop Dynamic languages on CLR?
> >
> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-
> > 11F0-45DF-8B78-DC1B43134038)
> >
> > -----Original Message-----
> > From: users-bounces at lists.ironpython.com [mailto:users-
> > bounces at lists.ironpython.com] On Behalf Of Alex Henderson
> > Sent: Monday, May 15, 2006 1:48 PM
> > To: 'Discussion of IronPython'
> > Subject: Re: [IronPython] Line numbers in snippets...
> >
> > Not quite... my problem is I don't have a PythonSyntaxError thrown, I
> > believe that's because I'm actually receiving a python generated
> > exception,
> > for instance I might catch a PythonNameError when someone incorrectly
> > spells
> > a variable name... and that doesn't contain any information I can use
> the
> > locate where in the snippet string the error occurred... Is there a way
> to
> > get this information out of the PythonEngine itself perhaps?
> >
> > The reason I ask that I just want to implement a feature where by a user
> > can
> > look at a log "view" in our product, see an error has occurred in their
> > script, and be able to double click the entry and navigate to our code
> > editor and be on the right line for fixing the problem - for this to
> > happen
> > we need to be able to extract some details of where the error occurred
> > when
> > using PythonEngine.Execute...
> >
> > Any ideas I would be greatly appreciated... :)
> >
> > Chez,
> >
> >  - Alex
> >
> > > -----Original Message-----
> > > From: users-bounces at lists.ironpython.com [mailto:users-
> > > bounces at lists.ironpython.com] On Behalf Of Dino Viehland
> > > Sent: Tuesday, 16 May 2006 8:21 a.m.
> > > To: Discussion of IronPython
> > > Subject: Re: [IronPython] Line numbers in snippets...
> > >
> > > We recently made a change so that PythonSyntaxError contains a Line,
> > > Column, Filename, and some other properties on it that you should be
> > able
> > > to get at for this information.  Is that what you're looking for?
> > >
> > >
> > > Do you want to help develop Dynamic languages on CLR?
> > >
> >
> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-
> > > 11F0-45DF-8B78-DC1B43134038)
> > > -----Original Message-----
> > > From: users-bounces at lists.ironpython.com [mailto:users-
> > > bounces at lists.ironpython.com] On Behalf Of Alex Henderson
> > > Sent: Monday, May 15, 2006 1:09 PM
> > > To: 'Discussion of IronPython'
> > > Subject: [IronPython] Line numbers in snippets...
> > >
> > > We've been using IronPython as a scripting engine in one of our
> products
> > > that's in development for a while now, works great :)
> > >
> > > However when executing code which has syntax errors in it we can't
> seem
> > to
> > > get line numbers back from the exception, or find any compilation
> > context
> > > we
> > > can examine for a list of errors - which makes it difficult to
> diagnose
> > > problems obviously.
> > >
> > > I figure this is probably a limitation of the execute method, unless
> > I've
> > > missed something... is there a different approach we could use where
> we
> > > will
> > > get line numbers when an error occurs?
> > >
> > > Chez,
> > >
> > >  - Alex
> > >
> > > _______________________________________________
> > > users mailing list
> > > users at lists.ironpython.com
> > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > > _______________________________________________
> > > users mailing list
> > > users at lists.ironpython.com
> > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
> > _______________________________________________
> > users mailing list
> > users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> > _______________________________________________
> > users mailing list
> > users at lists.ironpython.com
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> 
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From alessandro.freschi at alexide.com  Tue May 16 08:26:26 2006
From: alessandro.freschi at alexide.com (Freschi Alessandro - Alexide srl)
Date: Tue, 16 May 2006 08:26:26 +0200
Subject: [IronPython] Equals operator in IronPython beta 6
Message-ID: <001701c678b1$a9ae6140$6500a8c0@freschi>

Hi all,

After installing IP 1.0 Beta 6 I obtained an error with this commands:

IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> None == 'foo'
Traceback (most recent call last):
  File , line 0, in input##0
SystemError: Object reference not set to an instance of an object.
>>>


while With IP 1.0 Beta 5 I obtained this result:

IronPython 1.0.2280 (Beta) on .NET 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
>>> None == 'aaa'
False
>>>


Is it a bug of beta 6 version?


Alessandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060516/4ed7d87a/attachment.html>

From sanxiyn at gmail.com  Tue May 16 09:35:51 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Tue, 16 May 2006 16:35:51 +0900
Subject: [IronPython] Equals operator in IronPython beta 6
In-Reply-To: <001701c678b1$a9ae6140$6500a8c0@freschi>
References: <001701c678b1$a9ae6140$6500a8c0@freschi>
Message-ID: <5b0248170605160035oc58f344l59c966ed65cbb4a7@mail.gmail.com>

2006/5/16, Freschi Alessandro - Alexide srl <alessandro.freschi at alexide.com>:
> After installing IP 1.0 Beta 6 I obtained an error with this commands:
>
> IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42
> Copyright (c) Microsoft Corporation. All rights reserved.
> >>> None == 'foo'
> Traceback (most recent call last):
>   File , line 0, in input##0
> SystemError: Object reference not set to an instance of an object.
> >>>
>
> Is it a bug of beta 6 version?

Yes.

See http://lists.ironpython.com/pipermail/users-ironpython.com/2006-May/002248.html
and replies.

Seo Sanghyeon


From jvm_cop at spamcop.net  Tue May 16 17:50:28 2006
From: jvm_cop at spamcop.net (J. Merrill)
Date: Tue, 16 May 2006 11:50:28 -0400
Subject: [IronPython] Line numbers in snippets...
References: <00dc01c67860$ddf76790$6601a8c0@tokai>
Message-ID: <7.0.1.0.2.20060516113409.0437d8b8@wheresmymailserver.com>

Shouldn't all Python errors (not just Synax) provide the filename & line number?  Column number would often be less important, particularly for run-time (vs compile-time -- e.g. not Syntax) errors.

As a practical matter, how can it be that a PythonNameError exception doesn't provide a way to get at the name that couldn't be resolved?  What more important bit of info could there be?  (But I haven't looked to make sure that the name is NOT available in the latest IP.)

At 04:55 PM 5/15/2006, Dino Viehland wrote
>Ahh, ok...  Can you wrap the user code you run w/ more python code?  If you could then you could do:
>[snip]


J. Merrill / Analytical Software Corp




From alex at syzmk.com  Tue May 16 22:24:23 2006
From: alex at syzmk.com (Alex Henderson)
Date: Wed, 17 May 2006 08:24:23 +1200
Subject: [IronPython] Line numbers in snippets...
In-Reply-To: <7.0.1.0.2.20060516113409.0437d8b8@wheresmymailserver.com>
Message-ID: <00cb01c67926$b8918320$6601a8c0@tokai>

The name error exception does give you the name causing the grief, but the
line number isn't available, not without doing a little extra work (as Dino
outlined) by wrapping up the evaluation of the snippet within a python
try... except block and pulling some of the info in from sys.exc_info() and
exposing it to the application hosting the PythonEngine.  

The name isn't really enough for us, we need access to the line number and a
python stack trace so clients can better analyse what went wrong (we aren't
evaluating one line exceptions, these are like 100 line snippets)... and
there are some other errors where the information provided in the exception
makes it very difficult to resolve the issue without access to the
additional info.

Chez,

 - Alex

> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of J. Merrill
> Sent: Wednesday, 17 May 2006 3:50 a.m.
> To: Discussion of IronPython
> Subject: Re: [IronPython] Line numbers in snippets...
> 
> Shouldn't all Python errors (not just Synax) provide the filename & line
> number?  Column number would often be less important, particularly for
> run-time (vs compile-time -- e.g. not Syntax) errors.
> 
> As a practical matter, how can it be that a PythonNameError exception
> doesn't provide a way to get at the name that couldn't be resolved?  What
> more important bit of info could there be?  (But I haven't looked to make
> sure that the name is NOT available in the latest IP.)
> 
> At 04:55 PM 5/15/2006, Dino Viehland wrote
> >Ahh, ok...  Can you wrap the user code you run w/ more python code?  If
> you could then you could do:
> >[snip]
> 
> 
> J. Merrill / Analytical Software Corp
> 
> 
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



From glee at pharsight.com  Wed May 17 00:16:48 2006
From: glee at pharsight.com (Greg Lee)
Date: Tue, 16 May 2006 15:16:48 -0700
Subject: [IronPython] from xml import xpath
Message-ID: <5B833E900330354F9FDA984D06F924284C1545@ca-exchange.corp.pharsight.com>

I'm porting an application that uses PyXML.  The following from the PyXml documentation http://pyxml.sourceforge.net/topics/howto/section-XPath.html doesn't work:

from xml import xpath
Traceback (most recent call last):
  File , line 0, in input##113
ImportError: cannot import xpath from xml

Any suggestions?  I messed around with adding site-packages to IRONPYTHONPATH but other BadThings happened.

Here's the installation:

Microsoft Windows XP [Version 5.1.2600]
IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42

python 2.4.2
pyxml 0.8.4
pywin32 205
py2exe 0.6.3

IRONPYTHONPATH = c:\python24\lib

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060516/0fff6602/attachment.html>

From michael.foord at resolversystems.com  Wed May 17 15:35:39 2006
From: michael.foord at resolversystems.com (Michael Foord)
Date: Wed, 17 May 2006 14:35:39 +0100
Subject: [IronPython] Dictionary Ordering
Message-ID: <446B26AB.4090108@resolversystems.com>

Hello all,

IronPython seems to default to have a dictionary 'ordering' based on key 
insertion order.

This is nice, but differs from the CPython implementation. However the 
spec (as I'm sure you're aware) says : (from 
http://docs.python.org/lib/typesmapping.html )

     Keys and values are listed in an arbitrary order which is 
non-random, varies across Python
    implementations, and depends on the dictionary's history of 
insertions and deletions.

So IronPython behaviour is well within the spec. My question is, can we 
rely on the ordered behaviour of IronPython ? (Or is it an 
implementation detail that may change in future versions ?)

Michael Foord
http://www.resolversystems.com




From dinov at exchange.microsoft.com  Wed May 17 17:14:57 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 17 May 2006 08:14:57 -0700
Subject: [IronPython] Dictionary Ordering
In-Reply-To: <446B26AB.4090108@resolversystems.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EE77979F5@df-foxhound-msg.exchange.corp.microsoft.com>

It's an implementation detail which may change in future versions.

There's a OrderedDict in the Python cookbook though that should work w/ IP.

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/438823



Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Wednesday, May 17, 2006 6:36 AM
To: Discussion of IronPython
Subject: [IronPython] Dictionary Ordering

Hello all,

IronPython seems to default to have a dictionary 'ordering' based on key
insertion order.

This is nice, but differs from the CPython implementation. However the
spec (as I'm sure you're aware) says : (from
http://docs.python.org/lib/typesmapping.html )

     Keys and values are listed in an arbitrary order which is
non-random, varies across Python
    implementations, and depends on the dictionary's history of
insertions and deletions.

So IronPython behaviour is well within the spec. My question is, can we
rely on the ordered behaviour of IronPython ? (Or is it an
implementation detail that may change in future versions ?)

Michael Foord
http://www.resolversystems.com


_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Wed May 17 20:11:47 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 17 May 2006 11:11:47 -0700
Subject: [IronPython] from xml import xpath
In-Reply-To: <5B833E900330354F9FDA984D06F924284C1545@ca-exchange.corp.pharsight.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EE7797BC2@df-foxhound-msg.exchange.corp.microsoft.com>

This doesn't work for my in CPython 2.4 either, so I think the docs are wrong:

>>> from xml import xpath
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: cannot import name xpath
>>> import sys
>>> sys.version
'2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]'
>>>

Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Greg Lee
Sent: Tuesday, May 16, 2006 3:17 PM
To: users at lists.ironpython.com
Subject: [IronPython] from xml import xpath


I'm porting an application that uses PyXML.  The following from the PyXml documentation http://pyxml.sourceforge.net/topics/howto/section-XPath.html doesn't work:

from xml import xpath
Traceback (most recent call last):
  File , line 0, in input##113
ImportError: cannot import xpath from xml

Any suggestions?  I messed around with adding site-packages to IRONPYTHONPATH but other BadThings happened.

Here's the installation:

Microsoft Windows XP [Version 5.1.2600]
IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42

python 2.4.2
pyxml 0.8.4
pywin32 205
py2exe 0.6.3

IRONPYTHONPATH = c:\python24\lib
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060517/b4a635e4/attachment.html>

From simon.dahlbacka at gmail.com  Wed May 17 20:41:25 2006
From: simon.dahlbacka at gmail.com (Simon Dahlbacka)
Date: Wed, 17 May 2006 21:41:25 +0300
Subject: [IronPython] from xml import xpath
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214EE7797BC2@df-foxhound-msg.exchange.corp.microsoft.com>
References: <5B833E900330354F9FDA984D06F924284C1545@ca-exchange.corp.pharsight.com>
	<4039D552ADAB094BB1EA670F3E96214EE7797BC2@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <57124720605171141s39e44ed8yf2d70e409ec430cd@mail.gmail.com>

Dino, you seemed to have missed the part about pyxml..

It works in cpython with pyxml installed. However, pyxml is playing tricks
with paths etc, and there might even be pyd:s involved..

C:\Python24>python.exe
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml
>>> xml.__file__
'C:\\Python24\\lib\\site-packages\\_xmlplus\\__init__.pyc'
>>> from xml import xpath
>>>

On 5/17/06, Dino Viehland <dinov at exchange.microsoft.com> wrote:
>
>  This doesn't work for my in CPython 2.4 either, so I think the docs are
> wrong:
>
>
>
> >>> from xml import xpath
>
> Traceback (most recent call last):
>
>   File "<stdin>", line 1, in ?
>
> ImportError: cannot import name xpath
>
> >>> import sys
>
> >>> sys.version
>
> '2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]'
>
> >>>
>
>
>
> Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038>
> (
> http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038
> )
>   ------------------------------
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Greg Lee
> *Sent:* Tuesday, May 16, 2006 3:17 PM
> *To:* users at lists.ironpython.com
> *Subject:* [IronPython] from xml import xpath
>
>
>
> I'm porting an application that uses PyXML.  The following from the PyXml
> documentation http://pyxml.sourceforge.net/topics/howto/section-XPath.htmldoesn't work:
>
> from xml import xpath
> Traceback (most recent call last):
>   File , line 0, in input##113
> ImportError: cannot import xpath from xml
>
> Any suggestions?  I messed around with adding site-packages to
> IRONPYTHONPATH but other BadThings happened.
>
> Here's the installation:
>
> Microsoft Windows XP [Version 5.1.2600]
> IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42
>
> python 2.4.2
> pyxml 0.8.4
> pywin32 205
> py2exe 0.6.3
>
> IRONPYTHONPATH = c:\python24\lib
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060517/11bf238b/attachment.html>

From dinov at exchange.microsoft.com  Wed May 17 20:50:03 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 17 May 2006 11:50:03 -0700
Subject: [IronPython] from xml import xpath
In-Reply-To: <57124720605171141s39e44ed8yf2d70e409ec430cd@mail.gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EE7797C39@df-foxhound-msg.exchange.corp.microsoft.com>

You're right, I did miss that...  Looking at this page: http://pyxml.sourceforge.net/topics/howto/section-install.html  It would seem that you may be right about the Pyd's (it at least requires a C compiler, making that likely - and almost guaranteeing it won't work w/ IronPython).

Unfortunately we don't support PYD's currently (and aren't likely to soon) so most likely this won't currently work. If you absolutely need XPath support in the mean time I'd suggest using .NET's XMLPath (and if you need to work on both you could make a thin wrapper over either PyXml for CPython and .NET's XPath support).  For example:

import clr
clr.AddReference('System.Xml')
import System.Xml.XPath as XPath

xpathDoc = XPath.XPathDocument('file://foo.txt')



Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Simon Dahlbacka
Sent: Wednesday, May 17, 2006 11:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] from xml import xpath

Dino, you seemed to have missed the part about pyxml..

It works in cpython with pyxml installed. However, pyxml is playing tricks with paths etc, and there might even be pyd:s involved..

C:\Python24>python.exe
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml
>>> xml.__file__
'C:\\Python24\\lib\\site-packages\\_xmlplus\\__init__.pyc'
>>> from xml import xpath
>>>

On 5/17/06, Dino Viehland <dinov at exchange.microsoft.com<mailto:dinov at exchange.microsoft.com>> wrote:

This doesn't work for my in CPython 2.4 either, so I think the docs are wrong:

>>> from xml import xpath

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

ImportError: cannot import name xpath

>>> import sys

>>> sys.version

'2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]'

>>>

Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> ( http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
________________________________

From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Greg Lee
Sent: Tuesday, May 16, 2006 3:17 PM
To: users at lists.ironpython.com<mailto:users at lists.ironpython.com>
Subject: [IronPython] from xml import xpath

I'm porting an application that uses PyXML.  The following from the PyXml documentation http://pyxml.sourceforge.net/topics/howto/section-XPath.html doesn't work:

from xml import xpath
Traceback (most recent call last):
  File , line 0, in input##113
ImportError: cannot import xpath from xml

Any suggestions?  I messed around with adding site-packages to IRONPYTHONPATH but other BadThings happened.

Here's the installation:

Microsoft Windows XP [Version 5.1.2600]
IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42

python 2.4.2
pyxml 0.8.4
pywin32 205
py2exe 0.6.3

IRONPYTHONPATH = c:\python24\lib

_______________________________________________
users mailing list
users at lists.ironpython.com<mailto:users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060517/2947fa52/attachment.html>

From jvm_cop at spamcop.net  Wed May 17 21:01:33 2006
From: jvm_cop at spamcop.net (J. Merrill)
Date: Wed, 17 May 2006 15:01:33 -0400
Subject: [IronPython] Line numbers in snippets...
In-Reply-To: <00cb01c67926$b8918320$6601a8c0@tokai>
References: <7.0.1.0.2.20060516113409.0437d8b8@wheresmymailserver.com>
	<00cb01c67926$b8918320$6601a8c0@tokai>
Message-ID: <7.0.1.0.2.20060517145125.04054f40@wheresmymailserver.com>

I was trying to suggest to the IP developers that access to file, line and perhaps column should be readily available from any exception.  Your response suggests that I might not have said so clearly.

When there's a Name Error, it's often possible to work on solving the problem without line number info -- you can look at the script for where the bad name is used.  (In the particular case of Name Error, the code that's wrong isn't necessarily on the line that was running when the exception occurs -- if you define a method named SpelledRite and other code calls method SpelledRight, the error will be on the line that does the call, regardless of which name you intended to use.)

At 04:24 PM 5/16/2006, Alex Henderson wrote
>The name error exception does give you the name causing the grief, but the
>line number isn't available, not without doing a little extra work (as Dino
>outlined) by wrapping up the evaluation of the snippet within a python
>try... except block and pulling some of the info in from sys.exc_info() and
>exposing it to the application hosting the PythonEngine.  
>
>The name isn't really enough for us, we need access to the line number and a
>python stack trace so clients can better analyse what went wrong (we aren't
>evaluating one line exceptions, these are like 100 line snippets)... and
>there are some other errors where the information provided in the exception
>makes it very difficult to resolve the issue without access to the
>additional info.
>
>Chez,
>
> - Alex
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of J. Merrill
>> Sent: Wednesday, 17 May 2006 3:50 a.m.
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Line numbers in snippets...
>> 
>> Shouldn't all Python errors (not just Synax) provide the filename & line
>> number?  Column number would often be less important, particularly for
>> run-time (vs compile-time -- e.g. not Syntax) errors.
>> 
>> As a practical matter, how can it be that a PythonNameError exception
>> doesn't provide a way to get at the name that couldn't be resolved?  What
>> more important bit of info could there be?  (But I haven't looked to make
>> sure that the name is NOT available in the latest IP.)
>> 
>> At 04:55 PM 5/15/2006, Dino Viehland wrote
>> >Ahh, ok...  Can you wrap the user code you run w/ more python code?  If
>> you could then you could do:
>> >[snip]


J. Merrill / Analytical Software Corp




From fuzzyman at voidspace.org.uk  Thu May 18 00:44:04 2006
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 17 May 2006 23:44:04 +0100
Subject: [IronPython] Dictionary Ordering
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214EE77979F5@df-foxhound-msg.exchange.corp.microsoft.com>
References: <4039D552ADAB094BB1EA670F3E96214EE77979F5@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <446BA734.7010906@voidspace.org.uk>

Dino Viehland wrote:
> It's an implementation detail which may change in future versions.
>
> There's a OrderedDict in the Python cookbook though that should work w/ IP.
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/438823
>
>   
Hey - there's an even better one at :

    http://www.voidspace.org.uk/python/odict.html

:-)

I was wondering whether the ordering in IronPython was a design decision 
or a con-incidence.

We've just upgraded (downgraded ?) our unit tests from a home-brew 
system to PyUnit. Our own system ran tests in the order they were 
defined, which was just a co-incidence as it turns out - not a design 
decision on our part.

That change alone has uncovered a few issues for us, which in the long 
run is a good thing I guess.

Michael Foord
http://www.voidspace.org.uk/python/index.shtml

>
> Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Wednesday, May 17, 2006 6:36 AM
> To: Discussion of IronPython
> Subject: [IronPython] Dictionary Ordering
>
> Hello all,
>
> IronPython seems to default to have a dictionary 'ordering' based on key
> insertion order.
>
> This is nice, but differs from the CPython implementation. However the
> spec (as I'm sure you're aware) says : (from
> http://docs.python.org/lib/typesmapping.html )
>
>      Keys and values are listed in an arbitrary order which is
> non-random, varies across Python
>     implementations, and depends on the dictionary's history of
> insertions and deletions.
>
> So IronPython behaviour is well within the spec. My question is, can we
> rely on the ordered behaviour of IronPython ? (Or is it an
> implementation detail that may change in future versions ?)
>
> Michael Foord
> http://www.resolversystems.com
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From jvm_cop at spamcop.net  Thu May 18 04:31:36 2006
From: jvm_cop at spamcop.net (J. Merrill)
Date: Wed, 17 May 2006 22:31:36 -0400
Subject: [IronPython] Dictionary Ordering
In-Reply-To: <446BA734.7010906@voidspace.org.uk>
References: <4039D552ADAB094BB1EA670F3E96214EE77979F5@df-foxhound-msg.exchange.corp.microsoft.com>
	<446BA734.7010906@voidspace.org.uk>
Message-ID: <7.0.1.0.2.20060517222843.087049a0@wheresmymailserver.com>

At 06:44 PM 5/17/2006, Michael Foord wrote (in part)
>Dino Viehland wrote (in part):
>> It's an implementation detail which may change in future versions.
>[snip]
>I was wondering whether the ordering in IronPython was a design decision or a con-incidence. [snip]

It's likely that a dictionary with many entries will not behave the same way.  (Basing a dictionary's internal structure on the basis of the number of entries is quite sensible; the structure (and algorithms) that will give best performance for millions of entries has more overhead than makes sense if there 10 of fewer, and vice versa.





J. Merrill / Analytical Software Corp




From s.kobalczyk at softwaremind.pl  Thu May 18 13:33:16 2006
From: s.kobalczyk at softwaremind.pl (Szymon Kobalczyk)
Date: Thu, 18 May 2006 13:33:16 +0200
Subject: [IronPython] IronPython project in CodePlex
Message-ID: <446C5B7C.1060707@softwaremind.pl>

Hi,

I've just learned from Michael Swanson's blog that IronPython will be 
hosted on CodePlex.
There is already project and wiki at 
http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython.
Looks preatty cool with the News Feeds, Forum, Issue Tracker and all.
Can't wait to see you moving there from GotDotNet.

Regards,
Szymon Kobalczyk


From michael.foord at resolversystems.com  Fri May 19 11:28:05 2006
From: michael.foord at resolversystems.com (Michael Foord)
Date: Fri, 19 May 2006 10:28:05 +0100
Subject: [IronPython] IronPython on the Compact .NET Framework
Message-ID: <446D8FA5.8030008@resolversystems.com>

Hello all,

I realise this has been discussed on the mailing list several times before.

Just to add that I (as an individual) and the company I work for 
(ResolverSystems) would be very interested in seeing IronPython for the 
.NET compact framework, were that to become possible. :-)

Any word on Beta 7 by the way ?

All the best,


Michael Foord
http://www.resolversystems.com


From andrzej.krzywda at resolversystems.com  Fri May 19 12:24:52 2006
From: andrzej.krzywda at resolversystems.com (Andrzej Krzywda)
Date: Fri, 19 May 2006 11:24:52 +0100
Subject: [IronPython] default contructor allows parameters
Message-ID: <446D9CF4.1090505@resolversystems.com>

Hi all,

It seems that IronPython is allowing parameters to the default 
constructor but CPython isn't.


CPython

 >>> class Foo(object):
...     pass
...
 >>> Foo(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: default __new__ takes no parameters
 >>>

IronPython Beta 6

 >>> class Foo(object):
...     pass
...
 >>> Foo(5)
<Foo object at 0x000000000000002B>
 >>>

Regards,
Andrzej Krzywda
http://www.resolversystems.com


From info at geatec.com  Fri May 19 17:39:17 2006
From: info at geatec.com (J. de  Hooge)
Date: Fri, 19 May 2006 17:39:17 +0200
Subject: [IronPython] Dict iteration inconsistency?
Message-ID: <000001c67b5a$67678b30$6402a8c0@GEADELL>

LS

Following code fragments seem to behave inconsistently

[START OF CODE]

# --- Fragment 1
#
#	Accepted by CPython
#
#	Accepted by IronPython1.0 B6

dictionary = dict (zip (range (10), range (0, 100, 10)))

print dictionary

for key in dictionary.keys ():
	dictionary [key] = 100 * key
	
print dictionary

# --- Fragment 2: IronPython objects to the following, CPython thinks its OK
#
#	Accepted by CPython
#
#	Rejected by IronPython1.0 B6:
#		Traceback (most recent call last):
#		File C:\activ_dell\prog\qQuick\try\try.py, line 29, in
Initialize
#		RuntimeError: dictionary changed size during iteration

dictionary = dict (zip (range (10), range (0, 100, 10)))

print dictionary

for key in dictionary:
	dictionary [key] = 100 * key
	
print dictionary

# --- Shouldn't fragments 1 and 2 be both rejected or both accepted by
IronPython?

[END OF CODE]


Kind regards,
Jacques de Hooge
info at geatec.com




From simon.dahlbacka at gmail.com  Fri May 19 18:19:52 2006
From: simon.dahlbacka at gmail.com (Simon Dahlbacka)
Date: Fri, 19 May 2006 19:19:52 +0300
Subject: [IronPython] Dict iteration inconsistency?
In-Reply-To: <000001c67b5a$67678b30$6402a8c0@GEADELL>
References: <000001c67b5a$67678b30$6402a8c0@GEADELL>
Message-ID: <57124720605190919s1cb3b15dxdbabe4b27ea19931@mail.gmail.com>

They don't do the same thing..
fragment 1 iterates over a *copy* of the dictionarys keys, while fragment 2
iterates over the dictionary

On 5/19/06, J. de Hooge <info at geatec.com> wrote:
>
> LS
>
> Following code fragments seem to behave inconsistently
>
> [START OF CODE]
>
> # --- Fragment 1
> #
> #       Accepted by CPython
> #
> #       Accepted by IronPython1.0 B6
>
> dictionary = dict (zip (range (10), range (0, 100, 10)))
>
> print dictionary
>
> for key in dictionary.keys ():
>         dictionary [key] = 100 * key
>
> print dictionary
>
> # --- Fragment 2: IronPython objects to the following, CPython thinks its
> OK
> #
> #       Accepted by CPython
> #
> #       Rejected by IronPython1.0 B6:
> #               Traceback (most recent call last):
> #               File C:\activ_dell\prog\qQuick\try\try.py, line 29, in
> Initialize
> #               RuntimeError: dictionary changed size during iteration
>
> dictionary = dict (zip (range (10), range (0, 100, 10)))
>
> print dictionary
>
> for key in dictionary:
>         dictionary [key] = 100 * key
>
> print dictionary
>
> # --- Shouldn't fragments 1 and 2 be both rejected or both accepted by
> IronPython?
>
> [END OF CODE]
>
>
> Kind regards,
> Jacques de Hooge
> info at geatec.com
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060519/6a74bea5/attachment.html>

From haiboluo at exchange.microsoft.com  Fri May 19 18:23:26 2006
From: haiboluo at exchange.microsoft.com (Haibo Luo)
Date: Fri, 19 May 2006 09:23:26 -0700
Subject: [IronPython] default contructor allows parameters
In-Reply-To: <446D9CF4.1090505@resolversystems.com>
Message-ID: <C880917115D23741B1FF3565AF50A096657601C2@df-foxhound-msg.exchange.corp.microsoft.com>

Thanks for the bug report. We are aware of this issue, will fix it before 1.0 RTM.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Andrzej Krzywda
Sent: Friday, May 19, 2006 3:25 AM
To: users at lists.ironpython.com
Subject: [IronPython] default contructor allows parameters

Hi all,

It seems that IronPython is allowing parameters to the default
constructor but CPython isn't.


CPython

 >>> class Foo(object):
...     pass
...
 >>> Foo(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: default __new__ takes no parameters
 >>>

IronPython Beta 6

 >>> class Foo(object):
...     pass
...
 >>> Foo(5)
<Foo object at 0x000000000000002B>
 >>>

Regards,
Andrzej Krzywda
http://www.resolversystems.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From haiboluo at exchange.microsoft.com  Fri May 19 18:27:09 2006
From: haiboluo at exchange.microsoft.com (Haibo Luo)
Date: Fri, 19 May 2006 09:27:09 -0700
Subject: [IronPython] IronPython on the Compact .NET Framework
In-Reply-To: <446D8FA5.8030008@resolversystems.com>
Message-ID: <C880917115D23741B1FF3565AF50A096657601C7@df-foxhound-msg.exchange.corp.microsoft.com>

Currently .NET compact framework does not support DynamicMethod (among other features), which is widely used in current IronPython implementation.

We will contact .NET CF team for this feature request.

Thanks!

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, May 19, 2006 2:28 AM
To: Discussion of IronPython
Subject: [IronPython] IronPython on the Compact .NET Framework

Hello all,

I realise this has been discussed on the mailing list several times before.

Just to add that I (as an individual) and the company I work for
(ResolverSystems) would be very interested in seeing IronPython for the
.NET compact framework, were that to become possible. :-)

Any word on Beta 7 by the way ?

All the best,


Michael Foord
http://www.resolversystems.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Fri May 19 18:32:59 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 19 May 2006 09:32:59 -0700
Subject: [IronPython] Dict iteration inconsistency?
In-Reply-To: <57124720605190919s1cb3b15dxdbabe4b27ea19931@mail.gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EEAEC6F2B@df-foxhound-msg.exchange.corp.microsoft.com>

But we probably shouldn't be throwing an exception here if CPython isn't... I've opened a bug on this.

Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Simon Dahlbacka
Sent: Friday, May 19, 2006 9:20 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Dict iteration inconsistency?

They don't do the same thing..
fragment 1 iterates over a *copy* of the dictionarys keys, while fragment 2 iterates over the dictionary

On 5/19/06, J. de Hooge <info at geatec.com<mailto:info at geatec.com>> wrote:
LS

Following code fragments seem to behave inconsistently

[START OF CODE]

# --- Fragment 1
#
#       Accepted by CPython
#
#       Accepted by IronPython1.0 B6

dictionary = dict (zip (range (10), range (0, 100, 10)))

print dictionary

for key in dictionary.keys ():
        dictionary [key] = 100 * key

print dictionary

# --- Fragment 2: IronPython objects to the following, CPython thinks its OK
#
#       Accepted by CPython
#
#       Rejected by IronPython1.0 B6:
#               Traceback (most recent call last):
#               File C:\activ_dell\prog\qQuick\try\try.py, line 29, in
Initialize
#               RuntimeError: dictionary changed size during iteration

dictionary = dict (zip (range (10), range (0, 100, 10)))

print dictionary

for key in dictionary:
        dictionary [key] = 100 * key

print dictionary

# --- Shouldn't fragments 1 and 2 be both rejected or both accepted by
IronPython?

[END OF CODE]


Kind regards,
Jacques de Hooge
info at geatec.com<mailto:info at geatec.com>


_______________________________________________
users mailing list
users at lists.ironpython.com<mailto:users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060519/abcc1c4a/attachment.html>

From glee at pharsight.com  Fri May 19 19:18:23 2006
From: glee at pharsight.com (Greg Lee)
Date: Fri, 19 May 2006 10:18:23 -0700
Subject: [IronPython] from xml import xpath
Message-ID: <5B833E900330354F9FDA984D06F924284C1559@ca-exchange.corp.pharsight.com>

Is a better diagnostic message possible?  This would let us distinguish a pyd problem from "playing tricks with paths", and presumably there might be some value in fixing any problems in the latter.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com]On Behalf Of Dino Viehland
Sent: Wednesday, May 17, 2006 11:50 AM
To: Discussion of IronPython
Subject: Re: [IronPython] from xml import xpath



You're right, I did miss that...  Looking at this page: http://pyxml.sourceforge.net/topics/howto/section-install.html  It would seem that you may be right about the Pyd's (it at least requires a C compiler, making that likely - and almost guaranteeing it won't work w/ IronPython).

 

Unfortunately we don't support PYD's currently (and aren't likely to soon) so most likely this won't currently work. If you absolutely need XPath support in the mean time I'd suggest using .NET's XMLPath (and if you need to work on both you could make a thin wrapper over either PyXml for CPython and .NET's XPath support).  For example:

 

import clr

clr.AddReference('System.Xml')

import System.Xml.XPath as XPath

 

xpathDoc = XPath.XPathDocument('file://foo.txt')

 

 

 

Do  <http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)


  _____  


From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Simon Dahlbacka
Sent: Wednesday, May 17, 2006 11:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] from xml import xpath

 

Dino, you seemed to have missed the part about pyxml..

It works in cpython with pyxml installed. However, pyxml is playing tricks with paths etc, and there might even be pyd:s involved..

C:\Python24>python.exe 
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml 
>>> xml.__file__
'C:\\Python24\\lib\\site-packages\\_xmlplus\\__init__.pyc'
>>> from xml import xpath
>>>

On 5/17/06, Dino Viehland < dinov at exchange.microsoft.com> wrote:

This doesn't work for my in CPython 2.4 either, so I think the docs are wrong:

 

>>> from xml import xpath

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

ImportError: cannot import name xpath

>>> import sys

>>> sys.version

'2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]'

>>> 

 

Do you want to help develop Dynamic languages on CLR? <http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038>  (  <http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)


  _____  


From: users-bounces at lists.ironpython.com [mailto:  <mailto:users-bounces at lists.ironpython.com> users-bounces at lists.ironpython.com] On Behalf Of Greg Lee
Sent: Tuesday, May 16, 2006 3:17 PM
To: users at lists.ironpython.com
Subject: [IronPython] from xml import xpath

 

I'm porting an application that uses PyXML.  The following from the PyXml documentation http://pyxml.sourceforge.net/topics/howto/section-XPath.html doesn't work:

from xml import xpath 
Traceback (most recent call last): 
  File , line 0, in input##113 
ImportError: cannot import xpath from xml 

Any suggestions?  I messed around with adding site-packages to IRONPYTHONPATH but other BadThings happened. 

Here's the installation: 

Microsoft Windows XP [Version 5.1.2600]
IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42

python 2.4.2
pyxml 0.8.4
pywin32 205
py2exe 0.6.3

IRONPYTHONPATH = c:\python24\lib 


_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060519/cdbc49a0/attachment.html>

From dinov at exchange.microsoft.com  Fri May 19 19:22:33 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 19 May 2006 10:22:33 -0700
Subject: [IronPython] IronPython on the Compact .NET Framework
In-Reply-To: <446D8FA5.8030008@resolversystems.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EEAEC6FB7@df-foxhound-msg.exchange.corp.microsoft.com>

As far as beta 7, while I mentioned earlier this week it'd probably come out this week, it looks like we're going to let it slide into early next week to get a few extra bug fixes in and then make sure things are stable.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Friday, May 19, 2006 2:28 AM
To: Discussion of IronPython
Subject: [IronPython] IronPython on the Compact .NET Framework

Hello all,

I realise this has been discussed on the mailing list several times before.

Just to add that I (as an individual) and the company I work for
(ResolverSystems) would be very interested in seeing IronPython for the
.NET compact framework, were that to become possible. :-)

Any word on Beta 7 by the way ?

All the best,


Michael Foord
http://www.resolversystems.com
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Fri May 19 19:25:54 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 19 May 2006 10:25:54 -0700
Subject: [IronPython] from xml import xpath
In-Reply-To: <5B833E900330354F9FDA984D06F924284C1559@ca-exchange.corp.pharsight.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EEAEC6FBE@df-foxhound-msg.exchange.corp.microsoft.com>

This is probably really tough to do - in order to know the PYD is playing tricks we'd need to support using the PYD, and then it's not a problem anymore.  I'll open a bug on this anyway to see if we can make the experience better, but I have no idea what sort of time frame we'd be able to do this in (another option for us would be to create an xpath wrapper around System.Xml.XPath which looks like pyxml, but it'd not solve any larger problems around PYDs in general).

Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Greg Lee
Sent: Friday, May 19, 2006 10:18 AM
To: Discussion of IronPython
Subject: Re: [IronPython] from xml import xpath

Is a better diagnostic message possible?  This would let us distinguish a pyd problem from "playing tricks with paths", and presumably there might be some value in fixing any problems in the latter.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com]On Behalf Of Dino Viehland
Sent: Wednesday, May 17, 2006 11:50 AM
To: Discussion of IronPython
Subject: Re: [IronPython] from xml import xpath

You're right, I did miss that...  Looking at this page: http://pyxml.sourceforge.net/topics/howto/section-install.html  It would seem that you may be right about the Pyd's (it at least requires a C compiler, making that likely - and almost guaranteeing it won't work w/ IronPython).

Unfortunately we don't support PYD's currently (and aren't likely to soon) so most likely this won't currently work. If you absolutely need XPath support in the mean time I'd suggest using .NET's XMLPath (and if you need to work on both you could make a thin wrapper over either PyXml for CPython and .NET's XPath support).  For example:

import clr
clr.AddReference('System.Xml')
import System.Xml.XPath as XPath

xpathDoc = XPath.XPathDocument('file://foo.txt')



Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
________________________________
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Simon Dahlbacka
Sent: Wednesday, May 17, 2006 11:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] from xml import xpath

Dino, you seemed to have missed the part about pyxml..

It works in cpython with pyxml installed. However, pyxml is playing tricks with paths etc, and there might even be pyd:s involved..

C:\Python24>python.exe
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml
>>> xml.__file__
'C:\\Python24\\lib\\site-packages\\_xmlplus\\__init__.pyc'
>>> from xml import xpath
>>>

On 5/17/06, Dino Viehland <dinov at exchange.microsoft.com<mailto:dinov at exchange.microsoft.com>> wrote:

This doesn't work for my in CPython 2.4 either, so I think the docs are wrong:

>>> from xml import xpath

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

ImportError: cannot import name xpath

>>> import sys

>>> sys.version

'2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]'

>>>

Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> ( http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
________________________________

From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Greg Lee
Sent: Tuesday, May 16, 2006 3:17 PM
To: users at lists.ironpython.com<mailto:users at lists.ironpython.com>
Subject: [IronPython] from xml import xpath

I'm porting an application that uses PyXML.  The following from the PyXml documentation http://pyxml.sourceforge.net/topics/howto/section-XPath.html doesn't work:

from xml import xpath
Traceback (most recent call last):
  File , line 0, in input##113
ImportError: cannot import xpath from xml

Any suggestions?  I messed around with adding site-packages to IRONPYTHONPATH but other BadThings happened.

Here's the installation:

Microsoft Windows XP [Version 5.1.2600]
IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42

python 2.4.2
pyxml 0.8.4
pywin32 205
py2exe 0.6.3

IRONPYTHONPATH = c:\python24\lib

_______________________________________________
users mailing list
users at lists.ironpython.com<mailto:users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060519/c9915818/attachment.html>

From simon.dahlbacka at gmail.com  Fri May 19 19:34:09 2006
From: simon.dahlbacka at gmail.com (Simon Dahlbacka)
Date: Fri, 19 May 2006 20:34:09 +0300
Subject: [IronPython] from xml import xpath
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214EEAEC6FBE@df-foxhound-msg.exchange.corp.microsoft.com>
References: <5B833E900330354F9FDA984D06F924284C1559@ca-exchange.corp.pharsight.com>
	<4039D552ADAB094BB1EA670F3E96214EEAEC6FBE@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <57124720605191034x60b7770ew8399a23dd0ce953d@mail.gmail.com>

Re pyd:s playing tricks..

In this case it's not any pyd:s that is playing tricks but
C:\Python24\Lib\xml\__init__.py :

_MINIMUM_XMLPLUS_VERSION = (0, 8, 4)


try:
    import _xmlplus
except ImportError:
    pass
else:
    try:
        v = _xmlplus.version_info
    except AttributeError:
        # _xmlplus is too old; ignore it
        pass
    else:
        if v >= _MINIMUM_XMLPLUS_VERSION:
            import sys
            sys.modules[__name__] = _xmlplus
        else:
            del v



(PyXML installs itself as _xmplus)

On 5/19/06, Dino Viehland <dinov at exchange.microsoft.com> wrote:
>
>  This is probably really tough to do ? in order to know the PYD is playing
> tricks we'd need to support using the PYD, and then it's not a problem
> anymore.  I'll open a bug on this anyway to see if we can make the
> experience better, but I have no idea what sort of time frame we'd be able
> to do this in (another option for us would be to create an xpath wrapper
> around System.Xml.XPath which looks like pyxml, but it'd not solve any
> larger problems around PYDs in general).
>
>
>
> Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038>
> (
> http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038
> )
>   ------------------------------
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Greg Lee
> *Sent:* Friday, May 19, 2006 10:18 AM
>
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] from xml import xpath
>
>
>
> Is a better diagnostic message possible?  This would let us distinguish a
> pyd problem from "playing tricks with paths", and presumably there might be
> some value in fixing any problems in the latter.
>
> -----Original Message-----
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com]*On Behalf Of *Dino Viehland
> *Sent:* Wednesday, May 17, 2006 11:50 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] from xml import xpath
>
> You're right, I did miss that?  Looking at this page:
> http://pyxml.sourceforge.net/topics/howto/section-install.html  It would
> seem that you may be right about the Pyd's (it at least requires a C
> compiler, making that likely ? and almost guaranteeing it won't work w/
> IronPython).
>
>
>
> Unfortunately we don't support PYD's currently (and aren't likely to soon)
> so most likely this won't currently work. If you absolutely need XPath
> support in the mean time I'd suggest using .NET's XMLPath (and if you need
> to work on both you could make a thin wrapper over either PyXml for CPython
> and .NET's XPath support).  For example:
>
>
>
> import clr
>
> clr.AddReference('System.Xml')
>
> import System.Xml.XPath as XPath
>
>
>
> xpathDoc = XPath.XPathDocument('file://foo.txt')
>
>
>
>
>
>
>
> Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038>
> (
> http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038
> )
>   ------------------------------
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Simon Dahlbacka
> *Sent:* Wednesday, May 17, 2006 11:41 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] from xml import xpath
>
>
>
> Dino, you seemed to have missed the part about pyxml..
>
> It works in cpython with pyxml installed. However, pyxml is playing tricks
> with paths etc, and there might even be pyd:s involved..
>
> C:\Python24>python.exe
> Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import xml
> >>> xml.__file__
> 'C:\\Python24\\lib\\site-packages\\_xmlplus\\__init__.pyc'
> >>> from xml import xpath
> >>>
>
> On 5/17/06, *Dino Viehland* <dinov at exchange.microsoft.com> wrote:
>
> This doesn't work for my in CPython 2.4 either, so I think the docs are
> wrong:
>
>
>
> >>> from xml import xpath
>
> Traceback (most recent call last):
>
>   File "<stdin>", line 1, in ?
>
> ImportError: cannot import name xpath
>
> >>> import sys
>
> >>> sys.version
>
> '2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]'
>
> >>>
>
>
>
> Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038>
> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038
> )
>   ------------------------------
>
> *From:* users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com]
> *On Behalf Of *Greg Lee
> *Sent:* Tuesday, May 16, 2006 3:17 PM
> *To:* users at lists.ironpython.com
> *Subject:* [IronPython] from xml import xpath
>
>
>
> I'm porting an application that uses PyXML.  The following from the PyXml
> documentation http://pyxml.sourceforge.net/topics/howto/section-XPath.htmldoesn't work:
>
> from xml import xpath
> Traceback (most recent call last):
>   File , line 0, in input##113
> ImportError: cannot import xpath from xml
>
> Any suggestions?  I messed around with adding site-packages to
> IRONPYTHONPATH but other BadThings happened.
>
> Here's the installation:
>
> Microsoft Windows XP [Version 5.1.2600]
> IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42
>
> python 2.4.2
> pyxml 0.8.4
> pywin32 205
> py2exe 0.6.3
>
> IRONPYTHONPATH = c:\python24\lib
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060519/72d1f27d/attachment.html>

From glee at pharsight.com  Fri May 19 19:47:49 2006
From: glee at pharsight.com (Greg Lee)
Date: Fri, 19 May 2006 10:47:49 -0700
Subject: [IronPython] from xml import xpath
Message-ID: <5B833E900330354F9FDA984D06F924284C155A@ca-exchange.corp.pharsight.com>

I looked at the .c for the likely PYD, and it's not playing tricks with the paths---I think the problem is simply IP's not supporting PYD format. 
 
If IP can't import from PYD format, perhaps it could throw an exception that identifies the offending pyd rather than just identifying the original import statement, which in this case is five levels up.  That's the only improvement in user experience that's warranted.

Writing an xpath wrapper around System.Xml.Xpath is not a good use of anyone's time now and probably a dead-end in the long-term.

 -----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com]On Behalf Of Dino Viehland
Sent: Friday, May 19, 2006 10:26 AM
To: Discussion of IronPython
Subject: Re: [IronPython] from xml import xpath



This is probably really tough to do - in order to know the PYD is playing tricks we'd need to support using the PYD, and then it's not a problem anymore.  I'll open a bug on this anyway to see if we can make the experience better, but I have no idea what sort of time frame we'd be able to do this in (another option for us would be to create an xpath wrapper around System.Xml.XPath which looks like pyxml, but it'd not solve any larger problems around PYDs in general).

 

Do  <http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)


  _____  


From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Greg Lee
Sent: Friday, May 19, 2006 10:18 AM
To: Discussion of IronPython
Subject: Re: [IronPython] from xml import xpath

 

Is a better diagnostic message possible?  This would let us distinguish a pyd problem from "playing tricks with paths", and presumably there might be some value in fixing any problems in the latter.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com]On Behalf Of Dino Viehland
Sent: Wednesday, May 17, 2006 11:50 AM
To: Discussion of IronPython
Subject: Re: [IronPython] from xml import xpath

You're right, I did miss that...  Looking at this page: http://pyxml.sourceforge.net/topics/howto/section-install.html  It would seem that you may be right about the Pyd's (it at least requires a C compiler, making that likely - and almost guaranteeing it won't work w/ IronPython).

 

Unfortunately we don't support PYD's currently (and aren't likely to soon) so most likely this won't currently work. If you absolutely need XPath support in the mean time I'd suggest using .NET's XMLPath (and if you need to work on both you could make a thin wrapper over either PyXml for CPython and .NET's XPath support).  For example:

 

import clr

clr.AddReference('System.Xml')

import System.Xml.XPath as XPath

 

xpathDoc = XPath.XPathDocument('file://foo.txt')

 

 

 

Do  <http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)


  _____  


From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Simon Dahlbacka
Sent: Wednesday, May 17, 2006 11:41 AM
To: Discussion of IronPython
Subject: Re: [IronPython] from xml import xpath

 

Dino, you seemed to have missed the part about pyxml..

It works in cpython with pyxml installed. However, pyxml is playing tricks with paths etc, and there might even be pyd:s involved..

C:\Python24>python.exe 
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml 
>>> xml.__file__
'C:\\Python24\\lib\\site-packages\\_xmlplus\\__init__.pyc'
>>> from xml import xpath
>>>

On 5/17/06, Dino Viehland < dinov at exchange.microsoft.com> wrote:

This doesn't work for my in CPython 2.4 either, so I think the docs are wrong:

 

>>> from xml import xpath

Traceback (most recent call last):

  File "<stdin>", line 1, in ?

ImportError: cannot import name xpath

>>> import sys

>>> sys.version

'2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)]'

>>> 

 

Do you want to help develop Dynamic languages on CLR? <http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038>  (  <http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)


  _____  


From: users-bounces at lists.ironpython.com [mailto:  <mailto:users-bounces at lists.ironpython.com> users-bounces at lists.ironpython.com] On Behalf Of Greg Lee
Sent: Tuesday, May 16, 2006 3:17 PM
To: users at lists.ironpython.com
Subject: [IronPython] from xml import xpath

 

I'm porting an application that uses PyXML.  The following from the PyXml documentation http://pyxml.sourceforge.net/topics/howto/section-XPath.html doesn't work:

from xml import xpath 
Traceback (most recent call last): 
  File , line 0, in input##113 
ImportError: cannot import xpath from xml 

Any suggestions?  I messed around with adding site-packages to IRONPYTHONPATH but other BadThings happened. 

Here's the installation: 

Microsoft Windows XP [Version 5.1.2600]
IronPython 1.0.60420 (Beta) on .NET 2.0.50727.42

python 2.4.2
pyxml 0.8.4
pywin32 205
py2exe 0.6.3

IRONPYTHONPATH = c:\python24\lib 


_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060519/a2f0e036/attachment.html>

From mbarnett at uniserve.com  Fri May 19 22:57:22 2006
From: mbarnett at uniserve.com (Lesley & Mitch Barnett)
Date: Fri, 19 May 2006 13:57:22 -0700
Subject: [IronPython] Learning IronPython?
Message-ID: <000401c67b86$e0b1a350$6401a8c0@NIS1861127372>

Hello,

 

I am sure this question has been answered before, but I can't find the
answer...  I am a C# programmer and have been using MS technologies since
1991.

 

However, I know little about IronPython.  Can anyone suggest any books or
reading material to get me up to speed ASAP?  Is there anything special
about IronPython that is different than Python?

 

I have downloaded the latest IronPython Beta and went through the tutorial
and have also been through the April VSSDK examples to a certain degree.

 

Sorry if this is a repeat question.

 

Regards,

 

Mitch

http://softwareindustrialization.com <http://softwareindustrialization.com/>


 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060519/a7d9e80d/attachment.html>

From fuzzyman at voidspace.org.uk  Sat May 20 00:29:18 2006
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Fri, 19 May 2006 23:29:18 +0100
Subject: [IronPython] Learning IronPython?
In-Reply-To: <000401c67b86$e0b1a350$6401a8c0@NIS1861127372>
References: <000401c67b86$e0b1a350$6401a8c0@NIS1861127372>
Message-ID: <446E46BE.6030901@voidspace.org.uk>

Lesley & Mitch Barnett wrote:
>
> Hello,
>
> I am sure this question has been answered before, but I can?t find the 
> answer... I am a C# programmer and have been using MS technologies 
> since 1991.
>
> However, I know little about IronPython. Can anyone suggest any books 
> or reading material to get me up to speed ASAP? Is there anything 
> special about IronPython that is different than Python?
>
IronPython almost has full Python 2.4 compliance, so it is not very 
different from Python at all.

In addition 'translating' MSDN docs for use with IronPython is quite easy.

At ResolverSystems we are building a full desktop application using 
IronPython and encountering very few difficulties. The only .NET 
functionality we have found that isn't exposed to IronPython (for which 
we have had to use C#) are a few parts needed for our functional tests. 
Only our program launcher uses C# in our production code.

This means you should find it easy to interface .NET code to IronPython. 
There are possibly some limitations that I haven't yet found. For 
example, I believe it is not yet possible to compile Python scripts.

If you have specific Python questions then comp.lang.python is a good 
place to ask :

http://groups.google.com/group/comp.lang.python?hl=en

For a good introduction to Python, the following online book is often 
recommended :

http://diveintopython.org/

For IronPython questions and Python-.NET interaction questions, this is 
a good forum to ask.

Hopefully in the next few days I will do a brief tutorial on using 
Windows Forms with IronPython. It will only show the basics, but that 
ought to be enough to show how to read the MSDN docs from a Python 
perspective.

All the best,

Fuzzyman
http://www.resolversytems.com
http://www.voidspace.org.uk/python/weblog/index.shtml
>
> I have downloaded the latest IronPython Beta and went through the 
> tutorial and have also been through the April VSSDK examples to a 
> certain degree.
>
> Sorry if this is a repeat question.
>
> Regards,
>
> Mitch
>
> http://softwareindustrialization.com 
> <http://softwareindustrialization.com/>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   



From richard.hsu at gmail.com  Sun May 21 15:47:15 2006
From: richard.hsu at gmail.com (richard hsu)
Date: Sun, 21 May 2006 09:47:15 -0400
Subject: [IronPython] Learning IronPython?
Message-ID: <d44be0840605210647j5e3d7c13x2d1cfd9c937725a2@mail.gmail.com>

Hi Mitch,

I second Michael's recommendation about comp.lang.python and Mark Pilgrim's
'Dive Into Python'. Another good online book that you might want to look at
is 'How to Think Like a Computer Scientist: Learning with Python' [
http://www.ibiblio.org/obp/thinkCSpy/].

I learnt Truth Value Testing from comp.lang.python [
http://docs.python.org/lib/truth.html]

Ironpython is perfect if you prefer the python syntax and know .NET's Base
Class Library well. That is what got me started as I, just like you, had
been programming with C# when I learnt python.

The quickest way to learn is to start writing your C# code in python,
download the python manual from python.org and use it whenever you need to
translate your C# equivalent. Slowly as you will read more python code, you
will start thinking more in python directly and when you write C# code, you
will come to like python's syntax.

When you have specific CLR <--> python questions, you can always trust this
mailing list to help you out.

Regards,
Richard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060521/eec10ba0/attachment.html>

From jonathan at jmail.za.net  Fri May  5 19:18:50 2006
From: jonathan at jmail.za.net (Jonathan Jacobs)
Date: Fri, 05 May 2006 17:18:50 -0000
Subject: [IronPython] Overriding derived methods
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214E0343DE1F@df-foxhound-msg.exchange.corp.microsoft.com>
References: <4039D552ADAB094BB1EA670F3E96214E0343DE1F@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <445B88E9.8020909@jmail.za.net>

Dino Viehland wrote:
> There's a bug in beta 5 and beta 6 where we can sometimes fail to call the correct derived method.  You can work around the bug in many cases w/:
> 
> Class MyForm(Form):
>         def __init__(self):
>                 self.OnKeyUp = self.OnKeyUp
>         def OnKeyUp(self, e):
>                 ...
> 
> Unfortunately you can still get some erattic behavior w/ the workaround in place.
> 
> This will be fixed for our beta 7 release.  This happens only when deriving from a type that has a large number of virtual methods, and unfortunately System.Windows.Forms hits this pretty heavily.

Thanks for the quick response, Dino. I've run into another (rather 
bizarre) situation, you'll need a few preliminary steps first:

1.) Create a vanilla "Windows Application" project in Visual Studio (C# 
2005 Express Edition, not sure if this matters)
2.) Compile it, add the compiled assembly to somewhere in your path.

I used the following code to reproduce the error:

 >>> clr.AddReferenceToFile('WindowsApplication1.exe')
 >>> from WindowsApplication1 import Form1
 >>> class MyForm(Form1):
...   def __init__(self):
...     self.OnKeyUp = self.OnKeyUp
...   def OnKeyUp(self, e):
...     print e
...
 >>> frm = MyForm()
 >>> Application.Run(frm)

Which yields the following output:

System.Windows.Forms.PaintEventArgs
System.Windows.Forms.KeyEventArgs
etc.

I'm really wondering about the PaintEventArgs object that sneaks in 
there. I haven't tried reproducing *all* of the generated C# code in 
pure IronPython code yet but the minimal form I mentioned in my previous 
email is not subject to this odd behaviour.

Regards
-- 
Jonathan


From dfrench at optio.com  Tue May 16 02:06:14 2006
From: dfrench at optio.com (Don French)
Date: Mon, 15 May 2006 20:06:14 -0400
Subject: [IronPython] Visual studio and IronPython
Message-ID: <9F61F758A669B34A93BA1A4179F8CE62046268F6@mail.optiosoftware.com>

I have been looking around for how to use VS 2005 with IronPython. I did
find a reference to the plugin tool set, but the instructions were not
clear.  Any help?

Donald French


From thomas at python.org  Thu May  4 16:45:57 2006
From: thomas at python.org (Thomas Wouters)
Date: Thu, 04 May 2006 14:45:57 -0000
Subject: [IronPython] [Python-Dev] Time since the epoch
In-Reply-To: <5b0248170605020055g2d6747baya099b967c9ae83fc@mail.gmail.com>
References: <5b0248170605020055g2d6747baya099b967c9ae83fc@mail.gmail.com>
Message-ID: <9e804ac0605040745ia9582a7l3f1bd4d2a0ce077@mail.gmail.com>

On 5/2/06, Sanghyeon Seo <sanxiyn at gmail.com> wrote:
>
> Hello,
>
> Python library reference 6.11 says, "The epoch is the point where the
> time starts. On January 1st of that year, at 0 hours, the "time since
> the epoch'' is zero. For Unix, the epoch is 1970."
>
> To me this seems to suggest that the epoch may vary among platforms
> and implementations as long as it's consistent. Am I correct?


Yes. (I believe the C standard doesn't specify the 'epoch', just POSIX does
-- for C. Regardless of that, Python's 'epoch' isn't guaranteed anywhere,
and the docs you quote are probably the most authorative docs on the
question.)

For example, does it make sense to file bug reports to Python projects
> assuming that time.time() returns seconds since the Unix epoch?


I would say so, yes.

I am asking because currently Python and IronPython returns very
> different values for time.time() even if they run on the same computer
> and at the same time.


As long as the value returned by time.time() is still 'seconds', and
everything in the time and datetime modules properly considers the same
epoch, I would say it's a bug (for third-party modules or for other parts of
the standard library) to break.

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060504/73dc0031/attachment.html>

From Aaron.Marten at microsoft.com  Mon May 22 19:31:28 2006
From: Aaron.Marten at microsoft.com (Aaron Marten)
Date: Mon, 22 May 2006 10:31:28 -0700
Subject: [IronPython] Visual studio and IronPython
In-Reply-To: <9F61F758A669B34A93BA1A4179F8CE62046268F6@mail.optiosoftware.com>
References: <9F61F758A669B34A93BA1A4179F8CE62046268F6@mail.optiosoftware.com>
Message-ID: <5FCAA6E21F110544B8CD0EEBB51B0AE802B2CB41@RED-MSG-20.redmond.corp.microsoft.com>

Hi Donald,

I wrote a blog entry about this a while back. Right now, you'll need to
go download the April 2006 release of the Visual Studio SDK and build
the IronPythonIntegration sample to use IronPython in Visual Studio. 

"Open VS 2005 and (assuming you installed the SDK to the default
location) open the solution at "C:\Program Files\Visual Studio 2005
SDK\2006.04\VisualStudioIntegration\Samples\IronPythonIntegration".
Then, it should simply be a matter of hitting F5 for Build & Debug. This
will launch Visual Studio using the "Experimental hive". (If you want to
launch this without the debugger, run "devenv /rootsuffix Exp" or use
the shortcut that is placed under VS SDK in the Start Menu.)"

More at: http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx

Hope that helps!

Aaron

-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Don French
Sent: Monday, May 15, 2006 5:06 PM
To: users at lists.ironpython.com
Subject: [IronPython] Visual studio and IronPython

I have been looking around for how to use VS 2005 with IronPython. I did
find a reference to the plugin tool set, but the instructions were not
clear.  Any help?

Donald French
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Mon May 22 22:24:45 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 22 May 2006 13:24:45 -0700
Subject: [IronPython] Naming and resolution of generic types (complete!)
In-Reply-To: <65531D426735784F854EE658938A585302798CCA@MI8NYCMAIL03.Mi8.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EEAEC7917@df-foxhound-msg.exchange.corp.microsoft.com>

I apologize for the extreme delay on this reply...  This mail got stuck in our mailing list somewhere and didn't come out until today.

The way we've chosen to solve this is to go w/ the single type that allows you to disambiguate after the fact.  If you have System.IComparable (another good example is System.Nullable which has both generic & non-generic versions) we build one 'type' that allows you to disambiguate using __getitem__.

This is the same way you need to get a generic instantiation (e.g. if there were no IComparable conflicts you'd need to do IComparable[int] to get the specific instantiation) so it fits in nicely.  Otherwise the type is the non-generic version.

It would seem our str/repr of this type is pretty bad right now (showing you only the generic version) - we should make that more helpful (e.g. something like <type IComparable, IComparable[T]> maybe ?).

I guess the other remaining issue is how to get access to the generic type that isn't bound to a specific instantiation - currently this isn't much of a problem w/ IronPython as there's not much you can actually do w/ the open generic type, but we should probably solve it long term.

I've opened 2 bugs - the first one (str/repr of the type) should be easy to fix, but some thought probably needs to go into the open generic type issue.  We could make some __ __ method to do this, allow indexing by None, or something else - neither of those sounds particularly wonderful.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Brian Lloyd
Sent: Friday, March 31, 2006 12:43 PM
To: pythondotnet at python.org
Cc: users at lists.ironpython.com
Subject: [IronPython] Naming and resolution of generic types (complete!)


Hi all - I'm cross-posting this to the IP list as the subject seems to
be an open issue there too.

I'm working on generics support for Python for .NET, and there a couple
of thorny issues that could use some discussion regarding naming and
resolution of generic types.

In C# you can explicitly name a generic type, a la Dictionary<,>. That
syntax won't work in Python, of course. Looking at IP, it seems to allow
the apparent Python name to be the unmangled IL name so you can
naturally use the name.

The problem is that the mangled name is illegal as a python name, and
the unmangled name isn't guaranteed to be unique - you can potentially
have any number of generic types as well as a non-generic type with the
same base name in the same namespace:

namespace Spam {

    public class SpamCan {}
    public class SpamCan<T> {}
    public class SpamCan<T, V> {}
    ...
}

I imagine that maybe IP has enough information available at compile-time
to do the right thing for some common usage (binding and instantiating
the types), but the overloaded name can still be ambiguous. A real-life
example of this is System.IComparable - in IP, it doesn't seem possible
to get to the non-generic version of IComparable anymore (or at least it
was not obvious to me how to do it):

>>> import System
>>> System.IComparable
<type 'IComparable`1'>

It seems like we need to figure out some acceptable way of spelling
generic type names explicitly in Python (an equivalent to IComparable<>
in C#) that works within the existing syntax.

There don't appear to be a lot of great options :( It has to be a valid
Python name to work in an import statement, so that rules out strange
operator shenanigans akin to the [] hack used for generic type binding.

One would be to mimic the existing IL mangling in some way, a la:

>From System import IComparable   # the non-generic type
>From System import IComparable_1 # the 1-param generic

# or
from System import IComparable_T
from System.Collections.Generic import Dictionary_TT

These are all pretty gross, and still don't totally prevent hiding of
legit non-generic classes with those names (though it makes it less
likely that names will be hidden than the current approach).

I suppose another approach would be to continue to have only one type
end up with the simple name, but provide a way to disambiguate it after
the fact:

>>> import System
>>> System.IComparable
<type 'IComparable`1'>

>>> # abandon all hope, ye who enter here...
>>> NonGenericIComparable = System.IComparable<<0
>>> OneParamGenericIComparable = System.IComparable<<1
>>> TwoParamVersionIfThereWasOne = System.IComparable<<2

That feels to me like it violates Python Zen in several ways, though.

Thoughts?


-Brian

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From fuzzyman at voidspace.org.uk  Mon May 22 22:39:48 2006
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 22 May 2006 21:39:48 +0100
Subject: [IronPython] Visual studio and IronPython
In-Reply-To: <5FCAA6E21F110544B8CD0EEBB51B0AE802B2CB41@RED-MSG-20.redmond.corp.microsoft.com>
References: <9F61F758A669B34A93BA1A4179F8CE62046268F6@mail.optiosoftware.com>
	<5FCAA6E21F110544B8CD0EEBB51B0AE802B2CB41@RED-MSG-20.redmond.corp.microsoft.com>
Message-ID: <44722194.4070702@voidspace.org.uk>

Aaron Marten wrote:
> Hi Donald,
>
> I wrote a blog entry about this a while back. Right now, you'll need to
> go download the April 2006 release of the Visual Studio SDK and build
> the IronPythonIntegration sample to use IronPython in Visual Studio. 
>
>   
I've tried to install the Visual Studio SDK with Visual Studio Express 
C# (the free one), but it refuses to play ball. (It insists that Visual 
Studio isn't installed.)

Is this the expected behaviour ?

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> "Open VS 2005 and (assuming you installed the SDK to the default
> location) open the solution at "C:\Program Files\Visual Studio 2005
> SDK\2006.04\VisualStudioIntegration\Samples\IronPythonIntegration".
> Then, it should simply be a matter of hitting F5 for Build & Debug. This
> will launch Visual Studio using the "Experimental hive". (If you want to
> launch this without the debugger, run "devenv /rootsuffix Exp" or use
> the shortcut that is placed under VS SDK in the Start Menu.)"
>
> More at: http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx
>
> Hope that helps!
>
> Aaron
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Don French
> Sent: Monday, May 15, 2006 5:06 PM
> To: users at lists.ironpython.com
> Subject: [IronPython] Visual studio and IronPython
>
> I have been looking around for how to use VS 2005 with IronPython. I did
> find a reference to the plugin tool set, but the instructions were not
> clear.  Any help?
>
> Donald French
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From simon.dahlbacka at gmail.com  Mon May 22 22:39:14 2006
From: simon.dahlbacka at gmail.com (Simon Dahlbacka)
Date: Mon, 22 May 2006 23:39:14 +0300
Subject: [IronPython] Visual studio and IronPython
In-Reply-To: <44722194.4070702@voidspace.org.uk>
References: <9F61F758A669B34A93BA1A4179F8CE62046268F6@mail.optiosoftware.com>
	<5FCAA6E21F110544B8CD0EEBB51B0AE802B2CB41@RED-MSG-20.redmond.corp.microsoft.com>
	<44722194.4070702@voidspace.org.uk>
Message-ID: <57124720605221339m1a53b1cbrf9fc55a9aee232d4@mail.gmail.com>

On 5/22/06, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>
> Aaron Marten wrote:
> > Hi Donald,
> >
> > I wrote a blog entry about this a while back. Right now, you'll need to
> > go download the April 2006 release of the Visual Studio SDK and build
> > the IronPythonIntegration sample to use IronPython in Visual Studio.
> >
> >
> I've tried to install the Visual Studio SDK with Visual Studio Express
> C# (the free one), but it refuses to play ball. (It insists that Visual
> Studio isn't installed.)
>
> Is this the expected behaviour ?




[Aron Marten]
> > More at: http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx
>


Quote from above blog:

*What version of Visual Studio do I need? Can I use this with an Express
edition?*

Unfortunately, no. The Visual Studio Express editions do not support
extensibility (addins & packages). This is a limitation of the Express
products and not a limitation we are placing on the sample. You will need
Visual Studio Standard or higher to build and use the sample.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060522/aeeea356/attachment.html>

From fuzzyman at voidspace.org.uk  Mon May 22 22:48:12 2006
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 22 May 2006 21:48:12 +0100
Subject: [IronPython] Visual studio and IronPython
In-Reply-To: <57124720605221339m1a53b1cbrf9fc55a9aee232d4@mail.gmail.com>
References: <9F61F758A669B34A93BA1A4179F8CE62046268F6@mail.optiosoftware.com>	<5FCAA6E21F110544B8CD0EEBB51B0AE802B2CB41@RED-MSG-20.redmond.corp.microsoft.com>	<44722194.4070702@voidspace.org.uk>
	<57124720605221339m1a53b1cbrf9fc55a9aee232d4@mail.gmail.com>
Message-ID: <4472238C.8000907@voidspace.org.uk>

Simon Dahlbacka wrote:
>
>
> On 5/22/06, *Michael Foord* <fuzzyman at voidspace.org.uk 
> <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>     Aaron Marten wrote:
>     > Hi Donald,
>     >
>     > I wrote a blog entry about this a while back. Right now, you'll
>     need to
>     > go download the April 2006 release of the Visual Studio SDK and
>     build
>     > the IronPythonIntegration sample to use IronPython in Visual
>     Studio.
>     >
>     >
>     I've tried to install the Visual Studio SDK with Visual Studio Express
>     C# (the free one), but it refuses to play ball. (It insists that
>     Visual
>     Studio isn't installed.)
>
>     Is this the expected behaviour ? 
>
>
>  
>
>     [Aron Marten]
>     > More at:
>     http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx
>
>
>
> Quote from above blog:
>
> *What version of Visual Studio do I need? Can I use this with an 
> Express edition?*
>
> Unfortunately, no. The Visual Studio Express editions do not support 
> extensibility (addins & packages). This is a limitation of the Express 
> products and not a limitation we are placing on the sample. You will 
> need Visual Studio Standard or higher to build and use the sample.
>
>
Oh well, it was only a 186mb download. *sigh* - thanks.

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> ------------------------------------------------------------------------
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   



From dinov at exchange.microsoft.com  Tue May 23 05:42:46 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Mon, 22 May 2006 20:42:46 -0700
Subject: [IronPython] Overriding derived methods
In-Reply-To: <445B88E9.8020909@jmail.za.net>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EEB7A13E7@df-foxhound-msg.exchange.corp.microsoft.com>

Another message back from the other side of a black hole... sorry for the delay on this.

You're hitting the other side of "in many cases"...  Unfortunately if the other method is called then we'll dispatch to the incorrect method there too...  This is fixed in beta 7 which should be out real soon now.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Jacobs
Sent: Friday, May 05, 2006 10:19 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Overriding derived methods

Dino Viehland wrote:
> There's a bug in beta 5 and beta 6 where we can sometimes fail to call the correct derived method.  You can work around the bug in many cases w/:
>
> Class MyForm(Form):
>         def __init__(self):
>                 self.OnKeyUp = self.OnKeyUp
>         def OnKeyUp(self, e):
>                 ...
>
> Unfortunately you can still get some erattic behavior w/ the workaround in place.
>
> This will be fixed for our beta 7 release.  This happens only when deriving from a type that has a large number of virtual methods, and unfortunately System.Windows.Forms hits this pretty heavily.

Thanks for the quick response, Dino. I've run into another (rather
bizarre) situation, you'll need a few preliminary steps first:

1.) Create a vanilla "Windows Application" project in Visual Studio (C#
2005 Express Edition, not sure if this matters)
2.) Compile it, add the compiled assembly to somewhere in your path.

I used the following code to reproduce the error:

 >>> clr.AddReferenceToFile('WindowsApplication1.exe')
 >>> from WindowsApplication1 import Form1
 >>> class MyForm(Form1):
...   def __init__(self):
...     self.OnKeyUp = self.OnKeyUp
...   def OnKeyUp(self, e):
...     print e
...
 >>> frm = MyForm()
 >>> Application.Run(frm)

Which yields the following output:

System.Windows.Forms.PaintEventArgs
System.Windows.Forms.KeyEventArgs
etc.

I'm really wondering about the PaintEventArgs object that sneaks in
there. I haven't tried reproducing *all* of the generated C# code in
pure IronPython code yet but the minimal form I mentioned in my previous
email is not subject to this odd behaviour.

Regards
--
Jonathan
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From detlef.stute at seatec-gmbh.com  Tue May 23 10:43:52 2006
From: detlef.stute at seatec-gmbh.com (SEATEC: Detlef Stute)
Date: Tue, 23 May 2006 10:43:52 +0200
Subject: [IronPython] Real python question
In-Reply-To: <0MKpV6-1FiDd93u88-0001D9@mx.kundenserver.de>
Message-ID: <002701c67e45$05dfe400$0a01a8c0@Seatec.de>

Hi drew,
thank you for your response.
Yes, I'm new to python ( or other scipting languages), so sometimes I
struggle at these points.

Best regards
Detlef
MailTo:detlef.stute at seatec-gmbh.com
Web: www.seatec-gmbh.com




From sh at defuze.org  Tue May 23 10:47:42 2006
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Tue, 23 May 2006 09:47:42 +0100 (BST)
Subject: [IronPython] IronPython features matrix
Message-ID: <3130.194.221.74.7.1148374062.squirrel@mail1.python-hosting.com>

Hi folks,

I've been trying to fiond a way to make way through IP for a while now
(such as working on Seo's work of bringing CherryPy to IP) but I fail to
find the right catch the train because it's hard for an occasional user as
me to have a clear picture of what IP covers of the Python language as of
today.

Therefore is there a plan to create some kind of features matrix whic
would give a detailed overview of what is completed or not in IP in
regards to the Python language?

That would be a great help for me to become a more regular user.

Thanks,
- Sylvain


From korpse-ironpython at kaydash.za.net  Tue May 23 14:57:51 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Tue, 23 May 2006 14:57:51 +0200
Subject: [IronPython] __repr__ and __str__ for .NET types
Message-ID: <447306CF.9050204@kaydash.za.net>

Hi,

In all the cases I've seen, calling repr on a .NET type ends up calling 
ToString which is generally reasonably useful but almost always unnecessarily 
verbose. Sometimes it would be nice if it gave you something a little more 
specific about the object in question, something less like:

  >>> v = Microsoft.DirectX.Vector3()
  >>> repr(v)
  'X: 0\nY: 0\nZ: 0\n'

and something more like:

  >>> class Foo(object): pass
  >>> ...
  >>> repr(Foo())
  '<Foo object at 0x000000000000002B>'

and leaving __str__ to return the ToString value.

This behaviour also fits the CPython documentation 
(http://docs.python.org/ref/customization.html), for these two functions, more 
closely than the current behaviour, IMO.

Regards
-- 
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master


From fuzzyman at voidspace.org.uk  Tue May 23 15:56:58 2006
From: fuzzyman at voidspace.org.uk (Fuzzyman)
Date: Tue, 23 May 2006 14:56:58 +0100
Subject: [IronPython] User Privileges
Message-ID: <447314AA.3000408@voidspace.org.uk>

Hello all,

I just tried running the ironpythonconsole on a machine with no
administrative privileges. In fact the user on this machine has *fairly*
restricted privileges.

(The machine has the .NET 2.0 redistributable framework installed but
not the SDK, running on Windows XP SP2, with IP Beta 6)

Unhandled Exception: System.MethodAccessException: Attempt to access the
method
failed.
   at System.Delegate.BindToMethodInfo(Object target,
RuntimeMethodHandle method
, RuntimeTypeHandle methodType, DelegateBindingFlags flags)
   at System.Delegate.CreateDelegate(Type type, MethodInfo method,
Boolean throw
OnBindFailure)
   at IronPython.Compiler.CodeGen.CreateDelegate(MethodInfo methodInfo,
Type del
egateType)
   at IronPython.Runtime.OptimizedFunction1..ctor(String name,
MethodInfo info,
MethodBase[] targets, FunctionType functionType)
   at IronPython.Runtime.BuiltinFunction.MakeBuiltinFunction(String
name, Method
Info info, MethodBase[] targets, FunctionType functionType)
   at IronPython.Runtime.SystemState.Initialize()
   at IronPython.Runtime.SystemState..ctor()
   at IronPython.Hosting.PythonEngine..ctor()
   at IronPython.Hosting.PythonEngine..ctor(Options opts)
   at IronPythonConsole.PythonCommandLine.Main(String[] rawArgs)

Can anyone diagnose this ? Does the SDK need installing ? Must the user
have full privileges in order to be able to run IronPython ?

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml



From nbastin at opnet.com  Tue May 23 16:30:19 2006
From: nbastin at opnet.com (Nicholas Bastin)
Date: Tue, 23 May 2006 10:30:19 -0400
Subject: [IronPython] __repr__ and __str__ for .NET types
In-Reply-To: <447306CF.9050204@kaydash.za.net>
References: <447306CF.9050204@kaydash.za.net>
Message-ID: <67306D01-FA6E-4196-A1FC-FC54A1C2C7C8@opnet.com>


On May 23, 2006, at 8:57 AM, Jonathan Jacobs wrote:

> Hi,
>
> In all the cases I've seen, calling repr on a .NET type ends up  
> calling
> ToString which is generally reasonably useful but almost always  
> unnecessarily
> verbose. Sometimes it would be nice if it gave you something a  
> little more
> specific about the object in question, something less like:
>
>>>> v = Microsoft.DirectX.Vector3()
>>>> repr(v)
>   'X: 0\nY: 0\nZ: 0\n'
>
> and something more like:
>
>>>> class Foo(object): pass
>>>> ...
>>>> repr(Foo())
>   '<Foo object at 0x000000000000002B>'
>
> and leaving __str__ to return the ToString value.
>
> This behaviour also fits the CPython documentation
> (http://docs.python.org/ref/customization.html), for these two  
> functions, more
> closely than the current behaviour, IMO.

No, actually it doesn't.  The string returned by __repr__ should be  
able to be used to re-create the object, if that is possible.  In  
this case,  'X: 0\nY: 0\nZ: 0\n' is a *lot* closer to re-creating the  
object than  '<Foo object at 0x000000000000002B>' is.  The second  
case is what gets returned when it isn't possible to re-create the  
object, but that obviously isn't the case in the example of  
DirectX.Vector3.


--
Nick


From nbastin at opnet.com  Tue May 23 16:30:19 2006
From: nbastin at opnet.com (Nicholas Bastin)
Date: Tue, 23 May 2006 10:30:19 -0400
Subject: [IronPython] __repr__ and __str__ for .NET types
In-Reply-To: <447306CF.9050204@kaydash.za.net>
References: <447306CF.9050204@kaydash.za.net>
Message-ID: <67306D01-FA6E-4196-A1FC-FC54A1C2C7C8@opnet.com>


On May 23, 2006, at 8:57 AM, Jonathan Jacobs wrote:

> Hi,
>
> In all the cases I've seen, calling repr on a .NET type ends up  
> calling
> ToString which is generally reasonably useful but almost always  
> unnecessarily
> verbose. Sometimes it would be nice if it gave you something a  
> little more
> specific about the object in question, something less like:
>
>>>> v = Microsoft.DirectX.Vector3()
>>>> repr(v)
>   'X: 0\nY: 0\nZ: 0\n'
>
> and something more like:
>
>>>> class Foo(object): pass
>>>> ...
>>>> repr(Foo())
>   '<Foo object at 0x000000000000002B>'
>
> and leaving __str__ to return the ToString value.
>
> This behaviour also fits the CPython documentation
> (http://docs.python.org/ref/customization.html), for these two  
> functions, more
> closely than the current behaviour, IMO.

No, actually it doesn't.  The string returned by __repr__ should be  
able to be used to re-create the object, if that is possible.  In  
this case,  'X: 0\nY: 0\nZ: 0\n' is a *lot* closer to re-creating the  
object than  '<Foo object at 0x000000000000002B>' is.  The second  
case is what gets returned when it isn't possible to re-create the  
object, but that obviously isn't the case in the example of  
DirectX.Vector3.


--
Nick


From dinov at exchange.microsoft.com  Tue May 23 17:25:15 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 23 May 2006 08:25:15 -0700
Subject: [IronPython] User Privileges
In-Reply-To: <447314AA.3000408@voidspace.org.uk>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EEB7A14AD@df-foxhound-msg.exchange.corp.microsoft.com>

Are you running IronPython from a network share?  And have you also reduced any .NET rights instead of just windows rights?

You shouldn't need the SDK or full privileges to run IronPython.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Fuzzyman
Sent: Tuesday, May 23, 2006 6:57 AM
To: Discussion of IronPython
Subject: [IronPython] User Privileges

Hello all,

I just tried running the ironpythonconsole on a machine with no
administrative privileges. In fact the user on this machine has *fairly*
restricted privileges.

(The machine has the .NET 2.0 redistributable framework installed but
not the SDK, running on Windows XP SP2, with IP Beta 6)

Unhandled Exception: System.MethodAccessException: Attempt to access the
method
failed.
   at System.Delegate.BindToMethodInfo(Object target,
RuntimeMethodHandle method
, RuntimeTypeHandle methodType, DelegateBindingFlags flags)
   at System.Delegate.CreateDelegate(Type type, MethodInfo method,
Boolean throw
OnBindFailure)
   at IronPython.Compiler.CodeGen.CreateDelegate(MethodInfo methodInfo,
Type del
egateType)
   at IronPython.Runtime.OptimizedFunction1..ctor(String name,
MethodInfo info,
MethodBase[] targets, FunctionType functionType)
   at IronPython.Runtime.BuiltinFunction.MakeBuiltinFunction(String
name, Method
Info info, MethodBase[] targets, FunctionType functionType)
   at IronPython.Runtime.SystemState.Initialize()
   at IronPython.Runtime.SystemState..ctor()
   at IronPython.Hosting.PythonEngine..ctor()
   at IronPython.Hosting.PythonEngine..ctor(Options opts)
   at IronPythonConsole.PythonCommandLine.Main(String[] rawArgs)

Can anyone diagnose this ? Does the SDK need installing ? Must the user
have full privileges in order to be able to run IronPython ?

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Tue May 23 17:27:24 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 23 May 2006 08:27:24 -0700
Subject: [IronPython] IronPython features matrix
In-Reply-To: <3130.194.221.74.7.1148374062.squirrel@mail1.python-hosting.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EEB7A14AF@df-foxhound-msg.exchange.corp.microsoft.com>

Over at http://channel9.msdn.com/wiki/default.aspx/IronPython.RegressionTests we have a list of the regression tests that we currently pass against the standard library.  It's currently a little out of date, but I'll update it after we release beta 7.

That's the closest we have two a matrix of what works and what doesn't work.  In general we will be enabling the full language by 1.0 but we'll not have every built-in module implemented.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch
Sent: Tuesday, May 23, 2006 1:48 AM
To: users at lists.ironpython.com
Subject: [IronPython] IronPython features matrix

Hi folks,

I've been trying to fiond a way to make way through IP for a while now
(such as working on Seo's work of bringing CherryPy to IP) but I fail to
find the right catch the train because it's hard for an occasional user as
me to have a clear picture of what IP covers of the Python language as of
today.

Therefore is there a plan to create some kind of features matrix whic
would give a detailed overview of what is completed or not in IP in
regards to the Python language?

That would be a great help for me to become a more regular user.

Thanks,
- Sylvain
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From fuzzyman at voidspace.org.uk  Tue May 23 17:44:46 2006
From: fuzzyman at voidspace.org.uk (Fuzzyman)
Date: Tue, 23 May 2006 16:44:46 +0100
Subject: [IronPython] User Privileges
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214EEB7A14AD@df-foxhound-msg.exchange.corp.microsoft.com>
References: <4039D552ADAB094BB1EA670F3E96214EEB7A14AD@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <44732DEE.6050502@voidspace.org.uk>

Dino Viehland wrote:

>Are you running IronPython from a network share? 
>
Ah.... yes, it was. Running it from C: instead of H: solved it...

Thanks

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> And have you also reduced any .NET rights instead of just windows rights?
>
>You shouldn't need the SDK or full privileges to run IronPython.
>
>Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
>
>-----Original Message-----
>From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Fuzzyman
>Sent: Tuesday, May 23, 2006 6:57 AM
>To: Discussion of IronPython
>Subject: [IronPython] User Privileges
>
>Hello all,
>
>I just tried running the ironpythonconsole on a machine with no
>administrative privileges. In fact the user on this machine has *fairly*
>restricted privileges.
>
>(The machine has the .NET 2.0 redistributable framework installed but
>not the SDK, running on Windows XP SP2, with IP Beta 6)
>
>Unhandled Exception: System.MethodAccessException: Attempt to access the
>method
>failed.
>   at System.Delegate.BindToMethodInfo(Object target,
>RuntimeMethodHandle method
>, RuntimeTypeHandle methodType, DelegateBindingFlags flags)
>   at System.Delegate.CreateDelegate(Type type, MethodInfo method,
>Boolean throw
>OnBindFailure)
>   at IronPython.Compiler.CodeGen.CreateDelegate(MethodInfo methodInfo,
>Type del
>egateType)
>   at IronPython.Runtime.OptimizedFunction1..ctor(String name,
>MethodInfo info,
>MethodBase[] targets, FunctionType functionType)
>   at IronPython.Runtime.BuiltinFunction.MakeBuiltinFunction(String
>name, Method
>Info info, MethodBase[] targets, FunctionType functionType)
>   at IronPython.Runtime.SystemState.Initialize()
>   at IronPython.Runtime.SystemState..ctor()
>   at IronPython.Hosting.PythonEngine..ctor()
>   at IronPython.Hosting.PythonEngine..ctor(Options opts)
>   at IronPythonConsole.PythonCommandLine.Main(String[] rawArgs)
>
>Can anyone diagnose this ? Does the SDK need installing ? Must the user
>have full privileges in order to be able to run IronPython ?
>
>Fuzzyman
>http://www.voidspace.org.uk/python/index.shtml
>
>_______________________________________________
>users mailing list
>users at lists.ironpython.com
>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>_______________________________________________
>users mailing list
>users at lists.ironpython.com
>http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>  
>



From dinov at exchange.microsoft.com  Tue May 23 18:40:29 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 23 May 2006 09:40:29 -0700
Subject: [IronPython] [Python.NET] Naming and resolution of generic
 types (complete!)
In-Reply-To: <65531D426735784F854EE658938A5853038FAB97@MI8NYCMAIL03.Mi8.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EEB7A154A@df-foxhound-msg.exchange.corp.microsoft.com>

We actually handle this, at least as best we can - when we do the import we check and see if we already have a type of that name, and if so, we'll go ahead and replace the existing type w/ the combined "collision" type.

But if both the types are non-generic then you have a case where we'll actually need to replace the type.  In that case there's nothing we can automagically do.  Instead we actually expose all of the namespaces in a type off of the assembly.  Therefore you can do:

import clr
system = clr.LoadAssemblyByPartialName('System')
system.System.IComparable

and this gives finer control over assemblies / namespaces where it's needed.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: Brian Lloyd [mailto:Brian.Lloyd at revolution.com]
Sent: Tuesday, May 23, 2006 9:17 AM
To: Dino Viehland; Discussion of IronPython; pythondotnet at python.org
Subject: RE: [Python.NET] [IronPython] Naming and resolution of generic types (complete!)

Thanks for the reply - luckily this is pretty much where I ended
up as well ;)

One unlikely-but-technically-possible edge case I ran into was:

  - user imports assembly A that contains the generic type
'foo.bar.SomeType'
  - user creates instances of that type
  - then the user imports assembly B that contributes the non-generic
type
    'SomeType' to the namespace 'foo.bar'

Maybe that's not a problem for the IP implementation, but thought I'd
note it just in case.

-Brian



> -----Original Message-----
> From: pythondotnet-bounces at python.org
> [mailto:pythondotnet-bounces at python.org] On Behalf Of Dino Viehland
> Sent: Monday, May 22, 2006 4:25 PM
> To: Discussion of IronPython; pythondotnet at python.org
> Subject: Re: [Python.NET] [IronPython] Naming and resolution
> of generic types (complete!)
>
> I apologize for the extreme delay on this reply...  This mail
> got stuck in our mailing list somewhere and didn't come out
> until today.
>
> The way we've chosen to solve this is to go w/ the single
> type that allows you to disambiguate after the fact.  If you
> have System.IComparable (another good example is
> System.Nullable which has both generic & non-generic
> versions) we build one 'type' that allows you to disambiguate
> using __getitem__.
>
> This is the same way you need to get a generic instantiation
> (e.g. if there were no IComparable conflicts you'd need to do
> IComparable[int] to get the specific instantiation) so it
> fits in nicely.  Otherwise the type is the non-generic version.
>
> It would seem our str/repr of this type is pretty bad right
> now (showing you only the generic version) - we should make
> that more helpful (e.g. something like <type IComparable,
> IComparable[T]> maybe ?).
>
> I guess the other remaining issue is how to get access to the
> generic type that isn't bound to a specific instantiation -
> currently this isn't much of a problem w/ IronPython as
> there's not much you can actually do w/ the open generic
> type, but we should probably solve it long term.
>
> I've opened 2 bugs - the first one (str/repr of the type)
> should be easy to fix, but some thought probably needs to go
> into the open generic type issue.  We could make some __ __
> method to do this, allow indexing by None, or something else
> - neither of those sounds particularly wonderful.
>
>
> Do you want to help develop Dynamic languages on CLR?
> (http://members.microsoft.com/careers/search/details.aspx?JobI
> D=6D4754DE-11F0-45DF-8B78-DC1B43134038)
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Brian Lloyd
> Sent: Friday, March 31, 2006 12:43 PM
> To: pythondotnet at python.org
> Cc: users at lists.ironpython.com
> Subject: [IronPython] Naming and resolution of generic types
> (complete!)
>
>
> Hi all - I'm cross-posting this to the IP list as the subject
> seems to be an open issue there too.
>
> I'm working on generics support for Python for .NET, and
> there a couple of thorny issues that could use some
> discussion regarding naming and resolution of generic types.
>
> In C# you can explicitly name a generic type, a la
> Dictionary<,>. That syntax won't work in Python, of course.
> Looking at IP, it seems to allow the apparent Python name to
> be the unmangled IL name so you can naturally use the name.
>
> The problem is that the mangled name is illegal as a python
> name, and the unmangled name isn't guaranteed to be unique -
> you can potentially have any number of generic types as well
> as a non-generic type with the same base name in the same namespace:
>
> namespace Spam {
>
>     public class SpamCan {}
>     public class SpamCan<T> {}
>     public class SpamCan<T, V> {}
>     ...
> }
>
> I imagine that maybe IP has enough information available at
> compile-time to do the right thing for some common usage
> (binding and instantiating the types), but the overloaded
> name can still be ambiguous. A real-life example of this is
> System.IComparable - in IP, it doesn't seem possible to get
> to the non-generic version of IComparable anymore (or at
> least it was not obvious to me how to do it):
>
> >>> import System
> >>> System.IComparable
> <type 'IComparable`1'>
>
> It seems like we need to figure out some acceptable way of
> spelling generic type names explicitly in Python (an
> equivalent to IComparable<> in C#) that works within the
> existing syntax.
>
> There don't appear to be a lot of great options :( It has to
> be a valid Python name to work in an import statement, so
> that rules out strange operator shenanigans akin to the []
> hack used for generic type binding.
>
> One would be to mimic the existing IL mangling in some way, a la:
>
> >From System import IComparable   # the non-generic type
> >From System import IComparable_1 # the 1-param generic
>
> # or
> from System import IComparable_T
> from System.Collections.Generic import Dictionary_TT
>
> These are all pretty gross, and still don't totally prevent
> hiding of legit non-generic classes with those names (though
> it makes it less likely that names will be hidden than the
> current approach).
>
> I suppose another approach would be to continue to have only
> one type end up with the simple name, but provide a way to
> disambiguate it after the fact:
>
> >>> import System
> >>> System.IComparable
> <type 'IComparable`1'>
>
> >>> # abandon all hope, ye who enter here...
> >>> NonGenericIComparable = System.IComparable<<0
> >>> OneParamGenericIComparable = System.IComparable<<1
> >>> TwoParamVersionIfThereWasOne = System.IComparable<<2
>
> That feels to me like it violates Python Zen in several ways, though.
>
> Thoughts?
>
>
> -Brian
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>
>



From korpse-ironpython at kaydash.za.net  Tue May 23 20:58:13 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Tue, 23 May 2006 20:58:13 +0200
Subject: [IronPython] __repr__ and __str__ for .NET types
In-Reply-To: <67306D01-FA6E-4196-A1FC-FC54A1C2C7C8@opnet.com>
References: <447306CF.9050204@kaydash.za.net>
	<67306D01-FA6E-4196-A1FC-FC54A1C2C7C8@opnet.com>
Message-ID: <44735B45.8000702@kaydash.za.net>

Nicholas Bastin wrote:
> No, actually it doesn't.  The string returned by __repr__ should be  
> able to be used to re-create the object, if that is possible.  In  
> this case,  'X: 0\nY: 0\nZ: 0\n' is a *lot* closer to re-creating the  
> object than  '<Foo object at 0x000000000000002B>' is.  The second  
> case is what gets returned when it isn't possible to re-create the  
> object, but that obviously isn't the case in the example of  
> DirectX.Vector3.

Well, according to the documentation it should look like a valid Python 
expression (which "X: 0\nY: 0\nZ: 0\n" does not) and if that isn't possible 
then it should be in the form of "<...useful information...>". I did get them 
the wrong way around though, __repr__ is supposed to be information-rich 
whereas __str__ is supposed to be concise / convenient.

The reason this bugs me is that trying to debug something that has a 2-page 
ToString() output gets really messy.

-- 
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master


From nbastin at opnet.com  Tue May 23 21:09:55 2006
From: nbastin at opnet.com (Nicholas Bastin)
Date: Tue, 23 May 2006 15:09:55 -0400
Subject: [IronPython] __repr__ and __str__ for .NET types
In-Reply-To: <44735B45.8000702@kaydash.za.net>
References: <447306CF.9050204@kaydash.za.net>
	<67306D01-FA6E-4196-A1FC-FC54A1C2C7C8@opnet.com>
	<44735B45.8000702@kaydash.za.net>
Message-ID: <B27317E8-E90E-4808-98C1-93792173FCD7@opnet.com>


On May 23, 2006, at 2:58 PM, Jonathan Jacobs wrote:

> Nicholas Bastin wrote:
>> No, actually it doesn't.  The string returned by __repr__ should be
>> able to be used to re-create the object, if that is possible.  In
>> this case,  'X: 0\nY: 0\nZ: 0\n' is a *lot* closer to re-creating the
>> object than  '<Foo object at 0x000000000000002B>' is.  The second
>> case is what gets returned when it isn't possible to re-create the
>> object, but that obviously isn't the case in the example of
>> DirectX.Vector3.
>
> Well, according to the documentation it should look like a valid  
> Python
> expression (which "X: 0\nY: 0\nZ: 0\n" does not) and if that isn't  
> possible
> then it should be in the form of "<...useful information...>".

Generally we try to meet in the middle on __repr__ - in many cases,  
it's most convenient if the output from __repr__ can be fed back into  
a factory or constructor for the class the text came from, so that  
the following expression is legal:

new_object = Microsoft.DirectX.Vector3(repr(old_object))

since

eval(repr(old_object))

usually isn't convenient, fast, or safe.

Although, lets be clear in this case, I have no idea whether either  
one of those constructions will actually work for the object in  
question (well, clearly the eval() construction won't work).  It's  
just that it's much more common to find a __repr__ which makes the  
first construction valid more often than the second.  (Obvious,  
<Object foo at 0xFFFFFFFF> isn't going to solve anybody's problem  
when it comes to recreating the object).

--
Nick



From korpse-ironpython at kaydash.za.net  Tue May 23 22:50:35 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Tue, 23 May 2006 22:50:35 +0200
Subject: [IronPython] __repr__ and __str__ for .NET types
In-Reply-To: <B27317E8-E90E-4808-98C1-93792173FCD7@opnet.com>
References: <447306CF.9050204@kaydash.za.net>
	<67306D01-FA6E-4196-A1FC-FC54A1C2C7C8@opnet.com>
	<44735B45.8000702@kaydash.za.net>
	<B27317E8-E90E-4808-98C1-93792173FCD7@opnet.com>
Message-ID: <4473759B.6020905@kaydash.za.net>

Nicholas Bastin wrote:
> Generally we try to meet in the middle on __repr__ - in many cases,  
> it's most convenient if the output from __repr__ can be fed back into  
> a factory or constructor for the class the text came from, so that  
> the following expression is legal:
> 
> new_object = Microsoft.DirectX.Vector3(repr(old_object))
> 
> since
> 
> eval(repr(old_object))
> 
> usually isn't convenient, fast, or safe.

Consider the output of repr(file('foo', 'rw')).

> Although, lets be clear in this case, I have no idea whether either  
> one of those constructions will actually work for the object in  
> question (well, clearly the eval() construction won't work).  It's  
> just that it's much more common to find a __repr__ which makes the  
> first construction valid more often than the second.  (Obvious,  

I'm not aware of any .NET objects that can be constructed by a single string 
containing newline-separated variables / value pairs and leave you with 
something useful (apart from string and like circumstances, obviously.)

> <Object foo at 0xFFFFFFFF> isn't going to solve anybody's problem  
> when it comes to recreating the object).

No, but __repr__ is supposedly for debugging; it's quite difficult to tell the 
difference between vector A with X = Y = Z = 0 and vector B with X = Y = Z = 0 
with just the current output. There is also the case where ToString returns 2 
pages of variable / value pairs. If I want to see variable / value pairs I'm 
quite capable of using repr(obj.__dict__).
-- 
Jonathan



From dinov at exchange.microsoft.com  Wed May 24 01:08:47 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 23 May 2006 16:08:47 -0700
Subject: [IronPython] IronPython 1.0 Beta 7 Released!
Message-ID: <4039D552ADAB094BB1EA670F3E96214EF7726605@df-foxhound-msg.exchange.corp.microsoft.com>

Hello IronPython Community,

We have just released IronPython 1.0 Beta 7. This release focuses primarily on fixing bugs and improving compatibility with CPython.  We?ve enabled a significant number of CPython regression tests that pass unmodified (test_bufio, test_colorsys, test_dircache, test_dummy_threading, test_filecmp, test_fileinput, test_fnmatch, test_fpformat, test_hexoct, test_htmllib, test_list, test_pkg, test_pkgimport, test_popen, test_popen2, test_sgmllib, test_textwrap, test_univnewlines, test_userstring).  We?ve also partially enabled many tests that pass w/ a few test cases disabled (those include test_bisect, test_decimal, test_decorators, test_iter, test_pow, test_repr, test_scope, test_sort, test_syntax).

Additionally with this release we?ve started strong name signing of IronPython.  If you?d like to build your own strong named version you?ll need to provide your own key and use the Signed Release or Signed Debug build configurations.

A more complete list of changes follows at the end.

You can download the release from: http://www.microsoft.com/downloads/details.aspx?FamilyId=5024FDAA-634B-4A8E-916D-FB2CD2B78821&displaylang=en

We'd like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: Andrzej Krzywda, Anthony Tarlano, Erin Renshaw, J. de Hooge, Michael Foord, Paparipote, Seo Sanghyeon, Sumit Basu, Thottam Sriram, Tom McDonald, Vincent Wehren, ?iga Seilnacht, and ? ?.

Thanks and keep in touch,
The IronPython Team


More complete list of changes and bug fixes:
============================================
Support for multiple independent PythonEngine instances
Better handling of returning None from an .NET override that should return a value type
Improved delegate binding to account for default parameter values
Fixed issues w/ SymbolTable fast access using the wrong dictionary type
Fixed classes to follow scoping rules when assigning to a local from a global of the same name
Cleaned up differences between IronPython tutorial & latest IronPython
Removed SimpleAstWalker
Include lstat implementation in nt module
Enum conversions don?t check boundaries
global stmt ? expecting SyntaxError, name is assigned to before global declaration
CustomFieldIdDict.Values doesn?t count ExtraKeys values
Unified method dispatch algorithms for unoptimized & optimized code paths
Bugfix: Console does not respond to print statements after running demo
Bugfix: Fixed comparison of custom dictionaries
Bugfix: Binary operators not symmetric or implemented for numeric types and types inherited from them
Implemented ?Q command line parameter
Bugfix: Error defining properties with a name already in the global scope
Bugfix: BigNamespaceDictionary & getting inherited values is broken
Bugfix: Comparing container instance with sequence type instance
Bugfix: One more compare issue (or Tuple.Equals has some issue)
Bugfix: corner: expect "%.*f" % (0, -0.33333) to be "-0"
Bugfix: Fix method dispatch w/ >= 5 args param signature
Renamed dialog2.JPG to dialog2.jpg
Bugfix: True division, from __future__ import division
Removed wrappers on COM objects
Bugfix: Assignment w/ multiple targets raised an exception (Reset not implemented)
Bugfix: iter, make sure StopIteration is a sink state
Bugfix: Complex.__lt__ returns the wrong value, and complex compared against None is wrong
Bugfix: Fix many issues w/ binary operators as compared against CPython behavior
Updated test cases to not display any output during generate as snippets mode
Bugfix: TypeError should be raised when bad things are returned from __nonzero__
Bugfix: Consider interfaces when deriving from a new-style class
Bugfix: check for interfaces when assigning to __bases__ and disallow additional interfaces
Bugfix: Inheriting from an open generic instantiation raises a meaningful exception
Bugfix: Optional 'count' argument to re.sub results in behavior contrary to spec
Bugfix: re.findall doesn't return correct list of tuples for patterns containing multiple groups
Bugfix: re.findall("(\d)(\d\d)(\d\d\d)", "123456789123456789") returns wrong list of tuples
Bugfix: IsHexDigit and GetHexVal in PythonRegex appear to be dead code
Bugfix: re.subn("(ab)*", "cd", "abababababab", 10) result doesn't match with CPython's result on the same call
Bugfix: re.sub(r'(?P<id>z)', '\g<id>\g<id>blah', 'zz') does incorrect replacement
Bugfix: re.sub('x*', '-', 'abxd') result different from CPython result
Bugfix: Regex incompatibility (groups is wrong)
Bugfix: Many fixes to enable test_bool
Bugfix: Many fixes to partially enable test_scope
Bugfix: Many fixes to enable test_complex
Finished cleanup to enable sbs comparison tests
Bugfix: static unary negation operator not working from IP
Bugfix: None == ??
Bugfix: future division broken for built-in compile method when passing flags
Bugfix: IronPython ignores dont_inherit compiler flag
Bugfix: Many fixes to enable test_decimal
Bugfix: time.strftime('%x %X') is broken
Bugfix: Implement imp.new_module (or make it not return None)
Bugfix: Picking parameterized thread start instead of normal thread start when setting up a delegate to a bound method
Bugfix: thread.start_new, thread.exit_thread, and thread.allocate need to be implemented as synonyms of start_new_thread, exit, and allocate_lock
Bugfix: Assigning multiple keys w/ one key being none throws NullRef exception
Bugfix: os.stat doesn't return time values in seconds
Bugfix: TabError and IndentationError are now truly subtypes of SyntaxError
Bugfix: SyntaxErrors that occur during the Emit phase now have filename and line number info in them (tests in Syntax.py)
SourceFile moved into CompilerContext to fix these cases while simplifying and removing code
Changed void DumpException(...) to string FormatException(...).
Bugfix: Cannot access System.String.Split because Python is "Split" as well.
Bugfix: complex.__lt__ and others: should be fix-able
Bugfix: Adding a string to a float - bug
Bugfix: Printing Exceptions
Bugfix: Inheritance problem
Bugfix: Reflect optimizer has problems w/ leading out params & trailing arguments
Bugfix: method equality comparison is broken
Bugfix: DefaultValue wiredness
Bugfix: "IndentationError not raised for missing expected indented block"
Bugfix: remove assertion, add sort by name to allow consistent ordering.
Improved error handling at console for incomplete statements
IronPython is now strong named
Bugfix: __get__ methods require second argument
Bugfix: improve semantics of classmethod.__get__
Improved white space handling of interactive console
Bugfix: Compat: Classes (types) are missing a __class__ attribute:
Bugfix: Compat: classmethods don't pass the class' metaclass to method constructor
Bugfix: Compat: builtin object super has a lot of limitations
enable test_fpformat
Bugfix: "__module__: ip v. cpython discrepancies for in global scope, functions, and class methods". The ICustomAttribute implementations of PythonFunction and Method now respond to "__module__". Also, Method.TryGetAttr chains to PythonFunction.TryGetA
Instances of builtins (and ReflectedTypes in general) now do not have __dict__ like CPython.
documentation strings for common well-known method names like "__eq__" are now provided so that the doc string does not have to be repeated on every type exposing "__eq__"
Fixed reload(sys)
Bugfix: Support __getslice__, __delslice__, and __setslice__
Bugfix: Compat: metaclass is determined incorrectly

From paparipote at hotmail.com  Wed May 24 03:04:08 2006
From: paparipote at hotmail.com (Paparipote .)
Date: Tue, 23 May 2006 21:04:08 -0400
Subject: [IronPython] Running IP Beta 7
Message-ID: <BAY12-F3B39B6767EA39887EADA3DA980@phx.gbl>

Hello:

Using IP 1.0 beta 6 I run the next program without problems:
.ironpythonconsole AsigPresupSAP.py
08:56:18 2006. Conectando con SAP......
08:56:19 2006. Ejecutando la funci?n.....
09:00:11 2006. Bajando los datos .....
09:00:11 2006. Paso 1.....
09:00:11 2006. Paso 2.....
09:00:11 2006. Regs.recogidos: 42769
.
.
.

After installing and running the same program under IP 1.0 beta 7 I get next 
error:
.ironpythonconsole AsigPresupSAP.py
09:45:28 2006. Conectando con SAP......
09:45:28 2006. Ejecutando la funci?n.....
Traceback (most recent call last):
  File C:\IP\src\AsigPresupSAP.py, line 18, in Initialize
TypeError: Z_Fm_Asig_Get() takes exactly 6 arguments (5 given)

What do you suspect is happening?

The code is:
import time
import System
from System.IO import StreamWriter
import clr
print time.asctime()[10:] + ". Conectando con SAP......"
clr.AddReferenceToFile("SAPProxyE.dll")
#aso = System.Reflection.Assembly.LoadFrom('SAPProxyE.dll')
#System.Reflection.Assembly.LoadFrom('SAPProxyE.dll')
#clr.AddReference(aso)
#clr.AddReference("SAPProxyE.dll")
from SAPProxyE import *
#cs = 'ASHOST=.......'
cs = 'ASHOST=111.1.11.11 SYSNR=00 CLIENT=900 USER=xxx PASSWD=yyy 
LANGUAGE=EN'
pASI = SAPProxy1(cs)
tASI = ZASIGTABTable()
print time.asctime()[10:] + u". Ejecutando la funci?n....."
#exit
res = pASI.Z_Fm_Asig_Get("2006", "XXXX", "YYYY", "", tASI)  <- the error is 
here!!!
.
.
.
.
etc


I never made changes to the .dlls invoked.

Many, many thanks for your attention.

_________________________________________________________________
Consigue aqu? las mejores y mas recientes ofertas de trabajo en Am?rica 
Latina y USA: http://latam.msn.com/empleos/



From dinov at exchange.microsoft.com  Wed May 24 03:25:13 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 23 May 2006 18:25:13 -0700
Subject: [IronPython] Running IP Beta 7
In-Reply-To: <BAY12-F3B39B6767EA39887EADA3DA980@phx.gbl>
References: <BAY12-F3B39B6767EA39887EADA3DA980@phx.gbl>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EF79762F7@df-foxhound-msg.exchange.corp.microsoft.com>

Can you do:

print pASI.Z_Fm_Asig_Get.__doc__ ?

It's hard to tell what's going on w/o knowing the siganture of that method.  We did fix some bugs around calling params methods - so maybe this is a params method?

________________________________________
From: users-bounces at lists.ironpython.com On Behalf Of Paparipote .
Sent: Tuesday, May 23, 2006 6:04 PM
To: users at lists.ironpython.com
Subject: [IronPython] Running IP Beta 7

Hello:

Using IP 1.0 beta 6 I run the next program without problems:
.ironpythonconsole AsigPresupSAP.py
08:56:18 2006. Conectando con SAP......
08:56:19 2006. Ejecutando la funci?n.....
09:00:11 2006. Bajando los datos .....
09:00:11 2006. Paso 1.....
09:00:11 2006. Paso 2.....
09:00:11 2006. Regs.recogidos: 42769
.
.
.

After installing and running the same program under IP 1.0 beta 7 I get next
error:
.ironpythonconsole AsigPresupSAP.py
09:45:28 2006. Conectando con SAP......
09:45:28 2006. Ejecutando la funci?n.....
Traceback (most recent call last):
  File C:\IP\src\AsigPresupSAP.py, line 18, in Initialize
TypeError: Z_Fm_Asig_Get() takes exactly 6 arguments (5 given)

What do you suspect is happening?

The code is:
import time
import System
from System.IO import StreamWriter
import clr
print time.asctime()[10:] + ". Conectando con SAP......"
clr.AddReferenceToFile("SAPProxyE.dll")
#aso = System.Reflection.Assembly.LoadFrom('SAPProxyE.dll')
#System.Reflection.Assembly.LoadFrom('SAPProxyE.dll')
#clr.AddReference(aso)
#clr.AddReference("SAPProxyE.dll")
from SAPProxyE import *
#cs = 'ASHOST=.......'
cs = 'ASHOST=111.1.11.11 SYSNR=00 CLIENT=900 USER=xxx PASSWD=yyy
LANGUAGE=EN'
pASI = SAPProxy1(cs)
tASI = ZASIGTABTable()
print time.asctime()[10:] + u". Ejecutando la funci?n....."
#exit
res = pASI.Z_Fm_Asig_Get("2006", "XXXX", "YYYY", "", tASI)  <- the error is
here!!!
.
.
.
.
etc


I never made changes to the .dlls invoked.

Many, many thanks for your attention.

_________________________________________________________________
Consigue aqu? las mejores y mas recientes ofertas de trabajo en Am?rica
Latina y USA: http://latam.msn.com/empleos/

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From mbarnett at uniserve.com  Wed May 24 04:49:57 2006
From: mbarnett at uniserve.com (Lesley & Mitch Barnett)
Date: Tue, 23 May 2006 19:49:57 -0700
Subject: [IronPython] learning IronPython
In-Reply-To: <mailman.0.1148241955.2450.users-ironpython.com@lists.ironpython.com>
Message-ID: <000001c67edc$be3495e0$6401a8c0@NIS1861127372>

Thanks Michael and Richard, excellent info!  Much appreciated, Mitch


-----Original Message-----
Hi Mitch,
 
I second Michael's recommendation about comp.lang.python and Mark Pilgrim's
'Dive Into Python'. Another good online book that you might want to look at
is 'How to Think Like a Computer Scientist: Learning with Python' [
http://www.ibiblio.org/obp/thinkCSpy/].
 
I learnt Truth Value Testing from comp.lang.python
[http://docs.python.org/lib/truth.html]
 
Ironpython is perfect if you prefer the python syntax and know .NET's Base
Class Library well. That is what got me started as I, just like you, had
been programming with C# when I learnt python.
 
The quickest way to learn is to start writing your C# code in python,
download the python manual from python.org and use it whenever you need to
translate your C# equivalent. Slowly as you will read more python code, you
will start thinking more in python directly and when you write C# code, you
will come to like python's syntax. 
 
When you have specific CLR <--> python questions, you can always trust this
mailing list to help you out.
 
Regards,
Richard.

------------
IronPython almost has full Python 2.4 compliance, so it is not very
different from Python at all.

In addition 'translating' MSDN docs for use with IronPython is quite easy.

At ResolverSystems we are building a full desktop application using
IronPython and encountering very few difficulties. The only .NET
functionality we have found that isn't exposed to IronPython (for which we
have had to use C#) are a few parts needed for our functional tests. 
Only our program launcher uses C# in our production code.

This means you should find it easy to interface .NET code to IronPython. 
There are possibly some limitations that I haven't yet found. For example, I
believe it is not yet possible to compile Python scripts.

If you have specific Python questions then comp.lang.python is a good place
to ask :

http://groups.google.com/group/comp.lang.python?hl=en

For a good introduction to Python, the following online book is often
recommended :

http://diveintopython.org/

For IronPython questions and Python-.NET interaction questions, this is a
good forum to ask.

Hopefully in the next few days I will do a brief tutorial on using Windows
Forms with IronPython. It will only show the basics, but that ought to be
enough to show how to read the MSDN docs from a Python perspective.

All the best,

Fuzzyman



From sanxiyn at gmail.com  Wed May 24 06:18:47 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Wed, 24 May 2006 13:18:47 +0900
Subject: [IronPython] IronPython 1.0 Beta 7 Released!
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214EF7726605@df-foxhound-msg.exchange.corp.microsoft.com>
References: <4039D552ADAB094BB1EA670F3E96214EF7726605@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <5b0248170605232118x1d95bac3k47549f0c0e1fefbc@mail.gmail.com>

2006/5/24, Dino Viehland <dinov at exchange.microsoft.com>:
> Hello IronPython Community,
> We have just released IronPython 1.0 Beta 7...

But the release haven't appeared yet on gotdotnet workspace releases page.

Seo Sanghyeon


From sanxiyn at gmail.com  Wed May 24 12:02:33 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Wed, 24 May 2006 19:02:33 +0900
Subject: [IronPython] Special method lookup
Message-ID: <5b0248170605240302v49e6f66aj9036ab28f149a5e@mail.gmail.com>

Obscure. The issue is that special method lookup should only happen on
the type, not the instance. I am not sure whether this is clearly
specified...

# test.py
class Strange(object):
    pass

obj = Strange()
obj.__nonzero__ = lambda: False
print obj.__nonzero__()
print bool(obj)

# CPython
False
True

# IronPython
False
False

Seo Sanghyeon


From sanxiyn at gmail.com  Wed May 24 12:11:30 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Wed, 24 May 2006 19:11:30 +0900
Subject: [IronPython] Special method lookup
In-Reply-To: <5b0248170605240302v49e6f66aj9036ab28f149a5e@mail.gmail.com>
References: <5b0248170605240302v49e6f66aj9036ab28f149a5e@mail.gmail.com>
Message-ID: <5b0248170605240311p6c18f5afqca5973df8a402f5b@mail.gmail.com>

2006/5/24, Sanghyeon Seo <sanxiyn at gmail.com>:
> Obscure. The issue is that special method lookup should only happen on
> the type, not the instance. I am not sure whether this is clearly
> specified...

Python Reference Manual 3.3. The wording is not the best. Should file a doc bug.

"For instance, if a class defines a method named __getitem__(), and x
is an instance of this class, then x[i] is equivalent to
x.__getitem__(i)."

In this case, although x.__getitem__ exists, x is an instance of a
class which *does not* define a method named __getitem__(), so it
should not be called.

Seo Sanghyeon


From neville.bagnall at propylon.com  Wed May 24 15:45:24 2006
From: neville.bagnall at propylon.com (Neville Bagnall)
Date: Wed, 24 May 2006 13:45:24 -0000
Subject: [IronPython] __repr__ and __str__ for .NET types
In-Reply-To: <mailman.19767.1148444329.320.users-ironpython.com@lists.ironpython.com>
References: <mailman.19767.1148444329.320.users-ironpython.com@lists.ironpython.com>
Message-ID: <op.s915tyj666683y@nevillebagnall1.propylon.com>


>> Generally we try to meet in the middle on __repr__ - in many cases,  
>> it's most convenient if the output from __repr__ can be fed back into a  
>> factory or constructor for the class the text came from, so that the  
>> following expression is legal:
>>  new_object = Microsoft.DirectX.Vector3(repr(old_object))
>>  since
>>  eval(repr(old_object))
>>  usually isn't convenient, fast, or safe.
>Consider the output of repr(file('foo', 'rw')).

The standard library is inconsistent on this, some return "< description  
>", some an evaluable expression, (e.g. sets,mhlib).

The docs say:

'If at all possible, this should look like a valid Python expression that  
could be used to recreate an object with the same value (given an  
appropriate environment). If this is not possible, a string of the form  
"<...some useful description...>" should be returned.'

My reading of that, and the example of the standard library, suggests that  
repr(Microsoft.DirectX.Vector3()) should return something like  
"Vector3(0,0,0)".

But I don't see how IronPython can produce valid recreation expressions in  
the general case. Given that, my reading of the docs is that the angle  
delimiters are the conventional method of distinguishing descriptive repr  
strings from valid expressions.

FWIW in the general case I would have something equivalent to:

def GenRepr(object):
     strrep=object.ToString()
     if len(strrep)<40 and strrep.find('\n')==-1:
         return "<%s: %s>" % (object.__class__.__name__, repr(strrep)[1:-1])
     else:
         return "<%s at 0x%x>" % (object.__class__.__name__, id(object))

i.e. include a string representation only where it is reasonably concise,  
and include the markers in both cases.

Neville.


From paparipote at hotmail.com  Wed May 24 16:34:17 2006
From: paparipote at hotmail.com (Paparipote .)
Date: Wed, 24 May 2006 10:34:17 -0400
Subject: [IronPython] Running IP Beta 7
Message-ID: <BAY12-F134BED50AB2CC4E8A9090FDA980@phx.gbl>

Dino:

>>>print pASI.Z_Fm_Asig_Get.__doc__
(Void, int) Z_Fm_Asig_Get(str Z_Abgjr, str Z_Fictr, str Z_Kokrs, str 
Z_Kostl, ZASIGTABTable Salida)

Checking witl MSIL I Have:

.method public hidebysig newslot virtual
        instance void  Z_Fm_Asig_Get(string Z_Abgjr,
                                     string Z_Fictr,
                                     string Z_Kokrs,
                                     string Z_Kostl,
                                     [out] int32& Statu,
                                     class SAPProxyE.ZASIGTABTable& Salida) 
cil managed
{
  .custom instance void 
[SAP.Connector]SAP.Connector.RfcMethodAttribute::.ctor() = ( 01 00 01 00 54 
0E 08 41 62 61 70 4E 61 6D 65 0D   // ....T..AbapName.
                                                                             
         5A 5F 46 4D 5F 41 53 49 47 5F 47 45 54 )          // Z_FM_ASIG_GET
  .custom instance void 
[System.Web.Services]System.Web.Services.Protocols.SoapDocumentMethodAttribute::.ctor(string) 
= ( 01 00 20 68 74 74 70 3A 2F 2F 74 65 6D 70 75 72   // .. http://tempur


Thanks!!!

_________________________________________________________________
MSN Amor: busca tu ? naranja http://latam.msn.com/amor/



From korpse-ironpython at kaydash.za.net  Wed May 24 16:59:57 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Wed, 24 May 2006 16:59:57 +0200
Subject: [IronPython] __repr__ and __str__ for .NET types
In-Reply-To: <op.s915tyj666683y@nevillebagnall1.propylon.com>
References: <mailman.19767.1148444329.320.users-ironpython.com@lists.ironpython.com>
	<op.s915tyj666683y@nevillebagnall1.propylon.com>
Message-ID: <447474ED.60701@kaydash.za.net>

Neville Bagnall wrote:
> FWIW in the general case I would have something equivalent to:
> 
> def GenRepr(object):
>      strrep=object.ToString()
>      if len(strrep)<40 and strrep.find('\n')==-1:
>          return "<%s: %s>" % (object.__class__.__name__, repr(strrep)[1:-1])
>      else:
>          return "<%s at 0x%x>" % (object.__class__.__name__, id(object))
> 
> i.e. include a string representation only where it is reasonably concise,  
> and include the markers in both cases.

I would be happy with something like that and I think it ends up being a 
better solution than what is currently the situation.
-- 
Jonathan



From dinov at exchange.microsoft.com  Wed May 24 17:27:16 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 24 May 2006 08:27:16 -0700
Subject: [IronPython] Special method lookup
In-Reply-To: <5b0248170605240311p6c18f5afqca5973df8a402f5b@mail.gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EF772694E@df-foxhound-msg.exchange.corp.microsoft.com>

Thanks for the bug report - we're actually aware of this issue.  I made some small fixes while fixing other bugs that corrected this in some spots, but not all...  I've gone ahead and opened a bug to track it (we didn't have one before) so we'll get it entirely cleaned up for the next release.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Wednesday, May 24, 2006 3:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Special method lookup

2006/5/24, Sanghyeon Seo <sanxiyn at gmail.com>:
> Obscure. The issue is that special method lookup should only happen on
> the type, not the instance. I am not sure whether this is clearly
> specified...

Python Reference Manual 3.3. The wording is not the best. Should file a doc bug.

"For instance, if a class defines a method named __getitem__(), and x
is an instance of this class, then x[i] is equivalent to
x.__getitem__(i)."

In this case, although x.__getitem__ exists, x is an instance of a
class which *does not* define a method named __getitem__(), so it
should not be called.

Seo Sanghyeon
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Wed May 24 17:30:49 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 24 May 2006 08:30:49 -0700
Subject: [IronPython] __repr__ and __str__ for .NET types
In-Reply-To: <447474ED.60701@kaydash.za.net>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EF7726951@df-foxhound-msg.exchange.corp.microsoft.com>

I've opened a bug for us to reconsider what we're doing here.  I'm not sure what the final solution will be but we'll make sure to follow up on the mailing list with what we end up with.  Thanks for suggestion (and the interesting discussion!)

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Jacobs
Sent: Wednesday, May 24, 2006 8:00 AM
To: Discussion of IronPython
Subject: Re: [IronPython] __repr__ and __str__ for .NET types

Neville Bagnall wrote:
> FWIW in the general case I would have something equivalent to:
>
> def GenRepr(object):
>      strrep=object.ToString()
>      if len(strrep)<40 and strrep.find('\n')==-1:
>          return "<%s: %s>" % (object.__class__.__name__, repr(strrep)[1:-1])
>      else:
>          return "<%s at 0x%x>" % (object.__class__.__name__, id(object))
>
> i.e. include a string representation only where it is reasonably concise,
> and include the markers in both cases.

I would be happy with something like that and I think it ends up being a
better solution than what is currently the situation.
--
Jonathan

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Wed May 24 17:35:23 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 24 May 2006 08:35:23 -0700
Subject: [IronPython] Running IP Beta 7
In-Reply-To: <BAY12-F134BED50AB2CC4E8A9090FDA980@phx.gbl>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EF7726953@df-foxhound-msg.exchange.corp.microsoft.com>

This is definitely our bug - I've opened a bug in our database to track the issue.  Let me look into what the issue is more closely, maybe I can send out a small change that will fix this for you.


Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Paparipote .
Sent: Wednesday, May 24, 2006 7:34 AM
To: users at lists.ironpython.com
Subject: [IronPython] Running IP Beta 7

Dino:

>>>print pASI.Z_Fm_Asig_Get.__doc__
(Void, int) Z_Fm_Asig_Get(str Z_Abgjr, str Z_Fictr, str Z_Kokrs, str
Z_Kostl, ZASIGTABTable Salida)

Checking witl MSIL I Have:

.method public hidebysig newslot virtual
        instance void  Z_Fm_Asig_Get(string Z_Abgjr,
                                     string Z_Fictr,
                                     string Z_Kokrs,
                                     string Z_Kostl,
                                     [out] int32& Statu,
                                     class SAPProxyE.ZASIGTABTable& Salida)
cil managed
{
  .custom instance void
[SAP.Connector]SAP.Connector.RfcMethodAttribute::.ctor() = ( 01 00 01 00 54
0E 08 41 62 61 70 4E 61 6D 65 0D   // ....T..AbapName.

         5A 5F 46 4D 5F 41 53 49 47 5F 47 45 54 )          // Z_FM_ASIG_GET
  .custom instance void
[System.Web.Services]System.Web.Services.Protocols.SoapDocumentMethodAttribute::.ctor(string)
= ( 01 00 20 68 74 74 70 3A 2F 2F 74 65 6D 70 75 72   // .. http://tempur


Thanks!!!

_________________________________________________________________
MSN Amor: busca tu ? naranja http://latam.msn.com/amor/

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Wed May 24 17:35:45 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 24 May 2006 08:35:45 -0700
Subject: [IronPython] IronPython 1.0 Beta 7 Released!
In-Reply-To: <5b0248170605232118x1d95bac3k47549f0c0e1fefbc@mail.gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EF7726954@df-foxhound-msg.exchange.corp.microsoft.com>

Ahh, I had posted the release notes there but not the actual release.  Thanks for catching this, it's been corrected.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Tuesday, May 23, 2006 9:19 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython 1.0 Beta 7 Released!

2006/5/24, Dino Viehland <dinov at exchange.microsoft.com>:
> Hello IronPython Community,
> We have just released IronPython 1.0 Beta 7...

But the release haven't appeared yet on gotdotnet workspace releases page.

Seo Sanghyeon
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Wed May 24 19:17:38 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 24 May 2006 10:17:38 -0700
Subject: [IronPython] Running IP Beta 7
In-Reply-To: <BAY12-F134BED50AB2CC4E8A9090FDA980@phx.gbl>
Message-ID: <4039D552ADAB094BB1EA670F3E96214EF7726A6C@df-foxhound-msg.exchange.corp.microsoft.com>

The fix for this is really simple, if you open Src\IronPython\Runtime\ReflectedMethod.cs and change line 330:

From:   } else if(outArgs != 0 && outArgs == i) {
To  :   } else if(outArgs != 0 && (curArg+outArgs)  == i) {

Then this will work.

Sorry for the regression here.  We'll add this to our test suite so that we don't break it as we make additional changes to method dispatch.

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Paparipote .
Sent: Wednesday, May 24, 2006 7:34 AM
To: users at lists.ironpython.com
Subject: [IronPython] Running IP Beta 7

Dino:

>>>print pASI.Z_Fm_Asig_Get.__doc__
(Void, int) Z_Fm_Asig_Get(str Z_Abgjr, str Z_Fictr, str Z_Kokrs, str
Z_Kostl, ZASIGTABTable Salida)

Checking witl MSIL I Have:

.method public hidebysig newslot virtual
        instance void  Z_Fm_Asig_Get(string Z_Abgjr,
                                     string Z_Fictr,
                                     string Z_Kokrs,
                                     string Z_Kostl,
                                     [out] int32& Statu,
                                     class SAPProxyE.ZASIGTABTable& Salida)
cil managed
{
  .custom instance void
[SAP.Connector]SAP.Connector.RfcMethodAttribute::.ctor() = ( 01 00 01 00 54
0E 08 41 62 61 70 4E 61 6D 65 0D   // ....T..AbapName.

         5A 5F 46 4D 5F 41 53 49 47 5F 47 45 54 )          // Z_FM_ASIG_GET
  .custom instance void
[System.Web.Services]System.Web.Services.Protocols.SoapDocumentMethodAttribute::.ctor(string)
= ( 01 00 20 68 74 74 70 3A 2F 2F 74 65 6D 70 75 72   // .. http://tempur


Thanks!!!

_________________________________________________________________
MSN Amor: busca tu ? naranja http://latam.msn.com/amor/

_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From paparipote at hotmail.com  Thu May 25 03:56:56 2006
From: paparipote at hotmail.com (Paparipote .)
Date: Wed, 24 May 2006 21:56:56 -0400
Subject: [IronPython] Running IP Beta 7
Message-ID: <BAY12-F130DA16600B1FAB61DBCA3DA990@phx.gbl>

Dino:
Your solution worked!!
Many, many thanks for your attention and help.

_________________________________________________________________
MSN Amor: busca tu ? naranja http://latam.msn.com/amor/



From sanxiyn at gmail.com  Thu May 25 06:25:28 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 25 May 2006 13:25:28 +0900
Subject: [IronPython] IronPython 1.0 Beta 7 on Mono
Message-ID: <5b0248170605242125o172a894fnd30da3ab9a7360c0@mail.gmail.com>

You need Mono later than SVN revision 61043 to compile and run
IronPython 1.0 Beta 7.

Actually, that's because I hacked on Mono to just do that, and my
patch got applied in that revision. I didn't expect to hack on Mono
when I first started playing with IronPython... Such is life, I guess.

Seo Sanghyeon


From jvm_cop at spamcop.net  Thu May 25 06:54:50 2006
From: jvm_cop at spamcop.net (J. Merrill)
Date: Thu, 25 May 2006 00:54:50 -0400
Subject: [IronPython] Special method lookup
In-Reply-To: <5b0248170605240311p6c18f5afqca5973df8a402f5b@mail.gmail.co
 m>
References: <5b0248170605240302v49e6f66aj9036ab28f149a5e@mail.gmail.com>
	<5b0248170605240311p6c18f5afqca5973df8a402f5b@mail.gmail.com>
Message-ID: <7.0.1.0.2.20060525005242.0468e368@wheresmymailserver.com>

When you file the doc bug, make sure that your "in this case" paragraph mentions __nonzero__ rather than __getitem__ (assuming you use the same example that started this, of course).

At 06:11 AM 5/24/2006, Sanghyeon Seo wrote
>2006/5/24, Sanghyeon Seo <sanxiyn at gmail.com>:
>> Obscure. The issue is that special method lookup should only happen on
>> the type, not the instance. I am not sure whether this is clearly
>> specified...
>
>Python Reference Manual 3.3. The wording is not the best. Should file a doc bug.
>
>"For instance, if a class defines a method named __getitem__(), and x
>is an instance of this class, then x[i] is equivalent to
>x.__getitem__(i)."
>
>In this case, although x.__getitem__ exists, x is an instance of a
>class which *does not* define a method named __getitem__(), so it
>should not be called.
>
>Seo Sanghyeon


J. Merrill / Analytical Software Corp




From sanxiyn at gmail.com  Thu May 25 07:43:54 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Thu, 25 May 2006 14:43:54 +0900
Subject: [IronPython] Special method lookup
In-Reply-To: <5b0248170605240311p6c18f5afqca5973df8a402f5b@mail.gmail.com>
References: <5b0248170605240302v49e6f66aj9036ab28f149a5e@mail.gmail.com>
	<5b0248170605240311p6c18f5afqca5973df8a402f5b@mail.gmail.com>
Message-ID: <5b0248170605242243x2feb2b6bt51346fabd667ff24@mail.gmail.com>

2006/5/24, Sanghyeon Seo <sanxiyn at gmail.com>:
>
> "For instance, if a class defines a method named __getitem__(), and x
> is an instance of this class, then x[i] is equivalent to
> x.__getitem__(i)."
>
> In this case, although x.__getitem__ exists, x is an instance of a
> class which *does not* define a method named __getitem__(), so it
> should not be called.
>
> Seo Sanghyeon

Bah, I spoke too soon. This does not apply to old-style classes.

Seo Sanghyeon


From michael.foord at resolversystems.com  Thu May 25 15:52:54 2006
From: michael.foord at resolversystems.com (Michael Foord)
Date: Thu, 25 May 2006 14:52:54 +0100
Subject: [IronPython] IronPython & Windows Forms
Message-ID: <4475B6B6.605@resolversystems.com>

Hello all,

I've finally started work on a series of articles called "IronPython & 
Windows Forms". These are a tutorial on how to create Windows Forms 
applications with IronPython.

These will appear on my Voidspace website. As I complete parts of the 
articles I'm posting them as blog entries. The first two entries are now up.

    http://www.voidspace.org.uk/python/weblog/arch_d7_2006_05_20.shtml#e342
    http://www.voidspace.org.uk/python/weblog/arch_d7_2006_05_20.shtml#e343

These are a first rough cut, and will be refined when I turn them into 
articles. Corrections (including spelling, fact  and code corrections) 
are very much welcomed, as are suggestions.

When I post new entries, I'll email a 'heads up' here. I hope this is 
welcomed.

All the best,

Michael Foord
http://www.voidspace.org.uk/python/index.shtml


From ryan at acceleration.net  Thu May 25 15:57:57 2006
From: ryan at acceleration.net (Ryan Davis)
Date: Thu, 25 May 2006 09:57:57 -0400
Subject: [IronPython] IronPython & Windows Forms
In-Reply-To: <4475B6B6.605@resolversystems.com>
References: <4475B6B6.605@resolversystems.com>
Message-ID: <4475B7E5.4030101@acceleration.net>

This is very welcomed.

Ryan Davis
Acceleration.net
Director of Programming Services
2831 NW 41st street, suite B
Gainesville, FL 32606

Office: 352-335-6500 x 124
Fax: 352-335-6506



Michael Foord wrote:
> Hello all,
>
> I've finally started work on a series of articles called "IronPython & 
> Windows Forms". These are a tutorial on how to create Windows Forms 
> applications with IronPython.
>
> These will appear on my Voidspace website. As I complete parts of the 
> articles I'm posting them as blog entries. The first two entries are now up.
>
>     http://www.voidspace.org.uk/python/weblog/arch_d7_2006_05_20.shtml#e342
>     http://www.voidspace.org.uk/python/weblog/arch_d7_2006_05_20.shtml#e343
>
> These are a first rough cut, and will be refined when I turn them into 
> articles. Corrections (including spelling, fact  and code corrections) 
> are very much welcomed, as are suggestions.
>
> When I post new entries, I'll email a 'heads up' here. I hope this is 
> welcomed.
>
> All the best,
>
> Michael Foord
> http://www.voidspace.org.uk/python/index.shtml
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   


From korpse-ironpython at kaydash.za.net  Thu May 25 17:33:27 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Thu, 25 May 2006 17:33:27 +0200
Subject: [IronPython] Optimized methods and serious performance issues
Message-ID: <4475CE47.6000704@kaydash.za.net>

(Please disregard any earlier message about this, I think I might have pressed 
"Send" accidentally.)

Hi,

I ran across some "interesting" behaviour today.

Short version:
I have a handful of Direct3D.Mesh objects (courtesy of Direct3D.Mesh.Teapot) 
which I render using self.meshInstance.DrawSubset(0). I've been experiencing 
pretty serious performance issues, so I did a bit of testing and this is what 
I came up with:

(The averages are accumulated every call and averaged (and output) every 500 
calls, a small value is obviously better, all values are in milliseconds.)

No drawing calls:
running average: 0.0236448413598 ms
running average: 0.0229452898402 ms
running average: 0.0236400825059 ms
running average: 0.0257713352135 ms

No drawing calls, -X:NoOptimize:
running average: 0.0251883756139
running average: 0.0250299057799
running average: 0.0224732115359
running average: 0.0225412631463

self.mesh.DrawSubset(0):
running average: 3.40948918622 ms
running average: 3.45289207504 ms
running average: 3.43480367147 ms
running average: 3.45502784866 ms

self.mesh.DrawSubset(0), -X:NoOptimize:
running average: 0.111673644441 ms
running average: 0.118880928633 ms
running average: 0.134856876975 ms
running average: 0.11670232533 ms

Helper.DrawMesh(self.mesh, 0):
running average: 0.0415348007294 ms
running average: 0.0328241945979 ms
running average: 0.0296612223703 ms
running average: 0.0330559507815 ms

Helper.DrawMesh(self.mesh, 0), -X:NoOptimize:
running average: 0.063753413583 ms
running average: 0.0668509515698 ms
running average: 0.0603922350916 ms
running average: 0.070181197511 ms

Helper.DrawMesh is my own function implemented in C#:
public class Helper {
   public static void DrawMesh(Microsoft.DirectX.Direct3D.Mesh mesh, int id) {
     mesh.DrawSubset(id);
   }
}

I'm interested as to why the self.mesh.DrawSubset call is so disappointingly 
slow and why it is sped up by *disabling* method optimization.

Unfortunately, it is laborious for me to separate the useful code from the 
not-so-useful code and I'm not sure how to reproduce this outside of DirectX. 
I can take some time out to try and cut this down to the bare essentials if 
need be.

Regards
-- 
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master


From dinov at exchange.microsoft.com  Thu May 25 18:26:34 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 25 May 2006 09:26:34 -0700
Subject: [IronPython] Optimized methods and serious performance issues
In-Reply-To: <4475CE47.6000704@kaydash.za.net>
References: <4475CE47.6000704@kaydash.za.net>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E01A42A1023@df-foxhound-msg.exchange.corp.microsoft.com>

If I had to take a guess it would be that we are constantly re-optimizing the method (failing to successfully cache it) - which would be a significant performance loss.

Any chance we could get you to run a debug build w/ the -X:TrackPerformance and -D command line options?

You should then see in the output "DrawSubset #" where # should be small (e.g. 1 or 2) - if it's large then we know the issue, we just need to get a simple repro of it.

Do you know if the direct X classes come to you via a interop assembly?  Or if they're COM objects?  Maybe we have a strange interaction there that is preventing the back patching for one of those.

________________________________________
From: users-bounces at lists.ironpython.com On Behalf Of Jonathan Jacobs
Sent: Thursday, May 25, 2006 8:33 AM
To: IronPython List
Subject: [IronPython] Optimized methods and serious performance issues

(Please disregard any earlier message about this, I think I might have pressed
"Send" accidentally.)

Hi,

I ran across some "interesting" behaviour today.

Short version:
I have a handful of Direct3D.Mesh objects (courtesy of Direct3D.Mesh.Teapot)
which I render using self.meshInstance.DrawSubset(0). I've been experiencing
pretty serious performance issues, so I did a bit of testing and this is what
I came up with:

(The averages are accumulated every call and averaged (and output) every 500
calls, a small value is obviously better, all values are in milliseconds.)

No drawing calls:
running average: 0.0236448413598 ms
running average: 0.0229452898402 ms
running average: 0.0236400825059 ms
running average: 0.0257713352135 ms

No drawing calls, -X:NoOptimize:
running average: 0.0251883756139
running average: 0.0250299057799
running average: 0.0224732115359
running average: 0.0225412631463

self.mesh.DrawSubset(0):
running average: 3.40948918622 ms
running average: 3.45289207504 ms
running average: 3.43480367147 ms
running average: 3.45502784866 ms

self.mesh.DrawSubset(0), -X:NoOptimize:
running average: 0.111673644441 ms
running average: 0.118880928633 ms
running average: 0.134856876975 ms
running average: 0.11670232533 ms

Helper.DrawMesh(self.mesh, 0):
running average: 0.0415348007294 ms
running average: 0.0328241945979 ms
running average: 0.0296612223703 ms
running average: 0.0330559507815 ms

Helper.DrawMesh(self.mesh, 0), -X:NoOptimize:
running average: 0.063753413583 ms
running average: 0.0668509515698 ms
running average: 0.0603922350916 ms
running average: 0.070181197511 ms

Helper.DrawMesh is my own function implemented in C#:
public class Helper {
   public static void DrawMesh(Microsoft.DirectX.Direct3D.Mesh mesh, int id) {
     mesh.DrawSubset(id);
   }
}

I'm interested as to why the self.mesh.DrawSubset call is so disappointingly
slow and why it is sped up by *disabling* method optimization.

Unfortunately, it is laborious for me to separate the useful code from the
not-so-useful code and I'm not sure how to reproduce this outside of DirectX.
I can take some time out to try and cut this down to the bare essentials if
need be.

Regards
--
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Thu May 25 18:26:34 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 25 May 2006 09:26:34 -0700
Subject: [IronPython] Optimized methods and serious performance issues
In-Reply-To: <4475CE47.6000704@kaydash.za.net>
References: <4475CE47.6000704@kaydash.za.net>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E01A42A1023@df-foxhound-msg.exchange.corp.microsoft.com>

If I had to take a guess it would be that we are constantly re-optimizing the method (failing to successfully cache it) - which would be a significant performance loss.

Any chance we could get you to run a debug build w/ the -X:TrackPerformance and -D command line options?

You should then see in the output "DrawSubset #" where # should be small (e.g. 1 or 2) - if it's large then we know the issue, we just need to get a simple repro of it.

Do you know if the direct X classes come to you via a interop assembly?  Or if they're COM objects?  Maybe we have a strange interaction there that is preventing the back patching for one of those.

________________________________________
From: users-bounces at lists.ironpython.com On Behalf Of Jonathan Jacobs
Sent: Thursday, May 25, 2006 8:33 AM
To: IronPython List
Subject: [IronPython] Optimized methods and serious performance issues

(Please disregard any earlier message about this, I think I might have pressed
"Send" accidentally.)

Hi,

I ran across some "interesting" behaviour today.

Short version:
I have a handful of Direct3D.Mesh objects (courtesy of Direct3D.Mesh.Teapot)
which I render using self.meshInstance.DrawSubset(0). I've been experiencing
pretty serious performance issues, so I did a bit of testing and this is what
I came up with:

(The averages are accumulated every call and averaged (and output) every 500
calls, a small value is obviously better, all values are in milliseconds.)

No drawing calls:
running average: 0.0236448413598 ms
running average: 0.0229452898402 ms
running average: 0.0236400825059 ms
running average: 0.0257713352135 ms

No drawing calls, -X:NoOptimize:
running average: 0.0251883756139
running average: 0.0250299057799
running average: 0.0224732115359
running average: 0.0225412631463

self.mesh.DrawSubset(0):
running average: 3.40948918622 ms
running average: 3.45289207504 ms
running average: 3.43480367147 ms
running average: 3.45502784866 ms

self.mesh.DrawSubset(0), -X:NoOptimize:
running average: 0.111673644441 ms
running average: 0.118880928633 ms
running average: 0.134856876975 ms
running average: 0.11670232533 ms

Helper.DrawMesh(self.mesh, 0):
running average: 0.0415348007294 ms
running average: 0.0328241945979 ms
running average: 0.0296612223703 ms
running average: 0.0330559507815 ms

Helper.DrawMesh(self.mesh, 0), -X:NoOptimize:
running average: 0.063753413583 ms
running average: 0.0668509515698 ms
running average: 0.0603922350916 ms
running average: 0.070181197511 ms

Helper.DrawMesh is my own function implemented in C#:
public class Helper {
   public static void DrawMesh(Microsoft.DirectX.Direct3D.Mesh mesh, int id) {
     mesh.DrawSubset(id);
   }
}

I'm interested as to why the self.mesh.DrawSubset call is so disappointingly
slow and why it is sped up by *disabling* method optimization.

Unfortunately, it is laborious for me to separate the useful code from the
not-so-useful code and I'm not sure how to reproduce this outside of DirectX.
I can take some time out to try and cut this down to the bare essentials if
need be.

Regards
--
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From jvm_cop at spamcop.net  Thu May 25 18:29:21 2006
From: jvm_cop at spamcop.net (J. Merrill)
Date: Thu, 25 May 2006 12:29:21 -0400
Subject: [IronPython] Optimized methods and serious performance  issues
In-Reply-To: <4475CE47.6000704@kaydash.za.net>
References: <4475CE47.6000704@kaydash.za.net>
Message-ID: <7.0.1.0.2.20060525121940.0469a680@wheresmymailserver.com>

I know almost nothing about DirectX, am definitely not a Python guru, and have not experimented with IP in this area.  However, my impression is that there is a common Python "idiom" for speeding up method calls, which is to use a variable (often a local) to hold a reference to a "bound method" and make calls through that variable.  This avoids all the work that normally has to be done to figure out what actual method (the one associated with the instance, the class, the parent class, the parent class's parent, etc etc) is supposed to be called by a particular "callable" expression.

Whether this is appropriate in your case, I can't say.  For example, if the value of self.mesh can change while your loop is running, it won't give the right results to do
    methref = self.mesh.DrawSubset
and then call
    methref(0)
in your loop, because this will call via whatever value mesh had been when you set methref. 

If it's appropriate, have you tried that technique?

At 11:33 AM 5/25/2006, Jonathan Jacobs wrote
>(Please disregard any earlier message about this, I think I might have pressed 
>"Send" accidentally.)
>
>Hi,
>
>I ran across some "interesting" behaviour today.
>
>Short version:
>I have a handful of Direct3D.Mesh objects (courtesy of Direct3D.Mesh.Teapot) 
>which I render using self.meshInstance.DrawSubset(0). I've been experiencing 
>pretty serious performance issues, so I did a bit of testing and this is what 
>I came up with:
>
>(The averages are accumulated every call and averaged (and output) every 500 
>calls, a small value is obviously better, all values are in milliseconds.)
>
>No drawing calls:
>running average: 0.0236448413598 ms
>running average: 0.0229452898402 ms
>running average: 0.0236400825059 ms
>running average: 0.0257713352135 ms
>
>No drawing calls, -X:NoOptimize:
>running average: 0.0251883756139
>running average: 0.0250299057799
>running average: 0.0224732115359
>running average: 0.0225412631463
>
>self.mesh.DrawSubset(0):
>running average: 3.40948918622 ms
>running average: 3.45289207504 ms
>running average: 3.43480367147 ms
>running average: 3.45502784866 ms
>
>self.mesh.DrawSubset(0), -X:NoOptimize:
>running average: 0.111673644441 ms
>running average: 0.118880928633 ms
>running average: 0.134856876975 ms
>running average: 0.11670232533 ms
>
>Helper.DrawMesh(self.mesh, 0):
>running average: 0.0415348007294 ms
>running average: 0.0328241945979 ms
>running average: 0.0296612223703 ms
>running average: 0.0330559507815 ms
>
>Helper.DrawMesh(self.mesh, 0), -X:NoOptimize:
>running average: 0.063753413583 ms
>running average: 0.0668509515698 ms
>running average: 0.0603922350916 ms
>running average: 0.070181197511 ms
>
>Helper.DrawMesh is my own function implemented in C#:
>public class Helper {
>   public static void DrawMesh(Microsoft.DirectX.Direct3D.Mesh mesh, int id) {
>     mesh.DrawSubset(id);
>   }
>}
>
>I'm interested as to why the self.mesh.DrawSubset call is so disappointingly 
>slow and why it is sped up by *disabling* method optimization.
>
>Unfortunately, it is laborious for me to separate the useful code from the 
>not-so-useful code and I'm not sure how to reproduce this outside of DirectX. 
>I can take some time out to try and cut this down to the bare essentials if 
>need be.
>
>Regards
>-- 
>Jonathan
>
>When you meet a master swordsman,
>show him your sword.
>When you meet a man who is not a poet,
>do not show him your poem.
>                 -- Rinzai, ninth century Zen master


J. Merrill / Analytical Software Corp




From dinov at exchange.microsoft.com  Thu May 25 18:45:58 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 25 May 2006 09:45:58 -0700
Subject: [IronPython] Optimized methods and serious performance  issues
In-Reply-To: <7.0.1.0.2.20060525121940.0469a680@wheresmymailserver.com>
References: <4475CE47.6000704@kaydash.za.net>,
	<7.0.1.0.2.20060525121940.0469a680@wheresmymailserver.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E01A42A1025@df-foxhound-msg.exchange.corp.microsoft.com>

This common idiom actually works against our reflect optimization of built-in methods, but we still make it work.

Just to give you (and anyone else curious) an overview of this:  We have a piece of code called the ReflectOptimizer which generates an optimized call to .NET methods.  The way it does this is it generates code for doing type checks for all the possible overloads of a method and emits that all into one method.  Then when you call from Python we dispatch to this helper method, which can do a bunch of efficient type checks, and finally dispatch to the correct method.

Creating these methods isn't cheap, so we defer this until the first invocation of a method.  At that point in time we replace the callers method (in whatever dictionary they were in) with the new optimized method.

When someone follows the common idiom we cannot successfully back patch the reference to the method, so instead the non-optimized method needs to remember that it's been optimized and use the optimized method instead.  Eventually the local copy will go out of scope, and we'll be left w/ only the optimized version.

The back-patching is what's potentially problematic: If we get that back-patching wrong then we'll continuously re-optimize methods over and over again.  That obviously kills performance, which is what I suspect is going on here.

Now strangely enough because the work we do to make this common idiom still be efficient this could actually be a way to work around the back-patching bug, if that is indeed what we're seeing.

________________________________________
From: users-bounces at lists.ironpython.com On Behalf Of J. Merrill
Sent: Thursday, May 25, 2006 9:29 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Optimized methods and serious performance  issues

I know almost nothing about DirectX, am definitely not a Python guru, and have not experimented with IP in this area.  However, my impression is that there is a common Python "idiom" for speeding up method calls, which is to use a variable (often a local) to hold a reference to a "bound method" and make calls through that variable.  This avoids all the work that normally has to be done to figure out what actual method (the one associated with the instance, the class, the parent class, the parent class's parent, etc etc) is supposed to be called by a particular "callable" expression.

Whether this is appropriate in your case, I can't say.  For example, if the value of self.mesh can change while your loop is running, it won't give the right results to do
    methref = self.mesh.DrawSubset
and then call
    methref(0)
in your loop, because this will call via whatever value mesh had been when you set methref.

If it's appropriate, have you tried that technique?

At 11:33 AM 5/25/2006, Jonathan Jacobs wrote
>(Please disregard any earlier message about this, I think I might have pressed
>"Send" accidentally.)
>
>Hi,
>
>I ran across some "interesting" behaviour today.
>
>Short version:
>I have a handful of Direct3D.Mesh objects (courtesy of Direct3D.Mesh.Teapot)
>which I render using self.meshInstance.DrawSubset(0). I've been experiencing
>pretty serious performance issues, so I did a bit of testing and this is what
>I came up with:
>
>(The averages are accumulated every call and averaged (and output) every 500
>calls, a small value is obviously better, all values are in milliseconds.)
>
>No drawing calls:
>running average: 0.0236448413598 ms
>running average: 0.0229452898402 ms
>running average: 0.0236400825059 ms
>running average: 0.0257713352135 ms
>
>No drawing calls, -X:NoOptimize:
>running average: 0.0251883756139
>running average: 0.0250299057799
>running average: 0.0224732115359
>running average: 0.0225412631463
>
>self.mesh.DrawSubset(0):
>running average: 3.40948918622 ms
>running average: 3.45289207504 ms
>running average: 3.43480367147 ms
>running average: 3.45502784866 ms
>
>self.mesh.DrawSubset(0), -X:NoOptimize:
>running average: 0.111673644441 ms
>running average: 0.118880928633 ms
>running average: 0.134856876975 ms
>running average: 0.11670232533 ms
>
>Helper.DrawMesh(self.mesh, 0):
>running average: 0.0415348007294 ms
>running average: 0.0328241945979 ms
>running average: 0.0296612223703 ms
>running average: 0.0330559507815 ms
>
>Helper.DrawMesh(self.mesh, 0), -X:NoOptimize:
>running average: 0.063753413583 ms
>running average: 0.0668509515698 ms
>running average: 0.0603922350916 ms
>running average: 0.070181197511 ms
>
>Helper.DrawMesh is my own function implemented in C#:
>public class Helper {
>   public static void DrawMesh(Microsoft.DirectX.Direct3D.Mesh mesh, int id) {
>     mesh.DrawSubset(id);
>   }
>}
>
>I'm interested as to why the self.mesh.DrawSubset call is so disappointingly
>slow and why it is sped up by *disabling* method optimization.
>
>Unfortunately, it is laborious for me to separate the useful code from the
>not-so-useful code and I'm not sure how to reproduce this outside of DirectX.
>I can take some time out to try and cut this down to the bare essentials if
>need be.
>
>Regards
>--
>Jonathan
>
>When you meet a master swordsman,
>show him your sword.
>When you meet a man who is not a poet,
>do not show him your poem.
>                 -- Rinzai, ninth century Zen master


J. Merrill / Analytical Software Corp


_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From korpse-ironpython at kaydash.za.net  Thu May 25 18:46:09 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Thu, 25 May 2006 18:46:09 +0200
Subject: [IronPython] Optimized methods and serious performance  issues
In-Reply-To: <7.0.1.0.2.20060525121940.0469a680@wheresmymailserver.com>
References: <4475CE47.6000704@kaydash.za.net>
	<7.0.1.0.2.20060525121940.0469a680@wheresmymailserver.com>
Message-ID: <4475DF51.3070007@kaydash.za.net>

J. Merrill wrote:
> I know almost nothing about DirectX, am definitely not a Python guru, and
> have not experimented with IP in this area.  However, my impression is that
> there is a common Python "idiom" for speeding up method calls, which is to
> use a variable (often a local) to hold a reference to a "bound method" and
> make calls through that variable.  This avoids all the work that normally
> has to be done to figure out what actual method (the one associated with
> the instance, the class, the parent class, the parent class's parent, etc
> etc) is supposed to be called by a particular "callable" expression.
> 
> Whether this is appropriate in your case, I can't say.  For example, if the
> value of self.mesh can change while your loop is running, it won't give the
> right results to do methref = self.mesh.DrawSubset and then call methref(0)
>  in your loop, because this will call via whatever value mesh had been when
> you set methref.
> 
> If it's appropriate, have you tried that technique?

I'd forgotten about this, so I gave it a shot:

fun = self.mesh.DrawSubset
fun(0)

yielded no noticeable speedup, however:

fun = Direct3D.Mesh.DrawSubset
fun(self.mesh, 0)

yielded a significant speedup, oddly.
-- 
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master


From korpse-ironpython at kaydash.za.net  Thu May 25 18:59:26 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Thu, 25 May 2006 18:59:26 +0200
Subject: [IronPython] Optimized methods and serious performance issues
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214E01A42A1023@df-foxhound-msg.exchange.corp.microsoft.com>
References: <4475CE47.6000704@kaydash.za.net>
	<4039D552ADAB094BB1EA670F3E96214E01A42A1023@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <4475E26E.7010503@kaydash.za.net>

Dino Viehland wrote:
> If I had to take a guess it would be that we are constantly re-optimizing
> the method (failing to successfully cache it) - which would be a
> significant performance loss.
> 
> Any chance we could get you to run a debug build w/ the -X:TrackPerformance
> and -D command line options?
> 
> You should then see in the output "DrawSubset #" where # should be small
> (e.g. 1 or 2) - if it's large then we know the issue, we just need to get a
> simple repro of it.
> 
> Do you know if the direct X classes come to you via a interop assembly?  Or
> if they're COM objects?  Maybe we have a strange interaction there that is
> preventing the back patching for one of those.

Output with self.mesh.DrawSubset:
FieldTable DrawSubset 1664
BackwardsFieldTableLookup DrawSubset 2
DrawSubset 1660

Output with Direct3D.Mesh.DrawSubset (as mentioned in my reply to J. Merrill):
FieldTable DrawSubset 5
BackwardsFieldTableLookup DrawSubset 2
DrawSubset 1

So it looks like your guess was right on the money.

I wouldn't know if they're interop or COM. How would I find out?

-- 
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master


From Harry.Pierson at microsoft.com  Thu May 25 19:00:18 2006
From: Harry.Pierson at microsoft.com (Harry Pierson)
Date: Thu, 25 May 2006 10:00:18 -0700
Subject: [IronPython] Optimized methods and serious performance issues
References: <4475CE47.6000704@kaydash.za.net><4039D552ADAB094BB1EA670F3E96214E01A42A1023@df-foxhound-msg.exchange.corp.microsoft.com>
	<4475E26E.7010503@kaydash.za.net>
Message-ID: <92ED8A12D2BC094FAFCD16EC57E199FD03BF49@RED-MSG-81.redmond.corp.microsoft.com>

DirectX is COM based. Managed DirectX is a managed wraper around those COM obects.
 
Harry Pierson
Architect
Microsoft Architecture Strategy Team
email:                    hpierson at microsoft.com
IM/email:              harrypierson at hotmail.com
weblog:                 http://devhawk.net <http://.devhawk.net/>  
phone:                   425/705.6045
Make Trouble and Good Things Will Happen
 

________________________________

From: users-bounces at lists.ironpython.com on behalf of Jonathan Jacobs
Sent: Thu 5/25/2006 9:59 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Optimized methods and serious performance issues



Dino Viehland wrote:
> If I had to take a guess it would be that we are constantly re-optimizing
> the method (failing to successfully cache it) - which would be a
> significant performance loss.
>
> Any chance we could get you to run a debug build w/ the -X:TrackPerformance
> and -D command line options?
>
> You should then see in the output "DrawSubset #" where # should be small
> (e.g. 1 or 2) - if it's large then we know the issue, we just need to get a
> simple repro of it.
>
> Do you know if the direct X classes come to you via a interop assembly?  Or
> if they're COM objects?  Maybe we have a strange interaction there that is
> preventing the back patching for one of those.

Output with self.mesh.DrawSubset:
FieldTable DrawSubset 1664
BackwardsFieldTableLookup DrawSubset 2
DrawSubset 1660

Output with Direct3D.Mesh.DrawSubset (as mentioned in my reply to J. Merrill):
FieldTable DrawSubset 5
BackwardsFieldTableLookup DrawSubset 2
DrawSubset 1

So it looks like your guess was right on the money.

I wouldn't know if they're interop or COM. How would I find out?

--
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com




From dinov at exchange.microsoft.com  Thu May 25 21:34:49 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Thu, 25 May 2006 12:34:49 -0700
Subject: [IronPython] Optimized methods and serious performance issues
In-Reply-To: <4475E26E.7010503@kaydash.za.net>
References: <4475CE47.6000704@kaydash.za.net>
	<4039D552ADAB094BB1EA670F3E96214E01A42A1023@df-foxhound-msg.exchange.corp.microsoft.com>,
	<4475E26E.7010503@kaydash.za.net>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E01C48345A0@df-foxhound-msg.exchange.corp.microsoft.com>

Cool, that pretty much narrows it down to where we should be able to figure out what's going on.

I've opened a bug for this in our database - we should have this fixed for the next release.  I'll follow up if the fix is simple that you could update your local copy for.

Given Harry mentioning these were COM objects the problem likely stems from the fact that COM objects are a little special in IronPython.

________________________________________
From: users-bounces at lists.ironpython.com On Behalf Of Jonathan Jacobs
Sent: Thursday, May 25, 2006 9:59 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Optimized methods and serious performance issues

Dino Viehland wrote:
> If I had to take a guess it would be that we are constantly re-optimizing
> the method (failing to successfully cache it) - which would be a
> significant performance loss.
>
> Any chance we could get you to run a debug build w/ the -X:TrackPerformance
> and -D command line options?
>
> You should then see in the output "DrawSubset #" where # should be small
> (e.g. 1 or 2) - if it's large then we know the issue, we just need to get a
> simple repro of it.
>
> Do you know if the direct X classes come to you via a interop assembly?  Or
> if they're COM objects?  Maybe we have a strange interaction there that is
> preventing the back patching for one of those.

Output with self.mesh.DrawSubset:
FieldTable DrawSubset 1664
BackwardsFieldTableLookup DrawSubset 2
DrawSubset 1660

Output with Direct3D.Mesh.DrawSubset (as mentioned in my reply to J. Merrill):
FieldTable DrawSubset 5
BackwardsFieldTableLookup DrawSubset 2
DrawSubset 1

So it looks like your guess was right on the money.

I wouldn't know if they're interop or COM. How would I find out?

--
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 5073 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060525/e0157760/attachment.bin>

From sanxiyn at gmail.com  Fri May 26 12:05:51 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Fri, 26 May 2006 19:05:51 +0900
Subject: [IronPython] Compilation warnings on Mono
Message-ID: <5b0248170605260305w66536a65n735158f0d05b2915@mail.gmail.com>

>From the presence of warning pragmas, I assume that IronPython is
warning-clean on MS.NET.

Attached is compilation warnings produced by Mono C# Compiler while
compiling IronPython 1.0 Beta 7, and some of them seem to be valid.
Hope this help.

Seo Sanghyeon
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: warnings.txt
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060526/a70e584a/attachment.txt>

From dinov at exchange.microsoft.com  Fri May 26 17:26:49 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Fri, 26 May 2006 08:26:49 -0700
Subject: [IronPython] Compilation warnings on Mono
In-Reply-To: <5b0248170605260305w66536a65n735158f0d05b2915@mail.gmail.com>
References: <5b0248170605260305w66536a65n735158f0d05b2915@mail.gmail.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E01E1831DE3@df-foxhound-msg.exchange.corp.microsoft.com>

Yep, we do build clean on csc (and we compile w/ warnings treated as errors).  I've opened a bug to get these fixed.  Thanks for the bug report!

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo
Sent: Friday, May 26, 2006 3:06 AM
To: Discussion of IronPython
Subject: [IronPython] Compilation warnings on Mono

>From the presence of warning pragmas, I assume that IronPython is
warning-clean on MS.NET.

Attached is compilation warnings produced by Mono C# Compiler while compiling IronPython 1.0 Beta 7, and some of them seem to be valid.
Hope this help.

Seo Sanghyeon


From fuzzyman at voidspace.org.uk  Sat May 27 03:03:03 2006
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 27 May 2006 02:03:03 +0100
Subject: [IronPython] IronPython & WIndows Forms, Part III
Message-ID: <4477A547.1040001@voidspace.org.uk>

Hello all,

I've just posted part 3 of "IronPython & Windows Forms" to my blog. This 
entry is on widgets and event handlers. It starts to illustrate reading 
the MSDN docs from an IronPython point of view.


    http://www.voidspace.org.uk/python/weblog/arch_d7_2006_05_27.shtml#e344

This entry is a little rough as it's now 2 in the morning. :-)

I'm sure I will smooth it out later, but suggestions welcomed.

Michael Foord
http://www.voidspace.org.uk/python/index.shtml



From brian at sweetapp.com  Sat May 27 15:06:16 2006
From: brian at sweetapp.com (Brian Quinlan)
Date: Sat, 27 May 2006 15:06:16 +0200
Subject: [IronPython] Creating/using delegate types in IronPython
In-Reply-To: <4477A547.1040001@voidspace.org.uk>
References: <4477A547.1040001@voidspace.org.uk>
Message-ID: <44784EC8.2050101@sweetapp.com>

1. Is it possible to use existing delegates (as the caller) in
    IronPython e.g. is there some way to make this work:

 >>> from System import EventHandler, EventArgs
 >>> my_event = EventHandler()
Traceback (most recent call last):
   File , line 0, in input##5
 >>> # my_event += lambda x,y : None
 >>> # my_event(None, EventArgs())

Or some equivalent syntax for accomplishing the same thing?

2. Is it possible to define new delegate types in IronPython e.g. like 
this C# would:

public delegate Foo(int bar, string baz);

Cheers,
Brian





From sanxiyn at gmail.com  Sat May 27 18:37:11 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Sun, 28 May 2006 01:37:11 +0900
Subject: [IronPython] IronPython & WIndows Forms, Part III
In-Reply-To: <4477A547.1040001@voidspace.org.uk>
References: <4477A547.1040001@voidspace.org.uk>
Message-ID: <5b0248170605270937o5ef0c5dnf84ed73b89c8feba@mail.gmail.com>

2006/5/27, Michael Foord <fuzzyman at voidspace.org.uk>:
> I've just posted part 3 of "IronPython & Windows Forms" to my blog. This
> entry is on widgets and event handlers. It starts to illustrate reading
> the MSDN docs from an IronPython point of view.
>
> I'm sure I will smooth it out later, but suggestions welcomed.

You may want to mention these screenshots I took on Mono:
http://sparcs.kaist.ac.kr/~tinuviel/fepy/winforms/

I am willing to take more shots as you continue the series.

Seo Sanghyeon


From sanxiyn at gmail.com  Sat May 27 18:39:59 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Sun, 28 May 2006 01:39:59 +0900
Subject: [IronPython] IronPython & WIndows Forms, Part III
In-Reply-To: <4477A547.1040001@voidspace.org.uk>
References: <4477A547.1040001@voidspace.org.uk>
Message-ID: <5b0248170605270939v7fd32480u7791b2bd036410a7@mail.gmail.com>

Part II has a typo in the code listing. s/Main/HelloWorldForm/ in the full code.

Seo Sanghyeon


From fuzzyman at voidspace.org.uk  Sat May 27 19:21:22 2006
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 27 May 2006 18:21:22 +0100
Subject: [IronPython] IronPython & WIndows Forms, Part III
In-Reply-To: <5b0248170605270939v7fd32480u7791b2bd036410a7@mail.gmail.com>
References: <4477A547.1040001@voidspace.org.uk>
	<5b0248170605270939v7fd32480u7791b2bd036410a7@mail.gmail.com>
Message-ID: <44788A92.1000701@voidspace.org.uk>

Sanghyeon Seo wrote:
> Part II has a typo in the code listing. s/Main/HelloWorldForm/ in the full code.
>
>   
Thanks. Corrected.

Michael Foord
http://www.voidspace.org.uk/python/shareware.shtml

> Seo Sanghyeon
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From fuzzyman at voidspace.org.uk  Sat May 27 19:26:50 2006
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 27 May 2006 18:26:50 +0100
Subject: [IronPython] IronPython & WIndows Forms, Part III
In-Reply-To: <5b0248170605270937o5ef0c5dnf84ed73b89c8feba@mail.gmail.com>
References: <4477A547.1040001@voidspace.org.uk>
	<5b0248170605270937o5ef0c5dnf84ed73b89c8feba@mail.gmail.com>
Message-ID: <44788BDA.6050906@voidspace.org.uk>

Sanghyeon Seo wrote:
> 2006/5/27, Michael Foord <fuzzyman at voidspace.org.uk>:
>   
>> I've just posted part 3 of "IronPython & Windows Forms" to my blog. This
>> entry is on widgets and event handlers. It starts to illustrate reading
>> the MSDN docs from an IronPython point of view.
>>
>> I'm sure I will smooth it out later, but suggestions welcomed.
>>     
>
> You may want to mention these screenshots I took on Mono:
> http://sparcs.kaist.ac.kr/~tinuviel/fepy/winforms/
>
> I am willing to take more shots as you continue the series.
>   
*Great*.

I will add these. What OS do you have Mono running on for these 
screenshots ?

Michael

> Seo Sanghyeon
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From sanxiyn at gmail.com  Sat May 27 19:24:13 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Sun, 28 May 2006 02:24:13 +0900
Subject: [IronPython] IronPython & WIndows Forms, Part III
In-Reply-To: <44788BDA.6050906@voidspace.org.uk>
References: <4477A547.1040001@voidspace.org.uk>
	<5b0248170605270937o5ef0c5dnf84ed73b89c8feba@mail.gmail.com>
	<44788BDA.6050906@voidspace.org.uk>
Message-ID: <5b0248170605271024m720f4f36vb74a466adf6af52a@mail.gmail.com>

2006/5/28, Michael Foord <fuzzyman at voidspace.org.uk>:
> I will add these. What OS do you have Mono running on for these
> screenshots ?

Debian GNU/Linux, unstable branch. Mono SVN trunk. I use GNOME, the
window manager is Metacity, and GNOME theme I am using is Glider.

Seo Sanghyeon


From fuzzyman at voidspace.org.uk  Sat May 27 19:43:29 2006
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Sat, 27 May 2006 18:43:29 +0100
Subject: [IronPython] IronPython & WIndows Forms, Part III
In-Reply-To: <5b0248170605270937o5ef0c5dnf84ed73b89c8feba@mail.gmail.com>
References: <4477A547.1040001@voidspace.org.uk>
	<5b0248170605270937o5ef0c5dnf84ed73b89c8feba@mail.gmail.com>
Message-ID: <44788FC1.1000101@voidspace.org.uk>

Sanghyeon Seo wrote:
> 2006/5/27, Michael Foord <fuzzyman at voidspace.org.uk>:
>   
>> I've just posted part 3 of "IronPython & Windows Forms" to my blog. This
>> entry is on widgets and event handlers. It starts to illustrate reading
>> the MSDN docs from an IronPython point of view.
>>
>> I'm sure I will smooth it out later, but suggestions welcomed.
>>     
>
> You may want to mention these screenshots I took on Mono:
> http://sparcs.kaist.ac.kr/~tinuviel/fepy/winforms/
>
> I am willing to take more shots as you continue the series.
>
>   
These are now added. Many thanks.


Michael Foord


> Seo Sanghyeon
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   



From korpse-ironpython at kaydash.za.net  Sun May 28 19:27:41 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Sun, 28 May 2006 19:27:41 +0200
Subject: [IronPython] Singles from outer-space
Message-ID: <4479DD8D.2020804@kaydash.za.net>

Some odd behaviour with System.Single:

 >>> s = System.Single.Parse('5.2')
 >>> type(s)
<type 'Single'>
 >>> int(s)
Traceback (most recent call last):
   File , line 0, in <stdin>##50
TypeError: expected int, found Single
 >>> int(float(s))
5

-- 
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master


From sanxiyn at gmail.com  Mon May 29 13:42:26 2006
From: sanxiyn at gmail.com (Sanghyeon Seo)
Date: Mon, 29 May 2006 20:42:26 +0900
Subject: [IronPython] Takes at least 8 arguments (8 given)
Message-ID: <5b0248170605290442p4b89d0e8qaf4d4fab2a037ba0@mail.gmail.com>

I hate to reveal this, since I intended this one to be a surprise. :(

Anyway, attached script reports an error as in the title, and I can't
figure out why. Any idea? (You can guess what I am working on...)

Seo Sanghyeon
-------------- next part --------------
from System import AppDomain
from System.Reflection import AssemblyName
from System.Reflection.Emit import AssemblyBuilderAccess

pinvoke_module = None

def _define_pinvoke_module():
    global pinvoke_module
    if pinvoke_module is not None:
        return
    domain = AppDomain.CurrentDomain
    name = AssemblyName('pinvoke')
    flag = AssemblyBuilderAccess.Run
    assembly = domain.DefineDynamicAssembly(name, flag)
    pinvoke_module = assembly.DefineDynamicModule('pinvoke')

_define_pinvoke_module()

from System.Reflection import MethodAttributes

pinvoke_attributes = (
    MethodAttributes.Public |
    MethodAttributes.Static |
    MethodAttributes.PinvokeImpl
    )

from System import Int32, Double, String

import clr
c = clr.GetClrType

c_int = c(int)
c_float = c(float)
c_char_p = c(str)

from System.Reflection import CallingConventions
from System.Runtime.InteropServices import CharSet

pinvoke_module.DefinePInvokeMethod(
    'strlen', 'msvcrt',
    pinvoke_attributes, CallingConventions.Standard,
    c_int, [c_char_p],
    CallingConventions.Standard, CharSet.Ansi)
pinvoke_module.CreateGlobalFunctions()

strlen = pinvoke_module.GetMethod('strlen')
print strlen.Invoke(None, ['test'])

From tomba at bat.org  Mon May 29 14:50:07 2006
From: tomba at bat.org (Tomi Valkeinen)
Date: Mon, 29 May 2006 15:50:07 +0300 (EEST)
Subject: [IronPython] Takes at least 8 arguments (8 given)
In-Reply-To: <5b0248170605290442p4b89d0e8qaf4d4fab2a037ba0@mail.gmail.com>
References: <5b0248170605290442p4b89d0e8qaf4d4fab2a037ba0@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0605291546510.22449@baal.bat.org>

Hi,

On Mon, 29 May 2006, Sanghyeon Seo wrote:
> Anyway, attached script reports an error as in the title, and I can't
> figure out why. Any idea? (You can guess what I am working on...)

I didn't read your code, but I got the same error from my code and the 
reason was that one of the arguments to the method being called was of 
wrong type. The error message didn't help much finding that bug =). 
Perhaps you have the same problem.

  Tomi Valkeinen


From andrew at adersoftware.com  Tue May 30 08:03:43 2006
From: andrew at adersoftware.com (Andrew Deren)
Date: Tue, 30 May 2006 01:03:43 -0500
Subject: [IronPython] DynamicMethod question
In-Reply-To: <Pine.LNX.4.64.0605291546510.22449@baal.bat.org>
References: <5b0248170605290442p4b89d0e8qaf4d4fab2a037ba0@mail.gmail.com>
	<Pine.LNX.4.64.0605291546510.22449@baal.bat.org>
Message-ID: <000301c683ae$ceae10a0$6c0a31e0$@com>

I know the question is not directly related to IP, but I know IP uses
dynamic methods and some people know quite a bit about them.

I need to create dynamic method that takes params by ref or out. Dynamic
method has DefineParameter method that I can use to define
ParameterAttributes.Out, but no ref.
But even if I use Out, I get exception when creating delegate:
Error binding to target method.

A sample code I tried:
public delegate int ByRefDelegate(out int a);

			Module module = typeof(Test1).Module;
			DynamicMethod m1 = new DynamicMethod("test",
typeof(int), new Type[] { typeof(int) }, module);
			m1.DefineParameter(1, ParameterAttributes.Out,
"test");

			ILGenerator g = m1.GetILGenerator();
			g.Emit(OpCodes.Ldarg_0);
			g.Emit(OpCodes.Neg);
			g.Emit(OpCodes.Starg, 0);
			g.Emit(OpCodes.Ret);

			ByRefDelegate del =
(ByRefDelegate)m1.CreateDelegate(typeof(ByRefDelegate));

So I was just wondering if it's possible to have out or ref DynamicMethod?

Thanks.




From haiboluo at exchange.microsoft.com  Tue May 30 08:22:29 2006
From: haiboluo at exchange.microsoft.com (Haibo Luo)
Date: Mon, 29 May 2006 23:22:29 -0700
Subject: [IronPython] DynamicMethod question
In-Reply-To: <000301c683ae$ceae10a0$6c0a31e0$@com>
Message-ID: <C880917115D23741B1FF3565AF50A0960157BAB4DA@df-foxhound-msg.exchange.corp.microsoft.com>

I believe the main issue your code has is the parameter type: it should be typeof(int).MakeByRefType().

The following code print 20, 10 successfully.

---------------------------

public delegate int ByRefDelegate(out int a);

class Repro {
    static void Main(string[] args) {
        DynamicMethod m1 = new DynamicMethod("test", typeof(int), new Type[] { typeof(int).MakeByRefType() }, typeof(Repro).Module);
        m1.DefineParameter(1, ParameterAttributes.Out, "test");

        ILGenerator g = m1.GetILGenerator();
        g.Emit(OpCodes.Ldarg_0);
        g.Emit(OpCodes.Ldc_I4_S, 10);
        g.Emit(OpCodes.Stind_I4);
        g.Emit(OpCodes.Ldc_I4_S, 20);
        g.Emit(OpCodes.Ret);

        ByRefDelegate del = (ByRefDelegate)m1.CreateDelegate(typeof(ByRefDelegate));
        int b;
        Console.WriteLine(del(out b));
        Console.WriteLine(b);
    }

    static int Method(out int a) {
        a = 10;
        return 20;
    }
}

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Andrew Deren
Sent: Monday, May 29, 2006 11:04 PM
To: 'Discussion of IronPython'
Subject: [IronPython] DynamicMethod question

I know the question is not directly related to IP, but I know IP uses
dynamic methods and some people know quite a bit about them.

I need to create dynamic method that takes params by ref or out. Dynamic
method has DefineParameter method that I can use to define
ParameterAttributes.Out, but no ref.
But even if I use Out, I get exception when creating delegate:
Error binding to target method.

A sample code I tried:
public delegate int ByRefDelegate(out int a);

                        Module module = typeof(Test1).Module;
                        DynamicMethod m1 = new DynamicMethod("test",
typeof(int), new Type[] { typeof(int) }, module);
                        m1.DefineParameter(1, ParameterAttributes.Out,
"test");

                        ILGenerator g = m1.GetILGenerator();
                        g.Emit(OpCodes.Ldarg_0);
                        g.Emit(OpCodes.Neg);
                        g.Emit(OpCodes.Starg, 0);
                        g.Emit(OpCodes.Ret);

                        ByRefDelegate del =
(ByRefDelegate)m1.CreateDelegate(typeof(ByRefDelegate));

So I was just wondering if it's possible to have out or ref DynamicMethod?

Thanks.


_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From mbarnett at uniserve.com  Tue May 30 14:02:20 2006
From: mbarnett at uniserve.com (Lesley & Mitch Barnett)
Date: Tue, 30 May 2006 05:02:20 -0700
Subject: [IronPython] IronPython support In Visual Studio 2005 April VSSDK?
Message-ID: <000301c683e0$e8455a50$6401a8c0@NIS1861127372>

Hi, using the April 2005 VSSDK, I am able fire up a new Visual Studio
PythonProject (Experimental Hive) using the Windows Application template.  I
can drag and drop UI controls from the Toolbox onto the design surface.
However, I notice the IronPython code being generated for both the designer
and the form is placed in a single file called Form1.py.  In a C# WinForm
project, the code is separated into 2 files, Form1.cs and From1.Designer.cs.

 

Is the plan to have IronPython fully integrated into Visual Studio in the
same way as a C# project, including drop down list for types and members in
the code editor?  What about debugger support?

 

I ask this as I am trying to build a simple IronPython Windows app and while
being new to the Python language I am also finding it difficult to figure
out exactly where I put my code in Form1.py cause the both the design code
and "regular" code are in one place instead of separated as in a C# project.

 

Finally, I cannot get some simple code to work as it throws an exception, "A
first chance exception of type IronPython.Runtime.ArgumentTypeException'
occurred in IronPython.dll.  When I set the breakpoint to step through the
code I get into disassembly and I am not good at reading IL.  Then the
program aborts with the error above.

 

My project is real simple, has a Windows form and a listBox control.  All I
am doing is using System.Reflection to GetTypes from a DLL and put them in a
listBox.

 

In C# it looks like:

 

private void GetMyTypes()

        {

            Assembly myAssembly =
System.Reflection.Assembly.LoadFrom("mapack.dll");

            Type[] types = myAssembly.GetTypes();

            foreach (Type type in types)

            {

                listBox1.Items.Add(type);

            }

        }

 

In IronPython:

 

 

 def GetMyTypes():

     myAssembly = System.Reflection.Assembly.LoadFrom("mapack.dll")

     types = myAssembly.GetTypes()

     for types in types:

       _listBox1.Items.Add(types)

 

In both cases, the method is being called right after InitializeComponent()

 

Any ideas as to why this IronPython code won't run?

 

Thanks in advance,

 

Mitch

http://softwareindustrialization.com <http://softwareindustrialization.com/>


 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060530/fce5e440/attachment.html>

From vagmi.mudumbai at gmail.com  Tue May 30 14:35:06 2006
From: vagmi.mudumbai at gmail.com (Vagmi Mudumbai)
Date: Tue, 30 May 2006 18:05:06 +0530
Subject: [IronPython] IronPython support In Visual Studio 2005 April
	VSSDK?
In-Reply-To: <000301c683e0$e8455a50$6401a8c0@NIS1861127372>
References: <000301c683e0$e8455a50$6401a8c0@NIS1861127372>
Message-ID: <a55cfe9d0605300535q394971a0wb59ddc17681221c9@mail.gmail.com>

May be you should say

for type in types:

instead of

for types in types:

Regards,
Vagmi


On 5/30/06, Lesley & Mitch Barnett <mbarnett at uniserve.com> wrote:
>
>   Hi, using the April 2005 VSSDK, I am able fire up a new Visual Studio
> PythonProject (Experimental Hive) using the Windows Application template.  I
> can drag and drop UI controls from the Toolbox onto the design surface.
> However, I notice the IronPython code being generated for both the designer
> and the form is placed in a single file called Form1.py.  In a C# WinForm
> project, the code is separated into 2 files, Form1.cs and
> From1.Designer.cs.
>
>
>
> Is the plan to have IronPython fully integrated into Visual Studio in the
> same way as a C# project, including drop down list for types and members in
> the code editor?  What about debugger support?
>
>
>
> I ask this as I am trying to build a simple IronPython Windows app and
> while being new to the Python language I am also finding it difficult to
> figure out exactly where I put my code in Form1.py cause the both the
> design code and "regular" code are in one place instead of separated as in a
> C# project.
>
>
>
> Finally, I cannot get some simple code to work as it throws an exception,
> "A first chance exception of type
> IronPython.Runtime.ArgumentTypeException' occurred in IronPython.dll.
> When I set the breakpoint to step through the code I get into disassembly
> and I am not good at reading IL.  Then the program aborts with the error
> above.
>
>
>
> My project is real simple, has a Windows form and a listBox control.  All
> I am doing is using System.Reflection to GetTypes from a DLL and put them
> in a listBox.
>
>
>
> In C# it looks like:
>
>
>
> private void GetMyTypes()
>
>         {
>
>             Assembly myAssembly = System.Reflection.Assembly.LoadFrom("
> mapack.dll");
>
>             Type[] types = myAssembly.GetTypes();
>
>             foreach (Type type in types)
>
>             {
>
>                 listBox1.Items.Add(type);
>
>             }
>
>         }
>
>
>
> In IronPython:
>
>
>
>
>
>  def GetMyTypes():
>
>      myAssembly = System.Reflection.Assembly.LoadFrom("mapack.dll")
>
>      types = myAssembly.GetTypes()
>
>      for types in types:
>
>        _listBox1.Items.Add(types)
>
>
>
> In both cases, the method is being called right after
> InitializeComponent()
>
>
>
> Any ideas as to why this IronPython code won't run?
>
>
>
> Thanks in advance,
>
>
>
> Mitch
>
> http://softwareindustrialization.com
>
>
>
>
>
>
>
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>


-- 
http://geekswithblogs.net/vagmi.mudumbai
http://installneo.blogspot.com

"Peace is its own reward." - Mahatma Gandhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060530/fa58be79/attachment.html>

From dinov at exchange.microsoft.com  Tue May 30 17:35:20 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 30 May 2006 08:35:20 -0700
Subject: [IronPython] Singles from outer-space
In-Reply-To: <4479DD8D.2020804@kaydash.za.net>
References: <4479DD8D.2020804@kaydash.za.net>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E01E18326DA@df-foxhound-msg.exchange.corp.microsoft.com>

Thanks for the bug report.  We've been looking to get parity between .NET primitives and Python primitives but it looks like we've missed constructors.  I've opened a bug on this and it should be fixed for the next release.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Jacobs
Sent: Sunday, May 28, 2006 10:28 AM
To: Discussion of IronPython
Subject: [IronPython] Singles from outer-space

Some odd behaviour with System.Single:

 >>> s = System.Single.Parse('5.2')
 >>> type(s)
<type 'Single'>
 >>> int(s)
Traceback (most recent call last):
   File , line 0, in <stdin>##50
TypeError: expected int, found Single
 >>> int(float(s))
5

--
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master _______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Tue May 30 17:43:45 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 30 May 2006 08:43:45 -0700
Subject: [IronPython] IronPython support In Visual Studio 2005 April
 VSSDK?
In-Reply-To: <000301c683e0$e8455a50$6401a8c0@NIS1861127372>
References: <000301c683e0$e8455a50$6401a8c0@NIS1861127372>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E01E18326EC@df-foxhound-msg.exchange.corp.microsoft.com>

The two files that you see is being done through partial class support which is a language feature that both C# & VB support.  Python doesn't have such a feature, and so we've been discussing internally ways we could do this - unfortunately we haven't come up with the ideal solution yet.

Ultimately we want to have a very similar experience to C# & VB, but it certainly may not be the same.  I believe our next round of VS integration work will enable the drop-down list for types & members.  Debugging should work today, although you won't get the greatest display for your locals or classes always - but you can at least step through.  I don't believe we have any specific plans to improve debugging immediately.

You should be able to place your code anywhere in Form1.py.  The CodeDom parser should just merge generated code in along w/ your code.  If you run into any issues there let us know J.

Is the issue w/ the code the one Vagmi pointed out (types in types)?  This should work.  One suggestion would be to look in the Data property of the exception, and find the Python version of the exception - it may contain more meaningful information.


From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Lesley & Mitch Barnett
Sent: Tuesday, May 30, 2006 5:02 AM
To: users at lists.ironpython.com
Subject: [IronPython] IronPython support In Visual Studio 2005 April VSSDK?

Hi, using the April 2005 VSSDK, I am able fire up a new Visual Studio PythonProject (Experimental Hive) using the Windows Application template.  I can drag and drop UI controls from the Toolbox onto the design surface.  However, I notice the IronPython code being generated for both the designer and the form is placed in a single file called Form1.py.  In a C# WinForm project, the code is separated into 2 files, Form1.cs and From1.Designer.cs.

Is the plan to have IronPython fully integrated into Visual Studio in the same way as a C# project, including drop down list for types and members in the code editor?  What about debugger support?

I ask this as I am trying to build a simple IronPython Windows app and while being new to the Python language I am also finding it difficult to figure out exactly where I put my code in Form1.py cause the both the design code and "regular" code are in one place instead of separated as in a C# project.

Finally, I cannot get some simple code to work as it throws an exception, "A first chance exception of type IronPython.Runtime.ArgumentTypeException' occurred in IronPython.dll.  When I set the breakpoint to step through the code I get into disassembly and I am not good at reading IL.  Then the program aborts with the error above.

My project is real simple, has a Windows form and a listBox control.  All I am doing is using System.Reflection to GetTypes from a DLL and put them in a listBox.

In C# it looks like:

private void GetMyTypes()
        {
            Assembly myAssembly = System.Reflection.Assembly.LoadFrom("mapack.dll");
            Type[] types = myAssembly.GetTypes();
            foreach (Type type in types)
            {
                listBox1.Items.Add(type);
            }
        }

In IronPython:


 def GetMyTypes():
     myAssembly = System.Reflection.Assembly.LoadFrom("mapack.dll")
     types = myAssembly.GetTypes()
     for types in types:
       _listBox1.Items.Add(types)

In both cases, the method is being called right after InitializeComponent()

Any ideas as to why this IronPython code won't run?

Thanks in advance,

Mitch
http://softwareindustrialization.com<http://softwareindustrialization.com/>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060530/de0cafaf/attachment.html>

From korpse-ironpython at kaydash.za.net  Tue May 30 18:12:10 2006
From: korpse-ironpython at kaydash.za.net (Jonathan Jacobs)
Date: Tue, 30 May 2006 18:12:10 +0200
Subject: [IronPython] Takes at least 8 arguments (8 given)
In-Reply-To: <Pine.LNX.4.64.0605291546510.22449@baal.bat.org>
References: <5b0248170605290442p4b89d0e8qaf4d4fab2a037ba0@mail.gmail.com>
	<Pine.LNX.4.64.0605291546510.22449@baal.bat.org>
Message-ID: <447C6EDA.704@kaydash.za.net>

Tomi Valkeinen wrote:
> I didn't read your code, but I got the same error from my code and the 
> reason was that one of the arguments to the method being called was of 
> wrong type. The error message didn't help much finding that bug =). 
> Perhaps you have the same problem.

I've run into this a few times too. The exception should be a little more 
informative about what's wrong with your N arguments (or get a different 
exception, indicating the issue a little more clearly.)

I usually get caught out when I pass a float instead of an integer. I'm 
wondering whether it is viable for IronPython to check whether converting the 
parameter(s) to the intended type (eg. float -> int) is something that might 
work, and if so use that. It could be that I'm just lazy but this is how C# works.

-- 
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master


From dinov at exchange.microsoft.com  Tue May 30 18:32:06 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 30 May 2006 09:32:06 -0700
Subject: [IronPython] Takes at least 8 arguments (8 given)
In-Reply-To: <447C6EDA.704@kaydash.za.net>
References: <5b0248170605290442p4b89d0e8qaf4d4fab2a037ba0@mail.gmail.com>
	<Pine.LNX.4.64.0605291546510.22449@baal.bat.org>
	<447C6EDA.704@kaydash.za.net>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E01E1832751@df-foxhound-msg.exchange.corp.microsoft.com>

It looks like you're using the wrong calling convention enum, it's expecting a System.Runtime.InteropServices.CallingConvention, and you're passing it a System.Reflection.CallingConventions.

This is the 2nd calling convention parameter, the 1st one is still a System.Reflection.CallingConventions.

(and by the way, this is cool stuff Seo - I won't say any more so you can still surprise some people).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Jacobs
Sent: Tuesday, May 30, 2006 9:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Takes at least 8 arguments (8 given)

Tomi Valkeinen wrote:
> I didn't read your code, but I got the same error from my code and the
> reason was that one of the arguments to the method being called was of
> wrong type. The error message didn't help much finding that bug =).
> Perhaps you have the same problem.

I've run into this a few times too. The exception should be a little more informative about what's wrong with your N arguments (or get a different exception, indicating the issue a little more clearly.)

I usually get caught out when I pass a float instead of an integer. I'm wondering whether it is viable for IronPython to check whether converting the
parameter(s) to the intended type (eg. float -> int) is something that might work, and if so use that. It could be that I'm just lazy but this is how C# works.

--
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master _______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From dinov at exchange.microsoft.com  Tue May 30 18:34:49 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Tue, 30 May 2006 09:34:49 -0700
Subject: [IronPython] Takes at least 8 arguments (8 given)
In-Reply-To: <447C6EDA.704@kaydash.za.net>
References: <5b0248170605290442p4b89d0e8qaf4d4fab2a037ba0@mail.gmail.com>
	<Pine.LNX.4.64.0605291546510.22449@baal.bat.org>
	<447C6EDA.704@kaydash.za.net>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E01E1832757@df-foxhound-msg.exchange.corp.microsoft.com>

Oh, and we should allow a float -> int conversion, assuming there is no better conversion available.  We're actually looking into changing our dispatch rules to more closely mimic C#'s rules.

The error messages here are particularly bad - we already have one bug to improve the error messages for optimized methods, I'll update that w/ the suggestion to include the bad parameter.  Unfortunately we currently just try and match CPython's error messages, but they're not rich enough for calling complex .NET methods.


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jonathan Jacobs
Sent: Tuesday, May 30, 2006 9:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Takes at least 8 arguments (8 given)

Tomi Valkeinen wrote:
> I didn't read your code, but I got the same error from my code and the
> reason was that one of the arguments to the method being called was of
> wrong type. The error message didn't help much finding that bug =).
> Perhaps you have the same problem.

I've run into this a few times too. The exception should be a little more informative about what's wrong with your N arguments (or get a different exception, indicating the issue a little more clearly.)

I usually get caught out when I pass a float instead of an integer. I'm wondering whether it is viable for IronPython to check whether converting the
parameter(s) to the intended type (eg. float -> int) is something that might work, and if so use that. It could be that I'm just lazy but this is how C# works.

--
Jonathan

When you meet a master swordsman,
show him your sword.
When you meet a man who is not a poet,
do not show him your poem.
                 -- Rinzai, ninth century Zen master _______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From mbarnett at uniserve.com  Wed May 31 06:37:07 2006
From: mbarnett at uniserve.com (Lesley & Mitch Barnett)
Date: Tue, 30 May 2006 21:37:07 -0700
Subject: [IronPython] IronPython support In Visual Studio 2005 April
	VSSDK?
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214E01E18326EC@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <000001c6846b$dfdda5d0$6401a8c0@NIS1861127372>

Thanks Vagmi and Dino.  I should have mentioned that chunk of code does work
in the command line interpreter, but I will change it to see what happens.

 

As far as debugging is concerned, it does not step me through the source
like in C#, but rather the MSIL.  Maybe I am missing something?  Also,
sometimes the program will launh and then something will briefly appear in
the command window and then shutdown.  Not sure what that is about.  Thanks
for the other debugging info.

 

As a long time Visual Studio user (all the way back to VB1 in 91) I can only
suggest something similar to VB and C# - may not be a partial class, which
is fine to me, but perhaps better marked regions so it is more obvious or
structured.  That would be just fine by me in lieu of the partial class.
But maybe that will come as I am a real novice Python person, but can fly in
C#.  I have become so statically bound in the C# language that the freedom
of dynamic programming in IronPython is almost intoxicating!

 

Keep up the great work - IronPython is one of the best things to happen to
Microsoft.

 

Regards,

 

Mitch

  _____  

From: Dino Viehland [mailto:dinov at exchange.microsoft.com] 
Sent: May 30, 2006 8:44 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython support In Visual Studio 2005 April
VSSDK?

 

The two files that you see is being done through partial class support which
is a language feature that both C# & VB support.  Python doesn't have such a
feature, and so we've been discussing internally ways we could do this -
unfortunately we haven't come up with the ideal solution yet.  

 

Ultimately we want to have a very similar experience to C# & VB, but it
certainly may not be the same.  I believe our next round of VS integration
work will enable the drop-down list for types & members.  Debugging should
work today, although you won't get the greatest display for your locals or
classes always - but you can at least step through.  I don't believe we have
any specific plans to improve debugging immediately.

 

You should be able to place your code anywhere in Form1.py.  The CodeDom
parser should just merge generated code in along w/ your code.  If you run
into any issues there let us know :-).

 

Is the issue w/ the code the one Vagmi pointed out (types in types)?  This
should work.  One suggestion would be to look in the Data property of the
exception, and find the Python version of the exception - it may contain
more meaningful information.

 

 

From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Lesley & Mitch
Barnett
Sent: Tuesday, May 30, 2006 5:02 AM
To: users at lists.ironpython.com
Subject: [IronPython] IronPython support In Visual Studio 2005 April VSSDK?

 

Hi, using the April 2005 VSSDK, I am able fire up a new Visual Studio
PythonProject (Experimental Hive) using the Windows Application template.  I
can drag and drop UI controls from the Toolbox onto the design surface.
However, I notice the IronPython code being generated for both the designer
and the form is placed in a single file called Form1.py.  In a C# WinForm
project, the code is separated into 2 files, Form1.cs and From1.Designer.cs.

 

Is the plan to have IronPython fully integrated into Visual Studio in the
same way as a C# project, including drop down list for types and members in
the code editor?  What about debugger support?

 

I ask this as I am trying to build a simple IronPython Windows app and while
being new to the Python language I am also finding it difficult to figure
out exactly where I put my code in Form1.py cause the both the design code
and "regular" code are in one place instead of separated as in a C# project.

 

Finally, I cannot get some simple code to work as it throws an exception, "A
first chance exception of type IronPython.Runtime.ArgumentTypeException'
occurred in IronPython.dll.  When I set the breakpoint to step through the
code I get into disassembly and I am not good at reading IL.  Then the
program aborts with the error above.

 

My project is real simple, has a Windows form and a listBox control.  All I
am doing is using System.Reflection to GetTypes from a DLL and put them in a
listBox.

 

In C# it looks like:

 

private void GetMyTypes()

        {

            Assembly myAssembly =
System.Reflection.Assembly.LoadFrom("mapack.dll");

            Type[] types = myAssembly.GetTypes();

            foreach (Type type in types)

            {

                listBox1.Items.Add(type);

            }

        }

 

In IronPython:

 

 

 def GetMyTypes():

     myAssembly = System.Reflection.Assembly.LoadFrom("mapack.dll")

     types = myAssembly.GetTypes()

     for types in types:

       _listBox1.Items.Add(types)

 

In both cases, the method is being called right after InitializeComponent()

 

Any ideas as to why this IronPython code won't run?

 

Thanks in advance,

 

Mitch

http://softwareindustrialization.com <http://softwareindustrialization.com/>


 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060530/9e24c0a1/attachment.html>

From brian at sweetapp.com  Wed May 31 16:51:06 2006
From: brian at sweetapp.com (Brian Quinlan)
Date: Wed, 31 May 2006 16:51:06 +0200
Subject: [IronPython] Mutex creation wierdness
In-Reply-To: <000001c6846b$dfdda5d0$6401a8c0@NIS1861127372>
References: <000001c6846b$dfdda5d0$6401a8c0@NIS1861127372>
Message-ID: <447DAD5A.5060500@sweetapp.com>

Sorry if I'm posting problems that everyone knows about but:

 >>> from System.Threading import Mutex
 >>> m = Mutex(False, "Hello")
Traceback (most recent call last):
   File , line 0, in input##5
NotImplementedError: generate:  type: System.DBNull
 >>> m = Mutex()
Traceback (most recent call last):
   File , line 0, in input##34
NotImplementedError: generate:  type: System.DBNull

Cheers,
Brian


From dinov at exchange.microsoft.com  Wed May 31 17:09:43 2006
From: dinov at exchange.microsoft.com (Dino Viehland)
Date: Wed, 31 May 2006 08:09:43 -0700
Subject: [IronPython] Mutex creation wierdness
In-Reply-To: <447DAD5A.5060500@sweetapp.com>
References: <000001c6846b$dfdda5d0$6401a8c0@NIS1861127372>
	<447DAD5A.5060500@sweetapp.com>
Message-ID: <4039D552ADAB094BB1EA670F3E96214E01E20A7060@df-foxhound-msg.exchange.corp.microsoft.com>

What version of IronPython are you running against?  This seems to work for me against the most recently released version (beta 7).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Brian Quinlan
Sent: Wednesday, May 31, 2006 7:51 AM
To: Discussion of IronPython
Subject: [IronPython] Mutex creation wierdness

Sorry if I'm posting problems that everyone knows about but:

 >>> from System.Threading import Mutex
 >>> m = Mutex(False, "Hello")
Traceback (most recent call last):
   File , line 0, in input##5
NotImplementedError: generate:  type: System.DBNull  >>> m = Mutex() Traceback (most recent call last):
   File , line 0, in input##34
NotImplementedError: generate:  type: System.DBNull

Cheers,
Brian
_______________________________________________
users mailing list
users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


From brian at sweetapp.com  Wed May 31 17:47:10 2006
From: brian at sweetapp.com (Brian Quinlan)
Date: Wed, 31 May 2006 17:47:10 +0200
Subject: [IronPython] Mutex creation wierdness
In-Reply-To: <4039D552ADAB094BB1EA670F3E96214E01E20A7060@df-foxhound-msg.exchange.corp.microsoft.com>
References: <000001c6846b$dfdda5d0$6401a8c0@NIS1861127372>	<447DAD5A.5060500@sweetapp.com>
	<4039D552ADAB094BB1EA670F3E96214E01E20A7060@df-foxhound-msg.exchange.corp.microsoft.com>
Message-ID: <447DBA7E.3060306@sweetapp.com>

Dino Viehland wrote:
> What version of IronPython are you running against?  
 > This seems to work for me against the most recently
 > released version (beta 7).

Sorry, beta 6. I'll upgrade, thanks.

Cheers,
Brian


From Brian.Lloyd at revolution.com  Tue May 23 18:16:48 2006
From: Brian.Lloyd at revolution.com (Brian Lloyd)
Date: Tue, 23 May 2006 12:16:48 -0400
Subject: [IronPython] [Python.NET] Naming and resolution of generic
 types (complete!)
Message-ID: <65531D426735784F854EE658938A5853038FAB97@MI8NYCMAIL03.Mi8.com>

Thanks for the reply - luckily this is pretty much where I ended 
up as well ;)

One unlikely-but-technically-possible edge case I ran into was:

  - user imports assembly A that contains the generic type
'foo.bar.SomeType'
  - user creates instances of that type
  - then the user imports assembly B that contributes the non-generic
type 
    'SomeType' to the namespace 'foo.bar'

Maybe that's not a problem for the IP implementation, but thought I'd 
note it just in case. 

-Brian



> -----Original Message-----
> From: pythondotnet-bounces at python.org 
> [mailto:pythondotnet-bounces at python.org] On Behalf Of Dino Viehland
> Sent: Monday, May 22, 2006 4:25 PM
> To: Discussion of IronPython; pythondotnet at python.org
> Subject: Re: [Python.NET] [IronPython] Naming and resolution 
> of generic types (complete!)
> 
> I apologize for the extreme delay on this reply...  This mail 
> got stuck in our mailing list somewhere and didn't come out 
> until today.
> 
> The way we've chosen to solve this is to go w/ the single 
> type that allows you to disambiguate after the fact.  If you 
> have System.IComparable (another good example is 
> System.Nullable which has both generic & non-generic 
> versions) we build one 'type' that allows you to disambiguate 
> using __getitem__.
> 
> This is the same way you need to get a generic instantiation 
> (e.g. if there were no IComparable conflicts you'd need to do 
> IComparable[int] to get the specific instantiation) so it 
> fits in nicely.  Otherwise the type is the non-generic version.
> 
> It would seem our str/repr of this type is pretty bad right 
> now (showing you only the generic version) - we should make 
> that more helpful (e.g. something like <type IComparable, 
> IComparable[T]> maybe ?).
> 
> I guess the other remaining issue is how to get access to the 
> generic type that isn't bound to a specific instantiation - 
> currently this isn't much of a problem w/ IronPython as 
> there's not much you can actually do w/ the open generic 
> type, but we should probably solve it long term.
> 
> I've opened 2 bugs - the first one (str/repr of the type) 
> should be easy to fix, but some thought probably needs to go 
> into the open generic type issue.  We could make some __ __ 
> method to do this, allow indexing by None, or something else 
> - neither of those sounds particularly wonderful.
> 
> 
> Do you want to help develop Dynamic languages on CLR? 
> (http://members.microsoft.com/careers/search/details.aspx?JobI
> D=6D4754DE-11F0-45DF-8B78-DC1B43134038)
> 
> -----Original Message-----
> From: users-bounces at lists.ironpython.com 
> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Brian Lloyd
> Sent: Friday, March 31, 2006 12:43 PM
> To: pythondotnet at python.org
> Cc: users at lists.ironpython.com
> Subject: [IronPython] Naming and resolution of generic types 
> (complete!)
> 
> 
> Hi all - I'm cross-posting this to the IP list as the subject 
> seems to be an open issue there too.
> 
> I'm working on generics support for Python for .NET, and 
> there a couple of thorny issues that could use some 
> discussion regarding naming and resolution of generic types.
> 
> In C# you can explicitly name a generic type, a la 
> Dictionary<,>. That syntax won't work in Python, of course. 
> Looking at IP, it seems to allow the apparent Python name to 
> be the unmangled IL name so you can naturally use the name.
> 
> The problem is that the mangled name is illegal as a python 
> name, and the unmangled name isn't guaranteed to be unique - 
> you can potentially have any number of generic types as well 
> as a non-generic type with the same base name in the same namespace:
> 
> namespace Spam {
> 
>     public class SpamCan {}
>     public class SpamCan<T> {}
>     public class SpamCan<T, V> {}
>     ...
> }
> 
> I imagine that maybe IP has enough information available at 
> compile-time to do the right thing for some common usage 
> (binding and instantiating the types), but the overloaded 
> name can still be ambiguous. A real-life example of this is 
> System.IComparable - in IP, it doesn't seem possible to get 
> to the non-generic version of IComparable anymore (or at 
> least it was not obvious to me how to do it):
> 
> >>> import System
> >>> System.IComparable
> <type 'IComparable`1'>
> 
> It seems like we need to figure out some acceptable way of 
> spelling generic type names explicitly in Python (an 
> equivalent to IComparable<> in C#) that works within the 
> existing syntax.
> 
> There don't appear to be a lot of great options :( It has to 
> be a valid Python name to work in an import statement, so 
> that rules out strange operator shenanigans akin to the [] 
> hack used for generic type binding.
> 
> One would be to mimic the existing IL mangling in some way, a la:
> 
> >From System import IComparable   # the non-generic type
> >From System import IComparable_1 # the 1-param generic
> 
> # or
> from System import IComparable_T
> from System.Collections.Generic import Dictionary_TT
> 
> These are all pretty gross, and still don't totally prevent 
> hiding of legit non-generic classes with those names (though 
> it makes it less likely that names will be hidden than the 
> current approach).
> 
> I suppose another approach would be to continue to have only 
> one type end up with the simple name, but provide a way to 
> disambiguate it after the fact:
> 
> >>> import System
> >>> System.IComparable
> <type 'IComparable`1'>
> 
> >>> # abandon all hope, ye who enter here...
> >>> NonGenericIComparable = System.IComparable<<0 
> >>> OneParamGenericIComparable = System.IComparable<<1 
> >>> TwoParamVersionIfThereWasOne = System.IComparable<<2
> 
> That feels to me like it violates Python Zen in several ways, though.
> 
> Thoughts?
> 
> 
> -Brian
> 
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org 
> http://mail.python.org/mailman/listinfo/pythondotnet
> 
>