A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-November/049994.html below:

[Python-Dev] __pycode__ extension

[Python-Dev] __pycode__ extensionSamuele Pedroni pedronis at bluewin.ch
Thu Nov 18 00:44:56 CET 2004
Barry Warsaw wrote:

> On Wed, 2004-11-17 at 14:37, Samuele Pedroni wrote:
> 
> 
>>But I think we should rember that some people today rely on the fact 
>>that shipping only pycs files means not shipping directly the source.
> 
> 
> Absolutely. 

yes but further thinking I can imagine the following tension

- people will still want a way to ship without shipping the source, or 
such that reconstructing the source is not too easy, with varying 
degrees of what is considered enough "secure"

- although this can already be done partly today, this feature will make 
more tempting (especially in combination with features that can be 
expected from/constructed on top of the ast-branch or with the compiler 
package) to write e.g decorators that operate on functions by playing 
with their source. But then these tools will only work if the source or 
asts are there at runtime in some form [bytecode manipulation can be 
used similary but is less portable across python implementation, and 
seemingly harder than ast manipulations]

> If this is added (and in general it sounds like a decent,
> though PEP-worthy idea), there must be a way to turn it off.  I'm not
> sure a build-time configuration option is enough, but a command line
> option might be.
> 

and/or some setting changeable through a sys method

As I implicitly said I can see (at least these) three levels for the feature

1) disabled
2) store only the sources that cannot be recovered accessing .py files,
i.e. make inspect.getsource always work up to editing of the .py files
3) make things robust wrt .py files editing and other corner cases, i.e. 
likely store everything

to some extent 3 can be implemented without storing things in pyc files, 
as long as there are .py files around by an approach reading both in 
parallel

OTOH to have the tools described above work in a pyc-only scenario, 
source or asts would need to be stored in the pycs themself, opening the 
question about the resulting sufficient obfuscation/expressivity tradeoff
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4