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.scha...@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. _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
