Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #90044 > unrolled thread

Re: Encrypt python files

Started byAlbert-Jan Roskam <fomcl@yahoo.com>
First post2015-05-06 02:45 -0700
Last post2015-05-06 21:50 +1000
Articles 2 — 2 participants

Back to article view | Back to comp.lang.python


Contents

  Re: Encrypt python files Albert-Jan Roskam <fomcl@yahoo.com> - 2015-05-06 02:45 -0700
    Re: Encrypt python files Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-06 21:50 +1000

#90044 — Re: Encrypt python files

FromAlbert-Jan Roskam <fomcl@yahoo.com>
Date2015-05-06 02:45 -0700
SubjectRe: Encrypt python files
Message-ID<mailman.166.1430905888.12865.python-list@python.org>
-----------------------------
On Wed, May 6, 2015 11:04 AM CEST Steven D'Aprano wrote:

>On Wednesday 06 May 2015 17:23, Palpandi wrote:
>
>> On Wednesday, May 6, 2015 at 12:07:13 PM UTC+5:30, Palpandi wrote:
>> Hi,
>> 
>> What are the ways to encrypt python files?
>> 
>> No, I just want to hide the scripts from others.
>
>Why, are you ashamed of your code?
>
>Python is free, open source software. Hiding the code from others is not a 
>priority for the developers of the language. Besides, you can't hide the 
>code unless you only operate the application via a web service, or similar. 
>As soon as you give people a copy of the code, whether it is binary code or 
>source code, they have a copy of it and can look at it and work out how what 
>it does.
>
>If "hiding the code" was good for security, why are there so many viruses 
>and spybots and worms and other malware for Windows?
>
>No, as far as I am concerned, trying to hide the code is a waste of time 
>with Python. But if you absolutely must, you can distribute the .pyc files 
>instead of the .py files, and that will discourage casual tinkerers from 
>poking around in the program. The .pyc file is compiled to byte-code rather 
>than source code, so it's not readable without running it through a 
>decompiler.

I used the marshal module before as a faster alternative to shelve (I marshalled a huge dictionary). I always understood marshal files require the *exact* same interpreter version (incl. built number). Do the same limitations apply for .pyc files? Isn't it the same format?

We have a VCS with an option to use private repos. I am always wary of users who want to use this feature. Why would you not want to share your code with your colleagues? Embarrassed about unreadable crappy code, perhaps?  

[toc] | [next] | [standalone]


#90047

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2015-05-06 21:50 +1000
Message-ID<5549fffb$0$12983$c3e8da3$5496439d@news.astraweb.com>
In reply to#90044
On Wed, 6 May 2015 07:45 pm, Albert-Jan Roskam wrote:

> I used the marshal module before as a faster alternative to shelve (I
> marshalled a huge dictionary). I always understood marshal files require
> the *exact* same interpreter version (incl. built number). Do the same
> limitations apply for .pyc files? Isn't it the same format?

marshal is currently up to version 4 of the (otherwise undocumented) file
format. Obviously that's much less than the number of minor versions of
Python, so, no, marshal does not change every release.

https://docs.python.org/3/library/marshal.html

.pyc files, on the other hand, have a magic number which changes for each
minor release of Python. I think that, in principle, it could change in a
point release (say, between 3.4.1 and 3.4.2) but in practice I don't
believe that has ever happened. I think it is safe to assume that pyc files
will be portable across any minor release (e.g. 3.4.x for any x) but not
across changes to the minor or major release.

I don't think that is an outright promise, but it is a strong convention.

And of course, other implementations may not even use .pyc files, if they
don't use the same sort of byte code. E.g. Jython compiles to JVM byte
code:

foo.py
foo$py.class


Nick Coghlan has a very good blog post about the uses of pyc only
distributed software:

http://www.curiousefficiency.org/posts/2011/04/benefits-and-limitations-of-pyc-only.html

And Ned Batchelder has a good discussion of their internals:

http://nedbatchelder.com/blog/200804/the_structure_of_pyc_files.html



-- 
Steven

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web