[Ironpython-users] PythonTuple.MakeTuple

[Slide]

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.schaber at 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.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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20150825/6cf500f6/attachment.html>