PythonNet September 2011

pythonnet@python.org

4 participants
7 discussions

Setting PYTHONPATH from code
by Sharon Rozenblum 05 Apr '13

05 Apr '13

Hi! Can someone tell me how to set PYTHONPATH variable in code when working with Python.Runtime.dll without changing the value in the system variables before. Thanks SHARON ________________________________ PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

6 12

Re: [Python.NET] [ pythonnet-Bugs-3303462 ] Stack corruption
by Barton 23 Jan '12

23 Jan '12

Thank you very much! It will be helpful for us to know which platform (Windows [Mono or .NET] vs Linux) where this is happening. On 05/17/11 10:52, SourceForge.net wrote: > Bugs item #3303462, was opened at 2011-05-18 02:52 > Message generated for change (Tracker Item Submitted) made by christallire > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=823891&aid=3303462&group_… > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: xeph (christallire) > Assigned to: Nobody/Anonymous (nobody) > Summary: Stack corruption > > Initial Comment: > I'm using python.net heavily in my server/client project > > I found Stack buffer overflow exception OR stack corruption exception is caused when python script throws an exception, which is caught by CLR code especially when GC is collecting its own objects. > I think this problem is caused when allocated objects are unwinded by CLR engine. > (threw in CLR GC Collection/GC Security Cookie Check) > > I found problem this 2 months ago, been struggling to solve this problem, because it happens rarely, randomly when GC is collecting objects > I solved this problem via removing all of pythonexception throwing code from PythonEngine, changed to return parameters to null > > Hope you have better solution for solve this problem :) > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=823891&aid=3303462&group_… >

2 1

Regarding PyTables
by MATHE MANOJ 24 Sep '11

24 Sep '11

Hello All **** I am very new in using IronPython and now my task is to use Pytables in C# using IronPython as interpreter.**** After some R&D I came to know that it can’t be done, but i didn’t get the exact solution on the work around and even the difficulties on this, can anyone help me on this.**** ** ** Thanks**** ** ** Manoj

2 1

Re: [Python.NET] Is there a chance to imprive Python for .net to let "System.Windows.Forms.Form().Controls" be indexable?
by 刘振海 04 Sep '11

04 Sep '11

Hi Barton, Thanks for your reply,I really appriciate! Here is my thought: 在 2011年9月4日上午3:35，Barton <barton(a)bcdesignswell.com>写道： > ** > Yes, I agree that the Item Property is still there. > It seems to be exposed ONLY FROM IEnumerator.GetEnumerator() or the > Findxxx() functions provided by the class due to its virtual nature: > > public *virtual *Control this [ int index ] { get; } > * * I don't think the Item Property isn't exposed due to its virtual nature. I did some test in C#,it turns out that the virtual modified Item property can be accessed by python .net with the index manner .I noticed there is a new function "get_Item" being add to the instance object. The same new function "get_Item" can be find in the Form().Controls but Form().Controls can not be indexable. It is wield. I check the source code of python for .net and find this from "classmanager.cs": // Check for indexer ParameterInfo[] args = pi.GetIndexParameters(); if (args.GetLength(0) > 0) { Indexer idx = ci.indexer; if (idx == null) { ci.indexer = new Indexer(); idx = ci.indexer; } idx.AddProperty(pi); continue; } Maybe the mechanism of checking for indexer is not perfect? Thanks! > > Hope that helps > > > On 9/3/2011 7:09 AM, 刘振海 wrote: > > Hi Barton， > thanks for your reply. > I have check the MSDN documents. It seems the Item properties both exist in > .net2.0 and .net4.0 > here is the MSDN for > http://msdn.microsoft.com/en-us/library/system.windows.forms.control.contro… > [image: Public property] Item[Int32]<http://msdn.microsoft.com/en-us/library/333f9hk4.aspx> Indicates > the Control<http://msdn.microsoft.com/en-us/library/system.windows.forms.control.aspx> at > the specified indexed location in the collection. [image: Public > property] Item[String]<http://msdn.microsoft.com/en-us/library/s1865435.aspx> Indicates > a Control<http://msdn.microsoft.com/en-us/library/system.windows.forms.control.aspx> with > the specified key in the collection. > and I get the blew code from C# > " > public class ControlCollection : ArrangedElementCollection, IList, > ICollection, IEnumerable, ICloneable { > public virtual Control this[int index] { get; } > public virtual Control this[string key] { get; } > " > In C# the Controls support index,So I think It will be intuitive for > Controls to support index. > > > > 2011/9/3 Barton <barton(a)bcdesignswell.com> > >> Very interesting; >> Apparently, Microsoft doesn't think that it is a useful thing to index >> directly into a System.Windows.Forms.Control.ControlCollection Class. >> The collection is still iterable in versions above 2.0, but the class no >> longer supports indexing. So: >> >> >>> print form.Controls[0] # works in pythondotnet built on .NET >> 2.0 on prior. >> <System.Windows.Forms.Button object at 0xaa8bc6c> >> >>> >> >> for ctrl in form.Controls: >> print ctrl # works in .NET 3.0 and above. >> >> >> Compare >> >> http://msdn.microsoft.com/en-us/library/system.windows.forms.control.contro… >> with >> >> http://msdn.microsoft.com/en-us/library/system.windows.forms.control.contro… >> and you'll see that all ICollection and IList properties have been >> removed. >> >> Reasons why are a good topic for future discussion. >> >> >> On 8/31/2011 10:30 PM, 刘振海 wrote: >> >> Hi, >> >> here is the code: >> >> import clr >> clr.AddReference("System.Windows.Forms") >> from System.Windows.Forms import Form,Application,Button >> form=Form() >> form.Controls.Add(Button()) >> print form.Controls[0] #this code didnt work with an error say "not >> indexable object" >> >> but this worked in ironpython,it seems in ironpython it treats the >> "form.Controls" as an list like object >> I can only get the form.Controls value use the "form.Controls.get_Item(0)" >> in the python for .net >> So is there a chance to imprive Python for .net to have >> that characteristic? >> >> thanks >> >> >> _________________________________________________ >> Python.NET mailing list - PythonDotNet(a)python.org >> http://mail.python.org/mailman/listinfo/pythondotnet >> >> >

2 1

patch - further makefile changes based on OSX building
by Bradley Friedman 04 Sep '11

04 Sep '11

I just checked out trunk and ran through the process of making it work for OSX in pursuit of a more perfect build system. Thought I'd share the results (and diff). To accomplish this, I had to set up the PKG_CONFIG_PATH manually to point to the version of python I wanted to use, and to the mono I wanted to use. And as you can see in the diff, I had to pull some bad code out that wasn't using pkg-config, where it really should be. I suspect the contentious part will be where I remove an evaluation of python code into distutils, and instead use pkg-config to get the flags. I think both of these changes really strongly point to a need for a "configure" script. Getting build flags from the currently resolving shell command "python" doesn't really take into account the reality that python is often compiled directly into 3rd party applications… such as say, Maya or Nuke, from the visual effects world of applications. These are valid alternative cpython runtimes that are installed and will be able to take the clr module if the build system allows you to configure to target them rather than the one that happens to run when you type "python" at a shell. As far as the mono version goes… I actually have three. A binary package installed form the mono project's download page. An alternative build out of mac-ports. And… the one I actually built against, a build of the latest released tar ball, turning on their experimental 64bit support. There are issues with the others as they are 32bit only… and in lion land.. well we've gone 64bit and its a mess. But I figure: that it builds against a proper 64bit version, when you provide it, is a good thing. Anyhow, with the changes in the diff and the extra step of configuring the PKG_CONFIG_PATH environment variable by hand, it builds and I can import clr in the system installed python2.7. And I can run some methods off the System.IO.Path class. So well… TADA! Attached is a diff of what I did. Dunno if you want to consider applying it. I have not tested it on ubuntu, redhat or windows. But I'm curious as to thoughts on what I did. Thanks. -brad

1 0

Is there a chance to imprive Python for .net to let "System.Windows.Forms.Form().Controls" be indexable?
by 刘振海 04 Sep '11

04 Sep '11

Hi, here is the code: import clr clr.AddReference("System.Windows.Forms") from System.Windows.Forms import Form,Application,Button form=Form() form.Controls.Add(Button()) print form.Controls[0] #this code didnt work with an error say "not indexable object" but this worked in ironpython,it seems in ironpython it treats the "form.Controls" as an list like object I can only get the form.Controls value use the "form.Controls.get_Item(0)" in the python for .net So is there a chance to imprive Python for .net to have that characteristic? thanks

2 3

Several patches to improve compilation with Mono
by Philip Lorenz 02 Sep '11

02 Sep '11

Hi, after trying to compile Python for .NET on ArchLinux x86_64 I have run into several issues which the attached patches fix: 1. Enable Mono config file loading. Otherwise a Python build with UCS4 Unicode strings does not work as the Mono.Posix module cannot find msvcrt (which is mapped to libc in Mono's config files). 2. Python.Runtime.dll.config is missing mappings for Python 2.7 3. The architecture detection code in the Makefile did not work correctly (checking for the 86 substring is true for both x86 as well as x86_64 targets). 4. I have renamed the clrmodule.il target in the Makefile to clrmodule_make.il. Otherwise a fresh SVN checkout would not build as clrmodule.il is already included. 5. Adapt the clrmod Makefile to support Mono 2.8 pkgconfig change. Additionally, retrieve Glib 2 options from its pkgconfig and compile the x86_64 build with -fPIC. 6. Support the standard DESTDIR parameter for the install target. Additionally, install Python.Runtime.dll and Python.Runtime.dll.config to the site-packages folder so it is found by the clr module. If you have any comments or if there are any issues with these patches please let me know. Philip

4 7

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

PythonNet September 2011