[Sheets] Python Console Docker

[David Narvaez]

On Thu, Jan 21, 2016 at 3:59 AM, Jaroslaw Staniek <staniek at 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