On Thu, Jan 21, 2016 at 3:59 AM, Jaroslaw Staniek <stan...@kde.org> wrote: > Short answer, not many commits for that, even dedicated maintainer probably > welcome, no special interest resulting in real coding, and especially, > organized design. > > Longer answer require showing more context. > > I can first mention atmosphere around Python and scripting in general closer > to the Kexi circles. > > 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. > > 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. > > 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. > > 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. > 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. > > For that matter, also ruby and bash and perl, would be all better rejected > for the same reason. > 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. > > 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. > > 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. > > [1] Google for "Python sandbox" for detailed discussion from Python hackers > on why this is not possible and dropped idea. > [2] https://mail.kde.org/pipermail/kimageshop/2014-June/012331.html
Ditching Python because of sandboxing issues makes sense. That being said, I would use Python to access the file system from my spreadsheets all the time. I don't really remember what made me to look into scripting support in Sheets but I vaguely remember something merging several CSVs into a single spreadsheet. In any case, if the current plan is to remove Python support, I guess I am better off working on removing that instead of fixing it, correct? David E. Narvaez _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
