[Ironpython-users] IronPython, Daily Digest 5/6/2012
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New comment] Duplicate key in dict
--
ISSUES
1. [New comment] Duplicate key in dict
http://ironpython.codeplex.com/workitem/32527
User KeithJRome has commented on the issue:
"I have been poking around with this. The pop() is what causes things to go
downhill.
This is fine:
d = {'1': 1, '2': 1, '3': 1, 'a7': 1, 'a8': 1}
d['a8'] = 5
print d
This is fine:
d = {'1': 1, '2': 1, '3': 1, 'a7': 1, 'a8': 1}
d['a8'] = 5
d.pop('a7')
print d
This is NOT fine:
d = {'1': 1, '2': 1, '3': 1, 'a7': 1, 'a8': 1}
d.pop('a7')
d['a8'] = 5
print d"
--
--
You are receiving this email because you subscribed to notifications on
CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue
Tracker. You can unsubscribe or change your issue notification settings on
CodePlex.com.___
Ironpython-users mailing list
[email protected]
http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
Hi, Eric,
> Von Eric Snow
> I'm looking for feedback on PEP 421: "Adding sys.implementation". The
> idea came up in 2009 and garnered positive feedback, but didn't go
> anywhere. I've revived it and am hoping to get it worked out in time for
> Python 3.3.
>
> Any feedback would be very helpful, particularly with regard to the
> decision on the type of sys.implementation and the constraints on
> sys.implementation.version. Thanks.
As a user and embedder of IronPython, and a long-time user of cPython, I
welcome this idea.
Maybe we can add a required variable "host" which contains a tuple (or set) of
tagwords describing the hosting / embedding environment.
This could contain values like:
('apache', 'mod_python')
('apache', 'cgi')
('CoDeSys')
This idea just popped up in my mind, so it is not yet fully matured. :-)
Best regards
Markus Schaber
--
___
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax
+49-831-54031-50
Email: [email protected] | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects:
http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade
register: Kempten HRB 6186 | Tax ID No.: DE 167014915
___
Ironpython-users mailing list
[email protected]
http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
Hi, Jeff, > Von: Jeff Hardy > > Any feedback would be very helpful, particularly with regard to the > > decision on the type of sys.implementation and the constraints on > > sys.implementation.version. Thanks. > > I'd strongly prefer the named-tuple approach, like version_info. The > metadata attribute being a dict is fine (although the PEP doesn't actually > call that out in "Required Values" section; I had to search to find out if > it was actually a dict). I have some stuff I want to put in there already. Hmm, maybe we could put the host/embedder info I suggested in the other mail there. > I'm not really sure there's much value in having sys.version_info and > sys.implementation.version be different, but I believe PyPy works that > way, so I have no objection to it. They'll be the same in IronPython, > though. Hmm. It would open the possibility of IronPython supporting both Python 2.7 and 3.X for some grace period... > Thanks for pushing this through. I'll probably add it the day after it's > approved. Thanks. :-) Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: [email protected] | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
[Ironpython-users] IronPython Merge Modules for Windows
Hi, I've noticed IronRuby has merge modules available. Would this be the recommended way to redistribute IronPython? Now I need to embed IronPython in our product's installer. (This is still a prototype). Any advices about this? Probably that's an effort that can be shared, so instead of developing proprietary installation components I may contribute work on generic merge modules. Thank you a lot for the attention! Best regards Mello ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] IronPython Merge Modules for Windows
A colleague of mine also suggested implementing a stand-alone redistributable, to embed in our product's bootstrapper. That seems to be an easier trend in our installers. What do you think? Thanks a lot for the attention. Best regards Mello On Mon, May 7, 2012 at 11:41 AM, Cesar Mello wrote: > Hi, > > I've noticed IronRuby has merge modules available. Would this be the > recommended way to redistribute IronPython? > > Now I need to embed IronPython in our product's installer. (This is still > a prototype). Any advices about this? Probably that's an effort that can be > shared, so instead of developing proprietary installation components I may > contribute work on generic merge modules. > > Thank you a lot for the attention! > > Best regards > Mello > ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
On Sun, May 6, 2012 at 4:20 PM, Jeff Hardy wrote: > On Sun, May 6, 2012 at 12:05 PM, Eric Snow > wrote: >> Hi, >> >> I'm looking for feedback on PEP 421: "Adding sys.implementation". The >> idea came up in 2009 and garnered positive feedback, but didn't go >> anywhere. I've revived it and am hoping to get it worked out in time >> for Python 3.3. > > First off, I like it. It's long overdue, but better late than never. Agreed. Better cognizance of the alternate implementations has been a growing sentiment among the CPython core developers, especially Guido and Brett Cannon. Hopefully I'll be able to make a bigger push on this front once sys.implementation is all sorted out. >> >> Any feedback would be very helpful, particularly with regard to the >> decision on the type of sys.implementation and the constraints on >> sys.implementation.version. Thanks. > > I'd strongly prefer the named-tuple approach, like version_info. The > metadata attribute being a dict is fine (although the PEP doesn't > actually call that out in "Required Values" section; I had to search > to find out if it was actually a dict). I have some stuff I want to > put in there already. Good to know. Is your preference for a named tuple instead of a normal class? I'd rather not expose sys.implementation as a sequence type, but mostly I want to end up with something that's meaningful for everyone. > I'm not really sure there's much value in having sys.version_info and > sys.implementation.version be different, but I believe PyPy works that > way, so I have no objection to it. They'll be the same in IronPython, > though. > > Thanks for pushing this through. I'll probably add it the day after > it's approved. That's just what I wanted to hear. -eric ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
On Mon, May 7, 2012 at 2:11 AM, Markus Schaber wrote: > Hi, Jeff, > >> Von: Jeff Hardy >> > Any feedback would be very helpful, particularly with regard to the >> > decision on the type of sys.implementation and the constraints on >> > sys.implementation.version. Thanks. >> >> I'd strongly prefer the named-tuple approach, like version_info. The >> metadata attribute being a dict is fine (although the PEP doesn't actually >> call that out in "Required Values" section; I had to search to find out if >> it was actually a dict). I have some stuff I want to put in there already. > > Hmm, maybe we could put the host/embedder info I suggested in the other mail > there. > >> I'm not really sure there's much value in having sys.version_info and >> sys.implementation.version be different, but I believe PyPy works that >> way, so I have no objection to it. They'll be the same in IronPython, >> though. > > Hmm. It would open the possibility of IronPython supporting both Python 2.7 > and 3.X for some grace period... Yeah, the idea of the PEP in whole is to make things easier for Python implementors. If it allows you greater flexibility then it'll have been worth it. -eric ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
On Sun, May 6, 2012 at 4:20 PM, Jeff Hardy wrote: > The > metadata attribute being a dict is fine (although the PEP doesn't > actually call that out in "Required Values" section; I had to search > to find out if it was actually a dict). Thanks for pointing that out. I had certainly intended on specifying there that it's a dict. :) It'll be fixed on the next update. -eric ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
On Mon, May 7, 2012 at 7:53 AM, Eric Snow wrote: >> I'd strongly prefer the named-tuple approach, like version_info. The >> metadata attribute being a dict is fine (although the PEP doesn't >> actually call that out in "Required Values" section; I had to search >> to find out if it was actually a dict). I have some stuff I want to >> put in there already. > > Good to know. Is your preference for a named tuple instead of a > normal class? I'd rather not expose sys.implementation as a sequence > type, but mostly I want to end up with something that's meaningful for > everyone. Yeah, a normal class is fine (preferable, actually). For some reason I thought the options were named tuple a la version_info, or dict. One other question - for the metadata dict, is it mutable? Even though mutable is easier to implement, I'd still prefer it be read-only. - Jeff ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
On Mon, May 7, 2012 at 1:11 AM, Markus Schaber wrote: > Hmm, maybe we could put the host/embedder info I suggested in the other mail > there. Yeah, and things like which which CLR version (3.5, 4.0), implementation (MS, Mono), subset (Silverlight, MonoTouch, MonoDroid), what host it's running under, etc. I was thinking of adding fields to clr for that information anyway, but it can go here instead. >> I'm not really sure there's much value in having sys.version_info and >> sys.implementation.version be different, but I believe PyPy works that >> way, so I have no objection to it. They'll be the same in IronPython, >> though. > > Hmm. It would open the possibility of IronPython supporting both Python 2.7 > and 3.X for some grace period... That ... yikes. It already does support some (not much) stuff using -X:Python30, but that introduces a bunch of if statements and makes the code quite messy. There are other ways to do it, but a clean break in a new branch seems preferable to me. Plus there's the issue of the reorganized stdlib, which I'm not really sure how to cleanly solve. So my preference is to work in a different branch to 3k support. I'd like to do some work after 2.7.3 is released, but I'm not sure I'll get to it. - Jeff ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] IronPython Merge Modules for Windows
On Mon, May 7, 2012 at 7:41 AM, Cesar Mello wrote: > Hi, > > I've noticed IronRuby has merge modules available. Would this be the > recommended way to redistribute IronPython? > > Now I need to embed IronPython in our product's installer. (This is still a > prototype). Any advices about this? Probably that's an effort that can be > shared, so instead of developing proprietary installation components I may > contribute work on generic merge modules. If you've already got a bootstrapper, I would just but IronPython's MSI in there. Merge modules are really fragile and tend to break in weird ways, so I don't build them for IronPython (I refactored IP's MSI builds, so that's why they're different from IR's). The recommendation from MS seems to be to use full MSIs and chain them using a bootstrapper. One thing to watch for is that a user could upgrade IP and cause your app to be running against a new version. I try to make sure that upgrades shouldn't break anything for just that reason, but it does happen. The only way around this would be to build IP yourself, with a different signing key or AssemblyVersion, and ship that version with your app. - Jeff ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
On Mon, May 7, 2012 at 9:30 AM, Jeff Hardy wrote: > On Mon, May 7, 2012 at 7:53 AM, Eric Snow wrote: >> Good to know. Is your preference for a named tuple instead of a >> normal class? I'd rather not expose sys.implementation as a sequence >> type, but mostly I want to end up with something that's meaningful for >> everyone. > > Yeah, a normal class is fine (preferable, actually). For some reason I > thought the options were named tuple a la version_info, or dict. > > One other question - for the metadata dict, is it mutable? Even though > mutable is easier to implement, I'd still prefer it be read-only. A plain dict would be certainly be easier to implement, just using the builtin. Exposing an immutable dict type in CPython could open a can of worms, but if it makes sense we could consider it. -eric ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
On Mon, May 7, 2012 at 8:54 AM, Eric Snow wrote:
> A plain dict would be certainly be easier to implement, just using the
> builtin. Exposing an immutable dict type in CPython could open a can
> of worms, but if it makes sense we could consider it.
If it's going to be harder for CPython, then I wouldn't worry about it
too much.
I can't see any good reason to write to .metadata, so a PEP note
("Making changes to sys.implementation.metadata is not guaranteed to
work" or some such) should be fine. If it somebody tries to do it and
it breaks, well, they get to keep the pieces. :)
- Jeff
___
Ironpython-users mailing list
[email protected]
http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
On Mon, May 7, 2012 at 10:08 AM, Jeff Hardy wrote:
> On Mon, May 7, 2012 at 8:54 AM, Eric Snow wrote:
>> A plain dict would be certainly be easier to implement, just using the
>> builtin. Exposing an immutable dict type in CPython could open a can
>> of worms, but if it makes sense we could consider it.
>
> If it's going to be harder for CPython, then I wouldn't worry about it
> too much.
>
> I can't see any good reason to write to .metadata, so a PEP note
> ("Making changes to sys.implementation.metadata is not guaranteed to
> work" or some such) should be fine. If it somebody tries to do it and
> it breaks, well, they get to keep the pieces. :)
Yeah, that's the route I was planning on.
-eric
___
Ironpython-users mailing list
[email protected]
http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] IronPython Merge Modules for Windows
Thanks! I am evaluating both options. Installing our own version including the standard library copied from IronPython (./Lib, ./DLLs) in our application directory seem to work great! But if I install the MSI instead, how can I reference the standard library that is installed with IronPython? Where should I get the standard library path? I tried to get the path from Assembly.GetAssembly(typeof(Python)), but the GAC path is returned instead of C:\Program Files (x86)\IronPython 2.7. Thank you a lot for the attention! Best regards Mello On Mon, May 7, 2012 at 12:46 PM, Jeff Hardy wrote: > On Mon, May 7, 2012 at 7:41 AM, Cesar Mello wrote: > > Hi, > > > > I've noticed IronRuby has merge modules available. Would this be the > > recommended way to redistribute IronPython? > > > > Now I need to embed IronPython in our product's installer. (This is > still a > > prototype). Any advices about this? Probably that's an effort that can be > > shared, so instead of developing proprietary installation components I > may > > contribute work on generic merge modules. > > If you've already got a bootstrapper, I would just but IronPython's > MSI in there. Merge modules are really fragile and tend to break in > weird ways, so I don't build them for IronPython (I refactored IP's > MSI builds, so that's why they're different from IR's). The > recommendation from MS seems to be to use full MSIs and chain them > using a bootstrapper. > > One thing to watch for is that a user could upgrade IP and cause your > app to be running against a new version. I try to make sure that > upgrades shouldn't break anything for just that reason, but it does > happen. The only way around this would be to build IP yourself, with a > different signing key or AssemblyVersion, and ship that version with > your app. > > - Jeff > ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] IronPython Merge Modules for Windows
On Mon, May 7, 2012 at 12:34 PM, Cesar Mello wrote: > But if I install the MSI instead, how can I reference the standard library > that is installed with IronPython? Where should I get the standard library > path? I tried to get the path from Assembly.GetAssembly(typeof(Python)), but > the GAC path is returned instead of C:\Program Files (x86)\IronPython 2.7. The registry key HKLM\SOFTWARE\IronPython\27\InstallPath should have it. - Jeff ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] IronPython Merge Modules for Windows
Thank you so much!! Best regards! Mello On Mon, May 7, 2012 at 7:21 PM, Jeff Hardy wrote: > On Mon, May 7, 2012 at 12:34 PM, Cesar Mello wrote: > > But if I install the MSI instead, how can I reference the standard > library > > that is installed with IronPython? Where should I get the standard > library > > path? I tried to get the path from Assembly.GetAssembly(typeof(Python)), > but > > the GAC path is returned instead of C:\Program Files (x86)\IronPython > 2.7. > > The registry key HKLM\SOFTWARE\IronPython\27\InstallPath should have it. > > - Jeff > ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
Re: [Ironpython-users] feedback on PEP 421
Hi, Jeff, Von: Jeff Hardy [mailto:[email protected]] > On Mon, May 7, 2012 at 1:11 AM, Markus Schaber > wrote: > > Hmm, maybe we could put the host/embedder info I suggested in the other > mail there. > > Yeah, and things like which which CLR version (3.5, 4.0), implementation > (MS, Mono), subset (Silverlight, MonoTouch, MonoDroid), what host it's > running under, etc. I was thinking of adding fields to clr for that > information anyway, but it can go here instead. Sounds good. Everything of that informational stuff is far better placed there than in clr. If only for the fact that it can be probed without "import clr" which comes with some side effects. > >> I'm not really sure there's much value in having sys.version_info and > >> sys.implementation.version be different, but I believe PyPy works > >> that way, so I have no objection to it. They'll be the same in > >> IronPython, though. > > > > Hmm. It would open the possibility of IronPython supporting both Python > 2.7 and 3.X for some grace period... > > That ... yikes. It already does support some (not much) stuff using - > X:Python30, but that introduces a bunch of if statements and makes the > code quite messy. There are other ways to do it, but a clean break in a > new branch seems preferable to me. I agree here, it is much easier and cleaner to develop in two different branches. > Plus there's the issue of the > reorganized stdlib, which I'm not really sure how to cleanly solve. For the python part, it is easy: Deliver both versions in different directories, and set sys.path accordingly. For the C# part, maybe something like [PythonBindingAttribute(2)] and [PythonBindingAttribute(3)] could help. > So my > preference is to work in a different branch to 3k support. I'd like to do > some work after 2.7.3 is released, but I'm not sure I'll get to it. >From my own experience, it is the right way to branch, but often, when >everything is finished and cleaned up, one finds a realtively easy way to >reintegrate both branches. After all, Python 2 and Python 3 are not two >completely different languages (and IronPython2 already comes with some >Python3isms.). Don't get me wrong: right now, you should not try to force a generic implementation, but at least we should keep in mind that we can reevaluate everything once IronPython 3 is finished. Best regards Markus Schaber -- ___ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: [email protected] | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 ___ Ironpython-users mailing list [email protected] http://mail.python.org/mailman/listinfo/ironpython-users
