<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 21 January 2016 at 05:44, David Narvaez <span dir="ltr"><<a href="mailto:david.narvaez@computer.org" target="_blank">david.narvaez@computer.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I was very excited to see there was a Python console docker in Sheets, only to find that it does not work. I tried to get it back in shape and I have a couple of patches, plus a couple of roadblocks that I would like to discuss in this list. For patches, is Review Board still the way to go as described in [0]? Also, is anybody else working on Python scripting in Sheets right now?</div></div></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​Short answer, not many commits for that, even dedicated maintainer probably welcome, no special interest resulting in real coding, and especially, organized design. <br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Longer answer require showing more context.<br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​I can first mention atmosphere around Python and scripting in general closer to the Kexi circles.​</div> <div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​But I believe since the intent is to have consistent scripting in the future, it somehow helps to see some relation to Sheets, being in the same class of apps.<br>​</div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​As some people may know I like Python for its purposes. KDE even started (in Calligra) projects such as Kross to support more languages honestly. This support was were means for not too deep bindings, not language-specific, rather calling methods of objects without much regard to integration with data types or language specifics.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">As a part of general 'cleanup' Kexi 3 removes Kross usage and moves towards a single language-solution that happens to be JavaScript, using QtQml. The main reason is that sandbox works there and not in Python.[1] By default QtQml gives no tiny chance to access filesystem for example or run unwanted scripts.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">There are no declared lovers of JavaScript among us, C++ hackers I think. But the specifics of JavaScript is less of a problem than inherent insecurity of Python's execution environment. Insecurity would manifest once apps that use scripts get popular. The result I'd expect is very much like perfect cross-platforms viruses.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">This is possible if scripts are accessible with documents, which is assumption of Kexi (files are meant to be user-defined apps) and in the future, I believe, also Sheet's documents, if we want competitiveness.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br>For that matter, also ruby and bash and perl, would be all better rejected for the same reason.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Sure, there were ideas of digital signing of scripts but 1. Even tech people do not use that (and even for emails) in general, 2. Except for Krita "official" builds we're not controlling the deployment process, distros do that, and I imagine all sort of critical issues can sooner happen e.g. because of mixes responsibility. It seems that distros are able to act more "reactionary", not as  "owners" of the software as a product. Which does not surprise me and there's nothing to criticize.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">For Kexi <=2 (no matter what language is picked) scripting is marked as having experimental status. I am not sure whether this is the case for Sheets too but for Kexi there's because of such honest status we can assume there's no disservice to users. With Kexi 3 we have ability to start fresh and with knowledge/experience gathered in the past. Also about knowledge about the user base.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">For some other contexts the choice scripting can depend on external requirements. Like "industry" standards -- for Krita Python is perceived as some kind of standard for extending graphical features. Similar opinion applies for Krita itself - generic calligra-wide scripting never have been too actively maintained and was Kross is too simple, see [2]. For the record, Krita has a proof-of-concept implementation of scripting in a separate repo.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br>[1] Google for "Python sandbox" for detailed discussion from Python hackers on why this is not possible and dropped idea.<br>[2] <a href="https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html">https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html</a><br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks.</div><div><br></div><div>David E. Narvaez</div><div><br></div><div>[0] <a href="https://community.kde.org/Calligra/Contributing_a_Patch" target="_blank">https://community.kde.org/Calligra/Contributing_a_Patch</a></div></div>
<br>_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>