Hi Markus, Thank you for your excellent reply to my question. I was able to just use the constructor, for some reason I thought it wasn't working, when in reality it was working and I was just adding the incorrect items to the tuple. I appreciate your response!
Regards. Slide On Mon, Aug 24, 2015 at 1:27 AM Markus Schaber <m.scha...@codesys.com> wrote: > 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