Re: Obscuring Python source from end users

2014-10-02 Thread Chris Angelico
On Thu, Oct 2, 2014 at 5:50 PM, Johannes Bauer wrote: > On 29.09.2014 16:53, Sturla Molden wrote: >> Chris Angelico wrote: >> I have a project that involves distributing Python code to users in an organisation. Users do not interact directly with the Python code; they only know thi

Re: Obscuring Python source from end users

2014-10-02 Thread Johannes Bauer
On 29.09.2014 16:53, Sturla Molden wrote: > Chris Angelico wrote: > >>> I have a project that involves distributing Python code to users in an >>> organisation. Users do not interact directly with the Python code; they >>> only know this project as an Excel add-in. >>> >>> Now, internal audit tak

Re: Obscuring Python source from end users

2014-10-02 Thread Steven D'Aprano
Marko Rauhamaa wrote: > Dan Stromberg : > >> On Mon, Sep 29, 2014 at 4:47 AM, Steven D'Aprano >>> Yes. Distribute the pyc files only. >> >> Yes, this is the way it's usually done. > > Has the .pyc file format stabilized? A decade ago, my employer shipped > an application as .pyc files but had to

Re: Obscuring Python source from end users

2014-10-02 Thread Terry Reedy
On 10/2/2014 1:17 AM, Marko Rauhamaa wrote: Dan Stromberg : On Mon, Sep 29, 2014 at 4:47 AM, Steven D'Aprano Yes. Distribute the pyc files only. Yes, this is the way it's usually done. Has the .pyc file format stabilized? No. The cache files are binary specific and are so labelled. x.py

Re: Obscuring Python source from end users

2014-10-01 Thread Marko Rauhamaa
Dan Stromberg : > On Mon, Sep 29, 2014 at 4:47 AM, Steven D'Aprano >> Yes. Distribute the pyc files only. > > Yes, this is the way it's usually done. Has the .pyc file format stabilized? A decade ago, my employer shipped an application as .pyc files but had to ship the matching CPython binary wit

Re: Obscuring Python source from end users

2014-10-01 Thread Dan Stromberg
On Mon, Sep 29, 2014 at 4:47 AM, Steven D'Aprano wrote: > norman.i...@gmail.com wrote: > >> Hello list >> >> Python 3.4 applies. >> >> I have a project that involves distributing Python code to users in an >> organisation. Users do not interact directly with the Python code; they >> only know this

Re: Obscuring Python source from end users

2014-09-29 Thread Sturla Molden
Chris Angelico wrote: >> I have a project that involves distributing Python code to users in an >> organisation. Users do not interact directly with the Python code; they >> only know this project as an Excel add-in. >> >> Now, internal audit takes exception in some cases if users are able to >>

Re: Obscuring Python source from end users

2014-09-29 Thread Sturla Molden
Steven D'Aprano wrote: > Another possibility is to distribute your modules inside a zip file. See > here: > > https://mail.python.org/pipermail/python-list/2014-July/675506.html > > Such zip files are not just runnable, but also importable. Depending on your > Excel requirements, you might need

Re: Obscuring Python source from end users

2014-09-29 Thread Steven D'Aprano
norman.i...@gmail.com wrote: > Hello list > > Python 3.4 applies. > > I have a project that involves distributing Python code to users in an > organisation. Users do not interact directly with the Python code; they > only know this project as an Excel add-in. > > Now, internal audit takes excep

Re: Obscuring Python source from end users

2014-09-29 Thread Chris Angelico
On Mon, Sep 29, 2014 at 6:55 PM, Chris Angelico wrote: > It ought to be possible to do an AST reconstitution for at least part > of this. I can hunt down some of my PEP 463 test code to help out with > that. It should be possible to figure out what names are local, and > then just use those. > > I

Re: Obscuring Python source from end users

2014-09-29 Thread Chris Angelico
On Mon, Sep 29, 2014 at 6:41 PM, wrote: > Crunching the source is an interesting idea that could achieve that end, but > it seems fraught with problems like maintaining consistency between renaming > objects in a module and renaming where imports happen. > Here's a technique that you could use

Re: Obscuring Python source from end users

2014-09-29 Thread alister
On Mon, 29 Sep 2014 00:36:47 -0700, norman.ives wrote: > Hello list > > Python 3.4 applies. > > I have a project that involves distributing Python code to users in an > organisation. Users do not interact directly with the Python code; they > only know this project as an Excel add-in. > > Now,

Re: Obscuring Python source from end users

2014-09-29 Thread norman . ives
Thanks for the reply! I'm not concerned about hiding the source code in a fundamental way. The condition that needs to be satisfied is that independent validators (in the organisation) must not "have access" to the source code. Crunching the source is an interesting idea that could achieve that

Re: Obscuring Python source from end users

2014-09-29 Thread Chris Angelico
On Mon, Sep 29, 2014 at 5:36 PM, wrote: > I have a project that involves distributing Python code to users in an > organisation. Users do not interact directly with the Python code; they only > know this project as an Excel add-in. > > Now, internal audit takes exception in some cases if users

Obscuring Python source from end users

2014-09-29 Thread norman . ives
Hello list Python 3.4 applies. I have a project that involves distributing Python code to users in an organisation. Users do not interact directly with the Python code; they only know this project as an Excel add-in. Now, internal audit takes exception in some cases if users are able to see th