[Ironpython-users] PythonTuple.MakeTuple

[Markus Schaber]

Hi,

Von: Slide

> Can anyone tell me why this method is internal?!

My educated guess is that it uses the items array by value without copying it, while all public ways to construct the tuple actually copy the sequence you pass. Making that method public would allow users to create a tuple which may be modified by keeping a reference to the array. Making such an API public is rather risky. 

But you can have almost the same effect by using the public PythonTuple constructors directly.

Only the EMPTY optimization will not work, which may or may not be what you want.

PS: Note that IronPython standard library itself can still access said method, as the [InternalsVisibleTo]-Attribute on IronPython allows access to internal methods from the IronPython.Modules and IronPythonTest assemblies.

PS 2: I'm not sure whether the MakeItems() method internally used works correctly when we pass strings which contain non-BMP characters. It seems to assume a character is a single 16-bit unit. We should investigate that, and compare it to Python 2 and 3 behavior with Unicode strings containing non-BMP characters. I'm not mandating for a quick change here, but especially when Python 3.x is targeted with IronPython, we should use the most sensible behavior and (possibly) document it as one of the differences in string handling. (Another one is indexing [] into strings which contain non-BMP characters.)

PS 3: It might be an optimization to add a check o for being a ICollection, and directly allocate an array of the right size and using CopyTo. For large collections, this will be more efficient than the List<Object> constantly reallocating. On the other hand, the assumption may be that it's mostly used for small lists, and the additional type check / dynamic cast makes up for the difference. (However, we might replace bot the "is List" and "o as object[]" branches with the ICollection branch, as both implement ICollection, effectively saving one dynamic cast...)

Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH 

Inspiring Automation Solutions 
________________________________________
3S-Smart Software Solutions GmbH 
Dipl.-Inf. Markus Schaber | Product Development Core Technology 
Memminger Str. 151 | 87439 Kempten | Germany 
Tel. +49-831-54031-979 | Fax +49-831-54031-50 

E-Mail: m.schaber at codesys.com | Web: codesys.com | CODESYS store: store.codesys.com 
CODESYS forum: forum.codesys.com 

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 
________________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received 
this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure 
or distribution of the material in this e-mail is strictly forbidden.