程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> 關於.NET >> IronPython .NET Integration官方文檔翻譯筆記,

IronPython .NET Integration官方文檔翻譯筆記,

編輯:關於.NET

IronPython .NET Integration官方文檔翻譯筆記,


http://ironpython.net/documentation/dotnet/這是原文地址

以下筆記僅記錄閱讀過程中我認為有必要記錄的內容,大多數都是依賴翻譯軟件的機翻,配合個人對代碼的理解寫出的筆記,個別不是很確定的,會在句首標注   猜測:

另外,這篇文檔,也就是官方文檔中其實只講了怎麼在Python裡用.Net,感覺這篇文檔是寫給Python開發者看的,但是很奇怪,在百度上也能搜到在.Net中使用Python的例子,不知道那些人的資料是從哪裡得來的,我搜遍了官網提供的所有文檔和wiki始終

找不到關於在.Net中如何使用的例子,好詭異。。。

在ironPython 中想使用.Net的API必須先導入 CLR,借用CLR導入.Net的類,最常用的是下面這種導法

>>> import clr
>>> clr.AddReference("System.Xml")

All .NET assemblies have a unique version number which allows using a specific version of a given assembly. The following code will load the version of System.Xml.dll that ships with .NET 2.0 and .NET 3.5:

同樣支持輸入更詳細的程序集信息來導入指定版本的.Net類

>>> import clr
>>> clr.AddReference("System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089")

在CLR引入.Net大類之後,就可以使用Python代碼正式導入這些類,在IronPython中,會將這些.Net 轉化為Python類來對待,但如果使用類示例對比,會發現無論你對比的是.Net類還是Python類,都成立。
可以使用import 直接導入命名空間下所有東西,也可以用from x import x【,x...】的語法選擇性的導入個別需要被用到的類
>>> import System
>>> System #doctest: +ELLIPSIS
<module 'System' (CLS module, ... assemblies loaded)>
>>> System.Collections #doctest: +ELLIPSIS
<module 'Collections' (CLS module, ... assemblies loaded)>

The types in the namespaces are exposed as Python types, and are accessed as attributes of the namespace. The following code accesses the System.Environment class from mscorlib.dll:

>>> import System
>>> System.Environment
<type 'Environment'>

Just like with normal Python modules, you can also use all the other forms of import as well:

>>> from System import Environment
>>> Environment
<type 'Environment'>
>>> from System import *
>>> Environment
<type 'Environment'>

在ironPython裡你可以用這樣的語法來表示.net中的泛型
>>> from System.Collections.Generic import List, Dictionary
>>> int_list = List[int]()
>>> str_float_dict = Dictionary[str, float]()

Note that there might exist a non-generic type as well as one or more generic types with the same name [1]. In this case, the name can be used without any indexing to access the non-generic type, and it can be indexed with different number of types to access the generic type with the corresponding number of type parameters. The code below accesses System.EventHandler and also System.EventHandler<TEventArgs>

在.Net中很多類型都有泛型和非泛型版本,比如下面這個例子,用泛型和非泛型版本你將訪問不同類型的對象,使用python的dir方法可以明顯看出檢索出來的方法屬性列表是不同的

>>> from System import EventHandler, EventArgs
>>> EventHandler # this is the combo type object
<types 'EventHandler', 'EventHandler[TEventArgs]'>
>>> # Access the non-generic type
>>> dir(EventHandler) #doctest: +ELLIPSIS
['BeginInvoke', 'Clone', 'DynamicInvoke', 'EndInvoke', ...
>>> # Access the generic type with 1 type paramter
>>> dir(EventHandler[EventArgs]) #doctest: +ELLIPSIS
['BeginInvoke', 'Call', 'Clone', 'Combine', ...


很多時候在IronPython 中並不支持一口氣導入整個命名空間裡所有東西

.NET types are exposed as Python classes. Like Python classes, you usually cannot import all the attributes of .NET types using from <name> import *:

>>> from System.Guid import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: no module named Guid

You can import specific members, both static and instance:

你通常只能這樣玩,需要什麼,導入什麼

>>> from System.Guid import NewGuid, ToByteArray
>>> g = NewGuid()
>>> ToByteArray(g) #doctest: +ELLIPSIS
Array[Byte](...

Note that if you import a static property, you will import the value when the import executes, not a named object to be evaluated on every use as you might mistakenly expect:

當你導入個別靜態屬性時,其實你只是導入了一個值類型,如果你用全名稱來對比,你會發現無法對等(這句話意思其實有點難理解,反正看代碼就知道大概意思)

>>> from System.DateTime import Now
>>> Now #doctest: +ELLIPSIS
<System.DateTime object at ...>
>>> # Let's make it even more obvious that "Now" is evaluated only once
>>> a_second_ago = Now
>>> import time
>>> time.sleep(1)
>>> a_second_ago is Now
True
>>> a_second_ago is System.DateTime.Now
False


Some .NET types only have static methods, and are comparable to namespaces. C# refers to them as static classes , and requires such classes to have only static methods. IronPython allows you to import all the static methods of such static classes. System.Environment is an example of a static class:

有些.net類只包含靜態方法,你可以像這樣導入

>>> from System.Environment import *
>>> Exit is System.Environment.Exit
True

Nested types are also imported:

>>> SpecialFolder is System.Environment.SpecialFolder
True

However, properties are not imported:

然而你會發現只有靜態方法被導進來了,靜態屬性並沒有被導進來(這和上一段看起來有點矛盾,難理解。不過寫代碼的時候自己試一試就知道能不能行得通了)

>>> OSVersion
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'OSVersion' is not defined
>>> System.Environment.OSVersion #doctest: +ELLIPSIS
<System.OperatingSystem object at ...>


下面這段大概是說在IronPython裡導入.Net類型,如果用類型對比你會發現,他即可當做.Net類也可以當做Python類

.NET represents types using System.Type. However, when you access a .NET type in Python code, you get a Python type object [2]:

>>> from System.Collections import BitArray
>>> ba = BitArray(5)
>>> isinstance(type(ba), type)
True

This allows a unified (Pythonic) view of both Python and .NET types. For example, isinstance works with .NET types as well:

>>> from System.Collections import BitArray
>>> isinstance(ba, BitArray)
True

If need to get the System.Type instance for the .NET type, you need to use clr.GetClrType. Conversely, you can use clr.GetPythonType to get a type object corresponding to a System.Type object.

The unification also extends to other type system entities like methods. .NET methods are exposed as instances of method:

這段很難理解,看不懂

>>> type(BitArray.Xor)
<type 'method_descriptor'>
>>> type(ba.Xor)
<type 'builtin_function_or_method'>
下面這條我猜他是想說如果按照實例來對比.Net類可以等於Python類,但按照類型來對比,兩者並不對等

Note that the Python type corresponding to a .NET type is a sub-type of type:

>>> isinstance(type(ba), type)
True
>>> type(ba) is type
False

This is an implementation detail.

這段說的是從.Net那邊導進來的類,你不能隨意刪除裡面的方法和屬性

.NET types behave like builtin types (like list), and are immutable. i.e. you cannot add or delete descriptors from .NET types:

>>> del list.append
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: cannot delete attribute 'append' of builtin type 'list'
>>>
>>> import System
>>> del System.DateTime.ToByteArray
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't set attributes of built-in/extension type 'DateTime'


下面這段是說你可以把.Net類用Python的語法來實例化,也可以調用new方法來實例化,我覺得在python裡new看著特別扭,還是入鄉隨俗吧。

.NET types are exposed as Python classes, and you can do many of the same operations on .NET types as with Python classes. In either cases, you create an instance by calling the type:

>>> from System.Collections import BitArray
>>> ba = BitArray(5) # Creates a bit array of size 5

IronPython also supports inline initializing of the attributes of the instance. Consider the following two lines:

>>> ba = BitArray(5)
>>> ba.Length = 10

The above two lines are equivalent to this single line:

>>> ba = BitArray(5, Length = 10)

You can also call the __new__ method to create an instance:

>> ba = BitArray.__new__(BitArray, 5)


在python裡使用.Net類型其實和在.Net中使用方式相似(可以說一模一樣)

Invoking .NET instance methods works just like invoking methods on a Python object using the attribute notation:

>>> from System.Collections import BitArray
>>> ba = BitArray(5)
>>> ba.Set(0, True) # call the Set method
>>> ba[0]
True

IronPython also supports named arguments:

也支持命名參數

>>> ba.Set(index = 1, value = True)
>>> ba[1]
True

IronPython also supports dict arguments:

他還支持字典式傳參,這招在.Net裡是沒有的,通過下面這個例子你會發現,你可以在使用過程中逐步收集參數,按照順序放入集合裡,最後再丟進一個方法。

>>> args = [2, True] # list of arguments
>>> ba.Set(*args)
>>> ba[2]
True

IronPython also supports keyword arguments:

也支持使用鍵值對字典給方法傳參(爽)

>>> args = { "index" : 3, "value" : True }
>>> ba.Set(**args)
>>> ba[3]
True


在IronPython裡如果傳入的參數不符合方法需要的參數類型,那麼它會結合.Net和Python的綜合規則來進行強制轉化,比如下面這個例子,他會把string轉成數字,數字大於1就等於bool的true,然後None是Python裡的null等同於false

When the argument type does not exactly match the parameter type expected by the .NET method, IronPython tries to convert the argument. IronPython uses conventional .NET conversion rules like conversion operators , as well as IronPython-specific rules. This snippet shows how arguments are converted when calling theSet(System.Int32, System.Boolean) method:

>>> from System.Collections import BitArray
>>> ba = BitArray(5)
>>> ba.Set(0, "hello") # converts the second argument to True.
>>> ba[0]
True
>>> ba.Set(1, None) # converts the second argument to False.
>>> ba[1]
False

See appendix-type-conversion-rules for the detailed conversion rules. Note that some Python types are implemented as .NET types and no conversion is required in such cases. See builtin-type-mapping for the mapping.

Some of the conversions supported are:

Python argument type.NET method parameter type int System.Int8, System.Int16 float System.Float tuple with only elements of type T System.Collections.Generic.IEnumerable<T> function, method System.Delegate and any of its sub-classes


在IronPython中同樣支持.net中的函數重載,解釋器會自動匹配最適合的那個重載

.NET supports overloading methods by both number of arguments and type of arguments. When IronPython code calls an overloaded method, IronPython tries to select one of the overloads at runtime based on the number and type of arguments passed to the method, and also names of any keyword arguments. In most cases, the expected overload gets selected. Selecting an overload is easy when the argument types are an exact match with one of the overload signatures:

>>> from System.Collections import BitArray
>>> ba = BitArray(5) # calls __new__(System.Int32)
>>> ba = BitArray(5, True) # calls __new__(System.Int32, System.Boolean)
>>> ba = BitArray(ba) # calls __new__(System.Collections.BitArray)

The argument types do not have be an exact match with the method signature. IronPython will try to convert the arguments if an unamibguous conversion exists to one of the overload signatures. The following code calls __new__(System.Int32) even though there are two constructors which take one argument, and neither of them accept a float as an argument:

猜測:即使調用一個不存在的重載,IronPython也允許將參數強轉後找到最適合匹配的那個重載

>>> ba = BitArray(5.0)

However, note that IronPython will raise a TypeError if there are conversions to more than one of the overloads:

猜測:注意,如果傳入的參數需要被進行1次以上的強轉才能找到匹配的話,那麼將報錯

>>> BitArray((1, 2, 3))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Multiple targets could match: BitArray(Array[Byte]), BitArray(Array[bool]), BitArray(Array[int])

If you want to control the exact overload that gets called, you can use the Overloads method on method objects:

你也可以強制指定接下來的代碼必須匹配函數的哪種重載,例如下面代碼,最後一次試圖只傳入1個參數,那麼將會報錯

>>> int_bool_new = BitArray.__new__.Overloads[int, type(True)]
>>> ba = int_bool_new(BitArray, 5, True) # calls __new__(System.Int32, System.Boolean)
>>> ba = int_bool_new(BitArray, 5, "hello") # converts "hello" to a System.Boolan
>>> ba = int_bool_new(BitArray, 5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __new__() takes exactly 2 arguments (1 given)

TODO - Example of indexing Overloads with an Array, byref, etc using Type.MakeByrefType

 

猜測:在IronPython中允許一種特殊的調用方式,不同.Net,在.net中我們只能調用子類中實現了接口或者虛方法的方法,但在IronPython中允許直接調用接口中的方法或者虛類中的虛方法,解釋器能自動找到匹配的那個實現,例如下面的代碼,因為string繼承

object所以也有Clone方法,調用ICloneable的虛方法Clone,傳入參數string,那麼解釋器會去string類型裡尋找Clone方法

It is sometimes desirable to invoke an instance method using the unbound class instance method and passing an explicit self object as the first argument. For example, .NET allows a class to declare an instance method with the same name as a method in a base type, but without overriding the base method. SeeSystem.Reflection.MethodAttributes.NewSlot for more information. In such cases, using the unbound class instance method syntax allows you chose precisely which slot you wish to call:

>>> import System
>>> System.ICloneable.Clone("hello") # same as : "hello".Clone()
'hello'

The unbound class instance method syntax results in a virtual call, and calls the most derived implementation of the virtual method slot:

猜測:所以object的GetHashCode和String的GetHashCode是一樣的,因為string 繼承於object,但是string的GetHashCode方法和RunTimeHelpers類中的GetHashCode不同,猜測,可能是因為具體實現不同,解釋器能夠通過IL代碼分辨出實現是否一致?

>>> s = "hello"
>>> System.Object.GetHashCode(s) == System.String.GetHashCode(s)
True
>>> from System.Runtime.CompilerServices import RuntimeHelpers
>>> RuntimeHelpers.GetHashCode(s) == System.String.GetHashCode(s)
False

猜測:下面這段大概是講.Net裡方法的實現分為顯式和隱式兩種,比如說在.Net裡如果顯式實現方法,那麼我們只能用接口才能調用,如果隱式實現,那麼直接在實現類或者接口中都可以調用。

但是IronPython中似乎沒有這種限制,只要實現了,就都可以調用。最後一節推測大概是說,如果實現類中存在同名的方法(顯式實現),那麼最好還是用接口來調用,才准確無誤。

.NET allows a method with a different name to override a base method implementation or interface method slot. This is useful if a type implements two interfaces with methods with the same name. This is known as explicity implemented interface methods. For example, Microsoft.Win32.RegistryKey implementsSystem.IDisposable.Dispose explicitly:

>>> from Microsoft.Win32 import RegistryKey
>>> clr.GetClrType(RegistryKey).GetMethod("Flush") #doctest: +ELLIPSIS
<System.Reflection.RuntimeMethodInfo object at ... [Void Flush()]>
>>> clr.GetClrType(RegistryKey).GetMethod("Dispose")
>>>

In such cases, IronPython tries to expose the method using its simple name - if there is no ambiguity:

>>> from Microsoft.Win32 import Registry
>>> rkey = Registry.CurrentUser.OpenSubKey("Software")
>>> rkey.Dispose()

However, it is possible that the type has another method with the same name. In that case, the explicitly implemented method is not accessible as an attribute. However, it can still be called by using the unbound class instance method syntax:

>>> rkey = Registry.CurrentUser.OpenSubKey("Software")
>>> System.IDisposable.Dispose(rkey)


在這裡Python和.Net調用靜態方法的方式是一樣的

Invoking static .NET methods is similar to invoking Python static methods:

>>> System.GC.Collect()

Like Python static methods, the .NET static method can be accessed as an attribute of sub-types as well:

.Net的靜態方法會以Python的規則,方法會被認為是一個類的一個屬性,推測:下面這2個類的同名方法如果實現是一樣的,那麼對比起來結果就是一樣的

>>> System.Object.ReferenceEquals is System.GC.ReferenceEquals
True

TODO What happens if the sub-type has a static method with the same name but a different signature? Are both overloads available or not?

 

展示如何調用泛型方法

Generic methods are exposed as attributes which can be indexed with type objects. The following code calls System.Activator.CreateInstance<T>

>>> from System import Activator, Guid
>>> guid = Activator.CreateInstance[Guid]()


下面這段展示了在IronPython中也支持泛型的自動推斷功能,比如最後一段
Enumerable.Any[int](list, lambda x : x < 2)
Enumerable.Any(list, lambda x : x < 2)
解釋器會自動匹配適合的泛型,寫的時候就可以省略泛型,另外讓我驚奇的是這裡頭居然也支持lambda,真是屌爆了

In many cases, the type parameter can be inferred based on the arguments passed to the method call. Consider the following use of a generic method [3]:

>>> from System.Collections.Generic import IEnumerable, List
>>> list = List[int]([1, 2, 3])
>>> import clr
>>> clr.AddReference("System.Core")
>>> from System.Linq import Enumerable
>>> Enumerable.Any[int](list, lambda x : x < 2)
True

With generic type parameter inference, the last statement can also be written as:

>>> Enumerable.Any(list, lambda x : x < 2)
True

See appendix for the detailed rules.

 

下面這段大概是說在IronPython裡沒有像很多高級語言中有 ref和out的概念,在IronPython中對於這種輸出引用有兩種玩法,一種隱式的一種顯式的

The Python language passes all arguments by-value. There is no syntax to indicate that an argument should be passed by-reference like there is in .NET languages like C# and VB.NET via the ref and out keywords. IronPython supports two ways of passing ref or out arguments to a method, an implicit way and an explicit way.

下面展示的第一種是隱式的,直接調用方法,比如說原來.Net字典裡的TryGetValue方法,原本要傳入一個key和一個out引用參數,返回bool結果表示有沒找到,但是在IronPython中隱式實現只要直接調用方法,傳入key就行了,返回一個元組類型的返回值,裡面包含了方法返回值和引用輸出返回值。

In the implicit way, an argument is passed normally to the method call, and its (potentially) updated value is returned from the method call along with the normal return value (if any). This composes well with the Python feature of multiple return values. System.Collections.Generic.Dictionary has a method bool TryGetValue(K key, out value). It can be called from IronPython with just one argument, and the call returns a tuple where the first element is a boolean and the second element is the value (or the default value of 0.0 if the first element is False):

>>> d = { "a":100.1, "b":200.2, "c":300.3 }
>>> from System.Collections.Generic import Dictionary
>>> d = Dictionary[str, float](d)
>>> d.TryGetValue("b")
(True, 200.2)
>>> d.TryGetValue("z")
(False, 0.0)

下面展示的是顯式實現,說明裡說假如方法存在多種重載的話,這種方式很好用,例如下面的例子,使用CLR的方法生成一個float類型的引用對象,傳給方法,然後就和.Net玩法一模一樣了,方法還是只返回bool,輸出的值將通過引用對象的Value屬性來讀取,有點像.Net裡的可空類型

In the explicit way, you can pass an instance of clr.Reference[T] for the ref or out argument, and its Value field will get set by the call. The explicit way is useful if there are multiple overloads with ref parameters:

>>> import clr
>>> r = clr.Reference[float]()
>>> d.TryGetValue("b", r)
True
>>> r.Value
200.2

Extension methods

目前IronPython對於擴展方法的支持還不好,不能像C#那樣直接調用,只能通過靜態方法來調用,例如,假設string有一個substring方法是後來擴展的,在c#你可以寫成"sadsad".substring(...),但是在IronPython你只能寫成System.String.SubString("sadsad")

Extension methods are currently not natively supported by IronPython. Hence, they cannot be invoked like instance methods. Instead, they have to be invoked like static methods.

 

下面這段大概是說,在.Net裡有索引器的概念,我們可以像下面這樣去方便的訪問集合中的某個對象,

.NET indexers are exposed as __getitem__ and __setitem__. Thus, the Python indexing syntax can be used to index .NET collections (and any type with an indexer):

>>> from System.Collections import BitArray
>>> ba = BitArray(5)
>>> ba[0]
False
>>> ba[0] = True
>>> ba[0]
True

但是,也支持使用比較麻煩老土的get和set來訪問對象,就像下面這樣

The indexer can be called using the unbound class instance method syntax using __getitem__ and __setitem__. This is useful if the indexer is virtual and is implemented as an explicitly-implemented interface method:

>>> BitArray.__getitem__(ba, 0)
True

Non-default .NET indexers

這段看不懂

Note that a default indexer is just a property (typically called Item) with one argument. It is considered as an indexer if the declaraing type uses DefaultMemberAttribute to declare the property as the default member.

See property-with-parameters for information on non-default indexers.

 

在.Net中一個屬性都有一對Get和Set方法,所以在Python中調用.Net屬性進行讀寫,實際上後台操作也是調用屬性的get和set方法來進行

.NET properties are exposed similar to Python attributes. Under the hood, .NET properties are implemented as a pair of methods to get and set the property, and IronPython calls the appropriate method depending on whether you are reading or writing to the properity:

>>> from System.Collections import BitArray
>>> ba = BitArray(5)
>>> ba.Length # calls "BitArray.get_Length()"
5
>>> ba.Length = 10 # calls "BitArray.set_Length()"

上面的代碼相當於下面的代碼,效果一樣

To call the get or set method using the unbound class instance method syntax, IronPython exposes methods called GetValue and SetValue on the property descriptor. The code above is equivalent to the following:

>>> ba = BitArray(5)
>>> BitArray.Length.GetValue(ba)
5
>>> BitArray.Length.SetValue(ba, 10)


下面這段大概是說在IronPython裡索引.Net類型中的集合數組的方式以及訪問屬性的方式,直接訪問屬性,調用get/set, 調用 對象.Item[?]的方式訪問對象

.NET properties are exposed similar to Python attributes. Under the hood, .NET properties are implemented as a pair of methods to get and set the property, and IronPython calls the appropriate method depending on whether you are reading or writing to the properity:

>>> from System.Collections import BitArray
>>> ba = BitArray(5)
>>> ba.Length # calls "BitArray.get_Length()"
5
>>> ba.Length = 10 # calls "BitArray.set_Length()"

To call the get or set method using the unbound class instance method syntax, IronPython exposes methods called GetValue and SetValue on the property descriptor. The code above is equivalent to the following:

>>> ba = BitArray(5)
>>> BitArray.Length.GetValue(ba)
5
>>> BitArray.Length.SetValue(ba, 10)

Properties with parameters

COM and VB.NET support properties with paramters. They are also known as non-default indexers. C# does not support declaring or using properties with parameters.

IronPython does support properties with parameters. For example, the default indexer above can also be accessed using the non-default format as such:

>>> ba.Item[0]
False

.net的事件可以使用+= 和-=的形式進行注冊和卸載,在IronPython中同樣支持這種玩法,下面的代碼裡用python 代碼按照.Net的格式定義了一個回調函數,居然也能注冊到.Net事件裡去,真爽

.NET events are exposed as objects with __iadd__ and __isub__ methods which allows using += and -= to subscribe and unsubscribe from the event. The following code shows how to subscribe a Python function to an event using +=, and unsubscribe using -=

>>> from System.IO import FileSystemWatcher
>>> watcher = FileSystemWatcher(".")
>>> def callback(sender, event_args):
...     print event_args.ChangeType, event_args.Name
>>> watcher.Created += callback
>>> watcher.EnableRaisingEvents = True
>>> import time
>>> f = open("test.txt", "w+"); time.sleep(1)
Created test.txt
>>> watcher.Created -= callback
>>>
>>> # cleanup
>>> import os
>>> f.close(); os.remove("test.txt")

You can also subscribe using a bound method:

你也可以這樣寫,下面代碼把回調寫在一個類裡頭而已,感覺並沒有什麼卵用,看起來更麻煩了

>>> watcher = FileSystemWatcher(".")
>>> class MyClass(object):
...     def callback(self, sender, event_args):
...         print event_args.ChangeType, event_args.Name
>>> o = MyClass()
>>> watcher.Created += o.callback
>>> watcher.EnableRaisingEvents = True
>>> f = open("test.txt", "w+"); time.sleep(1)
Created test.txt
>>> watcher.Created -= o.callback
>>>
>>> # cleanup
>>> f.close(); os.remove("test.txt")

You can also explicitly create a delegate instance to subscribe to the event. Otherwise, IronPython automatically does it for you. [4]:

也可以顯示定義一個委托

>>> watcher = FileSystemWatcher(".")
>>> def callback(sender, event_args):
...     print event_args.ChangeType, event_args.Name
>>> from System.IO import FileSystemEventHandler
>>> delegate = FileSystemEventHandler(callback)
>>> watcher.Created += delegate
>>> watcher.EnableRaisingEvents = True
>>> import time
>>> f = open("test.txt", "w+"); time.sleep(1)
Created test.txt
>>> watcher.Created -= delegate
>>>
>>> # cleanup
>>> f.close(); os.remove("test.txt")
他說顯示定義委托可以使程序內存占用更少,不知為何。。。難道他指的是裝箱和拆箱過程的性能損耗? The only advantage to creating an explicit delegate is that it is uses less memory. You should consider it if you subscribe to lots of events, and notice excessive System.WeakReference objects.  

下面這段主要展示了怎麼使用python語法實例化.net數組和索引數組中的值

IronPython supports indexing of System.Array with a type object to access one-dimensional strongly-typed arrays:

>>> System.Array[int]
<type 'Array[int]'>

IronPython also adds a __new__ method that accepts a IList<T> to initialize the array. This allows using a Python list literal to initialize a .NET array:

>>> a = System.Array[int]([1, 2, 3])

Further, IronPython exposes __getitem__ and __setitem__ allowing the array objects to be indexed using the Python indexing syntax:

>>> a[2]
3

假如用GetValue索引一個負數,會報錯,你只能像a[-1]這種索引方式才不會報錯

Note that the indexing syntax yields Python semantics. If you index with a negative value, it results in indexing from the end of the array, whereas .NET indexing (demonstrated by calling GetValue below) raises a System.IndexOutOfRangeException exception:

>>> a.GetValue(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: Index was outside the bounds of the array.
>>> a[-1]
3

同樣也支持python 中的數組分割語法

Similarly, slicing is also supported:

>>> a[1:3]
Array[int]((2, 3))

.NET Exceptions

raise語句支持拋出.net和python中的異常

raise can raise both Python exceptions as well as .NET exceptions:

>>> raise ZeroDivisionError()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError
>>> import System
>>> raise System.DivideByZeroException()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: Attempted to divide by zero.

except關鍵字也可以catch兩種語言中的異常

The except keyword can catch both Python exceptions as well as .NET exceptions:

>>> try:
...    import System
...    raise System.DivideByZeroException()
... except System.DivideByZeroException:
...    print "This line will get printed..."
...
This line will get printed...
>>>


前面有一個例子講過,如果引用.Net對象,是不允許刪除和修改對象中的成員,在下面例子中,也一樣,如果是python的異常ZeroDivisionError,那麼這是一個python類,允許隨意修改,比如在裡面加一個foo屬性,但是換成System.DivideByZeroException就

不行了,因為這是一個.Net對象,如果試圖修改,就會報錯

IronPython implements the Python exception mechanism on top of the .NET exception mechanism. This allows Python exception thrown from Python code to be caught by non-Python code, and vice versa. However, Python exception objects need to behave like Python user objects, not builtin types. For example, Python code can set arbitrary attributes on Python exception objects, but not on .NET exception objects:

>>> e = ZeroDivisionError()
>>> e.foo = 1 # this works
>>> e = System.DivideByZeroException()
>>> e.foo = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'DivideByZeroException' object has no attribute 'foo'

下面這段寫了一大堆,大概意思就是說如果在IrinPython中,你寫的是python代碼,那只會catch到python類型的異常,.Net則是catch到.Net類型的異常,但是,通過捕獲到的異常對象的clsException對象可以得到兩種語言公共的異常類,這是靠CLS(公共語言系統)來維護的。

To support these two different views, IronPython creates a pair of objects, a Python exception object and a .NET exception object, where the Python type and the .NET exception type have a unique one-to-one mapping as defined in the table below. Both objects know about each other. The .NET exception object is the one that actually gets thrown by the IronPython runtime when Python code executes a raise statement. When Python code uses the except keyword to catch the Python exception, the Python exception object is used. However, if the exception is caught by C# (for example) code that called the Python code, then the C# code naturally catches the .NET exception object.

The .NET exception object corresponding to a Python exception object can be accessed by using the clsException attribute (if the module has excecuted import clr):

>>> import clr
>>> try:
...     1/0
... except ZeroDivisionError as e:
...     pass
>>> type(e)
<type 'exceptions.ZeroDivisionError'>
>>> type(e.clsException)
<type 'DivideByZeroException'>

推測:下面這段大概是說通過clsException對象中的Data可以索引到異常對應的Python版的異常

IronPython is also able to access the Python exception object corresponding to a .NET exception object [5], thought this is not exposed to the user [6].

[5]

The Python exception object corresponding to a .NET exception object is accessible (to the IronPython runtime) via the System.Exception.Data property. Note that this is an implementation detail and subject to change:

>>> e.clsException.Data["PythonExceptionInfo"] #doctest: +ELLIPSIS
<IronPython.Runtime.Exceptions.PythonExceptions+ExceptionDataWrapper object at ...>

下面是2種語言的常見異常類型對照表

[6] ... except via the DLR Hosting API ScriptEngine.GetService<ExceptionOperations>().GetExceptionMessage Python exception.NET exception     Exception System.Exception   SystemExit   IP.O.SystemExit StopIteration System.InvalidOperationException subtype   StandardError System.SystemException   KeyboardInterrupt   IP.O.KeyboardInterruptException ImportError   IP.O.PythonImportError EnvironmentError   IP.O.PythonEnvironmentError IOError System.IO.IOException   OSError S.R.InteropServices.ExternalException   WindowsError System.ComponentModel.Win32Exception   EOFError System.IO.EndOfStreamException   RuntimeError IP.O.RuntimeException   NotImplementedError System.NotImplementedException   NameError   IP.O.NameException UnboundLocalError   IP.O.UnboundLocalException AttributeError System.MissingMemberException   SyntaxError   IP.O.SyntaxErrorException (System.Data has something close) IndentationError   IP.O.IndentationErrorException TabError   IP.O.TabErrorException TypeError   Microsoft.Scripting.ArgumentTypeException AssertionError   IP.O.AssertionException LookupError   IP.O.LookupException IndexError System.IndexOutOfRangeException   KeyError S.C.G.KeyNotFoundException   ArithmeticError System.ArithmeticException   OverflowError System.OverflowException   ZeroDivisionError System.DivideByZeroException   FloatingPointError   IP.O.PythonFloatingPointError ValueError ArgumentException   UnicodeError   IP.O.UnicodeException UnicodeEncodeError System.Text.EncoderFallbackException   UnicodeDecodeError System.Text.DecoderFallbackException   UnicodeTranslateError   IP.O.UnicodeTranslateException ReferenceError   IP.O.ReferenceException SystemError   IP.O.PythonSystemError MemoryError System.OutOfMemoryException   Warning System.ComponentModel.WarningException   UserWarning   IP.O.PythonUserWarning DeprecationWarning   IP.O.PythonDeprecationWarning PendingDeprecationWarning   IP.O.PythonPendingDeprecationWarning SyntaxWarning   IP.O.PythonSyntaxWarning OverflowWarning   IP.O.PythonOverflowWarning RuntimeWarning   IP.O.PythonRuntimeWarning FutureWarning   IP.O.PythonFutureWarning

 

下面又講了一大堆,大概意思就是演示了一下如何在一段代碼中既捕獲.Net異常又捕獲Python異常,最後證實了兩種異常在CLS中,其實.net才是大哥,它才是參照標准。

Given that raise results in the creation of both a Python exception object and a .NET exception object, and given that rescue can catch both Python exceptions and .NET exceptions, a question arises of which of the exception objects will be used by the rescue keyword. The answer is that it is the type used in the rescue clause. i.e. if the rescue clause uses the Python exception, then the Python exception object will be used. If the rescue clause uses the .NET exception, then the .NET exception object will be used.

The following example shows how 1/0 results in the creation of two objects, and how they are linked to each other. The exception is first caught as a .NET exception. The .NET exception is raised again, but is then caught as a Python exception:

>>> import System
>>> try:
...     try:
...         1/0
...     except System.DivideByZeroException as e1:
...         raise e1
... except ZeroDivisionError as e2:
...     pass
>>> type(e1)
<type 'DivideByZeroException'>
>>> type(e2)
<type 'exceptions.ZeroDivisionError'>
>>> e2.clsException is e1
True

下面這段說的是如果Python用戶定義了一個Python類繼承.Net的Exception對象,然後代碼中捕獲到了這個異常,然後用.Net異常信息的讀取方式去訪問異常信息,你將啥也看不到,在下文中異常信息應該是"some message",但是用.net的方式訪問,你只會看到

'Python Exception: MyException'

Python user-defined exceptions get mapped to System.Exception. If non-Python code catches a Python user-defined exception, it will be an instance of System.Exception, and will not be able to access the exception details:

>>> # since "Exception" might be System.Exception after "from System import *"
>>> if "Exception" in globals(): del Exception
>>> class MyException(Exception):
...     def __init__(self, value):
...         self.value = value
...     def __str__(self):
...         return repr(self.value)
>>> try:
...     raise MyException("some message")
... except System.Exception as e:
...     pass
>>> clr.GetClrType(type(e)).FullName
'System.Exception'
>>> e.Message
'Python Exception: MyException'

那麼在.Net中調用IronPython腳本時,如何才能得知腳本運行過程中拋出的Python異常呢?可以使用ScriptEngine.GetService<ExceptionOperations>().GetExceptionMessage方法來獲取

In this case, the non-Python code can use the ScriptEngine.GetService<ExceptionOperations>().GetExceptionMessage DLR Hosting API to get the exception message.

 

Enumerations

下面是枚舉類型的使用示例

.NET enumeration types are sub-types of System.Enum. The enumeration values of an enumeration type are exposed as class attributes:

print System.AttributeTargets.All # access the value "All"

IronPython also supports using the bit-wise operators with the enumeration values:

也支持 位操作符

>>> import System
>>> System.AttributeTargets.Class | System.AttributeTargets.Method
<enum System.AttributeTargets: Class, Method>

Value types

下面這一大段說了一大堆,很復雜,機器翻譯困難,看了半天也不知他講什麼,推測:大概是在講,在IronPython中不要試圖修改.Net類型中的值類型,否則會發生很多意想不到的結果

Python expects all mutable values to be represented as a reference type. .NET, on the other hand, introduces the concept of value types which are mostly copied instead of referenced. In particular .NET methods and properties returning a value type will always return a copy.

This can be confusing from a Python programmer’s perspective since a subsequent update to a field of such a value type will occur on the local copy, not within whatever enclosing object originally provided the value type.

While most .NET value types are designed to be immutable, and the .NET design guidelines recommend value tyeps be immutable, this is not enforced by .NET, and so there do exist some .NET valuetype that are mutable. TODO - Example.

For example, take the following C# definitions:

struct Point {
    # Poorly defined struct - structs should be immutable
    public int x;
    public int y;
}

class Line {
    public Point start;
    public Point end;

    public Point Start { get { return start; } }
    public Point End { get { return end; } }
}

If line is an instance of the reference type Line, then a Python programmer may well expect "line.Start.x = 1" to set the x coordinate of the start of that line. In fact the property Start returned a copy of the Point value type and it’s to that copy the update is made:

print line.Start.x    # prints ‘0’
line.Start.x = 1
print line.Start.x    # still prints ‘0’

This behavior is subtle and confusing enough that C# produces a compile-time error if similar code is written (an attempt to modify a field of a value type just returned from a property invocation).

Even worse, when an attempt is made to modify the value type directly via the start field exposed by Line (i.e. “`line.start.x = 1`”), IronPython will still update a local copy of the Point structure. That’s because Python is structured so that “foo.bar” will always produce a useable value: in the case above “line.start” needs to return a full value type which in turn implies a copy.

C#, on the other hand, interprets the entirety of the “`line.start.x = 1`” statement and actually yields a value type reference for the “line.start” part which in turn can be used to set the “x” field in place.

This highlights a difference in semantics between the two languages. In Python “line.start.x = 1” and “foo = line.start; foo.x = 1” are semantically equivalent. In C# that is not necessarily so.

So in summary: a Python programmer making updates to a value type embedded in an object will silently have those updates lost where the same syntax would yield the expected semantics in C#. An update to a value type returned from a .NET property will also appear to succeed will updating a local copy and will not cause an error as it does in the C# world. These two issues could easily become the source of subtle, hard to trace bugs within a large application.

In an effort to prevent the unintended update of local value type copies and at the same time preserve as pythonic and consistent a view of the world as possible, direct updates to value type fields are not allowed by IronPython, and raise a ValueError:

>>> line.start.x = 1 #doctest: +SKIP
Traceback (most recent call last):
   File , line 0, in input##7
ValueError Attempt to update field x on value type Point; value type fields can not be directly modified

This renders value types “mostly” immutable; updates are still possible via instance methods on the value type itself.

 

Proxy types

推測:大概是說在ironPython裡不能直接使用C#裡的System.MarshalByRefObject實例,但是可以通過非綁定類的實例來調用,這個文檔通篇下來經常使用非綁定類這個詞,一直看不明白到底指的是什麼樣的類。

IronPython cannot directly use System.MarshalByRefObject instances. IronPython uses reflection at runtime to determine how to access an object. However, System.MarshalByRefObject instances do not support reflection.

You can use unbound-class-instance-method syntax to call methods on such proxy objects.

 

Delegates

python方法可以被轉化為委托,傳給事件參數用

Python functions and bound instance methods can be converted to delegates:

>>> from System import EventHandler, EventArgs
>>> def foo(sender, event_args):
...     print event_args
>>> d = EventHandler(foo)
>>> d(None, EventArgs()) #doctest: +ELLIPSIS
<System.EventArgs object at ... [System.EventArgs]>

Variance

ironPython支持委托的參數簽名和事件要求的委托參數簽名不一致,比如下例,使用了Python語法裡的“無限無名參數”

IronPython also allows the signature of the Python function or method to be different (though compatible) with the delegate signature. For example, the Python function can use keyword arguments:

>>> def foo(*args):
...     print args
>>> d = EventHandler(foo)
>>> d(None, EventArgs()) #doctest: +ELLIPSIS
(None, <System.EventArgs object at ... [System.EventArgs]>)

本來事件沒有返回值,但是在這裡也支持委托可以寫返回值(這是Python的語法),但實際運作過程中,返回的值會被忽略

If the return type of the delegate is void, IronPython also allows the Python function to return any type of return value, and just ignores the return value:

>>> def foo(*args):
...     return 100 # this return value will get ignored
>>> d = EventHandler(foo)
>>> d(None, EventArgs())

如果委托實際返回的返回值類型和事件要求的返回值類型不符合,那麼解釋器會嘗試強轉後再返回

If the return value is different, IronPython will try to convert it:

>>> def foo(str1, str2):
...     return 100.1 # this return value will get converted to an int
>>> d = System.Comparison[str](foo)
>>> d("hello", "there")
100

TODO - Delegates with out/ref parameters

 

Subclassing .NET types

支持Python類繼承或實現.net的類或接口

Sub-classing of .NET types and interfaces is supported using class. .NET types and interfaces can be used as one of the sub-types in the class construct:

>>> class MyClass(System.Attribute, System.ICloneable, System.IComparable):
...     pass

.Net裡不支持多重繼承,但Python裡支持這麼干,但是如下代碼,你支持繼承多個Python類,而不能繼承多個.Net類,不管繼承多少個,其中只能有一個.Net類

.NET does not support multiple inheritance while Python does. IronPython allows using multiple Python classes as subtypes, and also multiple .NET interfaces, but there can only be one .NET class (other than System.Object) in the set of subtypes:

>>> class MyPythonClass1(object): pass
>>> class MyPythonClass2(object): pass
>>> class MyMixedClass(MyPythonClass1, MyPythonClass2, System.Attribute):
...     pass

和.Net一樣,可以利用反射來驗證一個類是否是某個類的子類

Instances of the class do actually inherit from the specified .NET base type. This is important because this means that statically-typed .NET code can access the object using the .NET type. The following snippet uses Reflection to show that the object can be cast to the .NET sub-class:

>>> class MyClass(System.ICloneable):
...     pass
>>> o = MyClass()
>>> import clr
>>> clr.GetClrType(System.ICloneable).IsAssignableFrom(o.GetType())
True

下面又說Python並沒有真正繼承.Net子類,見類型映射表?  看著好玄乎

Note that the Python class does not really inherit from the .NET sub-class. See type-mapping.

 

Overriding methods

基類方法可以被用Python方法重寫

Base type methods can be overriden by defining a Python method with the same name:

>>> class MyClass(System.ICloneable):
...    def Clone(self):
...        return MyClass()
>>> o = MyClass()
>>> o.Clone() #doctest: +ELLIPSIS
<MyClass object at ...>

推測:下面意思可能是說,Python語法雖然允許你不真正實現接口方法,編譯上通過,但實際運行的時候會報錯,說實例中並不存在這個方法,所以我們必須要寫出具體實現

IronPython does require you to provide implementations of interface methods in the class declaration. The method lookup is done dynamically when the method is accessed. Here we see that AttributeError is raised if the method is not defined:

>>> class MyClass(System.ICloneable): pass
>>> o = MyClass()
>>> o.Clone()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'MyClass' object has no attribute 'Clone'

Methods with multiple overloads

推測:下面大概是說在Python裡不支持像.Net那樣的方法重載,如果你寫了一個Python類繼承.Net類型,想要實現方法重載,那麼只能定義一個同方法名,但是參數列表支持無數個參數的形式來變相的定義出方法重載的效果,例如下面這個例子

*args在Python 語法中表示接受任意個不限類型的參數

Python does not support method overloading. A class can have only one method with a given name. As a result, you cannot override specific method overloads of a .NET sub-type. Instead, you need to use define the function accepting an arbitrary argument list (see _tut-arbitraryargs), and then determine the method overload that was invoked by inspecting the types of the arguments:

>>> import clr
>>> import System
>>> StringComparer = System.Collections.Generic.IEqualityComparer[str]
>>>
>>> class MyComparer(StringComparer):
...     def GetHashCode(self, *args):
...          if len(args) == 0:
...              # Object.GetHashCode() called
...              return 100
...
...          if len(args) == 1 and type(args[0]) == str:
...              # StringComparer.GetHashCode() called
...              return 200
...
...          assert("Should never get here")
...
>>> comparer = MyComparer()
>>> getHashCode1 = clr.GetClrType(System.Object).GetMethod("GetHashCode")
>>> args = System.Array[object](["another string"])
>>> getHashCode2 = clr.GetClrType(StringComparer).GetMethod("GetHashCode")
>>>
>>> # Use Reflection to simulate a call to the different overloads
>>> # from another .NET language
>>> getHashCode1.Invoke(comparer, None)
100
>>> getHashCode2.Invoke(comparer, args)
200

Note

Determining the exact overload that was invoked may not be possible, for example, if None is passed in as an argument.

 

Methods with ref or out parameters

Python裡沒有相關的語法用來表示引用類型,如果你用Python重寫.Net中的方法,那麼原本參數列表中的輸出/引用類型將被解釋為一個CLR引用類型,其實這個概念前面內容中有一個例子裡有提到,看下面這個例子你會發現,在調用

python重寫的方法時原本傳入的那個參數集合中最後一個自動被定義為一個CLR引用類型,調用方法後,讀取那個對象的值就可以得到輸出結果,同樣,在重寫方法的過程中,我們也必須以  參數名.Value的形式給這個CLR引用類型的變量賦值

Python does not have syntax for specifying whether a method paramter is passed by-reference since arguments are always passed by-value. When overriding a .NET method with ref or out parameters, the ref or out paramter is received as a clr.Reference[T] instance. The incoming argument value is accessed by reading theValue property, and the resulting value is specified by setting the Value property:

>>> import clr
>>> import System
>>> StrFloatDictionary = System.Collections.Generic.IDictionary[str, float]
>>>
>>> class MyDictionary(StrFloatDictionary):
...     def TryGetValue(self, key, value):
...         if key == "yes":
...             value.Value = 100.1 # set the *out* parameter
...             return True
...         else:
...             value.Value = 0.0  # set the *out* parameter
...             return False
...     # Other methods of IDictionary not overriden for brevity
...
>>> d = MyDictionary()
>>> # Use Reflection to simulate a call from another .NET language
>>> tryGetValue = clr.GetClrType(StrFloatDictionary).GetMethod("TryGetValue")
>>> args = System.Array[object](["yes", 0.0])
>>> tryGetValue.Invoke(d, args)
True
>>> args[1]
100.1

Generic methods

當你用Python重寫一個.Net中的泛型方法時原本泛型<>括號裡的類型,在ironPython中將被當成是一組類型參數來對待,就像下面這個例子T1,T2被寫成參數放在convert方法的參數列表裡的,後面調用的時候,用clr的方法傳入類型參數生成了一個

泛型方法,這個文檔通篇大量使用clr的反射方法來調用.net,我不知道是否必須這樣做才能調用,如果是的話,那可真是太麻煩了, 而且性能絕對不咋地

When you override a generic method, the type parameters get passed in as arguments. Consider the following generic method declaration:

// csc /t:library /out:convert.dll convert.cs
public interface IMyConvertible {
    T1 Convert<T1, T2>(T2 arg);
}

The following code overrides the generic method Convert:

>>> import clr
>>> clr.AddReference("convert.dll")
>>> import System
>>> import IMyConvertible
>>>
>>> class MyConvertible(IMyConvertible):
...     def Convert(self, t2, T1, T2):
...         return T1(t2)
>>>
>>> o = MyConvertible()
>>> # Use Reflection to simulate a call from another .NET language
>>> type_params = System.Array[System.Type]([str, float])
>>> convert = clr.GetClrType(IMyConvertible).GetMethod("Convert")
>>> convert_of_str_float = convert.MakeGenericMethod(type_params)
>>> args = System.Array[object]([100.1])
>>> convert_of_str_float.Invoke(o, args)
'100.1'

Note

Generic method receive information about the method signature being invoked, whereas normal method overloads do not. The reason is that .NET does not allow normal method overloads to differ by the return type, and it is usually possible to determine the argument types based on the argument values. However, with generic methods, one of the type parameters may only be used as the return type. In that case, there is no way to determine the type paramter.

 

Calling from Python

這段看不懂,好像是在說如果一個.Net的方法被python重寫,就不能用python的方式去調用,那該怎麼調才行呢?

When you call a method from Python, and the method overrides a .NET method from a base type, the call is performed as a regular Python call. The arguments do not undergo conversion, and neither are they modified in any way like being wrapped with clr.Reference. Thus, the call may need to be written differently than if the method was overriden by another language. For example, trying to call TryGetValue on the MyDictionary type from the overriding-ref-args section as shown below results in a TypeError, whereas a similar call works with System.Collections.Generic.Dictionary[str, float]:

>>> result, value = d.TryGetValue("yes")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: TryGetValue() takes exactly 3 arguments (2 given)

Overriding properties

下面這段大概是說.net裡屬性都會有一對get set方法,這些方法是被包含在屬性原數據定義裡的,如果用python重寫.net類的屬性,只需要重寫get_屬性名 就可以實現對屬性返回值的修改,推測:而set方法似乎是只讀的,不讓重寫?

.NET properties are backed by a pair of .NET methods for reading and writing the property. The C# compiler automatically names them as get_<PropertyName> and set_<PropertyName>. However, .NET itself does not require any specific naming pattern for these methods, and the names are stored in the the metadata associated with the property definition. The names can be accessed using the GetGetMethod and GetSetMethods of the System.Reflection.PropertyInfo class:

>>> import clr
>>> import System
>>> StringCollection = System.Collections.Generic.ICollection[str]
>>> prop_info = clr.GetClrType(StringCollection).GetProperty("Count")
>>> prop_info.GetGetMethod().Name
'get_Count'
>>> prop_info.GetSetMethod() # None because this is a read-only property
>>>

Overriding a virtual property requires defining a Python method with the same names as the underlying getter or setter .NET method:

>>>
>>> class MyCollection(StringCollection):
...    def get_Count(self):
...        return 100
...    # Other methods of ICollection not overriden for brevity
>>>
>>> c = MyCollection()
>>> # Use Reflection to simulate a call from another .NET language
>>> prop_info.GetGetMethod().Invoke(c, None)
100

Overiding events

如果要重寫.net事件,你得這麼干,似乎比重寫屬性復雜一些,先要重寫事件名,然後重寫事件對應的add和remove方法

Events have underlying methods which can be obtained using EventInfo.GetAddMethod and EventInfo.GetRemoveMethod

>>> from System.ComponentModel import IComponent
>>> import clr
>>> event_info = clr.GetClrType(IComponent).GetEvent("Disposed")
>>> event_info.GetAddMethod().Name
'add_Disposed'
>>> event_info.GetRemoveMethod().Name
'remove_Disposed'

To override events, you need to define methods with the name of the underlying methods:

>>> class MyComponent(IComponent):
...     def __init__(self):
...         self.dispose_handlers = []
...     def Dispose(self):
...         for handler in self.dispose_handlers:
...             handler(self, EventArgs())
...
...     def add_Disposed(self, value):
...         self.dispose_handlers.append(value)
...     def remove_Disposed(self, value):
...         self.dispose_handlers.remove(value)
...     # Other methods of IComponent not implemented for brevity
>>>
>>> c = MyComponent()
>>> def callback(sender, event_args):
...     print event_args
>>> args = System.Array[object]((System.EventHandler(callback),))
>>> # Use Reflection to simulate a call from another .NET language
>>> event_info.GetAddMethod().Invoke(c, args)
>>>
>>> c.Dispose() #doctest: +ELLIPSIS
<System.EventArgs object at ... [System.EventArgs]>

Calling base constructor

如果你想讓一個繼承自.net的python子類調用它基類的構造函數,那你需要像下面這樣重寫一個*args參數的__new__構造,然後自己寫一堆判斷去調用基類的構造重載。。。

這篇文檔看到這裡,我覺得用IronPython,我們只要調.net就好了,不要去改寫它。。。這會給你帶來很多不必要的麻煩。。。盡可能用.net去寫代碼給python調,不要在python裡寫.net,太麻煩了,破規矩很多

.NET constructors can be overloaded. To call a specific base type constructor overload, you need to define a __new__ method (not __init__) and call __new__ on the .NET base type. The following example shows how a sub-type of System.Exception choses the base constructor overload to call based on the arguments it receives:

>>> import System
>>> class MyException(System.Exception):
...     def __new__(cls, *args):
...        # This could be implemented as:
...        #     return System.Exception.__new__(cls, *args)
...        # but is more verbose just to make a point
...        if len(args) == 0:
...            e = System.Exception.__new__(cls)
...        elif len(args) == 1:
...            message = args[0]
...            e = System.Exception.__new__(cls, message)
...        elif len(args) == 2:
...            message, inner_exception = args
...            if hasattr(inner_exception, "clsException"):
...               inner_exception = inner_exception.clsException
...            e = System.Exception.__new__(cls, message, inner_exception)
...        return e
>>> e = MyException("some message", IOError())

Accessing protected members of base types

推測:下面這段文檔寫的很矛盾,第一段給了一段代碼說IronPython中如果不在子類中直接調用Protected類型的方法會不讓訪問,但第二段內容中又指出說實際上在python中並沒有private protected等等這些概念的存在,並且方法是可以動態添加和刪除的,

的確,學過python都知道這個特點,但文檔之前的片段中有提到過ironPython中對於來源於.Net的類型是不允許動態修改方法和屬性的,這兩段豈不是矛盾了?到底哪種說法才是真的?

不過下面這2段代碼自己在ipy裡敲了試了一下,結論就是對於protected類型,確實不能直接調用,必須定義一個類繼承以後才能調用。下面文檔第一段中說“除非是一個private綁定”,意思難道是說只有protected不行,如果是private就可以訪問到了?有機會誰去試一下。

Normally, IronPython does not allow access to protected members (unless you are using private-binding). For example, accessing MemberwiseClone causes a TypeError since it is a protected method:

>>> import clr
>>> import System
>>> o = System.Object()
>>> o.MemberwiseClone()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot access protected member MemberwiseClone without a python subclass of object

IronPython does allow Python sub-types to access protected members of .NET base types. However, Python does not enforce any accessibility rules. Also, methods can be added and removed dynamically from a class. Hence, IronPython does not attempt to guard access to protected members of .NET sub-types. Instead, it always makes the protected members available just like public members:

>>> class MyClass(System.Object):
...     pass
>>> o = MyClass()
>>> o.MemberwiseClone() #doctest: +ELLIPSIS
<MyClass object at ...>

Declaring .NET types

Relationship of classes in Python code and normal .NET types

這段看不懂在說啥

A class definition in Python does not map directly to a unique .NET type. This is because the semantics of classes is different between Python and .NET. For example, in Python it is possible to change the base types just by assigning to the __bases__ attribute on the type object. However, the same is not possible with .NET types. Hence, IronPython implements Python classes without mapping them directly to .NET types. IronPython does use some .NET type for the objects, but its members do not match the Python attributes at all. Instead, the Python class is stored in a .NET field called .class, and Python instance attributes are stored in a dictionary that is stored in a .NET field called .dict [7]

>>> import clr
>>> class MyClass(object):
...     pass
>>> o = MyClass()
>>> o.GetType().FullName #doctest: +ELLIPSIS
'IronPython.NewTypes.System.Object_...'
>>> [field.Name for field in o.GetType().GetFields()]
['.class', '.dict', '.slots_and_weakref']
>>> o.GetType().GetField(".class").GetValue(o) == MyClass
True
>>> class MyClass2(MyClass):
...    pass
>>> o2 = MyClass2()
>>> o.GetType() == o2.GetType()
True

Also see Type-system unification (type and System.Type)

[7] These field names are implementation details, and could change.

__clrtype__

這段看不懂

It is sometimes required to have control over the .NET type generated for the Python class. This is because some .NET APIs expect the user to define a .NET type with certain attributes and members. For example, to define a pinvoke method, the user is required to define a .NET type with a .NET method marked withDllImportAttribute , and where the signature of the .NET method exactly describes the target platform method.

Starting with IronPython 2.6, IronPython supports a low-level hook which allows customization of the .NET type corresponding to a Python class. If the metaclass of a Python class has an attribute called __clrtype__, the attribute is called to generate a .NET type. This allows the user to control the the details of the generated .NET type. However, this is a low-level hook, and the user is expected to build on top of it.

The ClrType sample available in the IronPython website shows how to build on top of the __clrtype__ hook.

 

Accessing Python code from other .NET code

推測:這段大概是說ironPython中的代碼主要是由ipy動態解釋的,但是如果要從.net中運行ironpython代碼有別的方式

Statically-typed languages like C# and VB.Net can be compiled into an assembly that can then be used by other .NET code. However, IronPython code is executed dynamically using ipy.exe. If you want to run Python code from other .NET code, there are a number of ways of doing it.

Using the DLR Hosting APIs

推測:大概是說.net可以使用DLR Hosting Api來執行ironPython代碼

The DLR Hosting APIs allow a .NET application to embed DLR languages like IronPython and IronRuby, load and execute Python and Ruby code, and access objects created by the Python or Ruby code.

 

Compiling Python code into an assembly

看不懂

The pyc sample can be used to compile IronPython code into an assembly. The sample builds on top of clr-CompileModules. The assembly can then be loaded and executed using Python-ImportModule. However, note that the MSIL in the assembly is not CLS-compliant and cannot be directly accessed from other .NET languages.

dynamic

推測:因為有在.Net裡用過IronPython,這段可以這樣理解,就說在.Net裡執行IronPython代碼,假如返回值是一個ironpython對象,或者你要從.Net訪問一個ironPython對象,那你要用一個dynamic類型的變量來接收

Starting with .NET 4.0, C# and VB.Net support access to IronPython objects using the dynamic keyword. This enables cleaner access to IronPython objects. Note that you need to use the hosting-apis to load IronPython code and get the root object out of it.

Integration of Python and .NET features

下面這段大概是介紹 Python和.Net特征統一化在IronPython中的一些體現,比如支持python的doc功能讀.Net的API文檔,又或者讀不到就直接通過反射來讀取一些關於這個類的信息

  • Type system integration.

    • See "Type-system unification (type and System.Type)"
    • Also see extensions-to-python-types and extensions-to-dotnet-types
  • List comprehension works with any .NET type that implements IList

  • with works with with any System.Collections.IEnumerable or System.Collections.Generic.IEnumerable<T>

  • pickle and ISerializable

  • __doc__ on .NET types and members:

    • __doc__ uses XML comments if available. XML comment files are installed if TODO. As a result, help can be used:

      >>> help(System.Collections.BitArray.Set) #doctest: +NORMALIZE_WHITESPACE
      Help on method_descriptor:
      Set(...)
          Set(self, int index, bool value)
                          Sets the bit at a specific
           position in the System.Collections.BitArray to
           the specified value.
      <BLANKLINE>
          index:
                          The zero-based index of the
           bit to set.
      <BLANKLINE>
          value:
                          The Boolean value to assign
           to the bit.
      
    • If XML comment files are not available, IronPython generates documentation by reflecting on the type or member:

      >>> help(System.Collections.Generic.List.Enumerator.Current) #doctest: +NORMALIZE_WHITESPACE
      Help on getset descriptor System.Collections.Generic in mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.Enumerator.Current:
      <BLANKLINE>
      Current
          Get: T Current(self)
    • Extensions to Python types

      import clr exposes extra functionality on some Python types to make .NET features accessible:

      • method objects of any builtin or .NET types:
        • instance method
          • Overloads(t1 [, t2...])
      • type objects
        • instance method
          • __getitem__(t1 [, t2...]) - creates a generic instantiation

Extensions to .NET types

推測:這段大概是在介紹.Net被引入到ironPython後被擴展了一些方法,使其更加Python化

IronPython also adds extensions to .NET types to make them more Pythonic. The following instance methods are exposed on .NET objects (and .NET classes where explicitly mentioned):

  • Types with op_Implicit

    • TODO
  • Types with op_Explicit

    • TODO
  • Types inheriting from a .NET class or interface

    .NET base-type

    Synthesized Python method(s)

    System.Object

    all methods of object eg. __class__, __str__, __hash__, __setattr__

    System.IDisposable

    __enter__, __exit__

    System.Collections.IEnumerator

    next

    System.Collections.ICollection System.Collections.Generic.ICollection<T>

    __len__

    System.Collections.IEnumerable System.Collections.Generic.IEnumerable<T> System.Collections.IEnumerator System.Collections.Generic.IEnumerator<T>

    __iter__

    System.IFormattable

    __format__

    System.Collections.IDictionary System.Collections.Generic.IDictionary<TKey, TValue> System.Collections.Generic.ICollection<T> System.Collections.Generic.IList<T> System.Collections.IEnumerable System.Collections.Generic.IEnumerable<T> System.Collections.IEnumerator System.Collections.Generic.IEnumerator<T>

    __contains__

    System.Array

    • Class methods:
      • Indexing of the type object with a type object to access a specific array type
      • __new__(l) where l is IList<T> (or supports __getitem__?)
    • __getitem__, __setitem__, __slice__

    System.Delegate

    • Class method : __new__(type, function_or_bound_method)
    • __call__

    System.Enum

    __or__ TODO ?

  • Types with a .NET operator method name

    .NET operator method

    Synthesized Python method

    op_Addition, Add

    __add__

    Compare

    __cmp__

    get_<Name> [8]

    __getitem__

    set_<Name> [9]

    __setitem__

[8] where the type also has a property <Name>, and a DefaultMemberAttribute for <Name> [9] where the type also has a property <Name>, and a DefaultMemberAttribute for <Name>

Equality and hashing

TODO - This is currently just copied from IronRuby, and is known to be incorrect

Object equality and hashing are fundamental properties of objects. The Python API for comparing and hashing objects is __eq__ (and __ne__) and __hash__ respectively. The CLR APIs are System.Object.Equals and System.Object.GetHashCode respectively. IronPython does an automatic mapping between the two concepts so that Python objects can be compared and hashed from non-Python .NET code, and __eq__ and __hash__ are available in Python code for non-Python objects as well.

When Python code calls __eq__ and __hash__

  • If the object is a Python object, the default implementations of __eq__ and __hash__ get called. The default implementations call System.Object.ReferenceEquals and System.Runtime.CompileServices.RuntimeHelpers.GetHashCode respectively.
  • If the object is a CLR object, System.Object.Equals and System.Object.GetHashCode respectively get called on the .NET object.
  • If the object is a Python subclass object inheriting from a CLR class, the CLR's class's implementation of System.Object.Equals and System.Object.GetHashCode will get called if the Python subclass does not define __eq__ and __hash__. If the Python subclass defines __eq__ and __hash__, those will be called instead.

When static MSIL code calls System.Object.Equals and System.Object.GetHashCode

  • If the object is a Python objects, the Python object will direct the call to __eq__ and __hash__. If the Python object has implementations for these methods, they will be called. Otherwise, the default implementation mentioned above gets called.
  • If the object is a Python subclass object inheriting from a CLR class, the CLR's class's implementation of System.Object.Equals and System.Object.GetHashCode will get called if the Python subclass does not define __eq__ and __hash__. If the Python subclass defines __eq__ and __hash__, those will be called instead.

Hashing of mutable objects

The CLR expects that System.Object.GetHashCode always returns the same value for a given object. If this invariant is not maintained, using the object as a key in a System.Collections.Generic.Dictionary<K,V> will misbehave. Python allows __hash__ to return different results, and relies on the user to deal with the scenario of using the object as a key in a Hash. The mapping above between the Python and CLR concepts of equality and hashing means that CLR code that deals with Python objects has to be aware of the issue. If static MSIL code uses a Python object as a the key in a Dictionary<K,V>, unexpected behavior might happen.

To reduce the chances of this happenning when using common Python types, IronPython does not map __hash__ to GetHashCode for Array and Hash. For other Python classes, the user can provide separate implementations for __eq__ and Equals, and __hash__ and GetHashCode if the Python class is mutable but also needs to be usable as a key in a Dictionary<K,V>.

System.Object.ToString, __repr__ and __str__

ToString on Python objects

如果對一個Python對象使用 ToString,即便按照 Python的玩法,你重寫了__str__方法,你調用ToString解釋器還是會去調用.Net裡的那個toString方法,並不會調用你定義的這個__str__方法,推測:也就是說只要一個類是繼承自.Net的,那他的規則就是按照

.Net的來,如果是純Python的就按照python的規則來?

Calling ToString on Python objects calls the default System.Object.ToString implementation, even if the Python type defines __str__:

>>> class MyClass(object):
...     def __str__(self):
...         return "__str__ result"
>>> o = MyClass()
>>> # Use Reflection to simulate a call from another .NET language
>>> o.GetType().GetMethod("ToString").Invoke(o, None) #doctest: +ELLIPSIS
'IronPython.NewTypes.System.Object_...'

__repr__/__str__ on .NET objects

所有Python對象都自帶__repr__和__str__方法

All Python user types have __repr__ and __str__:

>>> class MyClass(object):
...     pass
>>> o = MyClass()
>>> o.__repr__() #doctest: +ELLIPSIS
'<MyClass object at ...>'
>>> o.__str__() #doctest: +ELLIPSIS
'IronPython.NewTypes.System.Object_...'
>>> str(o) #doctest: +ELLIPSIS
'<MyClass object at ...>'

For .NET types which do not override ToString, IronPython provides __repr__ and __str__ methods which behave similar to those of Python user types [10]:

推測:不重寫.Net對象的 ToString方法的對象,它讓你可以把它當成Python對象來處理,如果你想改寫Tostring就重寫它的__repr__和_-str__方法就好了?

>>> from System.Collections import BitArray
>>> ba = BitArray(5)
>>> ba.ToString() # BitArray inherts System.Object.ToString()
'System.Collections.BitArray'
>>> ba.__repr__() #doctest: +ELLIPSIS
'<System.Collections.BitArray object at ... [System.Collections.BitArray]>'
>>> ba.__str__() #doctest: +ELLIPSIS
'<System.Collections.BitArray object at ... [System.Collections.BitArray]>'

For .NET types which do override ToString, IronPython includes the result of ToString in __repr__, and maps ToString directly to __str__:

推測:如果ToString得不到你想要的結果,那麼結果可能包含在__repr__和__str__ 方法裡頭?

>>> e = System.Exception()
>>> e.ToString()
"System.Exception: Exception of type 'System.Exception' was thrown."
>>> e.__repr__() #doctest: +ELLIPSIS
"<System.Exception object at ... [System.Exception: Exception of type 'System.Exception' was thrown.]>"
>>> e.__str__() #doctest:
"System.Exception: Exception of type 'System.Exception' was thrown."

For Python types that override ToString, __str__ is mapped to the ToString override:

對於一個重寫了ToString方法的Python對象,調用__str__方法將會直接映射到ToString方法的結果,好亂。。。

>>> class MyClass(object):
...     def ToString(self):
...         return "ToString implemented in Python"
>>> o = MyClass()
>>> o.__repr__() #doctest: +ELLIPSIS
'<MyClass object at ...>'
>>> o.__str__()
'ToString implemented in Python'
>>> str(o) #doctest: +ELLIPSIS
'<MyClass object at ...>'

它又說這看起來有點矛盾,好像在下面這個地址可以得到答案?
There is some inconsistency in handling of __str__ that is tracked by http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24973

OleAutomation and COM interop

這段感覺對平時工作沒什麼用,就不去理解了,關於COM對象使用的

IronPython supports accessing OleAutomation objects (COM objects which support dispinterfaces).

IronPython does not support the win32ole library, but Python code using win32ole can run on IronPython with just a few modifications.

Creating a COM object

如何使用COM對象

Different languages have different ways to create a COM object. VBScript and VBA have a method called CreateObject to create an OleAut object. JScript has a method called TODO. There are multiple ways of doing the same in IronPython.

  1. The first approach is to use System.Type.GetTypeFromProgID and System.Activator.CreateInstance . This method works with any registered COM object:

    >>> import System
    >>> t = System.Type.GetTypeFromProgID("Excel.Application")
    >>> excel = System.Activator.CreateInstance(t)
    >>> wb = excel.Workbooks.Add()
    >>> excel.Quit()
    
  2. The second approach is to use clr.AddReferenceToTypeLibrary to load the type library (if it is available) of the COM object. The advantage is that you can use the type library to access other named values like constants:

    >>> import System
    >>> excelTypeLibGuid = System.Guid("00020813-0000-0000-C000-000000000046")
    >>> import clr
    >>> clr.AddReferenceToTypeLibrary(excelTypeLibGuid)
    >>> from Excel import Application
    >>> excel = Application()
    >>> wb = excel.Workbooks.Add()
    >>> excel.Quit()
    
  3. Finally, you can also use the interop assembly. This can be generated using the tlbimp.exe tool. The only advantage of this approach was that this was the approach recommeded for IronPython 1. If you have code using this approach that you developed for IronPython 1, it will continue to work:

    >>> import clr
    >>> clr.AddReference("Microsoft.Office.Interop.Excel")
    >>> from Microsoft.Office.Interop.Excel import ApplicationClass
    >>> excel = ApplicationClass()
    >>> wb = excel.Workbooks.Add()
    >>> excel.Quit()

Using COM objects

One you have access to a COM object, it can be used like any other objects. Properties, methods, default indexers and events all work as expected.

Properties

There is one important detail worth pointing out. IronPython tries to use the type library of the OleAut object if it can be found, in order to do name resolution while accessing methods or properties. The reason for this is that the IDispatch interface does not make much of a distinction between properties and method calls. This is because of Visual Basic 6 semantics where "excel.Quit" and "excel.Quit()" have the exact same semantics. However, IronPython has a strong distinction between properties and methods, and methods are first class objects. For IronPython to know whether "excel.Quit" should invoke the method Quit, or just return a callable object, it needs to inspect the typelib. If a typelib is not available, IronPython assumes that it is a method. So if a OleAut object has a property called "prop" but it has no typelib, you would need to write "p = obj.prop()" in IronPython to read the property value.

Methods with out parameters

Calling a method with "out" (or in-out) parameters requires explicitly passing in an instance of "clr.Reference", if you want to get the updated value from the method call. Note that COM methods with out parameters are not considered Automation-friendly [11]. JScript does not support out parameters at all. If you do run into a COM component which has out parameters, having to use "clr.Reference" is a reasonable workaround:

>>> import clr
>>> from System import Type, Activator
>>> command_type = Type.GetTypeFromProgID("ADODB.Command")
>>> command = Activator.CreateInstance(command_type)
>>> records_affected = clr.Reference[int]()
>>> command.Execute(records_affected, None, None) #doctest: +SKIP
>>> records_affected.Value
0

Another workaround is to leverage the inteorp assembly by using the unbound class instance method syntax of "outParamAsReturnValue = InteropAssemblyNamespace.IComInterface(comObject)".

[11] Note that the Office APIs in particular do have "VARIANT*" parameters, but these methods do not update the value of the VARIANT. The only reason they were defined with "VARIANT*" parameters was for performance since passing a pointer to a VARIANT is faster than pushing all the 4 DWORDs of the VARIANT onto the stack. So you can just treat such parameters as "in" parameters.

Accessing the type library

The type library has names of constants. You can use clr.AddReferenceToTypeLibrary to load the type library.

Non-automation COM objects

IronPython does not fully support COM objects which do not support dispinterfaces since they appear likey proxy objects [12]. You can use the unbound class method syntax to access them.

[12] This was supported in IronPython 1, but the support was dropped in version 2.

 

再往後幾條內容不怎麼重要了就不抄進來了,本篇筆記到此結束

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved